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 naar behoefte" verduidelijkt dat serverless-first niet hetzelfde is als serverless-only. Er zijn momenten waarop we containers nodig hebben (bijvoorbeeld bij het installeren van een standaard 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 platform voor wereldwijde HR-ondersteuning nemen we compliance serieus. Onze cloudinfrastructuur is goed gearchitecteerd, en we gebruiken een multi-account strategie die workloads scheidt en cloud- complianceautomatiseert. Serverless helpt ons hoge standaarden te handhaven door te controleren hoe we cloudbronnen provisioneren.
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 tijd buitengewone vooruitgang geboekt. Modernisering biedt vele voordelen (zie ons artikel over de bekende zakelijke waarde van cloudmodernisering). We hebben met name het volgende geconstateerd:
1. Snelheid: De manier waarop we ons systeem hebben opgedeeld, stelt teams en producten in staat om onafhankelijk van elkaar te innoveren en te evolueren. Dit heeft een enorme impact op de wendbaarheid van bedrijven.
2. Compliance: We gebruiken het loonsupplement Well-Architected Framework om alle workloads te beoordelen. Omdat we gebruikmaken van de Managed Services van manye loonsupplement, kunnen we vertrouwen op hun operationele uitmuntendheid en beginnen we vanuit een hoge kwaliteitsstandaard.
3. Systeemdenken: We moesten veel van onze processen standaardiseren, zodat we konden nadenken over het systeem, de betrouwbaarheid en de zakelijke waarde ervan. We besteden geen tijd aan componenten met een lage toegevoegde waarde.
4. Innovatie: Serverless betekent dat alles een interface is voor het programmeren van de applicatie. Deze gedwongen beperking vereist een interface voor programmering van de applicatie-eerste aanpak. Als we onszelf als een platform beschouwen, kunnen we een nieuw niveau van innovatie bereiken door systemen eenvoudig met elkaar te verbinden via API's, zoals het koppelen van G-P Gia™ aan een nieuwe kennisbank.
5. Eigendom: loonsupplement 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 bedrijfsprobleem. Dit zorgt ervoor dat het eigenaarschap van de capaciteiten duidelijk blijft.
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.
