Wir bauen eine Applikations-Plattform!

Nach den ersten erfolgreichen Microservices entsteht oft der Wunsch nach einer Applikations-Plattform. Das macht Sinn, um die weiteren Entwicklungsarbeiten zu beschleunigen – doch hier lauern leider einige böse Stolperfallen!

In meinem heutigen Blog möchte ich die häufigsten Probleme skizzieren, die wir immer wieder bei Kunden beobachten können. Sie fragen sich vielleicht, was das Ganze mit unserem Titelbild zu tun hat? Bei genauerer Betrachtung einiges – außerdem sind in unserer Branche witzige Analogien einfach Pflicht 😉

Eine DevOps-Plattform entsteht nicht „unterwegs“!

Mit Microservice-Plattformen und deren Microservices verhält es ähnlich wie mit Flugzeugträgern und Flugzeugen:

  1. Für zwei Flieger lohnt sich kein Flugzeugträger
  2. Der Flugzeugträger transportiert nicht nur Flugzeuge, sondern auch Piloten und Mechaniker
  3. Der Flugzeugträger hat Start- und Landebahnen, deren Länge exakt für die Flugzeugtypen an Bord berechnet und getestet wurde
  4. Beschädigte Flugzeuge können an Bord repariert und wieder aufgetankt werden (Hinweis: Bei Kamikaze-Flugzeugträgern ist dieser Punkt als optional anzusehen)

Leider erkennen viele Firmen diese Zusammenhänge nicht und möchten ihren „Flugzeugträger“ unterwegs bauen. Man stellt also im Hafen vier Flugzeuge auf einen provisorischen Flugzeugträger (20 zusammengebundene Baumstämme mit zwei Außenbordmotoren) und schippert erstmal los in Richtung Einsatzort:

Quelle: Wikipedia Commons

Da die Zeit wie immer knapp ist, hofft man, dass die vier Mechaniker an Bord bis zur Ankunft eine schöne Start- und Landebahn gebaut haben werden. Piloten sind nicht an Bord – die werden unterwegs von einsamen Inseln rekrutiert. Man hofft dadurch Geld zu sparen, denn auf den Inseln wird noch mit Muscheln bezahlt. Der Verteidigungsminister prägte für diesen Vorgang den Begriff „Near-Shoring“: das Abholen von unerfahrenen Piloten direkt am Strand!

Zunächst läuft alles prima und der Regierung (Business-Units) gefallen die Meldungen, dass sich der Flugzeugträger unaufhaltsam dem Feind nähert. Auch die Piloten sind schnell gefunden, denn die Fischer einer kleinen Inselgruppe haben viel Langeweile und finden die als Bezahlung angebotenen Muscheln natürlich klasse:

Quelle: Cargo Cult – The movie

Als man sich dem Ziel angenähert hat ist viel Zeit vergangen und daher muss es einfach schnell gehen: die 12 Ziele sind laut Angriffsbefehl aus der Heimat gleichzeitig zu bombardieren! Der Chef-Mechaniker (der aus Kostengründen gleichzeitig den Kapitän gibt) zählt die drei Flugzeuge an Bord nochmal durch (eines ging unterwegs bei einem Orkan über Bord) und macht sich an die Startvorbereitungen.

Leider haben die durchaus eifrigen Insulaner-Piloten kein Training erhalten, so dass die erste Maschine direkt von der provisorisch zusammengezimmerten Startbahn in den Ozean schlittert:

Quelle: Wikimedia Commons

Bei der zweiten Maschine läuft es besser, denn der Insulaner ist ein Naturtalent. Leider verwechselt er in 200 Meter Höhe den schicken roten Knopf für den Nachbrenner mit dem Auslöser für den Schleudersitz – so dass die Maschine zunächst mal ohne ihn weiterfliegt.

Da nun nur noch eine Maschine aber zwei Piloten zur Verfügung stehen, beschließt der Kapitän die Kompetenzen der beiden zu bündeln: einer soll steuern – der andere navigieren. Die dritte Maschine hebt ordnungsgemäß ab und steuert auch direkt in Richtung des ersten Ziels – in diesem Moment tippt einer der Mechaniker dem Kapitän, der zufrieden dem Flugzeug nachblickt, auf die Schulter und zeigt auf einen Stapel Lenkraketen, der noch an Bord steht. Verdammt noch eins! Da haben die Mechaniker doch glatt in der Hektik vergessen, die todbringenden Geschosse unter die Flügel des dritten Fliegers zu montieren. Sie waren gerade damit beschäftigt, den ersten Piloten aus den Fluten zu retten.

Und die Moral von der Geschicht‘?

Was sollte für eine DevOps-Plattform vorab geklärt sein?

  1. Erst nachdenken – dann losfahren!
  2. Bevor man effektiv angreifen kann, muss der Flugzeugträger fertig sein!
  3. Bevor man sein Ziel koordiniert treffen kann, benötigen die Piloten ein Training!
  4. Bevor eine Maschine abfliegen darf, benötigen die Mechaniker eine Checkliste, die auch unter Stress einwandfrei funktioniert!

Piloten und Mechaniker sind in unserer Analogie untrennbar mit ihrer Plattform verbunden. Selbst die Flugzeuge sind nutzlos ohne Treibstoff, Munition und jemanden der weiß wohin er fliegen muss.  Die Verbindung der Teile ist also das Geheimnis:

Woran erkennt man eine DevOps Microservice-Plattform?

