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:
- Is all your computing on Oracle’s infrastructure? Probably not.
- Do you want to move the Oracle part and the non-Oracle part to different clouds? Ideally, no.
- Do you like the idea of being even more locked in to Oracle than you are now? [Insert BDSM joke here.]
- Will Oracle do so much better of a job hosting its own infrastructure that you use its cloud anyway? Well, that’s an interesting question.
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:
- Test and dev(elopment) — usually phrased that way, although the opposite order makes more sense.
- Short-term projects — the most obvious examples are in investigative analytics.
- Disaster recovery.
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:
- High availability, and similarly disaster recovery. Duh.
- Second-source/avoidance of lock-in.
- Geo-compliance.
- Particular SaaS offerings being hosted in different places.
- Use of both true cloud and co-location for different parts of your business.
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:
- SQL
- UNIX (before LINUX).
- IBM-compatible PCs (or, as Ben Rosen used to joke, Compaq-compatible).
- Many cases in which vendors upgrade their own products.
I raise this point for two reasons:
- I think Amazon/OpenStack could be another important example.
- A vendor offering both cloud and on-premises versions of their offering, with minor incompatibilities between the two, isn’t automatically crazy.
8. SaaS vendors, in many cases, will need to deploy in many different clouds. Reasons include:
- If they want customers around the world, they may need to process data in customers’ home country or region.
- It could be the simplest way to meet the need of offering customers an on-premises option.
That said, there are of course significant differences between, for example:
- Deploying to Amazon in multiple regions around the world.
- Deploying to Amazon plus a variety of OpenStack-based cloud providers around the world, e.g. some “national champions” (perhaps subsidiaries of the main telecommunications firms).*
- Deploying to Amazon, to other OpenStack-based cloud providers, and also to an OpenStack-based system that resides on customer premises (or in their co-location facility).
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:
- Traditional business transaction data at large enterprises is typically managed by on-premises legacy systems. So legacy issues arise in full force.
- Internet interaction data — e.g. web site clicks — typically originates in systems that are hosted remotely. (Few enterprises run their websites on premises.) It is tempting to manage and analyze that data where it originates. That said:
- You often want to enhance that data with what you know from your business records …
- … which is information that you may or may not be willing to send off-premises.
- “Phone-home” IoT (Internet of Things) data, from devices at — for example — many customer locations, often makes sense to receive in the cloud. Once it’s there, why not process and analyze it there as well?
- Machine-generated data that originates on your premises may never need to leave them. Even if their origins are as geographically distributed as customer devices are, there’s a good chance that you won’t need other cloud features (e.g. elastic scalability) as much as in customer-device use cases.
Related link
- While the nuances of my views may change over time, I continue to think that computing platforms will almost all be appliances, clusters or clouds.
Comments
6 Responses to “Transitioning to the cloud(s)”
Leave a Reply
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.
http://cliveboulton.com/post/117937410643/crave-go-love-rails-hate-javascript-try-seven5
Happy to chat more, see seven5.
Clive,
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.
Curt,
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.
http://talks.golang.org/2013/oscon-dl.slide#1
Seven5 is not mine (link above) but see http://www.igneous.io/ (written in Go).
Moore’s law and multicore changes everything!
The “Go”pher is pleased to meet you.
https://golang.org/
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 )
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.
[…] 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 […]