Matthias Strauch und Michael Klutz - Microservices

From a monolithic mountain of software to independent and flexible microservices: In an interdisciplinary talk, developer Matthias Strauch and Michael Kluz, Scrum Master and Product Owner explain how to do it.

Which project are you working on?

Michael: We are responsible for the customer portal of a car manufacturer where I as the car owner can register and can administer and configure online services.

 

What are your roles in this project?

Matthias: I am one of the software developers in our team and mostly take care of the backend and its systems and application structure. If new capabilities and components are needed, it is up to me to assess what infrastructure is already in place, find out which systems we have to communicate with and then develop the necessary components.

Michael: I’m a Product Owner and Scrum Master rolled into one. As the Scrum Master I see to it that our teams have an understanding of the agile methods of Scrum and in particular SAFe and LeSS. Aside from that, I also moderate the dailies and retrospectives and I am responsible for networking the two internal teams that are working on the project. The other half of my job is to reconcile the stakeholders at the client with their requirements and to create a convincing concept on that basis.

 

How do you network several teams that work simultaneously?

Michael: To achieve this we use a so-called “Scrum of Scrums“ where all Scrum Masters of the individual teams of various companies coordinate regularly. The particular challenge lies in the fact that some of our teams are located in Argentina. In order for everybody to be on the same page in such a constellation, we bring our colleagues from Argentina to Germany for three month so that they can fully be integrated in our processes and to foster good knowledge transfer via Pair Programming.

 

From a developer’s point-of-view: What is so special about this project?

Matthias: The project has been running for 6 years already. Back then when we started, the portal was one monolithic software bundle. Together with our customers, we decided to change that to be able to make changes more quickly as well as making the addition of features faster in the future. That gave us the idea of breaking down the software into individual microservices.

 

What does “microservices“ mean in this context?

Matthias: Microservices stands for a modern architecture paradigm that encapsulates services and makes them usable with minimal dependencies. Our goal is transition complex requirements into easy-to- maintain software.

 

How do you manage that?

Matthias: Each microservice consists of a Spring Boot Application. This application contains only the code for the business logic and the required surrounding configuration. Shared components, such as the link to various backend systems, are integrated as libraries from a framework we developed. The advantage of this method is that we can share such components not only with each other but also with our customer’s teams. The challenge is that at present the software still exists in two different versions.

 

And why is that?

Matthias: The old portal is just being superseded step by step by a modern Single-Page-Application that communicates with REST-based services. Both versions are running simultaneously as we speak. We are making sure that the new services replace the existing implementations without compromising usability. Working with the frameworks allows us to quickly implement changes. That reduces integration work tremendously.

 

How do you access the required components of the framework?

Matthias: The dependencies of the individual libraries are managed by the build-system Maven. The finished application is packed into a Docker Image in the context of the build process. The finished images are made available as a container in a Kubernetes Cluster. The source code of our software is stored in a Git Repository. The Jenkins Build server monitors this process and automatically initiates a generated pipeline. This pipeline compiles the code and runs the automated tests as well as a code analysis of weak spots. As soon as the quality criteria have been met, the created Docker Image will be published in the test and integration environment. The advantage of this method is that changes to the code and their impact can be made visible within a couple of minutes.
Michael: I love this project since you always have to look beyond the horizon. Since the customer portal is linked to many other products of ours (e.g. the central platform and some services), it is not enough to only understand your own project. This requires a lively exchange of ideas with customers, other service providers and colleagues from other projects. There is always something new to learn.

More Topics