Leider ist es in einer Welt, in der alles irgendwie ein Programm oder Code ist, nicht für jeden Beteiligten so einfach zu erkennen, wie aus den Einzelteilen eine Plattform gebaut werden kann. Wir können zwar über die skurrile Flugzeugträger-Analogie schmunzeln – im echten Leben steht uns aber der kalte Schweiß auf der Stirn, wenn sich der Go-Live einer neuen Funktion um weitere zwei Monate verschiebt…

Woran erkennt man also in der Praxis, ob eine funktionierende Konstellation dieser Einzelteile vorliegt?

Letztendlich geht es darum, dass Entwickler und Ops sich zusammen ihre gemeinsame Welt aufbauen und am Laufen halten:

„Am Laufen halten“ bedeutet hier, dass Entwickler und das Ops-Team ungehindert miteinander kommunizieren können und nicht durch Formalismen behindert oder sogar ganz separiert werden!

Der hierfür relevante Layer innerhalb einer Microservice-Plattform ist der mittlere Layer „Central Services„: wird dieser Layer gleichberechtigt von Dev und Ops-Teams weiterentwickelt und genutzt, dann kann man von einer „echten“ DevOps-Umgebung sprechen. Besonders sichtbar wird dies an den hier erzeugten Artefakten- wenn alle Informationen ständig aktuell sind UND sich die folgenden Dokumentationstypen finden, dann „lebt“ der DevOps-Spirit:

  1.  Schnittstellendefinitionen aus der Entwicklung (z. B. Swagger)
  2. Automatisch erzeugte Endpunkt-Listen (z. B. aus Jenkins)
  3. Testergebnisse sind für alle sichtbar und nachvollziehbar
  4. Handgeschriebene FAQs fügen alles zu einem Gesamtbild
  5. Realtime-Dashboards (z. B. aus ElasticSearch-Log-Quellen)

Wenn Sie bei dieser Liste lächeln müssen und sich denken: „Dokumentation – die doch bei uns eher optional! Die gammelt als Word-Dokumentation auf irgendeinem Netzlaufwerk herum…“, dann leben Sie in einer dem Untergang geweihten IT-Umgebung.

Hilfe – unsere Dokumentation lebt!

In einer Microservice-Plattform ist ein Großteil der Dokumentation entweder über APIs erzeugt oder besteht aus API-Aufrufen (z. B. ein Dashboard, das per API aus AWS die aktuellen Kostendaten visualisiert). Die Dokumentation selbst besteht zum größten Teil aus Tools anstatt aus Dokumenten.

Der Umweg von einem „Betriebshandbuch“ über einen Mitarbeiter, der die Inhalte technisch nachvollziehen kann, bis hin zum „händischen“ Nachtippen der Inhalte des Betriebshandbuchs entfällt also.

Self-Service-Tools für Entwickler = lebende Dokumentation!

Genau in der gedachten „Mitte“ der Central Services sind ein reiferen Architekturen die Self-Service-Tools für Entwickler zu finden. Sie umfassen z. B.

  • Anlegen von neuen Microservices
  • Provisionieren von Resourcen auf der Plattform/Cloud (z. B. DB-Instanzen)
  • Kontrollmöglichkeiten für den Kostenrahmen (Billing-Dashboard)
  • Erweiterte Fehlerdiagnosemöglichkeiten (jenseits der Log-Analyse)
  • Kontrollmöglichkeiten für mehrstufige Backend-Prozesse (Workflow-Dashboard)

Die Self-Service Tools ersetzen Prozesse, die vorher über IT-Service-Desk-Anfragen behandelt wurden, z. B. das Anlegen einer neuen Datenbank. Dabei steht die Automatisierung der Prozesse im Vordergrund und nicht wie (zuvor) deren Abrechenbarkeit. Mit der Automatisierung wird meist auch der Rollback implizit mit realisiert, d. h. das Housekeeping der gesamten Plattform. Viele Kunden realisieren erst spät, dass auch ungenutzte Container in der Cloud ständig bezahlt werden müssen!

Wer soll die Entwicklung der Tools bezahlen?

Damit die Tools ihren maximalen Nutzen entfalten, müssen sie von Devs und Ops gemeinsam genutzt werden. Das initiale Problem dabei: Vor der gemeinsamen Nutzung steht die Erarbeitung dieser Tools! „Wer soll das bezahlen?“, ist meist die Frage aus dem Business, das zwar den Wert in Funktionen für Client-Apps sieht – nicht aber in den „verborgenen Zahnrädchen“, die innerhalb der Application Platform alles am Laufen erhalten…

Die einzige Möglichkeit, dieses Funding-Thema zu adressieren, ist über den gedachten Platform-Owner, der hierzu ein bestimmtes Budget zur Verfügung stellen muss. Jede Hoffnung, dass das Developer-Tooling „auf dem Weg zum Ziel“ von selbst (bzw. kostenlos durch die Entwickler in ihrer Freizeit) gebaut wird ist unrealistisch!

Buchtipp: Site Reliability Engineering

Im lesenswerten Buch von Susan J. Fowler „Production-Ready Microservices“ sind viele wichtige Rahmenbedingungen aufgeführt, die im Konzernumfeld und/oder in Technologie-orientierten Firmen unbedingt beachtet werden sollten.

Ab Seite 17 finden Sie einen Abschnitt „Self-service internal development tools“, der insbesondere im Bezug auf die gesamte Architektur einer Microservice-Plattform interessant ist.

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.