Qualche anno fa abbiamo avuto un problema interessante. Siamo un'azienda completamente remota con tutti i nostri software nel cloud. E avevamo una suite di applicazioni Spring Boot in esecuzione su container con Infrastructure as Code. Ma avevamo bisogno di agilità aziendale.

Il mercato del lavoro globale si muove rapidamente e c'è sempre domanda 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 (Architecture Decision Record) che diceva, "server-less-first e container-as-needed." E ha scatenato il dibattito tra quasi 40 team di ingegneri.

Spieghiamo prima alcune terminologie

Serverless-first non è solo funzioni-as-a-service. È anche un gruppo di servizi gestiti da fornitori di servizi cloud che: 

  • Ridurre le spese operative non gestendo l'infrastruttura

  • Scalare in base alle necessità, inclusa la scalatura a zero per renderli completamente elastici

  • Avere prezzi elastici (si paga solo per quello che si utilizza) 

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 Compute, Storage, Messaging 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 tornare a un servizio più pesante, che richiede più investimenti operativi.

"Container-as-needed" chiarisce che serverless-first non significa solo serverless. Ci sono momenti in cui abbiamo bisogno di contenitori (ad esempio, l'installazione di un prodotto software COTS ) - e va bene.

Una strategia tecnologica che dà priorità ai clienti

Ci muoviamo a un ritmo agile per soddisfare le esigenze dei nostri clienti e utenti. Servizi come Lambda, S3 e DynamoBD sono incredibilmente resistenti e veloci. Scaricando il sollevamento pesante indifferenziato, possiamo dedicare più tempo alla creazione di funzionalità per gli utenti, piuttosto che lavorare sulla configurazione dell'infrastruttura generica.

Un principio chiave in G-P è: “Lo costruisci, lo gestisci”. I nostri team possiedono il loro software. Quindi, non ci limitiamo a buttare il software oltre il muro a un team DevOps. 

Vantaggi di "serverless-first"

Serverless è intrinsecamente basato sugli eventi.

La nostra architettura è completamente orientata agli eventi. Utilizzando EDA (Event-Driven Architecture), possiamo scalare sia la nostra organizzazione che il nostro software. Il serverless ci costringe a mantenere un raggio di esplosione ridotto e a comunicare in modo completamente cloud-nativo tramite eventi.

Abilitazione dei vincoli

In qualità di azienda global employment platform , prendiamo sul serio la conformità. La nostra infrastruttura cloud è ben strutturata e utilizziamo una strategia multi-account che separa i carichi di lavoro e automatizza la conformità al cloud. Serverless ci aiuta a far rispettare standard elevati controllando il modo in cui forniamo le risorse cloud.

Scarica il lavoro

Il nostro fornitore di servizi cloud gestisce i nostri servizi serverless. Un unico set di elementi costitutivi, integrati, protetti, ottimizzati, abilitati e mantenuti da AWS, ci consente di concentrarci maggiormente sulla catena del valore per i clienti.

carichi di lavoro ben strutturati

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

Informazioni sui nostri team

La nostra strategia tecnologica è ambiziosa e questo la rende difficile. Molti ingegneri non hanno lavorato in un'architettura serverless (o distribuita). La transizione all'architettura serverless non è facile e cerchiamo ingegneri che si sentano a proprio agio nell'apprendimento, nel pensare in grande e nel muoversi al ritmo.

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

Il risultato

Abbiamo fatto progressi straordinari in due anni. Ci sono molti vantaggi per la modernizzazione (vedi il nostro articolo su AWS / noto valore aziendale della modernizzazione del cloud ). Nello specifico, abbiamo osservato quanto segue:

1. Velocità: il modo in cui abbiamo suddiviso il nostro sistema consente ai team e ai prodotti di innovare ed evolversi in modo indipendente. Ciò 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 luogo di alta qualità.

3. Pensiero di sistema: Abbiamo dovuto standardizzare molti dei nostri processi in modo da poter ragionare sul sistema, sull'affidabilità e sul valore aziendale. Non passiamo il tempo a lavorare su componenti di basso valore.

4. Innovazione: Serverless significa che tutto è un'API. Questo vincolo forzato richiede un approccio API-first. Quando pensiamo a noi stessi come a una piattaforma, possiamo raggiungere un nuovo livello di innovazione collegando facilmente i sistemi tramite API, come collegare G-P Gia™ a una nuova base di conoscenze.

5. Proprietà: AWS possiede la nostra infrastruttura, ma noi siamo proprietari del nostro dominio aziendale. Il serverless-first con il design basato sul 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 la velocità del sistema piuttosto che la velocità dei singoli sviluppatori. Serverless-first è meno sull'uso delle funzioni e più sul pensare: "Il codice è una responsabilità. 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à ovvio la velocità a cui stiamo lavorando, che è un risultato diretto di serverless-first. Restate sintonizzati.