Der Container-Zug ist schon einige Jahre unterwegs - aber er ist nach wie vor Lichtjahre davon entfernt , die Universal-Lösung für alle IT-Probleme und Optimierung zu sein.
Viele Beratungsunternehmen preisen das nach wie vor völlig schmerzfrei an.
Container sollen doch alles verbessern, optimieren, beschleunigen ? Oder nicht?
Allgemeingültig betrachtet ganz sicher nicht . Diese Aussagen kommen von einem Spezialisten im RZ-/Cloud-/Großkunden-Bereich für High-availability Cluster, Software Defined Storage, Verzeichnisdienste sowie hochskalierbare und vollautomatisierte Container-Cluster-Infrastrukturen Bereich.
Wenn man sie denn irgendwie versions-übergreifend in einem Sack mit tausenden Schrauben - deren Anzahl , Größe und Form sich im schnellen Release-Zyklen-Wahnsinn permanent verändern - auch reproduzieren könnte. Das ist in Produktivumgebungen ein relativ sinnloses Zeit- und damit Geldverbrennungunterfangen, mit dem selbst OpenShift zu kämpfen hat.
Der Container-Hype läuft ungebremst weiter. Er wächst und skaliert sich selbst in unermessliche Komplexitätsgefilde. Und vor allem bleibt er die Gelddruckmaschine Nummer 1 aktueller IT-Landschaften.
Das Buzzword Container stellt nach wie vor allerorten einen Freibrief für Kompatibilitätsbrüche dar, für die Architekten und Entwickler noch vor wenigen Jahren geteert und gefedert worden wären- Container-„Standards“ hin oder her.
Die ganzen kleinen Blackbox-Klötzchen - sprich die Container bzw die Pods des Control Planes und weiterer Komponenten wie Pipelines - einfach irgendwie funktionieren.
Und wenn nicht … vielleicht funktioniert ja das nächste Klötzchen. Bis zum nächsten Upgrade. Sind ja eh meist nicht mal 100 Tage bis zum nächsten Kubernetes-Major-Release und vielleicht nur die Hälfte bis zur nächsten Pipeline - oder Mesh-Release, also was soll‘s….
Ist das wirklich der richtig Ansatz für Systeme die länger bestehen sollen??
Das US-Department of Defense (DoD) hat mittlerweile erkannt , dass es dringend notwendig ist, den ständigen, agil befeuerten Renewal-Wahn und der permanenten Verkomplizierung einen Riegel vorzuschieben.
Was ist mit der UNIX Regel Keep it stupid simpel ??
Bereits Ende 2018 veröffentlichte das DoD einen Draft namens Detecting Agile Bullshit (das ist absolut kein Scherz, so lautete der offizielle Name).
Sein Ziel: das sinnlose Verbrennen finanzieller Ressourcen (wie in den konzepbedingt stark agil-„lästigen“ DevOps-/Containerisierungsbereichen) drastisch einzuschränken.
Siehe auch:
https://thenewstack.io/the-u-s-department-of-defense-on-how-to-detect-agile-bs/
Sowie ebenfalls als Direktlink:
https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF
Im Grunde genommen spiegelt die Aufteilung in immer komplexer werdende, kleine und extrem kurzlebige Software-Häppchen auch die Entwicklung wider, die sich in unserer Gesellschaft - leider, muss man sagen - mehr und mehr erkennen lässt.
Häppchen müssen stets mundgerecht serviert werden, egal ob‘s hier und da mal nicht so schmeckt oder passt, wie es soll.
Schnell - Schneller am Schnellsten
Das ist das Motto in der Software-Entwicklung die frage stellt sich hier ob nicht ein konzipieren und überdenken der Komponenten durchaus Sinn macht?
Aber dieser Geschwindigkeitswahn spiegelt sich in der Gesellschaft wieder , das alles so aufbereitet werden muss , dass auch Rezipienten mit einer maximalen Aufmerksamkeitsspanne von 30 Sekunden nicht sofort gelangweilt sind.
…die nach wie vor schmerzhafte Realität…
Egal , wie gut die Tools sind : Leider zeigen fast alle bisherigen Erfahrungen, dass er allerwichtigste Teil gern komplett übersprungen wird - nämlich der zwingend erforderliche und sehr sorgfältige durchzuführende Evaluierungsprozess, dessen Ergebnis darüber entscheidet, ob eine Container/Microservice-Landschaft für das eigene Unternehmen bzw bestimmte Produktionsbereiche überhaupt Sinn macht.
Oft wurden bestehende nicht Containerisierung sehr gut funktionierende - Plattformen aufgrund von Präsentationen von Beratungsfirmen bezüglich wir skalieren mal auf Knopfdruck der kostspieligen Container-Abrissbirne übergeben.
Die traurige Bilanz, die selten in den Werbeblasen der Consulting-Unternehmen auftaucht , ist: Bis heute hat ein gutes Drittel der Firmen ihre Projekte zur Containerisierung in Teilen bzw. komplett wieder eingestellt. Und gerade mal ein Viertel der Firmen , die sich überhaupt mit Containern beschäftigen, setzen diese auch halbwegs produktiv ein. Für die anderen gilt: zu teuer, zu aufwendig, auf bestehende Strukturen nicht effizient anwendbar. Für ein zuvor gut funktionierendes Unternehmen kann eine im Vorfeld nicht sorgfältig evaluierte Umstellung auf Container das komplette finanzielle Aus bedeuten.
…und die Komplexitätsfalle
Ein zwangsläufiges Ergebnis , werden den Unternehmen doch oft - wie auch in der Vergangenheit das tolle Cloud-Thema - Technologien zu einem Zeitpunkt als reif verkauft , zu dem sie es lange noch nicht sind. Das Stichwort an dieser Stelle sei ein in einigen Unternehmen oft auf Biegen und Brechen durchgezogener Einsatz des permanently moving targets Vanilla Kubernetes . Noch dazu mit (den dann zwingend benötigten und) zahlreichen, angeflanschten 3rd-Party-Produkten wie Pipelines und Meshes. Natürlich mit - zu Kubernetes -meist völlig asynchronen Produktzyklen ebendieser Produkte.
Daher gilt nach wie vor bzw aktuell umso mehr: Der wichtigste Punkt vor jeder strategischen „Wir containerisieren jetzt einfach mal „ Entscheidung besteht darin, einfach mal das Hirn einzuschalten und dann eine sehr , sehr sorgfältige Evaluierung vorzunehmen, ob Container/Microservice-Landschaften für eine Optimierung des eigenen Unternehmens überhaupt geeignet sind.
Es sei denn, man hält sprechende Gummibärchen in der Werbung für echt.
Dann kann man sich diesen Punkt schenken.
… leider noch mal die traurige Realität
Umstrukturierungen waren in der Vergangenheit erfahrungsgemäß in den wenigsten Fällen tech-driven motiviert. Oder gar sorgfältig vorab evaluiert. Da geht es mehr um möglichst farbenfroh präsentierten Nonsens des jeweiligen Consulting-Unternehmens.
Und da wären wir wieder: Digitalisierung. Nachhaltigkeit. Container in der Cloud. Cloud-Native, KI und Machine-Learning-Systeme.
Na klar!
Irgendwann setzt die Realität und mit ihr die Ernüchterung ein.
Und die Tech-,HR-und Buchhaltungsabteilungen stellen unter dem Strich fest, dass - neben der nach wie vor bedenklichen „Sicherheit „ von Container-Clustern in der Cloud - deutlich mehr Budget , Personal und Arbeitsstunden verpulvert wurden, als es die wunderschönen PowerPoint-Präsentationen doch ursprünglich gepriesen hatten.
Aber dafür steckt das Unternehmen mittlerweile wenigstens im stahlharten Vendor-Lock
des immer teurer werdenden Container-Cloud Hosters.
I-a-a-S, P-a-a-S, F-a-a-S , Serverless,NoOps Nach dem Hype ist vor dem Hype
Hey Leute wie wärs zur Abwechslung mal mit B-a-a-S: Brain as a Service?
Fazit:
Fakt ist Conainer Cluster können mittlerweile viel . Richtig viel.
Aber eben nach wie vor nicht alles . Und sie passen nicht für jeden Einsatzzweck.
Die fünf Schlüsselworte sind und bleiben: Vorher sehr, sehr sorgfältig evaluieren . Punkt
