We hadden een paar jaar geleden een interessant probleem. We zijn een bedrijf dat volledig op afstand werkt en dat al onze software in de cloud staat. En we hadden een reeks Spring Boot-toepassingen die draaiden op containers met Infrastructure as Code. Maar we hadden zakelijke wendbaarheid nodig.

De wereldwijde arbeidsmarkt evolueert snel en er is altijd vraag naar nieuwe producten. We moesten een manier vinden om onze voorsprong in de hele sector te behouden.

We zijn een technologiebedrijf met een gedurfde strategie

In 2022maakten we een ADR (Architecture Decision Record) aan met de tekst: "serverless-first en containers-as-need." En leidde tot discussie tussen bijna 40 technische teams.

Laten we eerst wat terminologie uitleggen

Serverless-first is niet alleen function-as-a-service. Het is ook een groep managed services van cloudproviders die: 

  • Verlaag operationele overhead door de infrastructuur niet te beheren

  • Schaal indien nodig, inclusief schalen tot nul om ze volledig elastisch te maken

  • Heb elastische prijzen (je betaalt alleen voor wat je gebruikt) 

Bij G-P verwijst serverless-first naar ons gebruik van AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB en andere.

Serverless-first betekent dat wanneer we een oplossing kiezen voor Compute, Storage, Messaging of iets dergelijks, we willen dat teams beginnen met een serverloze optie. Een belangrijke opmerking: als de serverloze service niet aan de behoefte voldoet, moeten teams terugvallen op een zwaardere service — een service waarvoor meer operationele investeringen nodig zijn.

"Containers-as-needed" verduidelijkt dat serverless-first niet betekent serverless-only. Er zijn momenten waarop we containers nodig hebben (bijvoorbeeld het installeren van een COTS-softwareproduct) — en dat is prima.

Een technologiestrategie die klanten prioriteit geeft

We handelen in een snel tempo om aan de behoeften van onze klanten en gebruikers te voldoen. Diensten zoals Lambda, S3en DynamoBD zijn ongelooflijk veerkrachtig en snel. Door het ongedifferentieerde zware werk af te schuiven, kunnen we meer tijd besteden aan het bouwen van functies voor gebruikers dan aan generieke infrastructuurconfiguratie.

Een belangrijk principe bij G-P is: " U bouwt het, u beheert het. " Onze teams zijn eigenaar van hun software. We gooien software dus niet zomaar over de muur naar een DevOps-team. 

Voordelen van "serverless-first"

Serverloos is van nature afhankelijk van gebeurtenissen.

Onze architectuur is volledig gebaseerd op gebeurtenissen. Door EDA (Event-Driven Architecture) te gebruiken, kunnen we zowel onze organisatie als onze software opschalen. Serverless dwingt ons om een kleine explosieradius te behouden en op een volledig cloud-native manier te communiceren via EVENEMENTEN.

Beperkingen inschakelen

Als wereldwijd platform voor werkgelegenheid nemen we compliance serieus. Onze cloudinfrastructuur is goed ontworpen en we gebruiken een strategie voor meerdere accounts die de workloads van elkaar scheidt en de cloud compliance automatiseert. Serverless helpt ons om hoge normen te handhaven door te bepalen hoe we cloudbronnen aanbieden.

Laad het werk af

Onze cloudprovider beheert onze serverless diensten. Eén enkele set bouwstenen — geïntegreerd, beveiligd, afgestemd, mogelijk gemaakt en onderhouden door AWS — geeft ons de vrijheid om ons hoger in de waardeketen voor klanten te concentreren.

Goed ontworpen workloads

Elke workload die we creëren, wordt beoordeeld met het AWS Well-Architected Framework. We richten ons op schaalbaarheid, beveiliging, betrouwbaarheid en kostenoptimalisatie om ervoor te zorgen dat we niet alleen voldoen aan onze SLA (Service Level Agreement) maar ook overtreffen. Dit geeft onze technische teams meer mogelijkheden naarmate we blijven evolueren met cloudomgevingen. 

Over onze teams

Onze Technologie strategie is ambitieus, en dat maakt haar uitdagend. Veel ingenieurs hebben niet gewerkt in een serverless architectuur (of een gedistribueerde architectuur). De overgang naar serverless architectuur is niet eenvoudig, en we zoeken ingenieurs die comfortabel zijn met leren, groot denken en in tempo werken.

Sommige ingenieurs zijn niet zeker van de term serverless (ja, we weten dat er servers zijn) omdat de aanpak meer is dan alleen code schrijven in functies. Onze strategie vereist een holistische benadering van de klassieke cloud-native principes.

Het resultaat

We hebben in twee jaar buitengewone vooruitgang geboekt. Modernisering heeft veel voordelen (zie ons artikel over AWS/de bekende zakelijke waarde van cloudmodernisering). Specifiek hebben we het volgende waargenomen:

1. Snelheid: Dankzij de manier waarop we ons systeem hebben opgedeeld, kunnen teams en producten onafhankelijk innoveren en evolueren. Dit heeft een enorme impact op de wendbaarheid van het bedrijf.

2. compliance: we gebruiken het AWS Well-Architected Framework om alle workloads te beoordelen. Omdat we veel AWS Managed Services gebruiken, kunnen we vertrouwen op hun operationele uitmuntendheid en beginnen op een locatie van hoge kwaliteit.

3. Systeemdenken: We moesten veel van onze processen standaardiseren zodat we kunnen redeneren over het systeem, betrouwbaarheid en bedrijfswaarde. We besteden geen tijd aan onderdelen van lage waarde.

4. Innovatie: Serverloos betekent dat alles een Interface voor programmering van de applicatie is. Deze gedwongen beperking vereist een benadering van de Interface voor programmering van de applicatie. Als we onszelf als een Platform beschouwen, kunnen we een nieuw niveau van innovatie bereiken door systemen eenvoudig met elkaar te verbinden via interfaces voor programmering van de applicatie, bijvoorbeeld door G-P Gia™ aan te sluiten op een nieuwe kennisbank.

5. Eigendom: AWS is eigenaar van onze infrastructuur, maar wij zijn eigenaar van ons bedrijfsdomein. Serverless-first met domeingedreven ontwerp heeft ons gedwongen ons te richten op het zakelijke probleem. Zo blijft de eigendom van de capaciteit duidelijk.

Serverless-first is niet altijd sneller, maar het is wel voordeliger. We optimaliseren liever voor systeemsnelheid dan voor individuele ontwikkelaarssnelheid. Serverless-first draait minder om het gebruik van functies en meer om het denken: "Code is een risico. Het systeem is het bezit." Hoe minder code we hoeven te schrijven, hoe meer we het bedrijfssysteem dat we bouwen kunnen overwegen en vormgeven.

Terwijl we ons verhaal delen, wordt het duidelijk hoe snel we werken, wat een direct gevolg is van serverless-first. Blijf op de hoogte.