Engineers provide profound insights. About the world, work, and even the Cloud. I suspect the reason is that engineers, at least the ones I’ve met, think about things in terms of systems. Performant systems, emerging systems, and failed systems.
“Everyone in the Cloud is failing. Not everyone knows it. Whether you’re a fresh startup or a business unit in a major enterprise, the fastest and cheapest way to launch a new service is to use native services from the major cloud providers.” No surprise here, be patient.
“You can chart it. Inevitably, you will end up spending all your revenue, paying a public cloud provider for all those easy to use, developer-centric, on-demand services. No matter how big or small the organization is, they’ll have to re-platform their apps onto some form of IaaS with vendor supported or Open Source components just to stay in business. It is not sustainable any other way.”
McDonalds regret cloud-style. Tastes great. Who doesn’t love that salt hit? Easy to find, easier to eat. The bill comes later.
Cloud as both a concept and a consumption model presents economic and business challenges. VMware has many excellent articles on Cloud Economics. I encourage you to read them for an in-depth view of both the financial considerations and strategic options available with VMware and our partners.
Some examples:
The Economics of Cloud Computing
Behaviors and Biases: Understanding Cloud Economics
Business Value, ROI and the Economic Impact of Cloud
Gaining Visibility in the Cloud
Hybrid Cloud Costing and Capacity Planning
In this piece, I’ll challenge some of the “fast food” wisdom regarding Cloud finance and business. Customers, consultants, and yes, engineers have all called out these myths of Cloud Economics.
The Top 5 Myths of Cloud Economics
1. In the Cloud, you only pay for what you use.
Reality: you pay for what you don’t turn off.
2. In the Cloud, you can inexpensively scale apps.
Reality: scaling depends on your teams’ skill and the app topology, no matter where it is running.
3. In the Cloud, apps self-tune for cost automatically.
Reality: just as fast food doesn’t include self-control, Cloud does not include self-tuning.
4. In the Cloud, costs are fixed.
Reality: both fast food and Cloud may induce regret.
A big driver to the Cloud, at least at a management level, was to avoid surprises.
Cloud is full of surprises. Some are expensive.
The Total Cost of Ownership (TCO) of many Public Cloud services is often unknowable.
Or at least until you receive the final bill.
5. In the Cloud, there is less risk.
Reality: risk in the Cloud is different.
Why is managing risk in the Cloud so different? And how did we get here? Let’s go back to the beginning.
In 2006, NIST published its first set of guidelines on cloud computing.
NIST declared several naming conventions that are still in use today, such as IaaS, PaaS, and SaaS. Since then, the “as a Service” categories have grown to encompass Containers, Functions, APIs, Image Processing, Security, Costing, and XaaS – anything as a service. My favorite XaaS so far was BaaS – Beer as a Service.
The fact that today anything can be delivered “as a Service” illustrates a critical transformation in Cloud Economics. Fourteen years ago, when IaaS / PaaS / SaaS ruled the lexicon of cloud terminology, things were very different. Getting access to resources was difficult. Connectivity was not ubiquitous. Mobile was barely getting started. IT department budgets were still growing, and supporting the “developer experience” was a fresh concept for most enterprises.
Much has changed since 2006. Most, if not all, of the technologies that create developer-centric “as a Service” experiences are available to anyone. You could be using one public Cloud or five. You might have critical systems on monolithic stacks in the data center plus key systems hosted by a telco. Or even Kubernetes running at the edge on a Raspberry Pi. Wherever your workloads are running, it is now possible to consume and operate any system through self-service while the workloads are self-tuned and cost-optimized through policy based life-cycle management with code-driven deployment methodologies. Whew!
It feels weird to type all that out. Why? Because this wasn’t the case even three years ago, never mind in 2006. All of the above Cloud functionality, previously only available through the big public providers, is now available anywhere you want. Whether you are running a data center, need a private cloud, are all in on Public Cloud, are refactoring for Native Cloud, or are building a Multi-Cloud strategy, these capabilities are available now.
One way to see the power of VMware’s strategy of Any Device, Any App, Any Cloud is that the endpoint doesn’t matter. We are creating consistent and secure experiences for employees, developers, and, ultimately, the customer regardless of the Cloud or provider.
You do not have to run a Public Cloud to provide an “as a Service” experience to your the Lines of Business, the IT organization or the application teams. The platform and service capabilities that once differentiated the Public Cloud providers are no longer limited to those endpoints, which creates favorable Cloud Economics regardless of the mix of services in play already.
With that in mind, let’s review the Top 5 Cloud Economics Myths again, with an “IF” statement.
The Top 5 Myths Truths of Cloud Economics
(or where VMware Cloud Management impacts the myths in Private, Hybrid, Public, Multi and Native Cloud)
1. In the Cloud, you only pay for what you use.
IF you know what’s running and what you can turn off.
vRealize Operations (Datacenter, Private Cloud, Hybrid Cloud)
CloudHealth (Public Cloud, Multi-Cloud)
2. In the Cloud, you can inexpensively scale apps.
IF your scaling functions are built into the platform.
vRealize Operations (Datacenter, Private Cloud, Hybrid Cloud)
CloudHealth (Public Cloud, Multi-Cloud)
Tanzu (Cloud Native)
3. In the Cloud, apps self-tune for cost automatically.
IF your analytics provide actionable cost recommendations.
vRealize Operations (Datacenter, Private Cloud, Hybrid Cloud)
CloudHealth (Public Cloud, Multi-Cloud)
4. In the Cloud, costs are fixed.
IF you can baseline costs, compare to alternatives, and predict expense trends.
vRealize Operations (Datacenter, Private Cloud, Hybrid Cloud)
CloudHealth (Public Cloud, Multi-Cloud)
5. In the Cloud, there is less risk.
IF you can tag workloads to deploy to the environment that best matches its risk profile.
vRealize Automation (Datacenter, Private Cloud, Hybrid Cloud)
CloudHealth Secure State (Public Cloud, Multi-Cloud)
Using tagging and deployment intelligence manages risk, but is there less risk? That depends on how effective your teams are at determining your current operational state. Baselining against existing practices is essential because all risk is relative. Optimal security, availability, privacy, and costs can only be determined IF you have alternatives to compare against. You can only know whether renting a house is cheaper IF you have all the Total Cost of Ownership associated with buying a similar property.
So that wraps up some quick postulations inspired by my engineer friend’s insights on the state of the Cloud. Yes, you may need to switch to Cloud Native to recover from a case of Public Cloud fast food regret. The best strategy may be to change very little. Conversely, it might be absolutely the best choice to embrace the newest, shiniest, and most expensive functions only available through the Public Cloud to stay competitive.The trick is being able to know which is which across all your workloads in any Cloud.
That type of visibility into the financial impact of a Cloud decision is a big part of supporting a great developer experience. Primarily because the experience can remain economically sustainable.
By the way, I’m not finished with exploring engineers’ favorite area of insight.
Next blog: Cloud Is – Part Eight – a Failure
The full ‘Cloud Is’ series is available here
