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?

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.

Es hat bereits viele Diskussionen über die Vor- und Nachteile von Mobile Web und nativen Apps gegeben. OTTO selbst hat die iPad App hybrid entwickelt. In diesen Beitrag werden wir mehr auf die Vorteile beider Technologien eingehen und nennen Beispiele, wie man diese elegant kombinieren kann. Wir gehen weniger auf eine triviale Pro- und Contra Liste ein, welche bereits genügend im Netz zu finden sind. Wir werden erklären, warum wir uns für die hybride Lösung entschieden haben und weswegen wir keine Cross-Frameworks empfehlen.

Today, most online shop systems offer product recommendations. In addition to the page navigation and the onsite search, recommendations are another good possibility to lead customers to suitable products. If recommendations are based on click streams and purchases of customers, usually an external standard software is used for generating these recommendations. Otto.de uses the prudsys Realtime Decisioning Engine (prudsys RDE).

LHOTSE is the internal code name for our project to re-develop www.otto.de: in-house, based on open source software and using agile methodologies such as Scrum and XP. LHOTSE went live on 24th October 2013 – three months before schedule. Although it took us roughly two years to develop, with a team of more than 100 experts, getting LHOTSE live was practically a „non-event“. So, why did everything work out so well?

Teile und herrsche: Kleine Systeme für grosse Architekturen
von Stephan Kraus, Guido Steinacker, Oliver Wegner

Ein System = ein Team, wenige Richtlinien und viel Freiheit, Eigenverantwortung statt Governance, schlanke Integration über den Web-Standard REST, das Teilen eines großen Problems in viele kleine Probleme sowie permanente Veränderung, statt Angst vor dem großen Release.

In der Ausgabe September/Oktober 2013 des Magazins OBJEKTspektrum haben wir zum Schwerpunktthema „leichtgewichtige Architekturen“ einen Artikel über unsere neue E-Commerce-Plattform LHOTSE geschrieben.

Als in unserem Bereich die Ziele für einen neuen Onlineshop OTTO.de diskutiert wurden, war klar, dass die bestehenden Systeme der Produktdatenversorgung, sozusagen die Lebensader des Shops, „out-of-the-box“ nicht in der Lage sein würden, die nichtfunktionalen Ziele für den Shop mit zu erfüllen. Wieso? Unsere aktuelle Produktdatenversorgung exportiert auf Basis von Datenbanklinks massenhaft Daten, im wesentlichen als Vollexporte (Full Export), zwischen zwei Oracle-Datenbanken. Dabei wird zur Exportlaufzeit jede Menge Geschäftslogik („Business Rules“) ausgeführt, so zum Beispiel die Ermittlung, ob ein Artikel überhaupt exportierfähig für den Onlineshop ist, oder die Bestimmung von Anzeigereihenfolgen der Produkte auf unseren Produktlisten. Und das kostet Zeit.

The easiest way to crash your site.

With all the latest trends in the web such as “Social Sharing”, “Distributed marketing campaigns” or just simple website trackings, people tend to forget about one tiny simple fact:

Dependency on 3rd party vendors stability.

If your website is your sales channel or even your only product you must have the ambition to keep it running and fully functional 24/7 and with 99,99% uptime per year.