Die Zukunft der Infrastruktur ist containerisiert

Heute arbeiten die meisten Technologieunternehmen und Start-ups in der Cloud, aber viele nutzen noch nicht alle entsprechenden Vorteile. Wenn Sie in der Cloud, aber nicht auf Kubernetes sind, nutzen Sie wahrscheinlich proprietäre Lösungen und erstellen und verwalten eigene benutzerdefinierte Tools . Außerdem stehen Sie in Bezug auf die Effizienz, das Ausführen Ihrer Arbeitslasten auf nicht ausgelasteten virtuellen Maschinen (VMs) und der Gefahr, sich von Entwicklungen abzuschneiden nicht ideal da.

Wie viele Tools verwenden Sie heute, um Ihre VMs zu verwalten und zu korrigieren? Wie führen Sie ein Upgrade Ihrer Anwendungen durch? Wie sieht Ihre VM-Auslastung aus? Was Sie jetzt haben, ist vielleicht nicht so effizient. Es treten Ausfälle, Probleme bei der Skalierbarkeit usw. aufgrund von Schwächen in der VM-Architektur auf, die Kosten geraten außer Kontrolle oder Ihre Infrastruktur unterstützt eine Vielzahl von Dingen nicht, die Ihr Unternehmen tun muss:

• Eine MVP in eine skalierbare Lösung umwandeln/umgestalten
• In zusätzliche Cloud-Anbieter expandieren, um gesetzliche Bestimmungen oder Kundenerwartungen zu erfüllen
• Weitere Standorte hinzufügen, um die Latenz zu verringern und einem breiteren Kundenstamm ein besseres Erlebnis zu bieten
• Ende-zu-Ende-Sicherheit verbessern
• Verbesserung der Kundenumgebung (z. B. Serviceverfügbarkeit)

Legacy- und technische Schulden können Sie bremsen. Aus diesem Grund erfolgt zunehmend ein Umstieg auf Kubernetes. Eine moderne Architektur aus verwalteten Containern ermöglicht den Zugriff auf bewährte Muster zum Ausführen einer zuverlässigen und sicheren Infrastruktur. Sie können Ihre Produkteinführungszeit verkürzen und Ihre Produktivität steigern, ohne Abstriche bei Stabilität und Sicherheit machen zu müssen – mit dem zusätzlichen Vorteil, dass Sie mit den besten technischen Fachkräften an Innovationen arbeiten können.

Sie sollten sich außerdem Gedanken darüber machen, ob Sie sich von der Kubernetes-Community und deren Ökosystem abkapseln möchten, da die stabile Innovation dieser Community die aktuellen Branchenstandards und Best Practices definiert. Letztendlich müssen Sie – und das ist aufgrund der aktuellen Probleme auf dem Arbeitsmarkt besonders wichtig – entscheiden, womit Ihre Entwickler ihre Zeit verbringen sollen. Sollen sie Ihre Infrastruktur warten und benutzerdefinierte Tools erstellen und pflegen, oder sollen sie Ihre wichtige Ziele verfolgen und Ihr Unternehmen voranbringen? Ihre Lösung mag aktuell funktionieren, aber Ihre Roadmap enthält wahrscheinlich unerwünschte Elemente wie das Abzahlen von Schulden für Hardware und das Ausfüllen von Lücken in Ihrem Plattformangebot:

• Ende-zu-Ende-Verschlüsselung
• Beobachtbarkeit (Logs, Messwerte, automatisches Logging)
• Richtlinienverwaltung und -erzwingung
• Hochverfügbarkeit und automatisches Failover
• Kostenreduzierung

