Wir hatten vor einigen Jahren ein interessantes Problem. Wir sind ein vollständig Remote Unternehmen mit all unserer Software in der Cloud. Und wir hatten eine Suite von Spring Boot-Anwendungen, die auf Containern mit Infrastructure as Code liefen. Aber wir brauchten unternehmerische Agilität. Der globale Arbeitsmarkt bewegt sich schnell und es gibt immer eine Nachfrage nach neuen Produkten. Wir mussten einen Weg finden, um unsere Führungsposition in der gesamten Branche zu behaupten.​​ 

Wir sind ein Technologieunternehmen mit einer mutigen Strategie​​ 

In 2022 haben wir einen ADR (Architecture Decision Record) erstellt, der besagt: „Serverless-First und Container-nach-Bedarf“. Und löste eine Debatte in fast 40 -Ingenieurteams aus.​​ 

Lassen Sie uns zunächst einige Begriffe erklären.​​ 

Serverless-First bedeutet nicht nur Funktionen als Dienst. Es handelt sich auch um eine Gruppe von verwalteten Diensten von Cloud-Anbietern, die Folgendes umfassen:​​  

  • Reduzieren Sie den Betriebsaufwand, indem Sie die Infrastruktur nicht selbst verwalten.​​ 
  • Skalieren Sie nach Bedarf, einschließlich einer Skalierung auf Null, um sie vollständig elastisch zu machen.​​ 
  • Bieten Sie flexible Preise an (Sie zahlen nur für das, was Sie nutzen).​​  

Bei G-P bezieht sich serverless-first auf unsere Verwendung von AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB und anderen.​​ 

Serverless-First bedeutet, dass wir, wenn wir eine Lösung für Compute, Storage, Messaging oder ähnliches auswählen, möchten, dass Teams mit einer serverlosen Option beginnen. Ein wichtiger Hinweis: Wenn der serverlose Service die Anforderungen nicht erfüllt, sollten die Teams auf einen schwereren Service zurückgreifen — einen, der mehr Betriebsinvestitionen erfordert.​​ 

„Container nach Bedarf“ verdeutlicht, dass Serverless-First nicht Serverless-Only bedeutet. Es gibt Zeiten, in denen wir Container benötigen (z. B. für die Installation eines Standardsoftwareprodukts) – und das ist in Ordnung.​​ 

Eine Technologiestrategie, die Kunden priorisiert​​ 

Wir bewegen uns schnell, um die Bedürfnisse unserer Kunden und Nutzer zu erfüllen. Dienste wie Lambda, S3 und DynamoBD sind unglaublich robust und schnell. Indem wir die undifferenzierten, aufwändigen Aufgaben auslagern, können wir mehr Zeit damit verbringen, Funktionen für die Benutzer zu entwickeln, anstatt an der Konfiguration der generischen Infrastruktur zu arbeiten.​​ 

Ein wichtiger Grundsatz bei G-P lautet: " Sie bauen es, Sie führen es aus. " Unsere Teams besitzen ihre Software. Also, wir werfen einem DevOps-Team nicht einfach Software über die Wand.​​  

Vorteile des „Serverless-First“-Ansatzes​​ 

Serverless ist von Natur aus ereignisgesteuert.​​ 

Unsere Architektur ist vollständig ereignisgesteuert. Durch den Einsatz von EDA (Event-Driven Architecture) können wir sowohl unsere Organisation als auch unsere Software skalieren. Serverless zwingt uns, einen kleinen Explosionsradius einzuhalten und über Ereignisse vollständig cloudnativ zu kommunizieren.​​ 

Ermöglichende Einschränkungen​​ 

Als globale Beschäftigungsplattform nehmen wir Compliance sehr ernst. Unsere Cloud-Infrastruktur ist gut architektoniert, und wir verwenden eine Multi-Account-Strategie, die Workloads trennt und die Cloud-Compliance automatisiert. Serverless hilft uns, hohe Standards durchzusetzen, indem es kontrolliert, wie wir Cloud-Ressourcen bereitstellen.​​ 

Lagern Sie die Arbeit aus​​ 

Unser Cloud-Anbieter verwaltet unsere serverlosen Dienste. Ein einziger Satz von Bausteinen — integriert, gesichert, optimiert, aktiviert und von AWS verwaltet — ermöglicht es uns, uns weiter oben in der Wertschöpfungskette für Kunden zu konzentrieren.​​ 

