Modernize the Legacy — Microservices & Industrialization

4 min readJun 30, 2021

Microservices, Cloud-Native, Agile, DevOps are all essential parts of Software Development nowadays. The main target is to achieve agility and development speed to reduce the time to market. Microservices as architectural pattern helps to decouple and focus. The key challenge is still to identify the “right” Microservices in terms of business functionality, size, coupling. You need good and experienced architects to do so. Large organizations tend to have huge application landscapes that already exist for quite some time. They often are reluctant against change, either architectural or organizational. One should never underestimate the huge invests of the past and the complexity of the given landscape. Once we start the modernization with Microservices journey we’ve to take those frame conditions into account. It’s not a greenfield, but a brownfield from which we start.

The architectural impact of Microservices is often looked at from the outside view

How to “identify” the Microservices (domain model and bounded context)?
What does “eventual consistency” mean from a business perspective?
Which communication patterns are used?
What advantages result from the free choice of technology?
How to increase productivity by utilizing the best fitting programming language to the given challenge and team?
How can the availability of the application be ensured (“resilient”)?
What degree of horizontal scaling can be achieved?
How does the versioning of interfaces work in detail?

Those are all relevant questions and should be answered properly when staring the journey towards Microservices. Unfortunately, it’s not all… at least in the context I’m typically working.

When modernizing an application portfolio of a huge company with several thousands of application things are different. By empowering the team and giving the freedom to choose the best fitting way to build that Microservice you open a “Pandora’s box”. We must avoid the “maintenance hell” which you can easily end up by utilizing several different technologies, programming languages, processes, development tools, etc in each and every Microservice. In such scenarios the internal view is just as important as the external view and the experience of more than 50 years of software development is the basis for the successful implementation of a mission critical long-lasting application based on Microservices.

What layers does a Microservice consist of?
How does the interface between the server and the client look like or even is there one?
Which client and server technologies and frameworks are used?
Which database technologies are fitting best?
How does database management (e.g. backup, schema migration) take place?
What is the best size for a Microservice?
How to handle security and patching in the long term?

Reuse and shoring are nowadays widespread. The degree of industrialization, in particular the use of centralized services (e.g. ensuring code quality, uniform monitoring, standardized configuration management), are often an integral part of large-scale, industrialized software development.

I typically deliberately limit the degrees of freedom regarding technology, tools and frameworks in order to ensure maintainability in the long term. In addition, the seniority of our agile teams is typically not homogeneous. We usually have a mix of senior and junior team members. For me it’s key to give guidance and guard rails to safeguard the quality and maintainability of the delivered software. For this setting standards and colleagues which are trained on them are essential.

devonfw consists of a standardized, technical architecture blueprint, software components based on it, documentation, best practices, patterns, development environment including generators, DevOps toolchain and trainings. It is a holistic, but at the same time modular approach to enable a high degree of reuse. A basic principle is to build on existing and recognized OpenSource frameworks (e.g. Spring, Hibernate, Angular, …) and only add the glue code or configuration that may be necessary.

devonfw allows the quick setup of a project and in the further course of the efficient implementation. The technical basis is defined, and the developers can focus directly on the business requirements. An active, international community of more than 1,000 architects and developers work together with a dedicated team on maintenance and further development of this Open Source asset.

The operation of a Microservice implemented with devonfw (e.g. based on Spring Boot/Cloud utilizing Istio Service Mesh) can be carried out on any infrastructure. It should be noted that the use of a PaaS platform is optimal for applications based on Microservices. In this respect one can go pure cloud-native with well-known hyper scalers or stay agnostic and utilize other third parties like OpenShift or Kubernetes.

With our customers, I often have discussions on the topic of standardization of architecture and technology for Microservices. Is the use of different programming languages, frameworks, middleware and databases a curse or a blessing?

Who reflects on the past knows the answer …

Modernize the Legacy — Microservices & Industrialization

Written by Thilo Hermann