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.
”Containrar-efter-behov” förtydligar att serverlös-först inte betyder endast serverlös. Det finns tillfällen då vi behöver containrar (t.ex. installation av en COTS-programvara) – 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 flerkontostrategi 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 Årligt lönetillägg / känt affärsvärde av molnmodernisering). Mer 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 flexibilitet.
2. Efterlevnad: Vi använder Årligt lönetilläggs välarkitekturerade ramverk för att granska alla arbetsbelastningar. Eftersom vi använder många årliga lönetilläggshanteringstjänster kan vi lita på deras operativa excellens och börja med hög kvalitet.
3. Systemtänkande: Vi var tvungna att standardisera många av våra processer så att vi kunde resonera kring systemet, tillförlitligheten och affärsvärdet. Vi lägger inte tid på att arbeta med komponenter av lågt värde.
4. Innovation: Serverlöst innebär att allt är ett applikationsprogrammeringsgränssnitt. Denna påtvingade begränsning kräver en metod som först bygger på applikationsprogrammeringsgränssnittet (Application Programming Interface). När vi tänker på oss själva som en plattform kan vi nå en ny nivå av innovation genom att enkelt koppla samman system via API:er, som att koppla in G-P Gia™ i en ny kunskapsbas.
5. Ägarskap: Årligt lönetillägg äger vår infrastruktur, men vi äger vår affärsdomän. Serverlös-först med domändriven design har tvingat oss att fokusera på affärsproblemet. Detta håller ägande av kapacitet tydlig.
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.
