Implementare un'architettura a microservizi: Docker/Spring Boot Vs Serverless/Lambda

Con microservizi si intende un approccio di sviluppo software in cui è prevista la suddivisione in servizi indipendenti di piccole dimensioni. Questi sono autonomi e specializzati e la comunicazione tra loro avviene attraverso API definite. Rispetto a un’architettura monolitica, i microservizi hanno il vantaggio di semplificare tutte le operazioni di gestione e aggiornamento.

Approfondiamo ora due modalità di implementazione di un’architettura di questo tipo analizzando in particolare le loro specifiche tecniche.

Framework Spring Boot in un container Docker

Se utilizziamo il metodo Docker/Spring Boot (DSB) si tratta di realizzare i microservizi in Java con il framework Spring Boot e di farli eseguire in runtime confinati all'interno di container Docker. A loro volta i microservizi sono gestiti in un ambiente di esecuzione (cluster di server) e possibilmente organizzati con un framework come Kubernetes.

In questo caso è necessario prendersi in carico anche la gestione dell'ambiente di esercizio.

Framework Serverless con servizio Lambda

Per quanto riguarda Serverless/Lambda (SLL), il primo passaggio da fare è identificare un cloud provider, che nel caso di Lambda è AWS, e i microservizi vengono poi realizzati in uno dei linguaggi supportati. In Ariadne utilizziamo Node.js e Python ma è possibile scegliere anche Ruby, Java, Go, .NET e volendo anche custom. 

L’esecuzione dei microservices avviene in un ambiente controllato totalmente dal cloud provider, non ci sono server, cluster o Kubernetes da gestire. Il tradeoff con SLL è che, delegando tutto al cloud provider, si crea un lockin più forte.

Una cosa da notare è che i cloud provider hanno sviluppato servizi per sostenere architetture DSB, mentre in AWS ci sono ECS ed EKS che creano una sorta di compromesso in termini di delega e di lockin.

Perché scegliere DSB

Semplificando, possiamo dire che DSB consente di mantenere un lockin al minimo ma prevede che ci si prenda in carico molte attività tipicamente IT. Per questi procedimenti ci si può affidare anche ai servizi del cloud provider, ricadendo però nel problema lockin.  Per DSB la gestione dei costi è più legata alla "capacity" predeterminata, tenendo conto della possibilità di automatismi di scale up/down. 

In sintesi le premesse della scelta di questa soluzione devono essere un forte orientamento per:

• la gestione dell'infrastruttura;
• il controllo del lockin;
• il mantenimento in esercizio di servizi con "lunghe esecuzioni";
• il recupero di componenti "legacy".

Quando orientarsi su SLL?

Il servizio SLL consente, invece, di focalizzare l’effort unicamente sullo sviluppo dei microservizi, realizzando applicazioni per la loro stessa gestione e delegando al cloud provider tutto il resto. In questo caso i fattori da considerare sono:

• il non volersi preoccupare della scalabilità;
• un modello di costo che segue direttamente l'uso (modello pay per use);
• un rapporto esclusivo con un cloud provider.

La scelta di Ariadne: SLL

In base alla nostra specifica situazione queste sono le motivazioni della scelta del metodo Serverless/Lambda:

• Carenza di risorse umane dedicate: la necessità è quella di minimizzare le competenze essenziali da acquisire. DSB richiede infatti la padronanza di uno stack più ampio e più complesso da gestire a livello di esperienza;
• Il lockin non è una issue: ovvero crediamo che il costo per controllare il non-lockin sia elevato e quindi giustificato solo in casi particolari. Per molte aziende, per esempio, costa meno pensare di riadattare o rifare completamente  i microservizi su un diverso cloud provider (considerando che un certo livello di lockin viene normalmente assunto anche da chi appoggia un DSB su un cloud provider);
• La limitazione di risorse umane, inoltre, ci ha imposto di focalizzarci su uno specifico cloud provider (AWS): in quest’ottica non troviamo utile cercare di gestire un lockin;
• Esperienza sui linguaggi: il tradeoff tra la rapidità di sviluppare in JS rispetto a Java e la capacità di conversione da Java a JS ci ha indotto a non prendere per ora in considerazione Java come linguaggio per le lambda (anche se supportato). Non è detto che questa possibilità non possa essere considerata in futuro.

In conclusione, a nostro parere SLL consente un’attivazione più rapida nell'adozione di architetture a microservizi rispetto a DSB che necessita di una messa a regime di tutto il gruppo di lavoro e dell'azienda che vuole adottarlo. Questo dovrebbe anche consentire una migliore "scalabilità" delle risorse di sviluppo.

Questo non significa che sia in assoluto semplice o veloce attivare delle risorse SLL, ma a nostro avviso è così attuando un paragone con DSB.