Infrastructure as Code – Whose Responsibility Is It?

During my interviews with backend engineer candidates, I have consistently noticed a lack of familiarity with the infrastructure as code (IaC) approach. Surprisingly, only a small percentage of individuals actually apply this approach in their work. It seems that in many companies, infrastructure deployment is handled by specialized departments, such as DevOps engineers.

This observation has prompted me to wonder about the reasons behind this phenomenon.

In my experience, the development of microservice architecture and infrastructure go hand in hand. It's hard to imagine these tasks being handled by separate teams.

Infrastructure as code (IaC) is a methodology that involves creating, managing, and automating infrastructure using code. One of its key advantages is idempotence, which means that the same operation will always produce the same result. This ensures that the deployment command installs the same configuration regardless of the initial state of the system. By implementing IaC, we can eliminate the influence of human error and create identical test and production environments. This is crucial for maintaining high-quality application development processes.

Using IaC in development is widely recognized for its importance. Those who do not implement this approach in practice often face limitations due to a lack of competence or resources. However, I would highly recommend utilizing IaC, even in companies with just one developer.

I would like to go into a little more detail. Who should still be engaged in infrastructure - backend developers or DevOps engineers? In our company, this functionality is performed by developers and this gives many advantages.

• Qualification growth

  Large modern web applications cannot be imagined without a microservice architecture. In order to implement it effectively, you need to have a broad outlook and know what technology to use when implementing a particular task. The ability to only write code and cover it with tests has become insufficient in modern development. By delving into the infrastructure, developers better understand how their application functions. They see the whole picture and can avoid creating a bottleneck in the system already at the design stage of the task.

• Acceleration of the development and roll-out process in the production

  Developing an application consisting of dozens or even hundreds of microservices (in my case, 300+), your next task may be related to any of them. In addition to writing business logic, it may be necessary to deploy a cache, or a database, add ingress to Kubernetes or open a location in nginx. When the developer knows how to do this, the task execution will go faster. There is no need to go to someone to ask, gather meetings or make applications. You can go to the repository at any time, see how it was done for similar services, and also do it on your own. Having rolled out the script to raise the infrastructure on the test, exactly the same script will work on the production. In this case, the developer works at his own pace and does not depend on the availability of people from other departments.

• Unified responsibility

  Having taken up the task, the developer needs to implement it, cover it with tests, if necessary, conduct load testing, and roll it out into the production. When one person is responsible for this, he will be motivated to solve it in all possible ways. If you are stuck somewhere, you can read the guide in the corporate knowledge base or go for help to a colleague who solved a similar problem earlier. The team always knows at what stage the task is now, and it is possible to better predict the time of its completion.

• Speeding up the solution of bugs from the production

  No one likes to fix bugs on the production. In ideal conditions, they should not appear there, since before that the code was covered with unit and integration tests, and the functionality was tested by QA. However, the test and production environments do not always coincide 100% due to technical limitations. Fixing bugs in production can be complicated by the fact that developers do not have access rights there. All communication will take place through the support team. Logs may not be complete due to sensitive data. When a developer understands how the infrastructure and the system as a whole work, it becomes easier to find bugs and solve problems. It's no secret that modern large web applications have a very complex architecture. Even an experienced developer sometimes lacks a year to learn all the nuances of a project. I have worked on projects where teams do narrow functionality within one or more microservices. Developers focus exclusively on the code and have little idea of what is going on outside the framework. They do not represent how the whole system functions. Solving bugs in such a case could take weeks or even months, and solving the problem could go beyond the scope of the team.

• Improving application performance

  IaC is self-documenting. The developer can see which infrastructure is deployed and where, which ports are involved, and with which configuration each microservice works. All this is described and lies in the repository. If problems appear in some microservice, you can look at the metrics, identify the cause, add the necessary hardware, or tune it up. When you have all the information in front of your eyes, you can easily conduct a comparative analysis and find the optimal solution. The load on the service has increased - let's add more instances to it, it began to fall on the OOM - let's add memory to it or take some of the information to the cache, requests are going on for a long time - let's play with timeouts on the entire call chain. Comparing the reference microservices with your own, you can quickly solve the problem without wasting time on experiments.

• Cost reduction

  If the competence for automation and deployment of infrastructure lies on the shoulders of developers, you do not need to have an additional team of DevOps engineers. Of course, you will have to sacrifice part of the time for business tasks, but you can do it elegantly by creating a technical task direction. The infrastructure deployment code is always available, as it lies in the repository. Developers do not need to spend their time, which is very expensive, studying and writing from scratch. The code is easily replicated to other microservices in the project. Once written and running, the Ansible script will then be used repeatedly. Hardware costs are also reduced since configurations are always optimally configured, and additional power can only be taken at peak times, which allows for example Kubernetes.

• Refusal of legacy, updating of software and infrastructure

  It is critically important to constantly monitor new software, versions of libraries, and frameworks so that the code and technologies on the project do not turn into legacy. In my company, developers spend 20% of their time on technical tasks. Within their framework, dependencies are updated, pilots are made using new technologies, load testing is carried out, training is conducted, and legacy code is rewritten (for example, the rewriting of microservices to Reactive or from Java to Kotlin). There are also many infrastructure tasks within this area. Thus, developers are constantly expanding their horizons, studying new technologies, and not closing themselves in the narrow framework of their business tasks, which may eventually turn into a routine. It may get boring to send JSON back and forth).

I tried to give examples that infrastructure can be handled not only by DevOps engineers but also by ordinary backend developers. And there are certain advantages to this. Someone may disagree with all the points since a person immersed only in DevOps will understand the problem more deeply. But like many issues in development, who will be responsible for the infrastructure of the project has its advantages and disadvantages. There is no silver bullet. As a result, it does not matter who does this work in your company, if you adhere to the IaC approach, the processes are optimally configured, and the time from setting the task to rolling out to production is not burdened with unnecessary meetings and approvals. I managed to work on different projects and at the moment I see a large community of developers who are independently engaged in IaC.