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
brauchten
Agilität.Der globale Arbeitsmarkt bewegt sich schnell und es gibt immer eine Nachfrage nach neuen Produkten. Wir mussten einen Weg finden, unsere Führungsposition in der 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 ernst. Unsere Cloud-Infrastruktur ist gut strukturiert, und wir nutzen 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 hat viele Vorteile (siehe unseren Artikel über AWS/ den bekannten Geschäftswert der Cloud-Modernisierung). Im Einzelnen haben wir Folgendes beobachtet:

1. Geschwindigkeit: Die Art und Weise, wie wir unser System aufgeteilt haben, ermöglicht es Teams und Produkten, unabhängig voneinander zu innovieren und sich weiterzuentwickeln. Dies hat massive Auswirkungen auf die Agilität von Unternehmen.

2. Compliance: Wir verwenden das AWS Well-Architected Framework, um alle Workloads zu überprüfen. Da wir viele AWS Managed Services nutzen, können wir uns auf ihre operative Exzellenz verlassen und von einem Ort mit hoher Qualität beginnen.

3. Systemisches Denken: Wir mussten viele unserer Prozesse standardisieren, um über das System, die Zuverlässigkeit und den Geschäftswert nachdenken zu können. Wir verschwenden keine Zeit mit der Bearbeitung von Komponenten mit geringem Wert.

4. Innovation: Serverlos bedeutet, dass alles eine Programmierschnittstelle ist. Diese erzwungene Einschränkung erfordert einen Programmierschnittstellen-First-Ansatz. Wenn wir uns selbst als Plattform betrachten, können wir ein neues Innovationsniveau erreichen, indem wir Systeme einfach über Programmierschnittstellen verbinden, zum Beispiel G-P Gia™ in eine neue Wissensdatenbank einbinden.

5. Inhaberschaft: AWS besitzt unsere Infrastruktur, aber wir besitzen unseren Geschäftsbereich. 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.