Development needs to be adapted for Kubernetes, first implement DevOps processes that affect all code development. And when companies adopt Kubernetes, they often abandon the old ways of working. Developers write code as before.
At the same time, the introduction of Kubernetes changes the distribution of roles and responsibilities in the team and highlights all cultural issues. If developers have no desire to implement DevOps, there is resistance to this methodology; its tools are useless, including Kubernetes.
In DevOps ideology, administrators maintain the infrastructure. And developers support the application from planning and coding to launch, implementation, monitoring, and production. Developers now cannot help but understand the infrastructure; they must understand how the code works in the context of all these processes.
However, such situations often arise: the team breaks the monolith into microservices, spends a lot of time on this, and stops all business development. After splitting the monolith, they are going to manage the application using Kubernetes. But developers weren’t prepared to implement Docker and CI. This creates resistance. As a result, Kubernetes and microservices appeared for the show, which did not affect the application.
Why doesn’t it get better if you don’t change the approach to development?
Because the following happens:
- If developers don’t know Docker, then the DevOps engineer writes the Docker files for them. At the same time, the developer knows how the application works, its versions, and its dependencies. He could quickly write a Docker file himself (if he could) and control the infrastructure of his application. When a DevOps engineer writes a Docker file, he may not consider all the details, plus he needs to understand the application – it takes more time.
- Sometimes DevOps engineers write for Kubernetes developers and manifests, although the technology again gives the developer the ability to control the application launch, resources, and health checks on his own. When DevOps do this, they spend more time again.
- Finally, there are far fewer DevOps engineers on any team than developers. If 100 developers generate microservices, and 5-10 DevOps try to write manifests for all this, rollouts are closed on them and line up. Processes are not accelerated but slowed down.
What exactly can cause resistance? Developers have to become familiar with the Docker Way concept. This includes learning Docker, Kubernetes manifests, implementing health checks, and specifying resources for the application. If there are errors in these moments, the application may not start, and the developer needs to understand this. Sometimes the development team does not understand why it should take on these traditional admin tasks.
In the declarative approach that Kubernetes implements, they describe not the tasks that need to be completed but the state that needs to have arrived. It significantly reduces the need to understand what works and what to do. It is not necessary to consider the state of the system now. To manage configurations, Kubernetes uses human-readable YAML manifests, transparent templates, IaC (infrastructure as code) tools that describe what, where, how it will be launched, and with what parameters.
As this approach develops, the team has standard pipelines for delivering software to servers, common CI / CD templates, and Kubernetes manifests within the development team, which significantly speeds up the processes. The developer no longer comes up with a new how-to connect something but connects ready-made templates for CI / CD tasks to CI files. Kubernetes manifest templates help you not rewrite them every time – DevOps provides tools for preparing uniform templates; developers only indicate the parameters that distinguish a specific case from a template.
Once everyone on the team understands the benefits, it is much easier to transition to DevOps practices.
Also Read: Quantum Computers Will Have To Be Hidden From Cosmic Rays In Mines
