Before we get into the details we need to be on the same base about how we define development setting in the context of this. In cloud-native software each service is dependent on many container types, functions that are serverless and cloud services in order to function. In this article the term "development environment" refers to an development environments is basically a sandbox where developers are able to run their code as well as dependencies to test. It's not an IDE as well as the compiler, debugger or any of these other tools.
Sound Familiar?
It's time to start a fresh project or plan to update an existing one. Your team has read everything about the latest and exciting cloud-native technology, such as Kubernetes, containers, and so on. Then, you decide to go for it and develop a cloud-native application.
The team is aware that a core team of SREs and DevOps is required to make everything run in a stable, scalable and automated configuration. DevOps engineers are recruited/trained, and begin their work. They install Kubernetes and CI/CD, monitor logs, monitoring, and all additional tools that we've studied are essential for modern application.
Everybody knows this is the DevOps/SRE team's responsibility to ensure that all this is working. But, development environments aren't top of the list. The DevOps team believes it is their responsibility to concentrate exclusively on production as well as CI/CD. development is the job of the developer. In the same way the developers feel that it is their responsibility to provide new features to the application and not maintain the infrastructure. It's not everyone's responsibility to think about the developer experience prior to CI/CD. Therefore, it's left to chance. If Developer do not have any prior knowledge on CI/CD then consider taking DevOps Certification.
Unfortunately, an ad-hoc method of development environments can emerge. When a new service is launched that is developed, the developer who is involved in it realizes that they require a way to start their dependencies and verify their program. It's when they Google around and come to the conclusion that Docker Compose could be an acceptable method to do this. Copy and paste an instance, and tweak it with trial and error until they are sure it's functioning, and then they proceed to the next step. The quality of the composition file is a bit variable according to the DevOps experience of the engineer that was to create it. Sometimes, it's quite solid. other times, it's weak and slow.
The worst part is that this cycle repeats. Each time there's a new service, it's redirected to an entirely new git repository and the new engineer is able to find themselves writing the compose file. It could be that this file was taken from an existing program. It could be that it was developed entirely completely from the ground up. Whatever the case, there are two separate composes files which have to be updated and maintained when the application changes in time. This cycle repeats until each service has its individual, slight configurations, which make it a challenge to maintain.
Top comments (0)