Kubernetes ist Open Source und plattformunabhängig. Es bietet alle gängigen Tools direkt an. So können Sie jede Phase des Erstellungs- und Bereitstellungszyklus beschleunigen und sichern. Es stellt die Summe aller Bash-Skripts und Best Practices dar, die Systemadministratoren im Laufe der Zeit gemeinsam zusammengestellt haben, als ein System hinter einer deklarativen Gruppe APIs angeboten. Alles ist automatisiert, die Details sind ausgeblendet, es kann direkt verwendet werden. Kubernetes kann einen großen Teil der Infrastruktur als Code eliminieren, während Sie Ihre Plattform zu Infrastruktur als Daten hin verschieben. Sie müssen dafür keinen Code schreiben oder pflegen. Sie sagen Kubernetes was Sie wollen, nicht, was es tun soll. Das spart in Sachen Verwaltungsaufwand jede Menge Zeit.

Wenn Sie herkömmliche Arbeitslasten ausführen möchten, können Sie dies auf einer modernen Plattform mit Kubernetes tun. Dazu trennen Sie Anwendungen und VMs und verschieben sie in Container. Das Verwenden von Container-Images für das verpacken Ihrer Software vereinfacht das Upgrade Ihrer VMs. Sie können jetzt die Lebenszyklusverwaltungen der VM und der Anwendung entkoppeln. So wird die VM vereinfacht, da Elemente wie Ruby, Python und Java entfernt werden. Verschoben an die gewünschte Stelle neben der Anwendung des Entwicklers können Sie nun alles an einem Ort steuern und Ihre Maschinen sauber halten.

Verwaltete Computing-Plattformen wandeln Cloud-Dienste in PaaS (Platform as a Service) um. Damit erhalten Sie die Leistung und Flexibilität von Containern und den Komfort des serverlosen Computing. Es gibt keinen Server, keine Clusterkonfiguration und keine Wartung. Das bedeutet, dass Sie einen enormen Vorteil erzielen und gleichzeitig die Kontrolle behalten können.

Bei Arbeitslasten, die keine große Kontrolle über die Clusterkonfiguration erfordern, können Sie die Dienste die zugrunde liegende Infrastruktur, einschließlich Knoten und Knotenpools, bereitstellen und verwalten lassen, während Sie nur für die Arbeitslast und nicht für den Cluster bezahlen. So können Sie die Clusterverwaltung vermeiden und dabei die Sicherheit optimieren und potenziell erhebliche Geldbeträge sparen.

Bei mehr cloudnativen Anwendungen bedeutet der serverlose Ansatz, dass weniger Aufwand erforderlich wird, da so die zugrunde liegende Infrastruktur entfällt und das Angebot als End-to-End-Host für Ihre Anwendungen, Daten und sogar Analysen dient. Mit einer serverlosen Plattform können Sie Container in einer vollständig verwalteten Umgebung mit minimaler Komplexität, hoher Sicherheit, Leistung, Skalierbarkeit und eingebundenen Best Practices ausführen.

Sehen wir uns die möglichen Auswirkungen auf Ihr Unternehmen an, nebst Optionen dazu, wie Sie Ihr Unternehmen der Effizienzkurve immer einen Schritt voraus halten können.

Für manche Unternehmen ist es notwendig, in mehreren Clouds zu arbeiten. Die Datenbindung sind real. Wenn Sie einen globalen Kundenstamm haben, werden Sie Kunden haben, die Latenzen und Netzwerkgebühren minimieren möchten, indem die Rechenressourcen nahe am Standort der Daten bleiben.

In solchen Fällen kann die Multi-Cloud Ihren adressierbaren Markt vergrößern; Sie werden ohnehin verwaltete Dienste und Daten bei anderen Anbietern unterstützen. Andere Unternehmen schätzen Multi-Cloud als Strategie zur Risikobewältigung. In beiden Fällen liegt der Schlüssel beim richtigen Einsatz von Multi-Cloud; auf Branchenstandards basierende Lösungen können helfen.

