The app developers of the retail chain are not distributed horizontally among teams for backends, frontends, and middleware, but vertically, i.e., one workgroup develops all layers of a functional module.
If too many developers work on a large application simultaneously, focus and responsibility are lost. The individual developer can no longer think through all the technical aspects from front to back. With microservices modules, on the other hand, this remains possible. When back-end developers deliver complicated interfaces that front-end developers have to build on top of, trouble is programmed in the literal sense of the word.
The classic model of horizontal layering of apps and teams has had its day. Today, you slice both vertically along functionally complete modules that split into microservices. In this way, developers better understand the purpose of the app, get on with their work more quickly, there are fewer interfaces between teams, and the app composed of microservices is easier to maintain.
Methods and tools
How well and quickly developers work depends primarily on the available methods and tools. The ongoing integration (continuous integration, CI) and delivery (continuous delivery, CD) of the microservices play a decisive role in the success of the project. In CI, the iteratively developed contributions of the team are automatically inserted into the overall app, and their function and interaction are tested in the process. Continuous delivery means delivering the interim status after each programming round in order to accelerate the productive use of the software, obtain user feedback and optimize the app iteratively.
The entire software pipeline must be automated. Every rollout costs time and money. The developers contact IT headquarters, tickets for the rollout are created and processed, sometimes the team waits hours or days for the colleague at headquarters to press a button. Frustrating. No one needs that. Here, automation of the rollout saves the budget – and the nerves!
Deployment governance is also important, a procedure that records all changes and documents the current status of the app in a binding manner. Essentially, this means release management, including definition of the scope of functions and version control.
Only if every change to the app can be tracked in detail do we know where the error analysis should start in the event of problems in live operation.
High-level automation streamlines not only the distribution of software, but also the infrastructure on which the app runs. The preferred method of deploying new software quickly and securely is to run it in a virtual container, or containerization for short.
The rollout should include the software and the infrastructure on which it is built. The method to be used is called Infrastructure as Code or programmable infrastructure. Virtualization with containers has only advantages, no disadvantages. The company keeps its software stack under control, and the individual development teams can optimally support their rollouts. A container contains everything needed, from environment variables to libraries and the Java version to the runtime environment.
However, software may only be put into operation with strict monitoring and automatic messages in the event of critical conditions.
If we map a business process with several microservices, we need to know in detail how the interaction works. This is not easy. We need metrics for both the overall process and the individual microservices. Just measuring and analyzing the services is not enough. We need to monitor the entire process as a chain of microservices.
Each development team must monitor its microservices itself throughout the entire lifecycle. This responsibility must never be delegated to a central office. What you can delegate are the infrastructure tasks, such as: Which tool do we use for monitoring, who sets up the tool, who monitors it? Such tasks are even better handled by a central office, especially since it ensures efficiency in the teams by providing specifications.
Our interlocutor considers the widespread central storage and analysis of log data for process control, which is recommended by some sources, to be less relevant. However, a business process mapped with microservices must remain traceable in its sequence by means of so-called correlation IDs.
Experience shows that errors in distributed processes can hardly be found with the central log system alone. When analyzing it, the teams point their fingers at each other again. Even if the log system works with correlation IDs, the IT knowledge is distributed among the different teams and a certain blinkered mentality prevails.
Nevertheless, central logging proves useful. In competent hands, it helps to minimize the personnel effort required for error analysis. However, this is where technical experts are more in demand than developers. However, even if errors can be located and corrected more quickly, this does not necessarily mean that the entire development project is accelerated.