October 3, 2016

Notes on the transition to the cloud

1. The cloud is super-hot. Duh. And so, like any hot buzzword, “cloud” means different things to different marketers. Four of the biggest things that have been called “cloud” are:

Further, there’s always the idea of hybrid cloud, in which a vendor peddles private cloud systems (usually appliances) running similar technology stacks to what they run in their proprietary public clouds. A number of vendors have backed away from such stories, but a few are still pushing it, including Oracle and Microsoft.

This is a good example of Monash’s Laws of Commercial Semantics.

2. Due to economies of scale, only a few companies should operate their own data centers, aka true on-prem(ises). The rest should use some combination of colo, SaaS, and public cloud.

This fact now seems to be widely understood.

3. The public cloud is a natural fit for those use cases in which elasticity truly matters. Many websites and other consumer internet backends have that characteristic. Such systems are often also a good fit for cloud technologies in general.

This is frequently a good reason for new — i.e. “greenfield” — apps to run in the cloud.

4. Security and privacy can be concerns in moving to the cloud. But I’m hearing that more and more industries are overcoming those concerns.

In connection to that point, it might be interesting to note:

5. Obviously, Amazon is the gorilla in the cloud business. Microsoft Azure gets favorable mentions as well. I don’t hear much about other public cloud providers, however, except that there are a lot of plans to support Google’s cloud just in case.

In particular, I hear less than I expected to about public clouds run by national-champion telecom companies around the world.

6. It’s inconvenient for an application vendor to offer both traditional and SaaS versions of a product. Release cycles and platform support are different in the two cases. But there’s no reason a large traditional application vendor couldn’t pull it off, and the largest are already more or less claiming to. Soon, this will feel like a market necessity across the board.

7. The converse is less universally true. However, some SaaS vendors do lose out from their lack of on-premises options. Key considerations include:

If both those things are true, and you don’t have an on-premises option, certain enterprises are excluded from your addressable market.

8. Line-of-business departments are commonly more cloud-friendly than central IT is. Reasons include:

I discussed some of this in my recent post on vendor lock-in.

9. When the public cloud was younger, it had various technological limitations. You couldn’t easily get fast storage like flash. You couldn’t control data movement well enough for good MPP (Massively Parallel Processing) in use cases like analytic SQL.

Those concerns seem to have been largely alleviated.

10. It takes a long time for legacy platforms to be decommissioned. At some enterprises, however, that work has indeed been going on for a long time, via virtualization.

11. If you think about system requirements:

I argued the latter point in my 2013 post on appliances, clusters, and clouds, using terminology and reasoning that are now only slightly obsolete.

So what will those clusters be? Some will be determined by app choices. Most obviously, if you use SaaS, the SaaS vendor decides which cloud(s) your data is in. And if you’re re-hosting legacy systems via virtualization, that’s another cluster.

Otherwise, clusters will probably be organized by database, in the most expansive sense of term. For example, there could be separate clusters for:

Indeed, since computing is rarely as consolidated as CIOs dream of it being, a large enterprise might have several clusters for any of those categories — each running different software for data and storage management — with different deployment choices among colo, true on-prem, and true cloud.


5 Responses to “Notes on the transition to the cloud”

  1. Ron Dunn on October 7th, 2016 7:35 am

    A factor I find affects many cloud data warehouse plans is the cost and duration of data movement. If you have an on-premise application, a SAAS application on AWS, and a data warehouse on Azure, you’re going to be paying a high cost for data movement between those locations.
    I don’t see this as the fault of cloud, more an argument for getting rid of on-prem completely, and concentrating cloud resources into the same data center where possible.

  2. Curt Monash on October 8th, 2016 10:02 pm


    That’s the kind of ideal that’s hard to pull off …

    … but it could also create a demand for SaaS vendors to run in LOT of different cloud data centers.

  3. Paul Johnson on November 4th, 2016 8:45 am

    We had a client last week that found it was quicker to move data from the EDW to AWS than it was to ship the same data around the corporate network.

    The cost of shipping data to/from the public cloud is typically dwarfed by the cost of CPU, RAM & software subscriptions.

    I don’t see data movement practicalities and/or data movement costs affecting most folks to the point that public cloud is off-limits.

  4. Jessica on December 29th, 2016 3:45 pm

    In addition to SaaS, organizations are moving to the cloud for Platform as a Service (PaaS) with secure, online databases to streamline the development and delivery process for agile applications. Limited developer resources and growing demand for applications are leading organizations to view PaaS as an attractive alternative to traditional development methods.

  5. More notes on the transition to the cloud | DBMS 2 : DataBase Management System Services on August 17th, 2017 5:11 am

    […] year I posted observations about the transition to the cloud. Here are some further […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.