Erstens: Es sollten so viele Ihrer Workflows wie möglich wiederverwendbar sein, um Aufgaben schnellstmöglich zu erledigen. Unter "Workflows" verstehen wir die Aufgabenautomatisierung, mit der die Dataflow-Architektur zwischen Datenbank und Compute erstellt wird. Hier ist Open Source wichtig. Wenn Sie eine Datenbank wählen, die nicht Open Source ist, ist es schwierig, die Dataflow-Architektur und -Automatisierung zu implementieren. Sie verwenden besser etwas wie das Postgres-Protokoll (z. B.Cloud Spanner) oder eine verwaltete Postgres-Datenbank (z. B. Cloud SQL) bei einem beliebigen Cloud-Anbieter. 

Zweitens: Kubernetes spart erheblich Zeit bei der Bereitstellung und Automatisierung von Rechenressourcen. Wenn Sie also eine Reihe von Technologien auswählen, achten Sie darauf, dass sie über die vom Anbieter festgelegten Grenzen hinaus funktionieren. Grenzen können verschiedene Regionen oder Zonen, verschiedene Projekte oder Konten und sogar die lokale Umgebung oder die Cloud betreffen. Verschwenden Sie keine Zeit auf das Erstellen und Pflegen separater Infrastrukturen für die einzelnen Cloud-Anbieter (z. B. für AWS, Google und Azure). Es würde Ihre Entwickler überlasten, sie auf dem gleichen Stand zu halten. Wenn Sie etwas einmal erstellen und in mehreren Clouds bereitstellen und dann Aktualisierungen vornehmen müssen, können Sie das zentral und konsistent tun. Computing-Stacks wie Kubernetes bieten einen enormen Vorteil für Kunden, die ernsthaft und effizient mit Multi-Cloud arbeiten und nicht jedes Mal das Rad neu erfinden müssen, wenn sie einen neuen Cloud-Anbieter nutzen möchten.

Drittens: Risikomanagement. Wenn Sie Ihren Stack in einer anderen Umgebung ausführen können, verringern Sie das Risiko für den Fall, dass Ihr Cloud-Anbieter ausfällt oder mit Ihrem Unternehmen konkurriert. Organisationen müssen Anbieter auswählen, um ihre Geschäftskontinuität zu gewährleisten und die gesetzlichen Vorschriften einzuhalten. Wenn Sie beispielsweise Abläufe in einer Region verlieren, kommt es nicht zu Ausfallzeiten, wenn Sie einen Ersatzanbieter haben.

Multi-Cloud-Migrationen, die in der Regel gut funktionieren, sind oft solche, die offene Standards nutzen. Beispiel: Kubernetes bietet eine anbieterunabhängige API zum Ausführen von Anwendungen, zum Konfigurieren und Bereitstellen dieser Anwendungen und zum Einbinden von Sicherheitsrichtlinien, Netzwerken und mehr. Stellen Sie sich Kubernetes als Multi-Cloud-Betriebssystem vor. Sobald Sie auf dieser Abstraktionsebene sind, können Sie die Unterschiede zwischen den meisten großen Cloud-Anbietern in der Regel ignorieren.

Wenn Sie sich für die Verwendung von Kubernetes entscheiden, haben Sie verschiedene Möglichkeiten. Sie können es selbst ausführen. Kubernetes ist ein Open-Source-Projekt, das Sie herunterladen können. Dann brauchen Sie Jahre dafür, es in Ihren Cloud-Anbieter oder Ihre bevorzugte Umgebung einzubinden.

Wenn Sie dies jedoch nicht möchten, können Sie ein verwaltetes Kubernetes-Angebot verwenden. Wenn Sie AWS nutzen, bedeutet das EKS. Wenn Sie Azure verwenden, bedeutet das AKS. Wenn Sie Google Cloud verwenden, bedeutet das Google Kubernetes Engine (GKE). All diese Optionen bieten Ihnen eine gemeinsame Kubernetes API. Wenn Ihr Team die Tools und Workflows ausbaut, können Sie sie dadurch für verschiedene Anbieter einsetzen.

