Abbiamo avuto un problema interessante qualche anno fa. Siamo un'azienda completamente remota con tutto il nostro software nel cloud. E avevamo una suite di applicazioni Spring Boot in esecuzione su contenitori con Infrastructure as Code. Ma avevamo bisogno di agilità aziendale.

Il mercato globale del lavoro si muove rapidamente e c'è sempre richiesta di nuovi prodotti. Abbiamo dovuto trovare un modo per mantenere il nostro vantaggio in tutto il settore.
​​ 

Siamo un'azienda tecnologica con una strategia audace​​ 

Nel 2022, abbiamo creato un ADR (Architectural Decision Record) che diceva "serverless-first e container-as-needed." E ha scatenato il dibattito tra quasi i team di ingegneri 40.​​ 

Spieghiamo prima un po' di terminologia​​ 

Serverless-first non è solo funzioni come servizio. È anche un gruppo di servizi gestiti da fornitori cloud che:​​  

  • Ridurre i costi operativi non gestendo l'infrastruttura​​ 

  • Scala secondo necessità, incluso lo scalaggio fino a zero per renderli completamente elastici​​ 

  • Avere prezzi elastici (paghi solo per ciò che usi)​​  

In G-P, serverless-first si riferisce al nostro utilizzo di AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB e altri.​​ 

Serverless-first significa che quando selezioniamo una soluzione per l'elaborazione, l'archiviazione, la messaggistica o simili, vorremmo che i team iniziassero con un'opzione serverless. Una nota importante: se il servizio serverless non soddisfa le esigenze, i team dovrebbero ricorrere a un servizio più pesante, che richiede maggiori investimenti operativi.​​ 

"Container-as-needed" chiarisce che serverless-first non significa serverless-only. Ci sono momenti in cui abbiamo bisogno di container (ad esempio, installando un prodotto software COTS) — e va bene così.​​ 

Una strategia tecnologica che dia priorità ai clienti​​ 

Ci muoviamo a un ritmo agile per soddisfare le esigenze dei nostri clienti e utenti. Servizi come Lambda, S3e DynamoBD sono incredibilmente resilienti e veloci. Scaricando il lavoro pesante e indifferenziato, possiamo dedicare più tempo a costruire funzionalità per gli utenti, piuttosto che lavorare su configurazioni infrastrutturali generiche.​​ 

Un principio chiave di G-P è: " Tu lo costruisci, lo gestisci. " I nostri team sono proprietari del loro software. Quindi, non ci limitiamo a dare il software al team DevOps.​​  

Vantaggi del "serverless-first"​​ 

Serverless è intrinsecamente basato sugli eventi.​​ 

La nostra architettura è completamente basata sugli eventi. Utilizzando EDA (Event-Driven Architecture), possiamo scalare sia la nostra organizzazione che il nostro software. Serverless ci obbliga a mantenere un raggio d'azione ridotto e a comunicare in modo completamente nativo per il cloud tramite eventi.​​ 

Abilitazione dei vincoli​​ 

Come piattaforma globale per l'impiego, prendiamo sul serio la conformità. La nostra infrastruttura cloud è ben architettata e utilizziamo una strategia multi-account che separa i carichi di lavoro e automatizza la conformità cloud. Serverless ci aiuta a far rispettare standard elevati controllando il modo in cui forniamo le risorse cloud.​​ 

Scarica il lavoro​​ 

Il nostro provider cloud gestisce i nostri servizi serverless. Un unico set di elementi costitutivi, integrati, sicuri, ottimizzati, abilitati e gestiti da AWS, ci consente di concentrarci più in alto sulla catena del valore per i clienti.​​ 

Carichi di lavoro ben progettati​​ 

Ogni carico di lavoro che creiamo viene esaminato con AWS Well-Architected Framework. Ci concentriamo su scala, sicurezza, affidabilità e ottimizzazione dei costi per assicurarci non solo di rispettare, ma anche di superare il nostro SLA (Service Level Agreement). Ciò consente ai nostri team di ingegneri di continuare a evolverci con gli ambienti cloud.​​  

Informazioni sui nostri team​​ 

La nostra strategia tecnologica è ambiziosa e questo la rende impegnativa. Molti ingegneri non hanno mai lavorato in un'architettura serverless (o distribuita). La transizione verso l'architettura serverless non è facile, e cerchiamo ingegneri che si sentano a proprio agio nell'imparare, pensare in grande e muoversi rapidamente.​​ 

Alcuni ingegneri non sono sicuri del termine serverless (sì, sappiamo che esistono server) perché l'approccio è più che scrivere codice nelle funzioni. La nostra strategia richiede un approccio olistico ai classici principi cloud-native.​​ 

L'esito​​ 

Abbiamo fatto progressi straordinari in due anni. Ci sono molti vantaggi nella modernizzazione (vedi il nostro articolo su AWS/Known business value of cloud modernization). In particolare, abbiamo osservato quanto segue:​​ 

1. Velocità: il modo in cui abbiamo suddiviso il nostro sistema consente a team e prodotti di innovarsi ed evolversi in modo indipendente. Questo ha un impatto enorme sull'agilità aziendale.​​ 

2. Conformità: utilizziamo AWS Well-Architected Framework per esaminare tutti i carichi di lavoro. Poiché utilizziamo molti servizi gestiti AWS, possiamo contare sulla loro eccellenza operativa e partire da un ambiente di alta qualità.​​ 

3. Pensiero sistemico: Abbiamo dovuto standardizzare molti dei nostri processi per poter ragionare sul sistema, sull'affidabilità e sul valore aziendale. Non perdiamo tempo a lavorare su componenti di basso valore.​​ 

4. Innovazione: Serverless significa che tutto è un'API. Questo vincolo forzato richiede un approccio basato sulle interfacce per la programmazione di applicazioni. Quando pensiamo a noi stessi come a una piattaforma, possiamo raggiungere un nuovo livello di innovazione connettendo facilmente i sistemi tramite interfaccia per la programmazione di applicazioni, ad esempio collegando G-P Gia™ a una nuova base di conoscenza.​​ 

5. Proprietà: AWS possiede la nostra infrastruttura, ma noi possediamo il nostro dominio aziendale. Serverless-first con design guidato dal dominio ci ha costretti a concentrarci sul problema aziendale. Ciò mantiene chiara la proprietà delle capacità.​​ 

Serverless-first non è sempre più veloce, ma è più vantaggioso. Preferiamo ottimizzare per la velocità del sistema piuttosto che per la velocità del singolo sviluppatore. Il serverless-first riguarda meno l'uso delle funzioni e più il pensare: "Il codice è un problema. Il sistema è la risorsa." Meno codice dobbiamo scrivere, più possiamo considerare e modellare il sistema aziendale che stiamo costruendo.​​ 

Mentre condividiamo la nostra storia, diventerà evidente la velocità con cui stiamo lavorando, che è una conseguenza diretta del serverless-first. Restate sintonizzati.​​