Blog

Ein kleines Beispiel: Das Unternehmen XYZ hat die Vorteile um Microservices, automatisierten Tests, Containern und CI/CD verstanden und hat es eingeführt. sie haben sich entschieden ihren software Monolithen in Modul A und Modul B zu zerteilen, die als eigenständige Services laufen. Ferner ein Modul C mit einigen neuen und unabhängigen Funktionen. Diese Module wurden in Container gepackt und unter Kubernetes deployed. Als sie anfingen diese Module in Produktion zu deployen stellten sie erste Probleme fest:

• Manchmal waren einige Services sehr inkonsistent in ihrem Antwortverhalten und haben sehr lange zum Abarbeiten der requests gebraucht.
• Manche Services haben unter Last gar nicht mehr geantwortet
• Wenn Service B keine Anfragen beantworten konnte dann antwortete Service A auch nicht, aber nur manchmal und für bestimmte Requests.
• Beim Deployment haben sich Bugs eingeschlichen, die während den automatisierten  Tests nicht abgefangen wurden. Die Deployments wurden im sogenannten Blue/Green deployment durchgeführt. Hierbei wird das neue Deployment komplett in separaten Containern gestartet („green“) und wenn das Deployment durchlief und die Container gestartet wurden, dann wurde der Traffic komplett umgeschwenkt von den alten („blue“) Containern auf die Neuen. Sie hatten gehofft, dass blue-green deployments das Risiko von Deployments verringern würden, aber in der Praxis roch es wieder nach „big-bang“ Releases; was sie eigentlich verhindern wollten. Zumindest hatten die Berater das so gesagt 😉
• Die Teams von Service A und B hatten jeweils eine komplett unterschiedliche Implementierung der Security. Team A wollte sichere Verbindungen mit Zertifikaten und Private Keys. Team B hatte eine eigene Implementierung favorisiert mit Servlet Interceptors. Team C hat gar keine Security Maßnahmen ergriffen, da es sich um interne Dienste handelte hinter einer Firewall.

Dieser Artikel ist Bestandteil einer Reihe welches technische Aspekte der digitalen Transformation beleuchtet.

Automatisierte Tests

Beim Lernen geht es darum, Feedback zu erhalten und unsere Fähigkeit, ein Ziel zu erreichen zu verbessern. Automatisierte Tests ermöglichen es uns, wichtige Teile der Feedbackschleife näher an unsere Entwicklungsabteilung heranzuführen. Wenn wir Änderungen an unserem Code vornehmen, können wir Regressionstests einrichten, um Fehler oder unerwartete Abweichungen von den vorgesehenen Funktionen zu erkennen. Obwohl Komponententests kritisch sind, sollte ein starker Schwerpunkt für automatisierte Tests auf Szenario- oder Funktionstests liegen. Diese Art von Tests zwingen uns, über die API des Dienstes nachzudenken und erlauben es uns auch, einen Einblick zu bekommen, wie unser Code verwendet wird, da unsere Tests letztendlich Verbraucher unserer API sind. Ein starker Fokus auf Feature-Tests wird auch das von unseren Kunden erwartete Verhalten bestätigen, nicht nur das Innenleben des Codes. Schließlich, da sich die Details der Implementierung aufgrund von Refactoring, Rückzahlung der technischen Schulden, Wartung usw. ändern, sollten sich unsere Funktionstests selten ändern müssen.

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.

Bei der XYZ GmbH kann kein Projekt starten bevor ein Budget festgelegt worden ist. Bevor die Entwicklung des Projektes starten kann kommen die Business Stakeholder zusammen und legen die Top Prioritäten fest. Es gibt wochenlang wenn nicht monatelang Meetings, Powerpoint Slides mit geschätzten Kosten und ROI Zahlen, um das Projekt zu rechtfertigen und zu belegen warum das Projekt wichtig ist und warum gerade die gewählte Vorgehensweise die bestmögliche für XYZ GmbH ist. Die hohen Kosten und lange Lieferzeiten resultieren meist aus der Menge an Features welches das Projekt alles liefern soll. 

Wenn die Entscheidung einmal gefallen ist legen dann Business Analysten, Designer und Requirement Engineers los, um eine lange Liste an Anforderungen zusammen zu schreiben. Dies dauert Monate bevor die Anforderungen an die Entwicklung zur Umsetzung gehen. In dieser Phase finden Umpriorisierungen statt, Qualitätstests werden definiert und das Ganze für die Produktion optimiert vorbereitet. Am Ende ist das Projekt weder in-time noch in-budget.