K8s Anti-Design Pattern Series – Mixing infrastructure and application deployment

Introduction:

Since Terraform’s introduction (along with other comparable tools like Pulumi), “infrastructure as code” has become a popular methodology for deploying systems. Even though technology can be deployed in a pipeline, that doesn’t mean it should be deployed alongside applications at the same time.

Bad Practices in Deployment

Many teams today use a unified workflow for both the provisioning of infrastructure (e.g., the establishment of a Kubernetes cluster or a container registry) and the subsequent deployment of an application on top of that provisioned infrastructure.In principle, this is a great approach (since it ensures that you are always starting from scratch with each deployment), but in practise, it can be quite time- and resource-intensive.

The application’s source code is subject to much more rapid evolution than the underlying system. It is challenging to generalise about the rate at which businesses change their technology versus the rate at which they change their applications. If you only have one pipeline that handles both tasks, every time you release a new version of your app you will be tearing down and rebuilding infrastructure that has never been updated. The time required to deploy the entire pipeline (infra and application) could be 30 minutes, while the time required to deliver just the application could be 5 minutes. With no changes to the underlying technology, you’re wasting 25 minutes on each deployment.

The second drawback is that it is not obvious who is responsible for checking the pipeline if it should break. If I’m a developer who wants to use Kubernetes to deploy a programme, I don’t care about Terraform errors, virtual networks, or storage volumes.DevOps’ primary goal is to give programmers access to automated processes so they can solve their own problems. Impeding their progress by making them contend with infrastructure when they don’t have to is

counterproductive.Of course, the best course of action is to separate distribution and infrastructure into their own channels. Application deployments will proceed more quickly because the infrastructure pipeline will be activated less frequently (and cutting down on lead time).

Good Practices in Deployment

Also, when the application workflow fails, the developers won’t have to worry about infrastructure issues or the specifics of how the Kubernetes cluster was set up. Administrators can make adjustments to the pipeline without impacting programmers. Everyone has the ability to function autonomously.

Some businesses make the mistake of combining infrastructure and applications, reasoning that their software can’t function without the support that infrastructure networks offer.A common scenario involves deploying an object with Terraform and then using that object’s output (say, an IP address) in subsequent stages of the workflow. If you’re experiencing this restriction, it’s likely because your programme is too tightly coupled to the underlying infrastructure (i.e. your application code should not need a specific IP address to be deployed).

Take note that this method can be applied to more extensive database revisions. Database changeset pipelines should not rely on the application’s code for operation. There should be no requirement to change both the database schema and the application code at the same time during deployment.