Infrastructure as code vs. platform as code

In its simplest form, the tech stack of any application has three layers — the infra layer containing bare metal instances, virtual machines, networking, firewall, security etc.; the platform layer with the OS, runtime environment, development tools etc.; and the application layer which, of course, contains your application code and data. A typical operations team works on the provisioning, monitoring and management of the infra and platform layers, in addition to enabling the deployment of code.

The rise of cloud computing first abstracted the infra layer. The infrastructure as a service (IaaS) model allowed IT/Operations teams to instantly provision cloud infrastructure at the click of a button. AWS EC2, Azure VM and Google CE are the most popularly used IaaS services today. Along came the platform as a service (PaaS) model that abstracted the next layer. Infrastructure providers themselves began offering the platform layer — operating system, development tools, database management and the like. PaaS services like AWS Beanstalk, Azure CDN, Google App Engine gained popularity.

In fact, Ops teams also began building their own PaaS, bringing together a selected subset of features to be compatible with their existing infra or have custom workflows. If you’re using containerization or microservices paradigms, this can get tedious and unwieldy.

The need for scale, consistency, repeatability, shareability and auditability in building microservices-based applications forces operations teams to consider radically new approaches to the workings of the infra and platform layers. It is in response to these concerns that the concepts of infrastructure as code (IaC) and platform as code (PaC) emerged.

SEE ALSO: Infrastructure as Code – Lessons learned from Dev to Ops

Infrastructure as code

Infrastructure as code is exactly what it says on the can: Managing and provisioning infrastructure through software, instead of physical hardware configuration or other tools. With IaC, you write declarative instructions about compute, storage and network requirements for the infra and execute it. The automation engine — tools like AWS Cloud Formation and Terraform — will then provision it for you by capturing declaration/code through an abstracted IaaS API.

As a result, provisioning infra becomes significantly faster, whether it’s a natural part of your delivery pipeline or meant to auto-scale in response to specific events. If you use multiple environments like dev, QA, staging, prod etc., firing up infra using the same code base ensures consistency, saving you much time and possible heartache by mitigating risks of errors, misconfigurations, downtime etc. Change management too becomes much simpler — you can write code to update your infra, and have complete version control.

This is especially impactful for containerized applications on the cloud.

• Containerization and microservices launch hundreds of small applications, instead of the handful of large instances like those used in the previous development paradigm. At this scale, there would be time lags into the development journey, affecting agility significantly.
• In multi-cloud deployments, repeatability across the hundreds / thousands of applications is crucial for delivery consistent customer experience.
• The money mechanics of cloud makes it prudent to up-scale and down-scale infra dynamically based on needs — something that would be nearly impossible to manage manually at that scale.

With infrastructure as code, cloud native applications can have consistent, reliable and version-controlled infrastructure at scale. But IaC alone doesn’t offer the best application lifecycle management experience. The platform still needs to be provisioned and managed by the Ops teams. IaC is implemented by writing abstractions as wrappers over APIs of infra layer, as a result, developers would need a new CLI for each abstraction.

For a smoother developer experience, IaC wasn’t enough. We needed platform as code.

SEE ALSO: Tutorial: Infrastructure as code with AWS and Terraform

Platform as code

Platform as code (PaC) is a similar abstraction of the platform layer. PaC allows you to write declarative instructions about the platform layer — including the OS and other tools that are needed for development and operations of your application — into code and execute it.

In essence, PaC allows the developers to define their own platform: That is, have a customized execution environment for your application. This can be a different environment for each application, how many ever they are. If Kubernetes is your platform, you’d be able to write YAML declarations for your platform elements just the way you would for your application code.

Unlike IaC, PaC is implemented through abstractions as Kubernetes API extensions instead of writing wrappers over k8s APIs. So, PaC abstractions become first-class entities, allowing developers to use kubectl and YAML to provide declarative instructions.

The savings in time and energy resulting from automation goes without saying. But the real value of PaC on Kubernetes is that there will be repeatability and control even as developers are creating custom platform stacks for their K8s cluster. It will ensure dev/prod parity for your application. All platform elements like YAML files, operator manifests etc. will be shareable. With Kubernetes Operators, you will also be able to deploy consistently on multi-cloud environments.

Platform as code as a paradigm has enabled efficient, consistent, repeatable delivery of enterprise applications at scale. It has brought Dev and Ops closer, collaborating through the common language. Most importantly, it has paved the way for the next generation of development lifecycle tools — which offer iterative development, optimized workflows, light-weight client-side tool, production-ready CI/CD pipelines and app centric deployment automation.

The post Infrastructure as code vs. platform as code appeared first on JAXenter.