Aber nicht alle Angebote für verwaltete Dienste sind gleich. Kubernetes ist nur so gut wie die Infrastruktur, in der es ausgeführt wird, und GKE füllt die Lücken als ausgereifter, vollständig verwalteter Kubernetes-Orchestrierungsdienst. Seine vollständig integrierte IaaS bietet Folgendes: Bereitstellung von Tau VMs mit einer 42 % besseren Leistung als bei vergleichbaren Angeboten für allgemeine Zwecke¹, Autoscaling für mehrere Zonen und Upgrades sowie Erstellen und Verwalten von GPUs, TPUs für maschinelles Lernen, Speicher-Volumes und Sicherheitsanmeldedaten nach Bedarf. Sie müssen nur Ihre Anwendung in einem Container platzieren und ein System auswählen, das Ihren Anforderungen entspricht.

Was ist, wenn Sie AWS als Cloud-Anbieter für VMs ausgewählt haben? Müssen Sie bei EKS bleiben? Auf übergeordneter Ebene ist Kubernetes für alle Cloud-Anbieter gleich. Sie erhalten die Kubernetes API. Unter der API befindet sich alles Nötige, ein Cluster, Worker-Knoten, Sicherheitsrichtlinien usw., und das ist das Besondere bei GKE.

Wenn Sie beispielsweise andere Cluster benötigen, können Sie eine Verbindung zu GKE Connect herstellen, wodurch Sie diese an einem zentralen Ort verwalten, anzeigen, prüfen und reparieren können, während Sie gleichzeitig Elemente wie Anmeldedaten zentral verwalten. GKE holt dank der End-to-End-Verwaltung das Beste aus Kubernetes heraus, nicht nur wegen seiner Steuerungsebene oder der Hochverfügbarkeit über mehrere Regionen oder Zonen hinweg. GKE kann außerdem globale Load-Balancer mit dem zentral verwalteten Multi-Cluster-Ingress über mehrere Cluster und Regionen nutzen.

Was, wenn Sie die Kubernetes API nutzen, aber nicht die Verantwortung für die Bereitstellung, Skalierung und das Upgrade von Clustern übernehmen möchten? Bei den meisten Arbeitslasten abstrahiert der GKE Autopilot die zugrunde liegende Infrastruktur des Clusters, einschließlich Knoten und Knotenpools. Sie zahlen dann nur für die Arbeitslast. Beim GKE Autopilot geht es darum, Ihnen die standardmäßige Kubernetes API mit allen ihren hohen Sicherheitsstandards zu bieten. So können Sie sich ganz auf Ihre Arbeitslasten statt auf den Cluster konzentrieren.

__________________________

¹ Die Ergebnisse beruhen auf einer geschätzten SPECrate®2017_int_base, ausgeführt auf Produktions-VMs von zwei anderen führenden Cloud-Anbietern und Google Cloud Tau VMs in der Vorproduktion mit vom Anbieter empfohlenen Compilern. SPECrate ist eine Marke der Standard Performance Evaluation Corporation. Weitere Informationen finden Sie unter www.spec.org.

Kubernetes hat Organisationen von VMs in eine neue Abstraktionsgruppe verschoben, mit denen Sie Vorgänge automatisieren und sich auf Ihre Anwendungen konzentrieren können. Für spezifischere Arbeitslasten (z. B. Web- und mobile Anwendungen, Backends von REST APIs, Datenverarbeitung, Workflowautomatisierung) können Sie dank dem serverlosen Modell jedoch noch weiter vereinfachen und Ihre Bereitstellung optimieren.

Vielleicht verwenden Sie AWS Lambda, eine beliebte serverlose Plattform, mit der Sie Funktionen als Dienst schreiben und mit verschiedensten Ereignissen verbinden können. Da Sie aber eine Verbindung zu einer Datenbank herstellen und Sicherheitsbedenken bewältigen müssen, wächst die Komplexität dieser Funktionen meist. Manche werden sogar komplexer als normale Anwendungen. Was, wenn Sie eine Anwendung haben, deren Komplexität die Einfachheit einer Funktion als Dienst sprengt, oder eine vorhandene Anwendung, die Sie serverlos ausführen möchten?

