Wir berichten seit einiger Zeit viel über unser Bestreben zum Einsatz von Microservices. Dazu habt ihr schon Beiträge (den Letzten von Guido) zu unseren architektonischen Ansichten lesen können. Damit ihr auch etwas über unsere Applikationssicht erfahrt, habe ich diesen Post geschrieben. Doch was hat das mit den Herren Tesla, Edison und Turing zu tun?
A Completely Biased Summary of the Assets of Microservice Architectures
When we started ‚Lhotse‘, the project to replace the old, monolithic e-commerce platform of otto.de a few years ago, we chose self-contained systems (SCS) to implement the new shop: Instead of developing a single big monolithic application, we chose to vertically decompose the system by business domains (’search‘, ’navigation‘, ‚order‘, …) into several mostly loosely coupled applications. Each application having it’s own UI, database, redundant data and so on. If you are more interested in the ‚how‘ instead of the ‚why‘, please have a look into an earlier article on monoliths and microservices.
Lately, some of these SCS turned out to be still too large, so we decomposed them by extracting several microservices. Because we are already running a distributed system, cutting applications into smaller pieces is now a rather easy exercise. One of the reasons, why I agree with Stephan Tilkov that you should not start with a monolith, when your goal is a microservices architecture.
This article is not about the pros and cons of microservice architectures. This article is mostly about the pros. Not because they do not have downsides, but because I’m biased and completely convinced that microservices are a great idea.
The architecture of otto.de is based on the concept of vertical decomposition: the whole system is vertically split into several loosely coupled applications. Every „vertical“ is responsible for a single business domain such as „Order“, „Search & Navigation“, „Product“, etc. It has its own presentation layer, persistence layer and a separate database. From the development perspective, every vertical is implemented by exactly one team and no code is shared between the different systems. We have already described the details of this architecture in an article in OBJEKTspektrum (German), a different blog post (German) and at conferences like QCon (English).
For some time, a different approach to decompose large systems is becoming more and more popular: microservices. What are the similarities and differences of both kinds of architectures and how is it possible to get the best of both? This is what I want to discuss in this text.