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:
- The Amazon cloud, Microsoft Azure, and their competitors, aka public cloud.
- Software as a service, aka SaaS.
- Co-location in off-premises data centers, aka colo.
- On-premises clusters (truly on-prem or colo as the case may be) designed to run a broad variety of applications, aka private cloud.
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:
- In the 1960s and 1970s, one of the biggest industries for remote computing services — i.e. SaaS — was commercial banking.
- Other big users were hospitals and stockbrokers.
- The US intelligence agencies are building out their own shared, dedicated cloud.
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:
- Does your application need to run close to your customers’ largest databases?
- Do your customers still avoid the public cloud?
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:
- Departments don’t necessarily see central IT as any “closer” to them than the cloud is.
- Departments don’t necessarily care about issues that give central IT pause.
- Departments sometimes buy things that only are available via remote delivery, e.g. narrowly focused SaaS applications or market data.
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:
- There is a lot of computing power in devices that may be regarded as IoT nodes — phones, TV boxes, thermostats, cars, industrial equipment, sensors, etc. Client-side computing is getting ever more diverse.
- Server-side computing, however, is more homogenous. Enterprises can, should and likely will meet the vast majority of their server requirements on a relatively small number of clusters each.
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:
- Operational data managed by your general-purpose RDBMS (Oracle, SQL Server, DB2, whatever).
- Relational data warehousing, whether in an analytic RDBMS or otherwise.
- Log files, perhaps managed in Hadoop or Splunk.
- Your website and other internet back-ends, perhaps running over NoSQL data stores.
- Text documents managed by some kind of search engine.
- Media block or object storage, if the organization’s audio/video/whatever would overwhelm a text search engine. (Text search or document management systems can often also handle low volumes of non-text media.)
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.
Comments
5 Responses to “Notes on the transition to the cloud”
Leave a Reply
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.
Ron,
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.
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.
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.
[…] year I posted observations about the transition to the cloud. Here are some further […]