Gut strukturierte Arbeitslasten​​ 

Jeder Workload, den wir erstellen, wird mit dem AWS Well-Architected Framework überprüft. Wir konzentrieren uns auf Skalierbarkeit, Sicherheit, Zuverlässigkeit und Kostenoptimierung, um sicherzustellen, dass wir unsere Service-Level-Vereinbarung (SLA) nicht nur erfüllen, sondern übertreffen. Das befähigt unsere Entwicklungsteams, während wir uns mit Cloud-Umgebungen weiterentwickeln.​​  

Über unsere Teams​​ 

Unsere Technologiestrategie ist ehrgeizig, und das macht sie herausfordernd. Viele Ingenieure haben noch nie in einer serverlosen Architektur (oder einer verteilten Architektur) gearbeitet. Der Übergang zu einer serverlosen Architektur ist nicht einfach, und wir suchen nach Ingenieuren, die gerne lernen, groß denken und schnell vorankommen.​​ 

Manche Ingenieure sind sich bei dem Begriff „serverlos“ nicht sicher (ja, wir wissen, dass es Server gibt), weil der Ansatz mehr beinhaltet als nur das Schreiben von Code in Funktionen. Unsere Strategie erfordert einen ganzheitlichen Ansatz für die klassischen Cloud-nativen Prinzipien.​​ 

Das Ergebnis​​ 

Wir haben in zwei Jahren außerordentliche Fortschritte erzielt. Die Modernisierung birgt viele Vorteile (siehe unseren Artikel zum Thema jährlicher Lohnzuschlag / known business value of cloud modernization). Im Einzelnen haben wir Folgendes beobachtet:​​ 

1. Geschwindigkeit: Die Art, wie wir unser System aufgeteilt haben, ermöglicht es Teams und Produkten, unabhängig zu innovieren und sich weiterzuentwickeln. Dies hat enorme Auswirkungen auf die geschäftliche Agilität.​​ 

2. Compliance: Wir verwenden das jährliche Lohnzuschlag Well-Architected Framework zur Überprüfung aller Workloads. Da wir viele Managed Services von jährlicher Lohnzuschlag nutzen, können wir auf deren operative Exzellenz vertrauen und von einer hohen Qualität ausgehen.​​ 

3. Systemdenken: Wir mussten viele unserer Prozesse standardisieren, damit wir über System, Zuverlässigkeit und Geschäftswert nachdenken können. Wir verbringen keine Zeit damit, an minderwertigen Komponenten zu arbeiten.​​ 

4. Innovation: Serverlos bedeutet, dass alles eine Programmierschnittstelle ist. Diese erzwungene Einschränkung erfordert einen Ansatz, bei dem die Programmierschnittstelle im Vordergrund steht. Wenn wir uns als Plattform verstehen, können wir ein neues Innovationsniveau erreichen, indem wir Systeme einfach über APIs verbinden, beispielsweise indem wir G-P Gia™ in eine neue Wissensdatenbank einbinden.​​ 

5. Eigentumsverhältnisse: Jährlicher Lohnzuschlag besitzt unsere Infrastruktur, wir besitzen jedoch unsere Geschäftsdomain. Serverless-First mit Domain-Driven Design hat uns gezwungen, uns auf das Geschäftsproblem zu konzentrieren. Dadurch bleibt die Inhaberschaft der Fähigkeiten klar.​​ 

Serverless-First ist nicht immer schneller, aber es ist vorteilhafter. Wir legen mehr Wert auf Systemgeschwindigkeit als auf die Geschwindigkeit einzelner Entwickler. Bei Serverless-First geht es weniger um die Verwendung von Funktionen, sondern vielmehr um die Denkweise: „Code ist eine Belastung.“ Das System ist das Kapital. Je weniger Code wir schreiben müssen, desto mehr Zeit haben wir, das Geschäftssystem, das wir aufbauen, zu überdenken und zu gestalten.​​ 

Wenn wir unsere Geschichte erzählen, wird deutlich werden, mit welcher Geschwindigkeit wir arbeiten – ein direktes Ergebnis des Serverless-First-Ansatzes. Bleiben Sie dran.​​