Cloud Complexity Paradox
The more undifferentiated heavy lifting you offload to the cloud, the more complex it becomes to use the cloud.
Cloud providers like Amazon Web Services’ primary value is that they take on the undifferentiated heavy lifting of providing a functional technology platform for your business. The idea is that why should your organisation employ deep networking, storage, and software specialists in areas that offer no differentiation to your business. They employ these experts, and use them to provide your organisation a platform to build the stuff that does make a difference to your business.
Over time cloud provider offerings have moved up the stack, taking on more and more of the workloads that are typical in enterprises, along with it more of the undifferentiated workload with each new service. AWS for example has gone from virtual machines by the hour, storage by the gigabyte and a messaging service to a behemoth with over 200 unique services, each of which have multiple features and options.
This explosion in offerings gives more flexibility than ever before, but comes with significant complexity that hinders adoption.
Complexity in choice.
Cloud providers have multiple services you can use to achieve the same outcome, with each service having specific benefits and drawbacks, which are dependent on a number of factors, many of which are unique to a specific organisation. In the case of Amazon Web Services, they famously have 17 ways to run a container workload, how does one decide which platform to use to run that container workload? Is a containerised workload even the best option when AWS also offers VM’s, bare metal, cloud functions and edge functions. Just the compute options are staggering. The choices don’t end with compute, there are multiple messaging services, database services, storage services, and so on. At this point the chances of making sub-optimal choices are probably higher than making the right contextual choice.
Complexity in tools.
Once service choices are made, which tool set do you use to provision and maintain this infrastructure? Within AWS alone there are a myriad of choices. Beyond using the web interface and CLI, there is the ubiquitous Cloudformation service providing an Infrastructure as Code(IaC) primitive service. Cloudformation can be used natively or via another tool, such as SAM (Serverless Application Model), or the Cloud Development Kit (CDK) from AWS, or 3rd party frameworks like the Serverless Framework and Architect. There is also Terraform which provides a 3rd party declarative IaC primitive, or Pulumi which provides imperative and declarative IaC. Each tool choice has its own characteristics which will impact choice, and relative success. Know which tool to use for which context can be daunting.
Complexity in abstraction.
The abstraction complexity ultimately is what drives all the other levels of complexity. Cloud providers offer undifferentiated heavy lifting, the question is how much of that heavy lifting do you want to hand off to the provider? Using highly abstracted services means reducing the lines of code you ship into production, and the amount of infrastructure you are directly responsible for. It reduces the complexity in your operational environment as the number of tasks required to operate your production workloads has reduced.
The flip side is that these abstracted services need more configuration, which sees significant increases in the amount of lines of configuration code. It is possible to build an entire application in AWS with no lines of code running in production, using services like Step Functions, with the tradeoff that there will be hundreds of lines of configuration code to define the behaviour of the services.
The more abstracted the service is, typically the more configuration options there are. The complexity tradeoff has moved from operational complexity to configuration complexity. Add to this the complexity of configuration tooling, using the more abstracted services of cloud providers can seem impenetrable to less experienced folks.
Confusion
All of this complexity leads to confusion. Steve Jobs famously wanted to create devices that were so intuitive they did not require an instruction manual. Cloud providers are on the opposite end of that spectrum. They create services so complex they need mountains of technical documentation, best practice guidelines and large teams dedicated to educating people how to use them correctly.
Over time cloud providers have created a fantastic moat for the people that have spent years building in depth knowledge of these services, whilst making it very challenging for folks and organisations new to cloud.
Original blog post published on Akeero.com.
