Vor einigen Jahren hatten wir ein interessantes Problem. Wir sind ein vollständig Remote-Unternehmen mit all unserer Software in der Cloud. Und wir hatten eine Reihe von Spring Boot-Anwendungen, die auf Containern mit Infrastructure als Code ausgeführt wurden. Aber wir brauchten geschäftliche 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ührungsrolle in der gesamten Branche zu behalten.

Wir sind ein Technologieunternehmen mit einer mutigen Strategie

Im Jahr 2022 erstellten wir einen ADR (Architecture Decision Record), der sagte: „serverless-first und container-as-needed“. Und löste eine Debatte über fast 40 Engineering-Teams aus.

Lassen Sie uns zuerst einige Begriffe erklären

Serverless-First ist nicht nur „Functions-as-a-Service“. Es handelt sich auch um eine Gruppe von Managed Services von Cloud-Anbietern, die: 

  • Geringerer Betriebsaufwand durch Nicht-Verwaltung der Infrastruktur

  • Skalieren Sie nach Bedarf, einschließlich der Skalierung auf Null, um sie vollständig elastisch zu machen

  • elastische Preise haben (Sie zahlen nur für das, was Sie verwenden) 

Bei G-P bezieht sich serverless-first auf unsere Nutzung 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 den Bedarf nicht erfüllt, sollten Teams auf einen schwereren Service zurückgreifen – einen, der mehr betriebliche Investitionen erfordert.

„Container nach Bedarf“ verdeutlicht, dass serverless-first nicht nur serverless bedeutet. Es gibt Zeiten, in denen wir Container benötigen (z. B. die Installation eines COTS-Softwareprodukts) – und das ist in Ordnung.

Eine Technologiestrategie, die Kunden Priorität einräumt

Wir bewegen uns in einem schnellen Tempo, um die Bedürfnisse unserer Kunden und Benutzer zu erfüllen. Dienste wie Lambda, S3 und DynamoBD sind unglaublich widerstandsfähig und schnell. Indem wir das undifferenzierte schwere Heben entlasten, können wir mehr Zeit mit der Erstellung von Funktionen für Benutzer verbringen, anstatt an einer generischen Infrastrukturkonfiguration zu arbeiten.

Ein Grundprinzip bei G-P ist: „Du baust es auf, du führst es.“ Unsere Teams sind Eigentümer ihrer Software. Wir werfen also Software nicht nur an ein DevOps-Team. 

Vorteile von „serverless-first“

Serverless ist von Natur aus ereignisgesteuert.

Unsere Architektur ist vollständig ereignisorientiert. Durch die Verwendung von EDA (Event-Driven Architecture) können wir sowohl unser Unternehmen als auch unsere Software skalieren. Serverless zwingt uns, einen kleinen Sprengradius beizubehalten und über Ereignisse vollständig cloudnativ zu kommunizieren.

Aktivieren von Einschränkungen

Als global employment platform Unternehmen nehmen wir Compliance ernst. Unsere Cloud-Infrastruktur ist gut konzipiert, und wir verwenden eine Multi-Account-Strategie, die Workloads trennt und die Cloud-Compliance automatisiert. Serverless hilft uns, hohe Standards durchzusetzen, indem wir kontrollieren, wie wir Cloud-Ressourcen bereitstellen.

Die Arbeit entladen

Unser Cloud-Anbieter verwaltet unsere serverlosen Dienste. Ein einziger Satz von Bausteinen – integriert, gesichert, abgestimmt, aktiviert und gepflegt von AWS – gibt uns die Möglichkeit, uns stärker auf die Wertschöpfungskette für Kunden zu konzentrieren.

Gut durchdachte Workloads

Jede von uns erstellte Arbeitslast wird mit dem AWS Well-Architected Framework überprüft. Wir konzentrieren uns auf Skalierung, Sicherheit, Zuverlässigkeit und Kostenoptimierung, um sicherzustellen, dass wir nicht nur unser SLA (Service Level Agreement) erfüllen, sondern auch übertreffen. Dies befähigt unsere Engineering-Teams, während wir uns mit Cloud-Umgebungen weiterentwickeln. 

Über unsere Teams

Unsere Technologiestrategie ist ehrgeizig und das macht sie zu einer Herausforderung. Viele Ingenieure haben nicht in einer serverlosen Architektur (oder einer verteilten Architektur) gearbeitet. Der Übergang zur serverlosen Architektur ist nicht einfach, und wir suchen nach Ingenieuren, die sich mit dem Lernen, dem großen Denken und dem Tempo wohlfühlen.

Einige Ingenieure sind sich über den Begriff serverlos nicht sicher (ja, wir wissen, dass es Server gibt), da der Ansatz mehr ist als 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ßergewöhnliche Fortschritte gemacht. Modernisierung bietet viele Vorteile (siehe unseren Artikel zu AWS/bekannter Geschäftswert der Cloud-Modernisierung). Insbesondere haben wir Folgendes beobachtet:

1. Schnelligkeit: Die Art und Weise, wie wir unser System aufgebaut haben, ermöglicht es Teams und Produkten, unabhängig zu innovativ und weiterentwickelt zu werden. Dies hat enorme Auswirkungen auf die geschäftliche Agilität.

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 hoher Qualität aus beginnen.

3. Systemdenken: Wir mussten viele unserer Prozesse standardisieren, damit wir über das System, die Zuverlässigkeit und den Geschäftswert nachdenken können. Wir verbringen keine Zeit mit der Arbeit an Komponenten von geringem Wert.

4. Innovation: Serverlos bedeutet, dass alles eine API ist. Diese Zwangsbedingung erfordert einen API-First-Ansatz. Wenn wir uns selbst als Plattform betrachten, können wir ein neues Innovationsniveau erreichen, indem wir Systeme einfach über APIs verbinden, wie z. B. G-P Gia™ an eine neue Wissensdatenbank anschließen.

5. Eigentum: AWS ist Eigentümer unserer Infrastruktur, aber wir sind Eigentümer unserer Geschäftsdomäne. Serverless-First mit domänengesteuertem Design hat uns gezwungen, uns auf das Geschäftsproblem zu konzentrieren. Dadurch bleibt die Verantwortung für die Fähigkeiten klar.

Serverless-First ist nicht immer schneller, aber vorteilhafter. Wir optimieren lieber die Systemgeschwindigkeit als die Geschwindigkeit einzelner Entwickler. Serverless-First bedeutet weniger die Verwendung von Funktionen als die Überlegung: „Code ist eine Haftung. Das System ist das Asset.“ Je weniger Code wir schreiben müssen, desto mehr können wir das Geschäftssystem, das wir aufbauen, berücksichtigen und formen.

Wenn wir unsere Geschichte erzählen, wird es offensichtlich, mit welcher Geschwindigkeit wir arbeiten, was ein direktes Ergebnis von serverlos zuerst ist. Bleiben Sie dran.