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.
L'espressione "Containers-as-needed" chiarisce che "serverless-first" non significa "serverless-only". Ci sono momenti in cui abbiamo bisogno di container (ad esempio, per installare 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
In quanto piattaforma di occupazione globale, prendiamo sul serio la compliance . La nostra infrastruttura cloud è ben progettata e utilizziamo una strategia multi-account che separa i carichi di lavoro e automatizza la conformità al cloud. L'approccio serverless ci aiuta a garantire standard elevati controllando le modalità di allocazione delle 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
In due anni abbiamo fatto progressi straordinari. La modernizzazione offre numerosi vantaggi (vedi il nostro articolo sull'integrazione salariale annuale / noto valore aziendale della modernizzazione del cloud). Nello specifico, abbiamo osservato quanto segue:
1. Velocità: il modo in cui abbiamo strutturato il nostro sistema consente a team e prodotti di innovare ed evolversi in modo indipendente. Ciò ha un impatto enorme sull'agilità aziendale.
2. Conformità: Utilizziamo il Well-Architected Framework del supplemento salariale annuale per esaminare tutti i carichi di lavoro. Grazie al nostro ampio utilizzo di servizi gestiti integrativi salariali annuali, possiamo contare sulla loro eccellenza operativa e partire da una posizione di elevata 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 scarso valore.
4. Innovazione: Serverless significa che tutto è un'interfaccia per la programmazione delle applicazioni. Questo vincolo forzato richiede un approccio di interfaccia per la programmazione delle applicazioni. Quando ci consideriamo una piattaforma, possiamo raggiungere un nuovo livello di innovazione collegando facilmente i sistemi tramite API, ad esempio integrando G-P Gia™ in una nuova base di conoscenza.
5. Proprietà: supplemento salariale annuale possiede la nostra infrastruttura, ma noi possediamo il nostro dominio aziendale. L'approccio serverless-first con progettazione orientata al 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.
