December 7, 2015

Transitioning to the cloud(s)

There’s a lot of talk these days about transitioning to the cloud, by IT customers and vendors alike. Of course, I have thoughts on the subject, some of which are below.

1. The economies of scale of not running your own data centers are real. That’s the kind of non-core activity almost all enterprises should outsource. Of course, those considerations taken alone argue equally for true cloud, co-location or SaaS (Software as a Service).

2. When the (Amazon) cloud was newer, I used to hear that certain kinds of workloads didn’t map well to the architecture Amazon had chosen. In particular, shared-nothing analytic query processing was necessarily inefficient. But I’m not hearing nearly as much about that any more.

3. Notwithstanding the foregoing, not everybody loves Amazon pricing.

4. Infrastructure vendors such as Oracle would like to also offer their infrastructure to you in the cloud. As per the above, that could work. However:

Actually, if we replace “Oracle” by “Microsoft”, the whole idea sounds better. While Microsoft doesn’t have a proprietary server hardware story like Oracle’s, many folks are content in the Microsoft walled garden. IBM has fiercely loyal customers as well, and so may a couple of Japanese computer manufacturers.

5. Even when running stuff in the cloud is otherwise a bad idea, there’s still:

So in many software categories, almost every vendor should have a cloud option of some kind.

6. Reasons for your data to wind up in a plurality of remote data centers include:

7. “Mostly compatible” is by no means the same as “compatible”, and confusing the two leads to tears. Even so, “mostly compatible” has stood the IT industry in good stead multiple times. My favorite examples are:

I raise this point for two reasons:

8. SaaS vendors, in many cases, will need to deploy in many different clouds. Reasons include:

That said, there are of course significant differences between, for example:

9. The previous point, and the last bullet of the one before that, are why I wrote in a post about enterprise app history:

There’s a huge difference between designing applications to run on one particular technology stack, vs. needing them to be portable across several. As a general rule, offering an application across several different brands of almost-compatible technology — e.g. market-leading RDBMS or (before the Linux era) proprietary UNIX boxes — commonly works out well. The application vendor just has to confine itself to relying on the intersection of the various brands’ feature sets.*

*The usual term for that is the spectacularly incorrect phrase “lowest common denominator”.

Offering the “same” apps over fundamentally different platform technologies is much harder, and I struggle to think of any cases of great success.

10. Decisions on where to process and store data are of course strongly influenced by where and how the data originates. In broadest terms:

Related link


6 Responses to “Transitioning to the cloud(s)”

  1. clive boulton on December 7th, 2015 11:57 pm

    Offering the “same” apps over fundamentally different platform technologies is much harder, and I struggle to think of any cases of great success.

    Canonical development of nextgen business client apps that run on phone, tablet, desktop or in the cloud by way seems imminent (within 3 years). Clear out that foul Nodejs tripe with Golang.

    Happy to chat more, see seven5.

  2. Curt Monash on December 8th, 2015 3:25 am


    Are you suggesting that some new language+runtime/framework will allow develop-once/run-many-places?

    I’ve been hearing that since 1981. Not coincidentally, I first became an analyst in 1981. I’m still waiting for it to be true.

  3. clive boulton on December 8th, 2015 6:16 am


    Canonical clients and back-ends have always won out. Because enterprise start-ups can scale client and server back-ends with the same dev team. (Windows on PC, Windows on Server).

    Node.js is currently the canonical king on browser and cloud database (mongodb).

    Spark written in Scala is hotter today than Hadoop in Java. Scala extends Java for concurrency on multicore.

    I am pretty sure Go (golang) will become more widespread for canonical development (it’s easier to learn than Scala).

    Quick but effective overview.

    Seven5 is not mine (link above) but see (written in Go).

    Moore’s law and multicore changes everything!

    The “Go”pher is pleased to meet you.

  4. Ranko Mosic on December 11th, 2015 11:17 am

    Perhaps two points need to be emphasized more clearly ( enterprise IT technical point of view ):
    – major cloud attraction: immediate provision time
    – major cloud drawback: data transfer speeds ( between cloud and on-premise )

  5. clive boulton on December 11th, 2015 4:27 pm

    On Ranko’s two points.

    -Big Data: Take the app to the data.
    -Small Data: Take the data to the app.

    Case in point, app stores deliver apps from the cloud to install on the smartphone for the best user experience with data on phone or in cloud.

  6. Oracle as the new IBM — has a long decline started? | DBMS 2 : DataBase Management System Services on January 2nd, 2016 6:20 am

    […] is my 2012 overview of Oracle’s evolution. Other posts to call out are my recent piece on transitioning to the cloud, and my series on enterprise application […]

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.