Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Cloud-Native beschreibt Software, die von der ersten Zeile an für die Cloud gebaut ist, statt für einen Server geschrieben und später dorthin verlagert zu werden. Sie setzt die Umgebung voraus, in der sie lebt: elastisch, verteilt und fähig, sich zu erholen, wenn ein Teil ausfällt. Die Cloud ist nicht der Ort, an dem die App zufällig sitzt. Sie ist eine Eigenschaft, um die herum die App entworfen ist.
In der Praxis heißt das meist ein paar konkrete Dinge, die zusammenwirken. Container verpacken die Anwendung, damit sie überall gleich läuft. Microservices teilen sie in unabhängige Stücke, die für sich skalieren und deployen. Orchestrierung, typischerweise Kubernetes, verwaltet das Ganze. Und Automatisierung übernimmt Deployment und Wiederherstellung, damit Menschen bei Routinearbeit nicht eingebunden sind. Das Gegenteil ist ein Monolith, gebaut für einen festen Server, wo Skalieren heißt, eine größere Maschine zu kaufen. Ein Cloud-Native-Dienst startet stattdessen mehr Kopien von sich, wenn der Verkehr ansteigt, und entfernt sie, wenn er sinkt, und so fängt eine Plattform einen Ansturm am Launch-Tag ab, ohne umzukippen.
Der Lohn sind Resilienz und Elastizität. Der Preis ist echte Komplexität, daher lohnt sich Cloud-Native, wenn Skalierung und Uptime wirklich zählen, und ist überdimensioniert, wenn nicht.
Wir bauen Cloud-Native, wenn die Last es verlangt. Systeme, die hart skalieren, durch Ausfälle hindurch stehen oder mehrmals täglich deployen müssen. Container, sinnvolle Servicegrenzen und Orchestrierung, die sich selbst erholt. Wir greifen nicht aus Reflex dazu, denn ein Monolith ist häufiger die richtige Antwort, als die Branche zugibt.
Wenn Cloud-Native die richtige Form ist, hält die umgebende Disziplin es zusammen. Wir richten CI/CD Pipelines ein, damit Deploys routiniert und umkehrbar sind, stützen uns auf Plattformstandardisierung, um die beweglichen Teile kohärent zu halten, und behalten die Kostenoptimierung im Blick, damit Autoscaling Geld spart, statt es still zu verbrennen. Unternehmen bringen uns ein System, das unter seinem eigenen Wachstum nachgibt, und wir bauen es mit ihnen zu etwas um, das ohne Drama skaliert.
Brauchen Sie ein System, das standhält, wenn der Verkehr ansteigt? Bauen wir es zum Skalieren.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















