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.

Abstract

In the last two months, we started our journey towards a new microservices architecture. Among other things, we found that our existing CD tools were not ready to scale with new requirements. So we tried a new approach, defining our pipelines in code using LambdaCD. In combination with a Mesos cluster we can deploy new applications after a few minutes to see how they fit into our architecture by running tests against existing services.

Part 1: The underlying infrastructure
Part 2: Microservices and continuous integration
Part 3: Current architecture and vision for the future

Abstract

In the last two months, we started our journey towards a new microservices architecture. Among other things, we found that our existing CD tools were not ready to scale with new requirements. So we tried a new approach, defining our pipelines in code using LambdaCD. In combination with a Mesos cluster we can deploy new applications after a few minutes to see how they fit into our architecture by running tests against existing services.

Part 1: The underlying infrastructure
Part 2: Microservices and continuous integration
Part 3: Current architecture and vision for the future

In this part of my article I want to explain how we define microservices and why we think they are the best choice for our applications. Furthermore I will give you a brief introduction outlining which problems we have with common CI tools and how we want to solve them with LambdaCD.

A little more than a year ago, things at work were completely different for me than they are now. I was a Java programmer working on a big, monolithic piece of software. There was also some JavaScript for frontend and MongoDB, some Groovy for scripting Gradle and the occasional Bash script, but if you had called me a 100% Java programmer, I would not have objected. Don’t get me wrong, I enjoyed my job and I always loved to work with Java but as you may relate to, after years of hacking Java, I was a little tired of it. As you may also relate to, I had little hope for the situation to change significantly anytime soon. As it turned out, I was wrong about that. Hugely wrong.

Abstract

In the last two months, we started our journey towards a new microservices architecture. Among other things, we found that our existing CD tools were not ready to scale with those new requirements. So we tried a new approach, defining our pipelines in code using LambdaCD. In combination with a Mesos cluster we can deploy new applications after a few minutes to see how they fit into our architecture by running tests against existing services.

Part 1: The underlying infrastructure
Part 2: Microservices and continuous integration
Part 3: Current architecture and vision for the future

Abstract: „Der Trend zu Microservices in komplexen Systemumgebungen ist die architektonische Antwort auf agile Softwareentwicklung und Continuous Delivery. Kleine Systeme, die unabhängig voneinander entwickelt und separat betrieben werden können – eine Architektur als Enabler für das Business. Den Vorteilen gegenüber stehen aber die klassischen Herausforderungen der Integration. Wie sehen Integrationstests aus, wie kann der übergreifende Betrieb sichergestellt werden und wie werden fachliche Abhängigkeiten behandelt? In diesem Vortrag werde ich anhand der neuen E-Commerce Plattform von OTTO aufzeigen, wie wir den Monolithen Otto.de in vertikale Systeme aufgeteilt und dadurch ein agiles Arbeitsumfeld ermöglicht haben. Besonders für die organisatorischen Konsequenzen werde ich Lösungsansätze mit ihren Vor- und Nachteilen vorstellen. Klassische Querschnittsaspekte wie Tracking, Performance und Security haben wir in die Architektur integriert und diese damit im Laufe der Zeit kontinuierlich weiterentwickelt.“

Die MicroXchg Konferenz am 12./13. Feb. 2015 in Berlin war die erste exklusive Konferenz zum Thema Microservices. In zwei parallelen Tracks gab es verschiedene Vorträge zum Thema Microservices – national und international, aus Anwender- und Beraterperspektive, von Microservice-Pionieren und Kritikern. Dieser Artikel fasst die wesentlichen Aussagen meines Vortrags zusammen und reflektiert die Reise der Otto.de Architektur von einem klassischen Monolithen zu einer verteilten Architektur mit Microservices.

Gibt es etwas zwischen Microservices und monolithischen Architekturen? Die Antwort lautet natürlich: JA. Aber warum?