How the Cloud Made Computing Harder, Not Easier

Remember when cloud computing was supposed to make the lives of IT pros easier? When PaaS and IaaS would free IT teams of the burden of physical infrastructure management, and SaaS would make it easy to deliver applications to any user, in any location, at any time?

The cloud did those things, to be sure. But overall, the cloud has made the lives of IT engineers (and developers, and security teams, and virtually everyone else who plays a hand in modern IT) harder, not easier.

The question that remains to answer is: Why? Why did cloud computing end up making the jobs of IT departments harder and more time-consuming, while also exposing businesses to new types of cybersecurity threats and increasing overall IT spending?

Let's explore that question by walking through how the cloud evolved and the factors that have resulted in a cloud computing ecosystem that is much more complex than it arguably needed to be.

Why Managing the Cloud Is Hard

Again, it's certainly true that the cloud has simplified computing in certain respects. It has allowed the majority of businesses to say goodbye to managing physical infrastructure. It has also placed sophisticated tools and services — like managed Kubernetes environments and cloud-based big data services — into the hands of IT organizations that would struggle to implement these technologies themselves on-premises due to limitations of staffing or expertise.

But in other ways, the cloud has added a great deal of difficulty to the lives of IT practitioners:

How to Simplify Cloud Computing

To be sure, the complexity of the cloud results to a significant degree from the flexibility and power that cloud computing offers. Complexity is the price IT teams pay for taking advantage of the cloud.

That said, the cloud arguably didn't have to end up being so difficult to manage. And it doesn't have to remain so. Here are a few ways in which cloud computing can be made simpler from the perspective of the engineers who manage cloud workloads.

Standardization across clouds

For one, cloud vendors could do a better job of standardizing the way their services are configured. All major clouds offer the same set of core services, like VM hosting, object storage, and IAM. Yet the configuration tools and policy frameworks that each cloud uses is different enough to make it impossible for an engineer who has mastered one cloud to administer a different cloud with equal competence.

This problem would be solved if cloud vendors would agree on some form of basic standards. They wouldn't have to offer the same exact services; that would obviously not be advantageous from a business perspective. But they could do things like standardize the way IAM policies are written, which would go far to reduce the complexity of administering the cloud.

Simpler pricing schedules

Simplifying pricing schedules is another way in which the public clouds could make the lives of IT teams considerably easier. Instead of factoring in a complex set of variables when calculating cloud service costs, the clouds could do something like offer tiered pricing options, wherein customers would pay a consistent, predictable price for fixed levels of consumption. In other words, they'd get preset levels of runtime, egress traffic, API calls, and so on, and their workloads could consume up to the preset levels for a predetermined price.

To be sure, tiered pricing doesn't make sense for all cloud services, and some customers benefit from the ability to pay based on exactly what they use. But offering simpler pricing terms at least as an option would solve the pricing puzzle of cloud computing for many customers.

Custom metrics

It would be unreasonable (not to mention very insecure) to expect cloud vendors to give customers full access to underlying cloud infrastructure. But the vendors could at least provide ways for customers to define custom metrics or pull data from a lower level of the hosting stack, within limits.

For example, instead of customers only being able to collect whichever metrics a cloud chooses to expose for its VM hosting service, the cloud could make it possible for them to run eBPF programs on the server that hosts VMs in order to collect low-level data through the host kernel. That would open up a whole new set of possibilities for monitoring and observability because IT engineers wouldn't be limited to the metrics provided by the cloud service and the data available from inside each VM instance. They could instead see what the hypervisor and the host kernel see.

Doing this in a secure way (without letting customers collect data about other customers' workloads) would be no mean feat from an engineering perspective. But if anyone has the development resources to build this type of solution, it's cloud vendors like Amazon and Microsoft.

Preferring open source tools

Part of the reason why learning to administer cloud services is hard is that cloud vendors have a habit of creating proprietary administration tools, even when there are good open source alternatives available.

For example, most cloud-based managed Kubernetes services are accompanied by various vendor-specific CLI tools — like eksctl and gkectl. Those tools arguably aren't necessary because the vendors could instead choose to use open source Kubernetes tooling — like kubectl — for this purpose. They might have to add some proprietary extensions to the tools, but the core tools could be open source.

Conclusion: The Cloud Is Great, but It Could Be Simpler

To be clear, I am by no means suggesting that IT teams should abandon the cloud, or that cloud vendors deliberately make cloud services harder to manage than they have to be. The problem is instead that cloud services and management tools have evolved in a way that has made cloud administration more complicated than it needs to be.

The good news is that there are actionable ways to reduce (if not completely solve) the cloud complexity challenge. Most of them require some effort on the part of cloud vendors, but there's no reason why they can't be managed.