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.