Im Gegensatz zu einer herkömmlichen serverlosen Plattform, die das Umschreiben Ihrer Anwendungen erfordert, bietet Cloud Run einen Ansatz, der Ihnen dabei hilft, vorhandene Investitionen in containerisierten Anwendungen wiederzuverwenden. Obwohl GKE ein verwalteter Dienst ist, müssen Sie einige wichtige Entscheidungen treffen: In welchen Zonen wollen Sie arbeiten, wo sollen Logs gespeichert werden, wie sollen der Traffic zwischen verschiedenen Anwendungsversionen, registrierte Domainnamen und SSL-Zertifikate verwaltet werden?

Cloud Run eliminiert alle diese Entscheidungen. Dadurch umgehen Sie traditionellere Arbeitslasten ausführen und Kaltstarts, da Sie Skalierungen ganz vermeiden. Wenn Ihre Anwendungen ständig ausgeführt werden müssen, unterstützt Cloud Run dies zusammen mit anderen traditionellen Anforderungen wie NFS-, WebSockets- und VPC-Integrationen. Wie die meisten traditionellen serverlosen Plattformen ist auch Cloud Run tendenziös und bietet Funktionen wie die integrierte Traffic-Verwaltung und das Autoscaling.

Angenommen, Sie haben noch nie Container verwendet und fragen sich, wo Sie anfangen sollen. Im Folgenden finden Sie einen pragmatischen Ansatz für die Einführung der Containerisierung.

Der erste Grund für den Umstieg auf Container ist die Lösung des Verpackungsproblems. Aktuell wird viel Arbeit geleistet, um reproduzierbare Artefakte zu produzieren und zu verstehen, was unsere Software eigentlich enthält. Die Branche spricht hier von der „sicheren Softwarelieferkette“. Wir denken, der ideale Weg, dies zu erreichen, ist die Verwendung von Container-Images, die Ihren Anwendungscode und Ihre Laufzeiten nebst deren Abhängigkeiten enthalten. Ein Vorteil von Containern besteht darin, dass sie auf VMs bereitgestellt werden können. Das reduziert die Komplexität der Bereitstellung und Wartung von Software auf allen Ihren Maschinen.

Der zweite Grund für die Einführung von Containern ist die Orchestrierung. Die Verwaltung von VMs bringt viel Verwaltungs- und Pflegeaufwand mit sich. Ihr Team führt wahrscheinlich Dutzende oder Hunderte von Schritten für die Verwaltung Ihrer Infrastruktur aus. Selbst wenn diese Schritte automatisiert sind, fallen für Automatisierungstools dennoch laufend Wartungsaktionen an. Dabei gehen wir davon aus, dass Sie branchenübliche Automatisierungstools wie Terraform, CPI, Chef und Ansible verwenden. Der Pflegeaufwand ist bei lokalen oder benutzerdefinierten Tools sogar noch höher.

Der dritte Grund für den Umstieg auf Container ist die Effizienz. Neben den Kosten für die Wartung erreichen die meisten Organisationen nur eine CPU-Auslastung von 5 bis 10 % – ganz zu schweigen von Arbeitsspeicher und Speicherung. Das ist viel Ressourcenverschwendung. Viele Teams erstellen noch weitere benutzerdefinierte Tools, um diese Lücke zu schließen, indem sie Funktionen wie Autoscaling und Bin-Packing implementieren, und so weitere Betriebszeit verschwenden. Dies führt zu Budgetüberschreitungen und einer überraschend hohen Cloud-Rechnung.

Nur sehr wenige Organisationen können erfolgreich eine eigene Orchestrierungsplattform aufbauen. Daher ist die Verwendung einer Open-Source-Plattform wie Kubernetes, Mesos oder Nomad eine typische Wahl. Wenn Sie aber eine Plattform nutzen möchten, die Vorteile wie reduzierte Wartung, branchenübliche Best Practices und eine tiefe Einbindung in die weiteren Elemente Ihres Cloud-Anbieters bietet, sollten Sie sich für einen verwalteten Dienst wie GKE entscheiden, um den Wert Ihrer Container zu maximieren.

