Pia Müller: Transitioning processes towards Micro Frontends as necessary means at DKV Mobility

Pia Müller: Transitioning processes towards Micro Frontends as necessary means at DKV Mobility
Image Pia Müller

Almost every business that can be thought of might need it earlier or sooner – a website of its own. It allows businesses to be accessible at any time of the day. It provides space for everyone to access the information they need when they need it. Especially nowadays, when people are looking for a product or service, they turn to online search. This makes it crucial to respond to these needs.

However, the mere act of creating a website is not sufficient. Thoughts and plans about design, digital-marketing strategies, compliances, web hosting etc. must be considered in order to stay competitive in the market and stand out to (potential) customers.

This is where decisions about the website’s architecture come into place, which is particularly relevant for medium to big-sized enterprises. In the case of DKV Mobility, we have started and still are in a process of transition – a transition away from monolithic front-end architectures towards something similar to Microservices, but for the UI, so-called Micro Frontends (MFEs).

What are Micro Frontends? MFEs extend the concepts of Microservices to the frond-end side of the application by decomposing the FE into individual and semi-independent FEs. The business logic will be separated from the FE, while also creating independent services that interact together – perceived by the user as a whole.

But why stop building in monolithic structures? Generally speaking, FEs – if it is not already MFEs – become monoliths over time with increasing complexity. Therefore, changes will most probably lead to unwanted effects on other parts owing to huge code bases, lots of dependencies, tight coupling between teams etc. Everything gets harder and slower; productivity drops and fails to scale. Of course, depending on the business requirements monoliths can prove to be successful. However, certain factors – such as the increasing deployment of applications to the cloud or the challenge of having to rebuild and deploy the whole monolith every time a minor change has been made – lead to a growing interest in alternative architectural styles.

So, there are general differences in the way how monoliths and microservices work.

Grafik Tech Story

The above graphic, taken from the article ‘Microservices’ written by James Lewis and Martin Fowler, illustrates these distinctions. A monolith brings its entire functionality together into one code base or process and duplicates the whole of it when necessary. Micro-Frontends, on the other hand, divide code into different services – depending on the functionality served. Every time the application needs to be replicated, it will be assembled by piecing together the needed services rather than copying the full application. 

Implementing a Microservices architecture allows for crucial benefits, such as managing multiple parallel development projects and thus reducing time and resource cost or having an overall greater consistency and continuity. Further advantages that can be named include long-term flexibility and support for new technologies, faster application testing and a generally more maintainable and reduced code. 

Wrapping it all up, MFEs provide a substantial number of advantages and might prove to be a better solution than monoliths in today’s enterprises and medium to large-sized businesses. As in the case of DKV Mobility, backend architecture might differ from the frontend – having microservices working in the background and slowly breaking down monolithic structures in the UI. There is still much work to do and mindsets need to be shifted. However the finishing line is already coming in sight.