Container: Bei Gesprächen fragt man heute nicht mehr „ob“, sondern „wie“.

Ich habe kürzlich ein Unternehmen gebeten, seine Containerstrategie zu beschreiben, und mir wurde gesagt, man habe noch keine, „aber das macht nichts, denn die Konkurrenz hinkt bei dieser Technologie Lichtjahre hinterher“.

Ich hoffe, diese falsche Annahme ist nicht allzu verbreitet, denn sie könnte sich für diejenigen, die sie teilen, als kostspielig erweisen. Als Director of App Transformation bei Rackspace arbeitet mein Team mit vielen Kunden – einige davon in der gleichen Branche wie der vermessene Redner – in diversen Phasen der Container-Einführung zusammen.
Die Realität sieht so aus, dass die Container-Einführung bereits in vollem Gange ist: Gartner schätzt, dass 75 % der globalen Unternehmen in den nächsten zwei Jahren Container in der Produktion einsetzen werden. Und warum auch nicht?

Container erzwingen die Modularisierung und erfordern Automatisierung in einem Maße, bei dem zum Hinzufügen einer Funktion oder dem Beheben eines Tippfehlers nichts weiter nötig ist, als den Code an die Quellenkontrolle zu übergeben und zuzusehen, wie die automatisierte Pipeline den Build ausführt, natürlich mit statischer Code-Analyse, Unit-Tests und automatisierten Akzeptanztests sowie der Bereitstellung in der Produktionsumgebung.

Container ermöglichen Multi- und Hybrid-Cloud-Lösungen

Der weitere große Vorteil besteht natürlich darin, dass Container den immer beliebteren Hybrid-Cloud-Ansatz ermöglichen, zu dem immer mehr CIOs tendieren. Die jährliche Wachstumsrate von 27 % spiegelt die Fähigkeit von Hybrid-Lösungen wider, größere Flexibilität und Effizienz zu liefern und gleichzeitig Sicherheitspräferenzen, Compliance-Anforderungen und Anforderungen an die Datenhoheit zu bedienen.

Bei dieser Mischung von Plattformen kann die Bereitstellung jedoch umständlich sein, da Skripte, die auf eine bestimmte Public Cloud ausgerichtet sind, nicht in einer dedizierten Umgebung funktionieren. Mit Containern ist die Bereitstellung weitaus unkomplizierter. Schließlich sieht ein Kubernetes-API-Endpunkt in einer Public Cloud genau aus wie ein Kubernetes-API-Endpunkt in einer Private Cloud. (Es gibt zwar viele Optionen für Container-Orchestratoren, doch der klare Spitzenreiter ist Kubernetes, weshalb ich mich im Rest dieses Artikels auf diese Technologie beziehen werde). Sobald Sie Kubernetes auf der physischen oder Cloud-Infrastruktur implementiert haben, können Sie das Potenzial von Multi-Cloud-App-Bereitstellungen voll ausschöpfen: erhöhte Portabilität, Flexibilität, Agilität und Geschwindigkeit.

Bei den Container-Fragen von heute geht es primär um das „Wie“

Da so viele Kunden sich heutzutage dieser Vorteile bewusst sind, geht es in den meisten Gesprächen, die ich und mein Team dieser Tage führen, um praktische Grundlagen für die Verwendung von Containern. Ich habe Antworten auf einige der Fragen zusammengestellt, die uns am häufigsten gestellt werden:

Wie schule ich mein Team in Bezug auf Container?

Es gibt nicht die einzig richtige Antwort auf diese Frage, aber es gibt einige wenige führende Ansätze. Erwägen Sie die Hinzuziehung eines Beraters oder eines professionellen Trainers. Auch wenn die meisten Entwickler in der Lage sind, mithilfe von YouTube und Leitfäden wie „Kubernetes the Hard Way“ selbstständig zu lernen, kann es schwierig sein, sich von den täglichen Eskalationen und P1-Fehlerbehebungen loszureißen, um sich auf etwas Neues zu konzentrieren. Ein formeller Schulungsplan mit einem festen Zeitplan kann dem Team helfen, sich auf das Training zu konzentrieren, und ihm ein Instrument an die Hand geben, um zu verhindern, dass Eskalationen während der Schulung für Störungen sorgen. Ziehen Sie in Betracht, einen Teil des Teams für das Training einzusetzen, während der Rest des Teams die bestehenden Workloads am Laufen hält, und lassen Sie nach Möglichkeit alle Ressourcen die Schulung nach einem Zeitplan durchlaufen.

Meine monolithische App hat zu viele technische Schulden, um auf Container umzusteigen

Dies ist eine häufige Sorge, die mit der Wasserfallmethode der Software-Entwicklung verbunden ist und sich mit ein wenig kreativer Programmierung und Architektur überwinden lässt. Microservices müssen nicht alle zusammen im Rahmen einer einzigen, gewaltigen Implementierung bereitgestellt werden. Sie können Stück für Stück abgearbeitet und bereitgestellt werden, sobald sie bereit sind. Es kann erforderlich sein, eine Software-Brücke zu entwickeln, um dieses Ziel zu erreichen – wenn die Legacy-App beispielsweise eine zentrale Datenbank als Datenspeicher und Messaging-Schicht verwendet, fangen Sie damit an! Entwerfen und entwickeln Sie eine Datenzugriffsschicht und beginnen Sie mit dem Refactoring, um eine Nachrichtenwarteschlange wie RabbitMQ oder AWS SQS anstelle der Datenbank zu verwenden. Sie werden diese DAL und MQ ohnehin brauchen, wenn Sie bei Kubernetes ankommen. Die Einführung von Containern erfordert möglicherweise einen mehrstufigen Plan. Stellen Sie fest, welche Schritte auf dem Weg hin zu Containern unternommen werden müssen, und beginnen Sie mit der Erstellung Ihrer Roadmap.

