Scaling with Microservices and Vertical Decomposition

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. Let us start with microservices: In short, „the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API“ (Martin Fowler). Sometimes, people refer to the code size: for example, a microservice should not have more than 100 lines of code. Personally, I do not find such definitions helpful, for several reasons. I prefer definitions from the feature perspective: A microservice should be responsible for a single use case. In other words, the „Single Responsibility Principle“ known from object oriented development should be adopted to applications. Let us have a look at an example from our online shop. There are different areas in the shop where we are promoting products: similar products, products other people were interested in, and so on. In a monolithic application, we would need a database of product data, having all the attributes needed for any kind of recommendation (in addition to all the information needed by other components of the shop). In the case of otto.de, this is a noticeable amount of data and a rather complex data model. The problem is that it is hardly possible to find a data structure that fits well for every use case. Using a microservice architecture, finding the „perfect“ solution for every kind of problem is much easier. For example, we could have a microservice only responsible for serving a single recommendation type. One service would have to serve „similar articles“, another one „best rated products“, and so on. The data needed to identify „similar articles“ is very different from the data used to select „best rated products“, so both services would have different data structures, fitting exactly their needs. Not only the data structures would differ: the services could also use different implementations, for example, one using in-memory calculations while others would make use of a relational database. A microservice architecture has a whole slew of advantages when compared to monolithic architectures:

  • Microservices are small enough to be developed by only a few developers in a short time.
  • A single developer is able to understand all aspects of a service.
  • It is possible to choose the „best“ programming language for different kind of problems.
  • The code of the service remains compact, without having too much boilerplate code, no need to use heavyweight frameworks or abstraction layers.
  • Together with REST there is an architecture to realize a loosely coupled system of services. There are other options like thrift or protocol buffers, having similar characteristics.
  • Microservices can be developed and deployed independent from each other. This is an important premise for continuous delivery.
  • The development stays highly efficient, while developing monolithic architectures tends to slow down over time.
  • Because microservices are small, it is easy to replace them by newer, better implementations.
  • The development of small services scales better: it is easier to establish independent teams in a microservice architectures than in monolithic ones.
  • The scalability of a distributed system is much better than a monolithic one because the different services can be scaled independently.

On the downside of microservices: like every distributed system, the operation of such an architecture is much more complex than the operation of monolithic systems. We need more hardware resources, it is a must to automate everything, monitoring and alarming is more complex and so on. Another problem is the comprehensibility of a pure microservice architecture for complex systems. Because the system is loosely coupled, consisting of independent applications, it is not easy for developers to „see“ the overall structure of the system.

Microservices

Microservices

This is where vertical decomposition comes into the game. The two concepts fit perfectly together, because vertical decomposition introduces another dimension to scale the system, and they help to give microservices  a structure. Microservices, on the other hand, help us to cut down verticals into smaller pieces, so they do not turn into large monolithic applications. From the outside, a vertical is a black box. There are some REST interfaces, but the internal structure (or micro architecture) is up to the development team responsible for the vertical. Whether or not a team is choosing microservices to realize a vertical is irrelevant from the perspective of other teams or systems, because it is only the URLs of the different REST resources that may differ.

Vertical Decomposition with Microservices

Vertical Decomposition with Microservices

Below the line, combining vertical decomposition with microservices is a great way to build large systems. Like namespaces in object oriented applications are structuring code, verticals are grouping microservices, so it is easier to understand the overall architecture. Microservices are a way to implement verticals, preventing the teams from turning an initially small vertical into a 100.000 lines of code monster application.

Guido Steinacker, Jahrgang 1969, Diplom-Informatiker. Nach mehreren Stationen in der Software-Entwicklung verschiedener mittelständischer Unternehmen stieß er 2009 zu OTTO. 2010 entwickelte er im Rahmen von Prototypen die Grundlagen für die neue Shop-Architektur von otto.de und ist mittlerweile als Executive Software-Architekt im Bereich E-Commerce tätig.

Tagged with: , , , , ,
Veröffentlicht in Architektur
16 comments on “Scaling with Microservices and Vertical Decomposition
  1. Jan Stenberg sagt:

    I listened to Oliver and Stefan at QCon earlier this year, and talked to Oliver afterwards. To me, the last picture looks more like a traditional Web Service Layered Architecture due to services using other services, and several services using the same database.

  2. Guido Steinacker sagt:

    An interesting article about „Experiences from Failing with Microservices“: http://t.co/L774siOoPJ

  3. Reminds me of the Intelligent Agent systems that we were all building in the 90’s. Additionally the article is clear and concise, thank you for that.

  4. […] 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 …  […]

  5. Hi Guido,

    Thank you for sharing your insights. They are very helpful. I was wondering how your microservices inside a vertical communicate. Is this remote or is this in-process? The other question I have is the following: How many unique (application) instances are you running, given that you have roughly 11 verticals?

    Cheers,

    Mark

  6. […] A nice complementary bullet point list to describe the nature and pros: Scaling with Microservices and Vertical Decomposition (Otto) […]

  7. […] Scaling with Microservices and Vertical Decomposition Discussion of an ecommerce site going from a sort of SOA arch. toward microservices […]

  8. […] Weile entschieden, die vertikale Architektur durch Microservices zu ergänzen. Im dem Beitrag “Scaling with Microservices and Vertical Decomposition” könnt ihr weitere Details dazu lesen. Doch bei der Einführung von Microservices gelangt man […]

  9. […] Scaling with Microservices and Vertical Decomposition […]

  10. […] As for the issue of the monolithic software, a lot has changed in quite a short period of  time. We moved from rather big vertically decomposed systems to micro-verticals and microservices. See for example Guido Steinacker’s post on that. […]

  11. […] are more advantages you can read about on our blog: Scaling with Microservices and Vertical Decomposition and Gibt es etwas zwischen Microservices und monolithischen Architekturen? […]

  12. […] if this is one of the most important topics, because I’ve already covered this in some  earlier articles […]

  13. […] der Logik getrnnt ist, haben Self-contained Services eine UI. Der Versandhändler Otto baut seine Webwendungen als Self-contained Systems, nennt diese aber “verticals”. Auch Galleria Kaufhof setzt auf das […]

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: