A Completely Biased Summary of the Assets of Microservice Architectures

by @GuidoSteinacker

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.

When we began the development of our new Online Shop otto.de, we chose a distributed, vertical-style architecture at an early stage of the process. Our experience with our previous system showed us that a monolithic architecture does not satisfy the constantly emerging requirements. Growing volumes of data, increasing loads and the need to scale the organization, all of these forced us to rethink our approach.

Therefore, this article will describe the solution that we chose, and explain the reasons behind our choice.

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).

Vertical Decomposition
Vertical Decomposition

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.

In vielen Projekten erfolgt die Entwicklung von neuen Features in dem einen oder anderen Branching Modell wie zum Beispiel Git Flow: Features werden zunächst auf einem separaten Branch entwickelt und erst nach „Fertigstellung“ des Features wieder integriert. Beim Mergen der Änderungen kommt es dann gelegentlich zu Konflikten und wenn man Pech hat, landet man in der „Merging Hell“. Moderne VCS wie GIT machen Branching + Merging zwar deutlich einfacher, ändern aber auch nichts daran, dass es gelegentlich schwierig ist, konkurrierende Änderungen zu einem lauffähigen Deployment zu integrieren.

Das Hauptproblem mit Feature Branches ist aber ein anderes: Wann ist ein Feature „fertig“, kann also integriert werden? Erfolgt die Abnahme einer Story auf Basis des Feature Branches, muss nach der Integration eine weitere Qualitätssicherung erfolgen – denn sonst könnten sich Fehler in der Kombination mit parallel entwickelten Features einschleichen. Erfolgt die Qualitätssicherung erst nach der Integration auf einem Release Branch, könnte sich herausstellen, dass das Feature eben doch nicht fertig ist, weil die eine oder andere Anforderung nicht erfüllt ist.

Continuous Integration verfolgt daher einen anderen Weg: die Entwicklung erfolgt auf dem HEAD und jeder Commit wird direkt automatisiert integriert. Jenkins, TeamCity oder andere Tools helfen dabei, regelmässig alle paar Minuten einen aktuellen Build zu erstellen und auf einen CI Server zu deployen. Die Abnahme der Feature erfolgt entweder auf dem CI Server oder einer separaten Stage der Build Pipeline.

Eines der Ziele, die wir uns für die Lhotse Plattform gesetzt haben ist Continous Delivery: Änderungen sollen nicht nur kontinuierlich integriert, sondern auch rasch in Produktion genommen werden, sobald die Abnahme erfolgt ist. Wie wir das in der Praxis erreichen wollen, ist ein anderes Thema. Damit wir aber prinzipiell in der Lage sind, jederzeit eine neue Version live zu stellen, muss das System in der Lage sein, ohne Unterbrechung auf ein neues Release umzuschalten.

Der Begriff „Architektur“ bzw. „Software-Architekt“ hat in der Softwareentwicklung nicht den besten Ruf. Man denkt unwillkürlich an umfangreiche Konzepte, fehlenden Pragmatismus, Elfenbeintürme, Architektur-Reviews, merkwürdige UML-Diagramme voller Halbwahrheiten, „upfront design“, usw. usf. So ganz ohne Leitlinien geht es aber natürlich auch nicht…

Donnerstag, 28.2.2013: Livegang alpha.otto.de

Um 12:00 wurden die ersten paar tausend Einladungen an Kunden versendet, die ersten „echten“ Kunden trudeln ein: alpha.otto.de, ist live! Eine vollständig neu entwickelte Shop-Plattform, die ab Herbst die Grundlage für otto.de bilden wird.

Mit der Alpha Version wollen wir erste Erfahrungen in der freien Wildbahn sammeln, den Betrieb der Plattform üben und – vor allem – Feedback von Kunden für die Weiterentwicklung erhalten.