In dem letzen Artikel in dieser Serie haben wir festgestellt, dass es bei der digitalen Transformation im Grunde darum geht Hypothesen aufzustellen, die es zu validieren gilt. Wir brauchen Experimente, die wir für echte Nutzer / Kunden ausrollen und beobachten was die Zielgruppe mit unserer Hypothese anstellt. Aus den Erkenntnissen stellen wir neue Hypothesen auf usw. Das Ziel ist ein Endprodukt welches der Kunde maßgeblich mit beeinflusst hat. Der beste Weg ist also echte Kunden zu nehmen.
An die IT stellt dies besondere Herausforderungen, denn wir müssen in der Lage sein Software schnell in Produktion zu bringen. Lange Release Zyklen sind hier kontraproduktiv. Die meisten Leser werden aber genau diese Probleme kennen. Es dauert zu lange neue Anforderungen umzusetzen und zu releasen. Hat man dann die neuen Features endlich online schlagen andere Dinge fehl, die vorher funktioniert haben. Microservice Architekturen, automatisierte Tests, Container, continuous integration und continuous delivery sind Mechanismen, die uns helfen diesen Prozess agil zu gestalten. Alles weitere Bausteine der digitalen Transformation.
Microservices
Ein Aspekt bei der Implementierung unserer Systeme ist es agil zu sein und schneller auf Veränderungen reagieren zu können. Des Weiteren muss man der Komplexität traditioneller Anwendungen Rechnung tragen und wie sie sich über die Zeit verändern. Vor nicht allzu langer Zeit und auch heute ist es durchaus noch üblich große Systeme zu bauen dessen Komponenten eine starke Abhängigkeit untereinander aufweisen und meist zusammen in einem großen Applikationsserver deployed werden. Wenn die Feature Anforderungen mit der Zeit wachsen, dann wird dieses System immer größer und komplexer.
Die Reaktion der IT Abteilung ist es mehr Entwickler ins Team zu packen. Das führt dazu, dass natürlich die Code Basis größer wird, Abhängigkeiten und Komplexität zunimmt. Man sagt die Entropie des Systems steigt. In solch einem System sind Probleme bei Releases vorprogrammiert. Dies ist auch der Grund warum Software Releases lange dauern. Aus Entwickler Sicht bedeutet das lang-lebige Feature Branches deren Integration in den Release Branch fehlerträchtig sind. Das System wird mit der Zeit unbeherrschbar und das Ganze zu einem Glücksspiel. Deployments wurden ein hochriskantes „Big-Bang“ Szenario.
Die Service Orientierte Architektur (SOA) aus den frühen 2000ern versprachen eine Entkopplung dieser Monolithen durch Services. Services wurden mit typisierten Contracts und Implementierung gegen vorgegebener Interfaces implementiert. Der Ansatz war schon ganz gut, jedoch setzte diese Architektur ein hoch zentralisiertes Backbone (Enterprise Service Bus) voraus, welche ebenfalls eine zentralisierte Governance erforderte. Conway’s Law war am Werk allerdings im negativen Sinne.
Conway’s Law ist eine Beobachtung von Melvin Conway wie Organisationen sich strukturieren und wie Ihre Kommunikationsmuster sich in den System wieder spiegeln, die sie implementieren. Was wir mit SOA erlebt haben kann mit Conway’s Law beschrieben werden: Die IT Organisationen brauchten Integrations Möglichkeiten, also bildete man ein „Integration Team“. Sie wollten kontrollieren welche Änderungen an einem System durchgeführt wurden, also bildet man ein „Governance Team“ usw. Daraus resultierten Silos und es gab diesen Silos die Autorität Ideen abzulehnen die „Änderung“ bedeuten.
Obwohl SOA eine gute Idee war, so hatte die Implementierung doch Schwächen. Denn eigentlich sollte es helfen von langen Release Zyklen und Big Bang Releases weg zu kommen. Das Ziel Hypothese->Testen->Hypothese bis hin zu einem Mehrwert schaffenden Produkt war damit immer noch nicht erfüllt. Firmen wie Google, Amazon und Netflix haben ihre eigenen Service Orientierten Architekturen und Tools gebaut, die genau diesem Ziel näher kamen. Gerade in volatilen Cloud und verteilte Umgebungen ist die Herausforderung noch größer.
So um das Jahr 2012 haben Martin Fowler und James Lewis einen Begriff geprägt für eine Architektur welches genau diese oben beschriebenen Probleme addressierte. Sie nannten es „Microservices“, allein um auch in der Terminologie einen Unterscheid zu betonen zu den damals üblichen SOA und ESB Implementierungen. Microservices stellen eine Architektur vor, in dem große, monolithische Anwendungen zergliedert werden in kleinere Teile. Dies hat mehrere Vorteile: Komplexität wird beherrschbar, kleinere Teams können an ihren eigenen Service arbeiten ohne das Gesamtsystem zu beeinflussen und Releases unabhängig vom Gesamtsystem durchzuführen. Dies erst ermöglicht kleinere, schneller Releases durchzuführen um Kundenfeedback umzusetzen und agiler zu werden.
Microservices ist zudem ein Vorgehensmodell, welches große Systeme in kleinere Teile zerlegt die eine bestimmte Business Funktionalität kapseln und nach aussen mit anderen Services kommunizieren. Es gibt für diese Kapselung einen ganz bestimmten Grund: unabhängige Deployments und Einführung von Änderungen ohne das Gesamtsystem zu beeinflussen. Alle Vorteile von Microservices aufzuzählen würde den Rahmen dieses Artikels sprengen. Von daher verweisen wir auf andere Quellen im Netz und einen späteren Artikel hier bei skillbyte.
Microservices werden nur möglich wenn man einen hohen Grad an Automatismen und eine funktionierende Delivery Pipeline hat. Microservices, Cloud Plattformen und DevOps Methodiken arbeiten Hand in Hand um Software schneller und sicherer in Produktion zu bringen und dies wiederum – ich kann es nicht oft genug sagen – um Kundenfeedback zu erhalten, daraus bessere Software zu bauen um daraus Mehrwert oder ein besseres Erlebnis zu schaffen. Dann folgt der Umsatz automatisch.
Stellen Sie sich vor Sie könnten Ihre Software 100 mal am Tag deployen anstatt einmal im Quartal. Die Fähigkeit Software schneller zu liefern und Dinge auszuprobieren und schneller zu lernen ist der Schlüssel und das Unterscheidungsmerkmal im Konkurrenzkampf.
In diesem Artikel haben wir den ersten Baustein der digitalen Transformation aus technischer Sicht beschrieben: Microservices. Im nächsten gehen wir auf automatisierte Tests, CI/CD, Container Technologien ein, welche Herausforderungen in dieser schönen neuen Welt existieren und wie man sie meistert.
