#Microservices #Container
In nahezu allen Unternehmen hat sich die IT zum zentralen Faktor für den Geschäftserfolg entwickelt. Damit sie nicht zum Hemmschuh wird, muss die IT eine hohe Flexibilität unterstützen und damit die zügige Umsetzung neuer Geschäftsanforderungen ermöglichen. Der Einsatz von Microservices und Container-Technologie spielt dabei eine entscheidende Rolle.
Wie bei anderen IT-Trends auch, folgt die Entwicklung bei den Microservices einer typischen Hype-Kurve: von der Euphorie über die Ernüchterung zum Pragmatismus. Allzu begeisterte und manchmal auch unbedarfte Herangehensweisen haben in der Praxis teils skurrile Blüten getrieben. So kam es vor, dass der Anspruch „Micro“ sehr strikt interpretiert wurde und ein regelrechter Wettbewerb um die kleinste funktionale Einheit, die in einem Service isoliert werden kann, ausbrach. In anderen Fällen waren siebenköpfige Scrum-Teams plötzlich für 50 Microservice-Projekte verantwortlich und waren somit personell gar nicht in der Lage, einen Kernvorteil dieser Architektur auszunutzen – nämlich, dass jedes Projekt unabhängig von allen anderen weiterentwickelt werden kann.
Pragmatismus statt der buchstabengetreuen Umsetzung
Die Lehren aus diesen Entwicklungen: Statt den Code der reinen Lehre zufolge und ohne Berücksichtigung des Kontextes zu zergliedern, sollte „Right-Sizing“ das Motto sein. Wenn einem Software-Architekten die Segregation von Funktionalitäten in mehrere Services vermeintlich dazu zwingt, etablierte Lösungen wie eine Datenbankplattform, in Frage zu stellen, dann ist das sehr wahrscheinlich keine gute Idee. Auch dann, wenn das Endergebnis laut Domain-Driven-Design korrekt aussehen würde. Wichtiger als die Reinheit der Domäne eines Services sind am Ende eher praktische Eigenschaften wie schneller Start/Shutdown, Statuslosigkeit und der problemlose Betrieb auf Container-Plattformen, also klassische Tugenden der 12-Faktor-App.
In verteilten Systemen neue Konzepte zur Datenkonsistenz und -aggregation – etwa Event-Sourcing und CQRS (Command-Query-Responsibility-Segregation) – zusammen mit Microservices zu verwenden, klingt vielversprechend, ist aber auch sehr ambitioniert. Dennoch wurden diese in einigen Fällen zu leichtfertig eingesetzt. Am Ende entstand ein hochkomplexes System, das erhebliche administrative Aufmerksamkeit und Knowhow erfordert, für das sich dann aber niemand wirklich verantwortlich fühlte. Entsprechende Pläne und die Auswirkungen, die sich aus dem Einsatz dieser Systeme ergeben, sollten früh kommuniziert und gegebenenfalls auf den Einsatz verzichtet
werden.
Unter Architekturaspekten empfiehlt es sich, eine evolutionäre statt einer revolutionären Transition existierender Applikationslandschaften zu betreiben: Ein funktionierender Anwendungsmonolith wird nicht in einem Schritt dekonstruiert, sondern es werden nacheinander einzelne, leicht isolierbare, funktionale Domänen ausgegliedert und in separate Microservice-Projekte ausgelagert. Das gibt allen Beteiligten die Möglichkeit, sich sowohl technisch als auch kulturell an das neue Modell zu gewöhnen und ein klareres Bild von den Herausforderungen zu
entwickeln, bevor die großen Aufgaben angepackt werden.
Microservices und Programmiersprachen
Aktuell verbreitet sich Googles neue Programmiersprache Go sehr rasch im Microservice-Umfeld. Entwickler schätzen an Go die Gradlinigkeit bei der Umsetzung gängiger, nicht allzu komplexer Use-Cases – beispielsweise Web-Services mit Datenbank-Backend – und die hohe Performance. Im Zusammenspiel mit dem hochoptimierten Kommunikations-Framework gRPC ist Go eine prädestinierte Lösung für sehr stark frequentierte Web-Services, bei denen massive Skalierbarkeit erforderlich ist.
Aber auch Java- und andere JVM-basierte Sprachen spielen eine wichtige Rolle; unter den Frameworks sind Spring Boot und Java EE die Spitzenreiter. Funktionale Plattformen wie AWS Lambda oder Google Cloud Functions sind im Kommen und stoßen auf großes Interesse. Sie müssen aber noch zeigen, ob sie für den Mainstream der Anwendungsfälle das Werkzeug der Wahl sind oder ob sie eine Nischenlösung bleiben.
Container-Plattformen für den Betrieb von Microservices
Eine Reihe von Entwickler-Teams haben mit dem Aufkommen von Docker vor ein paar Jahren bereits viel Energie und Knowhow in den Aufbau eigener Plattformen für den containerisierten Betrieb und das Testing investiert. Nun aber etabliert sich eine neue Generation von integrierten Lösungen für das Container-Clustering wie Google Kubernetes, Red Hat OpenShift Container Platform (Abb. 1) oder Docker Datacenter, die gerade hinsichtlich einfachen Betriebs und funktionalen Umfangs punkten.
Bei den Pionieren ist die Bereitschaft aktuell natürlich gering, die eigenen Lösungen nun wieder zu ersetzen. Nach dem betriebenen Aufwand sind die Prozesse vielleicht gerade erst wirklich etabliert und man identifiziert sich natürlich auch mit der eigenen Herangehensweise. Daher könnte sich diese Early-Adoption jetzt als Hemmschuh herausstellen, da sich die neuen Plattformen, den Eigenbau-Lösungen in Hinsicht Flexibilität und Zukunftssicherheit als überlegen herausstellen könnten. Wer also bislang noch nicht auf den Container-Zug (Abb. 2) aufgesprungen ist, könnte nun bei der Umstellung seiner Infrastruktur so etwas wie die „Gnade der späten Geburt“ erleben und direkt auf eine der gereiften Lösungen der neuen Generation setzen.
Sind Container-Plattformen sicher?
Ein Aspekt, der Betreibern von Container-Plattformen teilweise Kopfzerbrechen bereitet, ist die Kontrolle der deployten Systeme hinsichtlich ihrer Sicherheit – insbesondere wegen der Geschwindigkeit, mit der neue, sehr heterogene Apps aus dem Boden schießen können. Man fürchtet einen allzu ausufernden Wildwuchs von Systemen mit einer unübersehbaren Anzahl aktiver Komponenten in diversen Versionen. Tatsächlich muss sich hier aber erst noch zeigen, wie sensibel das Thema tatsächlich ist, oder ob der partielle Kontrollverlust beziehungsweise die Verlagerung der Verantwortung zum Projekt-Team nicht notwendige Übel sind. Red Hat bietet hier mit der auf einheitlichen Basis-Images aufbauenden s2i-Strategie eine potentielle Lösung.
Public-Cloud oder lieber selber hosten?
Darüber hinaus existiert eine gewisse Unsicherheit, ab welcher Unternehmensgröße es sich lohnt, eine Container-Plattform On-Premise selbst zu betreiben oder ob es nicht oft besser wäre, eines der Angebote von großen Cloud-Providern, wie Amazon AWS, Microsoft Azure oder Google Cloud, zu nutzen. Einigen Firmen erscheinen letztere Lösungen zunächst einmal als teuer, dafür sparen sie sich einen Großteil des administrativen Aufwandes und als Bonus können sie gefühlt grenzenlos skalieren, auch wenn dies die wenigsten Anwender wohl jemals benötigen.
Gerade in Deutschland spielt aber auch der Datenschutz eine zentrale Rolle, der bei US-amerikanischen Cloud-Anbietern aufgrund herrschender Gesetzgebung und gemessen an den hiesigen Anforderungen zumindest mit einem Fragezeichen zu versehen ist. Potentielle Alternativen: Microsofts Azure-Deutschland, das von T-Systems als deutschem Datentreuhänder kontrolliert wird (jedoch seit Herbst diesen Jahres nur noch von Bestandskunden genutzt werden kann), oder dem auf Red Hat OpenShift Container-Platform-basierten AppAgile-Angebot, ebenfalls von T-Systems, das deutschem Recht unterliegt.
Oliver Weise ist Development-Teamleiter bei Consol Software in München.
