For Operations There Is Never an “Entirely Green Field”

Certainly, microservices are a topical subject and bring along new technologies, concepts, and organizational changes. However, one should always consider that enterprises introducing microservices hardly ever start from scratch! There are always some kinds of legacy systems or entire IT environments that already exist and might better not be replaced in a Big Bang approach. Usually these legacy systems have to be integrated into the brave new world of microservices; at least they will have to coexist.

For this reason, it is important to take these systems into consideration when planning a microservices-based architecture, especially in regards to IT costs. Can the existing hardware infrastructure really be restructured for the microservices or is there a legacy system that relies exactly on this infrastructure? These are often questions that get caught on the infrastructure or operations team—if there is such an organizational unit in the company. Otherwise it might happen that these questions first arise when a deployment to the system test or production environment is supposed to be done. To recognize these questions early on, I recommend dealing with the deployment pipeline as early as possible in the reorganization project. The deployment pipeline should already be in place before the first business functionality is implemented by the teams. A simple “Hello World” program will often be sufficient, which then is brought towards production by the combined forces of the entire team. While doing so, the team will almost always encounter open questions, which in the worst case will have effects on the design of the systems. However, as not much is implemented at this stage early on during the project, such changes are still comparably cost-efficient to implement.

Conclusion

Up to now the organizational changes with regard to Conway’s Law that accompany the introduction of microservices are often underestimated. Old habits, prejudices, and maybe even trench wars are often deep-rooted, especially if the new teammates were previously assigned to different departments. However, “one team” has to be more than just a buzzword. If the team manages to bury their prejudices and put their different experiences to good use, it can advance together. Everyone has to understand that all of them now share the task and responsibility to bring a stable software into production for the customer. Everybody can profit from the experiences of the others when everybody acts on the premise: “Everybody voices their concerns, and we will solve it jointly.”