Cloud Native platforms, driven in large part by Kubernetes, is at the peak of the hype cycle and almost every enterprise we talk to have embraced or in the process of embracing such platforms. At Rishidot Research, we focus on finding patterns emerging from the enterprise users and share it with a larger audience. One of the patterns we expect to gain traction in the coming years is to empower developers to handle the underlying distributed systems through code. Though the concept of infrastructure as code is nothing new, we are seeing a new trend that empowers developers to use familiar programming languages to handle the underlying infrastructure than using config management tools or complex YAML files. We are bucketing the application platforms, broadly, into three buckets. In this post, we will differentiate between these three platform philosophies so that enterprise users can find the right platform for their needs.
The traditional approach is Platform Abstraction
The traditional approach to solving the complexity for developers is to build an abstraction and offer developers an API to deploy their applications. The abstraction took away most of the underlying infrastructure complexity and made it easy for developers to deploy their applications. Typical examples include Red Hat OpenShift, Pivotal, Mesosphere, Docker EE, Rancher Labs, etc.. They range in focus from developer centricity to focus on IT operators. In the early cloud days, this bucket was categorized as PaaS.
- Helps developers deploy applications fast without worrying about the underlying infrastructure
- Helps companies with traditional separation between the Ops and Dev teams gain agility without cross-pollination of expertise
- It also helps companies embrace DevOps and agile deployments without too much disruption in their existing processes
- Organizations can embrace agility even if they couldn’t hire more expensive developers with operations knowledge. The platform abstraction ensures that the operational complexity is removed from the developers but they still have to manage the configuration of their applications (YAML hell?)
- Unless the same platform is used across Dev, Test, and Production, the traditional issues of “it worked in Dev but not in production” will continue to haunt enterprise IT
- YAML complexity could go out of hand derailing the very agility needed for the modern enterprise. It could also impact portability to move across providers/platforms, flexibility to evolve as newer technologies enter the modern enterprise horizon (derailing the continuous innovation mantra)
Infrastructure as code
Driven by public clouds and the self-service interface for consuming infrastructure services, a more DevOps-centric approach to operations gained traction in the last decade. With configuration management tools like Chef, Puppet and Ansible gaining traction and modern approaches like GitOps promoted by WeaveWorks, treating infrastructure as a code are widely used by startups and some of the cutting edge enterprises. Hashicorp’s Terraform is another example in this category. In the early cloud days, this was categorized as IaaS+.
- Infrastructure is treated as cattle (as in Pets vs Cattle) empowering developers to deploy their apps in production with confidence (provided they understand the operations)
- DevOps centric approach to agility driven by tools like Chef, Puppet, and Ansible. This approach is about doing DevOps with an emphasis on Ops
- Updates and upgrades are as easy as bringing up new machines
- Useful when the underlying infrastructure is more diverse
- Hiring unique resources is difficult and expensive. Organizations needed developers with operations knowledge and IT Ops who can code. Developers needed to learn config management tools and YAML to handle the underlying application infrastructure
- Without a proper culture in place, it is a complete mess
- YAML complexity can fast overwhelm the developers and IT operations
Infrastructure as developer-friendly code
Infrastructure as a code is nothing new. It has steadily gained adoption with the cloud, especially among the startups and some of the enterprises. Platform abstraction was attractive for many large enterprises wanting to modernize their infrastructure. In both cases, the configuration files are fast becoming a bottleneck with the ever-increasing complexity. A third new approach to application infrastructure is gaining attention and it could change the way enterprises are thinking about platforms. Driven by startups like Pulumi Inc and the Metaparticle project started by Brenden Burns of Microsoft, this new approach aims to bring abstractions to infrastructure components straight to developers and empower them to handle the underlying infrastructure in a language (as in programming languages) familiar to them. Metaparticle is focussed on Kubernetes for now and Pulumi takes an approach that is independent of the type of the cloud service or provider. The rationale behind this philosophy is that this abstraction will not only reduce the complexity of configuration files dramatically but also make it more palatable for developers who need not learn a brand new language specification for handling the underlying infrastructure.
- Less configuration complexity and developer friendly infrastructure abstractions
- It enables developers to deploy in production with complete confidence because they control the underlying infrastructure as the application code travels from developer laptop to testing to production
- Fits the needs of 2 Pizza teams deploying Microservices architecture. This approach takes DevOps and puts an emphasis on the Dev part
- No need to hire developers with extensive operations knowledge and developers can code the infrastructure in the programming language of their choice
- A newer abstraction (in the form of libraries) to manage
- At this point, it is pretty new and we have very little feedback about real-world problems
- No major enterprise vendor or cloud provider has fully committed to this approach at this point in time
These are three different approaches to application platforms that will compete to gain enterprise adoption. If the developer-centric approach to infrastructure gains momentum, expect to see vendors in the first two categories to bring in another layer of abstraction in front of their platforms. Very early days but an interesting approach that requires the attention of modern enterprise decision makers.
tl:dr version: Abstracted platforms keep the role of Devs and Ops separate; Infrastructure as code requires Devs to understand Operations; Infrastructure as developer friendly code puts a developer-friendly wrapper around infrastructure