AWS dominiert den Markt, fokussiert aber überwiegend auf Versager-Kunden, was man wunderbar an der Dokumentation und dem Tooling erkennen kann. Doch der Reihe nach:
1. Köder auslegen
AWS stellt ein neues Feature vor. Aufwändig wird dies auf eigenen Veranstaltungen, in Livestreams, Trainings, „User-Groups“ und durch eigene Mitarbeiter auf allen Kanälen beworben. Prägnant und mit bunten Bildern wird das neue „Killerfeature“ vorgestellt: Mit 3 Klicks zum fertigen hyperkonvergenten Cluster! Hier 3x Klicken und ausfüllen und UP YOU GO! SERVERLESS HYPERSCALE.
2. Opfer beissen an.
Die Zielgruppe, also die Opfer, sind Leute aus Organisationen ohne Sachkenntnis und voller Legacy-Problemen. Die Hütte brennt, die Technik ist 20 Jahre alt, der Betriebsrat jammert, die Konkurrenz überholt. Es gibt weder konkurrenzfähige Inhouse-Expertise (oder sie wird nicht verstanden) noch Vertrauen in Mensch und Maschine. Ideale Opfer sind also relativ neue Operations-Verantwortliche, die entweder nicht warm mit dem bestehenden Setup (Menschen + Technik) sind oder glauben, man müsse alles neue aufbauen, statt Schritt-für-Schritt Probleme anzugehen und zu verbessern.
Letztlich ist aber der Ist-Zustand das Spiegelbild der Anforderungen (ob gerechtfertigt oder nicht), Erfahrungen, Management und Personal. Und so wird sich das Ergebnis auch mit einer neuen technischen Grundlage wiederholen oder die Erfahrung geht verloren, wenn man sich des Teams und der Bestands-Infrastruktur entledigt. Das hat den Vorteil, dass man die „Besserwisser“ kaltgestellt hat und somit kein direkter Vergleich (der eventuell die neue Lösung nicht so vorteilhaft dastehen lässt) mehr möglich ist.
Der Prototyp-Operations-Manager hat selbst so gut wie keine technische Expertise und sieht sich als Manager. Er wird von der Präsentation angesprochen, sieht „easy wins“, das „unglaubliche Potenzial“ und erkennt die Risiken nicht: AWS ist etabliert und niemand wurde je gefeuert für das Kaufen von IB…AWS-Ressourcen.
WIN-WIN-Situation!
3. Die Türe fällt ins Schloss
Der Entscheider hat nun mit Unterstützung des Managements die Erlaubnis und den Auftrag, die Infrastruktur auf AWS umzustellen. Hierbei soll ausschliesslich modernste Technologie zum Einsatz kommen, weshalb auch gleichzeitg alles auf Container und Kubernetes umgestellt werden soll. Damit die Umstellung gelingt, wird ein externes Beratungs-Unternehmen engagiert, das der Entscheider zufällig schon lange kennt und das sehr kompetent sein soll. Je nach Budget verbleibt das Beratungsunternehmen quasi dauerhaft im Unternehmen oder platziert strategische Komponenten/Best-Practices, die auch in Zukunft Umsätze generieren sollen.
Zurück zu AWS mit einem Beispiel: Mit dem Einsatz von ECS sollen alle Probleme gelöst werden! Amazon bietet hier Megabyte-Weise Dokumentationen und How-Tos an, die aber allesamt für geistig zurückgebliebene Nutzer entworfen worden sind: Grundsätzlich wird nicht an zentraler Stelle dokumentiert, welche einzelnen AWS-Ressourcen zu Einrichtung und Betrieb notwendig sind, noch wie diese automatisiert erstellt werden können. Stattdessen gibt es, mittlerweile auch auf Kindergartendeutsch, Anleitungen, die das Verwenden der Web-Console beschreiben und dort die notwendigen 30 Schritte anleiten. (Dahinter werden 120 Ressourcen angelegt, deren Reihenfolge und Parametrisierung zwar existenziell sind, aber dem User verborgen bleiben).
Damit meine ich nicht die Dinge ausserhalb von AWS, die natürlich Betriebsgeheimnis von Amazon sind, sondern aus welchen dutzenden Rollen, VPS, EC2 Security Groups, DB Security Groups, VPC Subnets in mindestens zwei AZs, Policies, Lifecycle-Snapshot-Rulesets und sonstwas der gesamte Dienst besteht.
Und wie man dieses Zeug automatisiert und im Schadensfall reproduzierbar wiederaufbauen kann.
Ist das Zufall oder Absicht?
Selbst 50-100 einzelne API-Calls mit dem AWS CLI zum Aufbau einer Basis-Architektur wären wunderbar in einem Shellscript zu dokumentieren, mit Verweisen zu den jeweiligen Verben und Attributen. Gibt es aber nicht.
In seltenen Fällen wird eine „Anleitung mit dem CLI“ veröffentlicht, die aber schon beim Punkt 2 wieder auf manuelle Interaktion im Browser zurückfällt bzw darauf verweist.
Natürlich gibt es Tools wie CloudFormation oder Terraform, die allesamt in der Lage sind, jede AWS-Ressource anzulegen und zu verwalten. Aber welche nun z.B. für ein typisches ECS-Deployment benötigt werden, erfährt man hier auch nicht bzw. muss man bereits wissen, bevor man diese Tools anwenden kann.
Eine AWS-Mitarbeiterin antwortete sinngemäß mit „bei Azure ist es noch schlimmer“ – und sehr wahrscheinlich hat sie sogar recht.
Nachwort
Wir alle wissen aus Erfahrung, dass 95% der Leute sich den Aufwand des Verstehens nicht machen wollen oder werden, sie werden klicken und nochmal klicken und wollen schnell Resultate sehen. Und wenn es nicht mehr funktioniert, explodiert alles. Sie werden es weder in Einzelteile zerlegen noch reparieren können. Und dann werden sie erneut klicken, eventuell woanders klicken und migrieren und hoffentlich ein Backup haben oder mittlerweile schon beim nächsten Unternehmen eine Karrierestufe höher tätig sein.
Und in vielen Fällen ist genau diese Inkompetenz und Verantwortungslosigkeit bei der Technologie-Auswahl auch der Grund dafür, warum überhaupt erst das bestehende Legacy-System so an die Wand fahren konnte. Fehler stellt man nur ab, wenn man versteht, was man falsch gemacht hat und warum. Waren die Anforderungen unrealistisch? Hat man eingesetzte Technologien nicht verstanden? Gab es Teammitglieder oder Teamleiter, die aktiv oder passiv sabotiert haben oder selbst mit falschen Tatsachen „geködert“ worden sind? Wurde auch bisher eher extern zugekauft statt intern das Verstehen zu fördern, also den Wissensaufbau?
Warum also die Fehler nochmal machen, nur weil Amazon AWS draufsteht? Warum lernen wir nicht aus unseren Fehlern und den Fehlern anderer?
Spoiler: Viele tun genau dies hochprofitabel und arbeiten bei den unzähligen IT-Beratungshäusern, die alles von Analyse/Audit, Entwicklung bis zu Betrieb anbieten und Geld aus Unternehmen absaugen, wie Zecken das Blut ihrer Opfer. Ich habe das auch getan.
Aber ich bin bisher immer so fair gewesen, den Kunden die Probleme offen zu kommunizieren, manchmal sogar mit einer schriftlichen Analyse, wie die Mitarbeiter des Kunden die Probleme in Zukunft vermeiden oder noch offene Probleme entschärfen können. Hierbei habe ich versucht „keine Namen zu nennen“ und keine „Schuldigen“ ausgemacht sondern versucht eine produktive Lösung aufzuzeigen. Und die mir übertragenen Probleme in time und Budget gelöst, teilweise sogar Monate vor Projektende (was nicht daran lag, das ich besonders gut bin, sondern…komme gleich darauf zu sprechen).
Wussten die Kunden das zu schätzen? Haben Sie mir weitere Aufträge zukommen lassen oder wenigstens die Chance genutzt, ihr Setup selbst oder mit mir dauerhaft in Ordnung zu bringen? Nein. Fast alle Kunden bzw Abteilungen hat es nach ein paar Jahren zerlegt, die Leute sind gegangen oder entlassen worden. Produkte sind gestorben.
Natürlich bin ich mittlerweile schlauer und habe begriffen, warum das so passiert ist. Technologie spielte überhaupt keine Rolle und die Projektdauer ist oft schlicht eine Budgetfrage und Teil einer innerbetrieblichen Argumentation. Seht, wir müssen so viel Geld bezahlen, damit Externe unser kaputtes System am Leben erhalten! Ich brauche mehr Budgetverantwortung, größeren Headcount und einen Firmenwagen!
Ich hätte also auch locker doppelt so lange benötigen oder halbgare Sachen abliefern können, hätte damit viel mehr Geld verdient und vermutlich meinen Auftraggebern sogar noch besser Gründe für ihre bereits gefallenen Entscheidungen gegeben oder damit geholfen, das Elend früher zu beenden.
Externe werden eingekauft, weil intern ein mieses Betriebsklima herrscht, teilweise zwischen Arbeitsverweigerung und Krieg, zwischen Mitarbeitern, Vorgesetzten, Abteilungen und Managern von Managern. Externe sind apolitische Söldner, die im Namen des internen Auftraggebers strategisch/politisch eingesetzt werden um eine Entscheidung im Sinne des Auftraggebers herbeizuführen: Leute feuern, Leute einstellen, Technologie wechseln, Positionslevel durch Budgetausweitung erhöhen.
Leider „liebe“ ich meinen Job zu sehr. Ich mag funktionierende Software und Infrastruktur, die meinen Kunden hilft, viel Geld zu verdienen. Und das so lange und so viel wie möglich – natürlich mit dem Hintergedanken, dass dann auch meine Dienste beansprucht werden können (aber nicht müssen. Ich möchte lebende Referenzen, keine Leichensammlung in meiner CV).
Es fällt mir sehr schwer, inkl. körperlicher Abwehrreaktion, etwas zu tun, von dem ich genau weiss, dass es Scheisse werden wird und die posaunten Features auch nie realisiert werden können.