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

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

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

År 2022 skapade vi en ADR (Architecture Decision Record) som sa, "serverless-first och containers-as-behövs." 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: 

  • Sänk driftskostnaderna genom att inte hantera infrastrukturen

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

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

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

Serverless-first innebär att när vi väljer en lösning för Compute, Storage, Messaging eller liknande vill vi att team ska börja med ett serverlöst alternativ. En viktig anmärkning: Om den serverlösa tjänsten inte uppfyller behovet bör teamen falla tillbaka till en tyngre tjänst - en som kräver mer operativa investeringar.

"Containers-as-behövs" klargör att serverless-first inte betyder serverless-only. Det finns tillfällen då vi behöver behållare (t.ex. installera en COTS-programvaruprodukt) – och det är okej.

En teknikstrategi som prioriterar kunder

Vi rör oss i en snabb takt 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 de odifferentierade tunga lyften kan vi spendera mer tid på att bygga funktioner för användare, snarare än att arbeta med generisk infrastrukturkonfiguration.

En viktig princip vid G-P är: "Du bygger det, du kör 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”

Serverless är i sig händelsedriven.

Vår arkitektur är helt händelsedriven. Genom att använda EDA (Event-Driven Architecture) kan vi skala både vår organisation och vår programvara. Serverless tvingar oss att hålla en liten blastradie och kommunicera på ett helt molnbaserat sätt via händelser.

Aktivera begränsningar

Som global employment platform tar vi efterlevnad på allvar. Vår molninfrastruktur är välorganiserad och vi använder en strategi för flera konton som separerar arbetsbelastningar och automatiserar molnefterlevnad. Serverless 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, inställda, aktiverade och underhållna av AWS – gör att vi kan fokusera högre upp i värdekedjan för kunderna.

Välutrustade arbetsbelastningar

Varje arbetsbelastning vi skapar granskas med AWS välorganiserade ramverk. 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 ingenjörsteam när vi fortsätter att utvecklas med molnmiljöer. 

Om våra team

Vår teknikstrategi ä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 efter 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 serverless (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 av molnmodernisering). Specifikt har vi observerat följande:

1. Hastighet: Det sätt på vilket vi har brutit upp vårt system gör det möjligt för team och produkter att innovera och utvecklas självständigt. Detta har en enorm inverkan på verksamhetens smidighet.

2. Efterlevnad: Vi använder AWS välordnade ramverk för att granska alla arbetsbelastningar. Eftersom vi använder många AWS Managed Services kan vi lita på deras operativa excellens och börja från en plats av 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örlitlighet och affärsvärde. Vi ägnar inte tid åt att arbeta med komponenter med lågt värde.

4. Innovation: Serverless betyder att allt är ett API. Denna tvingade begränsning kräver en API-först-metod. När vi ser oss själva som en plattform kan vi nå en ny nivå av innovation genom att enkelt ansluta system via API:er, som att ansluta G-P Gia™ till en ny kunskapsbas.

5. 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 gör att äganderätten till kapaciteten är tydlig.

Serverless-first är inte alltid snabbare, men det är mer fördelaktigt. Vi vill hellre optimera för systemhastighet än enskilda utvecklares hastighet. 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 affärssystemet vi bygger.

När vi delar vår historia blir det uppenbart vilken hastighet vi arbetar med, vilket är ett direkt resultat av serverless-first. Håll ögonen öppna.