Die Sicherheits- & Compliance-Abteilung lässt mein Team nicht mehr als einmal pro Woche bereitstellen. Wie kann ich ihre Meinung ändern?

Einer der Nachteile von schnelleren und einfacheren Bereitstellungen besteht darin, dass sich eine Schwachstelle ebenfalls leichter bereitstellen lässt. Kommunizieren Sie frühzeitig mit Ihrem Sicherheitsteam und arbeiten Sie mit ihm zusammen, um eine Strategie und Implementierung zu entwickeln, bei der sich das Team mit einem agileren Bereitstellungsansatz wohlfühlt. Ein „Shift left“-Ansatz für Tests und Sicherheit ist bei der Verwendung von Containern unbedingt erforderlich. Statische Code-Analyse mit Tools wie Veracode, Image-Scans mit Tools wie Clair und integrierte CI/CD-Sicherheitsintegration mit Tools wie Twistlock oder Stackrox können dazu beitragen, Ihr Risiko zu mindern. Stellen Sie einen Plan dafür auf, wie Ihr Team die Master- und Worker-Knoten im Falle eines Zero-Day-Exploits patchen wird. Twistlock, Aquasec und Stackrox verfügen allesamt über integrierte Mechanismen, die Ihnen helfen werden, ausgleichende Kontrollen bereitzustellen, bis Sie alles gepatcht haben. Die Integration dieser Tools bedeutet, dass Ihr Unternehmen, Ihre Daten und Ihre Workloads sicherer sind.

Das Entwicklungsteam führt die letzten Tests durch, und die Apps werden auf Kubernetes bereitgestellt. Was nun? Woher weiß ich, ob es funktioniert?

 Vorausschauende Entwickler können gelegentlichTechnologieentscheidungen treffen, bei denen die Betriebsabteilung völlig ratlos ist und nicht weiß, wie sie die neue Laufzeitversion unterstützen soll. Kubernetes ist eine relativ neue Technologie, und das Ökosystem um sie herum ist dynamisch und wächst sehr schnell, was zu einer überdurchschnittlich hohen Zahl von Zero-Day-Exploits und einer wachsenden Liste von Schwachstellen führt. Es ist wichtig zu wissen, wie sich die Laufzeit überwachen und sichern lässt, und dahingehend gibt es eine gewaltige Auswahl an Unternehmen und Produkten. Monitoring-Tools wie Prometheus erfordern eine gewisse Investition von den Entwicklern, während das bloße Setzen einiger Schwellenwerte für Speicherplatz und CPU-Auslastung in Nagios durch die IT-Ops nach Schema F schlichtweg unzureichend ist. Der Lohn für die Zeit, die in das Full-Stack-Monitoring investiert wird, ist umso größer, da die Betriebs- und Entwicklungsteams tieferen Einblick haben und schneller auf Probleme reagieren können.

Meine Apps sind containerisiert, meine Workloads sind sicher und alles ist automatisiert. Kann ich mich jetzt zurücklehnen und entspannen?

 Vielleicht, aber nur für einen Moment. Die Wahrheit ist, dass Sie nicht einfach Pause machen können, selbst wenn Sie die oben genannten Herausforderungen überwunden haben. Kubernetes ist ein unglaublicher technologischer Wegbereiter, doch es ist immer noch neu und im Wachstum begriffen – und wie ich bereits oben erwähnt hatte, bringt es eine beträchtliche Kompetenzlücke mit sich. Am besten integrieren Sie Automatisierungspläne in Ihre Gesamtstrategie und Ressourcenplanung. Bereiten Sie beispielsweise einen Plan vor, damit Ihr nächster neuer Mitarbeiter Kubernetes – und was noch wichtiger ist, den Container-Stack und die Toolchain Ihres Unternehmens – gleich im Rahmen des Onboardings für neue Mitarbeiter kennenlernt.
Stellen Sie Interview-Fragen, die die Fähigkeit eines Kandidaten testen, schnell neue Technologien zu erlernen, denn die Chancen stehen gut, dass Sie keinen erfahrenen Kubernetes-Entwickler in freier Wildbahn finden (oder sich keinen leisten können). Seien Sie offen für Remote-Ressourcen, wenn Sie zu dem Schluss kommen, dass Sie einen erfahrenen Kubernetes-Experten brauchen, denn möglicherweise ist in Ihrer Region niemand verfügbar. Möglicherweise sollten Sie auch Anreize zur Mitarbeiterbindung in Betracht ziehen, um Mitarbeiter zu halten, die sich auf Kubernetes und Ihren speziellen Container-Stack weiterbilden.

Denken Sie zudem daran, dass Kubernetes ein sich entwickelndes Ökosystem ist: Ihr Team wird Zeit für Forschung und Entwicklung benötigen, die fest in seine Arbeitswoche integriert ist, um auf dem neuesten Stand zu bleiben und mit neuen Tools zu experimentieren, sobald diese verfügbar werden. Planen Sie mindestens halbjährlich eine Überprüfung Ihres Container-Stacks und Ihrer Toolchain-Strategie ein, um sicherzustellen, dass Sie mit dem Container-Ökosystem Schritt halten.

Lassen Sie uns auf der KubeCon über Container sprechen!

Um mehr darüber zu erfahren, wie Rackspace-Experten Ihrem Unternehmen mit seiner Container-Strategie helfen können, und zu besprechen, wie wir Sie bei der Lösung der oben genannten Herausforderungen unterstützen können, besuchen Sie uns auf der KubeCon an Stand #S60! Sie können sich außerdem auf unserer Website über unseren Modernisierungsansatz informieren und unser Datenblatt zum Container-Enablement herunterladen.