Neun Jahre Microservices

Microservices sind gerade der Architektur-Hype schlechthin. Aber die Ideen sind schon recht alt und bewährt. Zeit, ein Blick in die Historie zu werfen.

Der Microservices-Ansatz teilt ein System in zahlreiche kleine Dienste auf. Einige der Pioniere berufen sich auf die UNIX-Philosophie, die schon 1969 in dem Betriebssystem umgesetzt wurde:

• Ein Programm soll nur eine Aufgabe erfüllen, und das soll es gut machen.
• Die Programme sollen zusammenarbeiten können.
• Außerdem sollen die Programme eine universelle Schnittstelle nutzen. In UNIX sind das Textströme.

Damit stellt die UNIX-Philosophie zumindest die Aufteilung eines System in kleine Programme in den Mittelpunkt. Bei UNIX sind diese Programme jedoch wiederverwendbar – beispielsweise "grep" zum Durchsuchen von Textströmen oder "sort" zum Sortieren. Microservices setzten üblicherweise eine genau definierte und spezielle Geschäftsfunktionalität um. Außerdem kommunizieren UNIX-Prozesse über Textströme, während Microservices über REST oder Messaging kommunizieren. Also sind die Ideen ähnlich, aber nicht gleich.

Von UNIX zu Amazon

Aber schon 2006 hat Amazons CTO Werner Vogels in einem Vortrag über die Konzepte von Microservices gesprochen. Ich habe damals darüber auch in meinem alten Blog gebloggt. Wesentliche Punkte seines Vortrags damals:

• Die Amazon Cloud stellt die Basis der Arbeit der Teams dar. Sie sind an die Techniken der Amazon Cloud gebunden. Damals gab es in Amazons Cloud nur virtuelle Maschinen (EC2) und die Möglichkeit zur Ablage von Daten (S3).
• Alle weiteren technischen Entscheidungen treffen die Teams. Also lassen sich praktisch alle Techniken nutzen. Diese Technologiefreiheit können auch aktuelle Microservices bieten.
• Die Teams implementieren eine Geschäftsfunktion, die für den Nutzer eine Bedeutung hat. Auch moderne Microservices sollten eine Geschäftsbedeutung haben und idealerweise von einem Team betreut werden.
• Neben der Implementierung sind die Teams auch für den Betrieb zuständig. Diese Idee bekam später den Namen DevOps. Bei dem heutigen Verständnis von Microservices ist DevOps wichtig, aber nicht zwingend.
• Die einzelnen Services können jeweils einen Teil einer HTML-Seite erzeugen, die dann komponiert werden. Eine solche Komposition der UI ist in der Microservice-Welt umstritten, aber einige sehen darin einen wichtigen Pfeiler für Microservices.

Also sind die grundlegenden Ideen von Microservices schon lange in der Praxis bewährt. Damals lag der Schwerpunkt eher auf Skalierbarkeit und Performance. Vor der neuen Amazon-Architektur waren Entwickler viel damit beschäftigt, die Skalierbarkeit ihrer Anwendungen zu garantieren. Dieses Problem hat die Amazon Cloud und der neue Architekturansatz gelöst. Heute ist die unabhängige Arbeit der Teams ebenfalls ein sehr wichtiges Ergebnis einer Microservices-Architektur ist. Jedes Team kann unabhängig neue Versionen der eigenen Funktionen in Produktion bringen, sodass die Umsetzung viel schneller und einfacher ist.

Strategische investionen

Amazon hat zur Umsetzung der Konzepte massiv in die Infrastruktur – also die Amazon Cloud – investiert. Daraus kann man ableiten, wie wichtig dieser Ansatz dem Konzern war. Heute kann jeder auf genau dieser Amazon Cloud oder anderen Techniken aufsetzten, mit denen die Umsetzung dieser Ideen wesentlich kostengünstiger möglich ist.

Und: Amazon hatte damals auch in andere Bereichen schon technische Ideen, die erst viel später in den Mainstream gekommen sind: Als Nebenbemerkung hat Werner Vogels damals auch über das CAP-Theorem gesprochen – das einige Jahre später im Rahmen der NoSQL-Diskussion plötzlich für viele Entwickler relevant wurde und das Amazon mit dem Dynamo-Paper selbst auch umgesetzt hat. ()