Vi hade ett intressant problem för några år sedan. Vi är ett helt distansföretag med all vår programvara i molnet. Och vi hade en svit med Spring Boot-applikationer som kördes på containrar med infrastruktur som kod. Men vi behövde affärsmässig smidighet.

Den globala arbetsmarknaden rör sig snabbt, och det finns alltid en efterfrågan på nya produkter. Vi var tvungna att hitta ett sätt att behålla vår ledning i branschen.

Vi är ett teknologiföretag med en djärv strategi

I 2022 skapade vi en ADR (Architecture Decision Record) som sa " serverless-first och containers-as-needed. " Och utlöste debatt i nästan 40 ingenjörsteam.

Låt oss förklara lite terminologi först

Serverless-first är inte bara funktioner-som-en-tjänst. Det är också en grupp hanterade tjänster från molnleverantörer som: 

  • Lägre driftskostnader genom att inte hantera infrastruktur

  • Skala efter behov, inklusive skalning till noll för att göra dem helt elastiska

  • Har elastisk prissättning (du betalar bara för det du använder) 

Hos G-P syftar serverless-first på vår användning av AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB och andra.

Serverlöst-först innebär att när vi väljer en lösning för beräkning, lagring, meddelanden eller liknande, vill vi att teamen börjar med ett serverlöst alternativ. En viktig anmärkning: Om den serverlösa tjänsten inte uppfyller behovet bör teamen återgå till en tyngre tjänst – en som kräver mer operativa investeringar.

”Containers-as-needed” klargör att serverless-first inte betyder serverless-only. Det finns tillfällen när vi behöver containrar (t.ex. installera en COTS-mjukvaruprodukt) - och det är okej.

En teknikstrategi som prioriterar kunder

Vi rör oss i ett snabbt tempo för att möta våra kunders och användares behov. Tjänster som Lambda, S3 och DynamoBD är otroligt motståndskraftiga och snabba. Genom att avlasta det odifferentierade tunga lyftet kan vi spendera mer tid på att bygga funktioner för användare, snarare än att arbeta med generisk infrastrukturkonfiguration.

En viktig princip på G-P är: "Du bygger det, du driver det." Våra team äger sin programvara. Så vi kastar inte bara programvara över väggen till ett DevOps-team. 

Fördelar med ”serverless-first”

Serverlös är i sig händelsedriven.

Vår arkitektur är helt händelsedriven. Genom att använda EDA (Event-Driven Architecture) kan vi skala upp både vår organisation och vår programvara. Serverlöshet tvingar oss att hålla en liten explosionsradie och kommunicera helt molnbaserat via händelser.

Aktivera begränsningar

Som en global anställningsplattform tar vi efterlevnad på största allvar. Vår molninfrastruktur är välstrukturerad och vi använder en strategi för flera konton som separerar arbetsbelastningar och automatiserar molnefterlevnad. Serverlös hantering hjälper oss att upprätthålla höga standarder genom att kontrollera hur vi tillhandahåller molnresurser.

Avlasta arbetet

Vår molnleverantör hanterar våra serverlösa tjänster. En enda uppsättning byggstenar – integrerade, säkrade, finjusterade, aktiverade och underhållna av AWS – ger oss frihet att fokusera högre upp i värdekedjan för kunderna.

Väldesignade arbetsbelastningar

Varje arbetsbelastning vi skapar granskas med AWS Well-Architected Framework. Vi fokuserar på skala, säkerhet, tillförlitlighet och kostnadsoptimering för att säkerställa att vi inte bara uppfyller utan också överträffar vårt SLA (Service Level Agreement). Detta stärker våra teknikteam i takt med att vi fortsätter att utvecklas med molnmiljöer. 

Om våra team

Vår teknologi strategi är ambitiös, och det gör den utmanande. Många ingenjörer har inte arbetat i en serverlös arkitektur (eller en distribuerad arkitektur). Övergången till serverlös arkitektur är inte lätt, och vi söker ingenjörer som är bekväma med att lära sig, tänka stort och röra sig i takt.

Vissa ingenjörer är inte säkra på termen serverlös (ja, vi vet att det finns servrar) eftersom tillvägagångssättet är mer än att skriva kod i funktioner. Vår strategi kräver en helhetssyn på de klassiska molnbaserade principerna.

Resultatet

Vi har gjort extraordinära framsteg på två år. Det finns många fördelar med modernisering (se vår artikel om AWS / känt affärsvärde för molnmodernisering). Specifikt har vi observerat följande:

1. Hastighet: Sättet vi har uppdelat vårt system på gör det möjligt för team och produkter att förnya sig och utvecklas oberoende av varandra. Detta har en enorm inverkan på affärsmässig smidighet.

2. Efterlevnad: Vi använder AWS Well-Architected Framework för att granska alla arbetsbelastningar. Eftersom vi använder många AWS Managed Services kan vi lita på deras operativa excellens och utgå från en plats med hög kvalitet.

3. Systemtänkande: Vi var tvungna att standardisera många av våra processer så att vi kan resonera om systemet, tillförlitligheten och affärsvärdet. Vi lägger inte tid på att arbeta med komponenter med lågt värde.

4. Innovation: Serverlöst innebär att allt är ett API. Denna påtvingade begränsning kräver en Application Programming Interface-först-metod. När vi tänker på oss själva som en plattform kan vi nå en ny nivå av innovation genom att enkelt ansluta system via API:er, som att koppla in G-P Gia i en ny kunskapsbas.

5. Ägarskap: AWS äger vår infrastruktur, men vi äger vår affärsdomän. Serverless-first med domändriven design har tvingat oss att fokusera på affärsproblemet. Detta håller ägarskapet för kapacitet tydligt.

Serverless-first är inte alltid snabbare, men det är mer fördelaktigt. Vi optimerar hellre för systemhastighet än individuell utvecklarhastighet. Serverless-first handlar mindre om att använda funktioner och mer om att tänka, ”Kod är ett ansvar. Systemet är tillgången.” Ju mindre kod vi måste skriva, desto mer kan vi överväga och forma det affärssystem vi bygger.

När vi delar vår historia kommer det att bli uppenbart hur snabbt vi arbetar med, vilket är ett direkt resultat av serverless-first. Håll ögonen öppna.