Vielleicht fragen Sie sich jetzt, ob die Migration zu Containern eine Menge Ausfallzeiten verursacht, ohne dass sich daraus ein Nutzen ergibt? Sie wollen ja auf keinen Fall die Pausentaste in Sachen zukünftiger Entwicklungen betätigen, oder?

Um diese Frage zu beantworten wollen wir zeigen, wie man die Sache richtig angeht, wobei wir Ihre bisherige Cloud-Erfahrung berücksichtigen werden.

Die Migration von Anwendungen von VMs in Container kann wie ein großes Wagnis wirken, insbesondere wenn dabei die gesamte Rechenarbeit zu einem neuen Cloud-Anbieter verschoben werden muss. Aber in der Praxis können Sie das weniger riskant angehen. Sie können Anwendungen nacheinander migrieren, wobei Sie mit VMs beginnen und dann jeweils eine oder zwei Anwendungen in Kubernetes bewegen, wo sie nebeneinander im selben Netzwerk leben und mit den VMs kommunizieren. Eine „Alles-auf-einmal“-Transition ist nicht notwendig. Sie können langsam von einer Plattform zur anderen wechseln.

Es kann sinnvoll sein, für einige Anwendungen weiter auf VMs zu setzen, z. B. bei großen, komplexen Datenbanken, die wenig von Kubernetes profitieren. Das ist Ok. Hier darf gemischt werden. Wir haben jedoch festgestellt, dass die meisten Kunden klar vom Bewegen ihrer Anwendungen und Open-Source-Projekte in Kubernetes-Umgebungen profitieren. Priorisieren Sie die Anwendungen, die durch den Wechsel zu GKE den größten Ertrag erzielen. Sie müssen nicht alles auf einmal verschieben.

Kubernetes wird auf den gleichen Linux-VMs ausgeführt, die Sie wahrscheinlich bereits verwenden. Was Sie wirklich erhalten, ist ein schlankerer und einheitlicherer Workflow, der viele Elemente umfasst, die in Ihrer Infrastruktur-Roadmap enthalten sein sollten, statt etwa einer Sammlung selbst erstellter Skripts und Automatisierungsfunktionen. Mit einem branchenüblichen Tool wie Kubernetes lässt sich die Einbindung neuer Teammitglieder viel einfacher gestalten, denn Sie müssen ihnen nicht all die speziellen benutzerdefinierten Ansätze Ihres Unternehmens erklären.

An diesem Punkt haben Sie einen Weg, um Container langsam, aber pragmatisch einzuführen, und sparen dadurch Ihrem Team Zeit in Sachen Verwaltungsaufwand und Geld bei den Computing-Kosten.

Wir haben viel über Container und Cloud-Migrationen gesprochen – egal, ob Sie komplett in Kubernetes arbeiten und ein besseres Angebot suchen, oder ob Sie einen neuen Ansatz wählen möchten, der zu Ihren bestehenden Anwendungen und Ihrer Roadmap passt.

Unabhängig von Ihrem Anwendungsentwicklungspfad können verwaltete Container Ihre Infrastrukturkosten minimieren. Gleichzeitig kann Ihr Team sich ganz auf die Erstellung großartiger Produkte konzentrieren. Die Zukunft der Infrastruktur ist die Containerisierung. Jetzt ist die Zeit, Ihre Entwickler und Ihr Unternehmen auf Erfolgskurs zu bringen. 

Kubernetes zu Cloud Native: Starten Sie Ihren Weg hin zur Entwicklung mit GKE

Container in der Cloud: Eine bessere Option, Anwendungen zu entwickeln und bereitzustellen

Vergangenheit, Gegenwart und Zukunft von Kubernetes mit Eric Brewer

Der Wechsel zu cloud-native: Ein evolutionärer Ansatz zur Steigerung der Entwicklerproduktivität