Container, Lambda e microservizi sono concetti tanto popolari e importanti, quanto fraintesi dai tecnici nello sviluppo software moderno. A voltesi parla di architetture a microservizi quando, in realt\u00e0, si tratta solo di un gruppo di piccoli container con monoliti fortemente accoppiati. <\/p>\n\n\n\n
In questo articolo, faremo chiarezza sui microservizi, e sui servizi gestiti da AWS che ci faciliteranno nella loro implementazione.<\/p>\n\n\n\n
Sfortunatamente, le cose non sono cos\u00ec semplici: i microservizi devono aderire a regole rigorose e avere definizioni chiare. <\/p>\n\n\n\n
Entraimo nel vivo della discussione.<\/p>\n\n\n\n
I microservizi dovrebbero essere: <\/p>\n\n\n\n
Vediamo ora i principi del design dei container: <\/p>\n\n\n\n
Come potete vedere, definizioni e concetti si sovrappongono in alcuni punti , ma il diavolo si nasconde nei dettagli: l\u2019uso di una tecnologia specifica non significa che il design dell\u2019architettura avr\u00e0 automaticamente tutte le propriet\u00e0 che ci aspettiamo (e non abbiamo nemmeno menzionato Lambda!).<\/p>\n\n\n\n
I container, infatti, offrono un modo per impacchettare in modo portabile ed eseguire il software in un ambiente isolato<\/strong>. Allo stesso tempo, un approccio a microservizi aiuta a dividere un problema complesso in pi\u00f9 servizi pi\u00f9 semplici, fortemente disaccoppiati, che comunicano utilizzando API e possono essere gestiti da diversi team.<\/p>\n\n\n\n I container<\/strong> possono aiutare con la scalabilit\u00e0, la portabilit\u00e0 e l\u2019efficienza delle risorse, ma richiedono anche un\u2019occhio attento a orchestrazione, monitoraggio e sicurezza.<\/p>\n\n\n\n Le lambda<\/strong> possono aiutare con l\u2019agilit\u00e0, la convenienza economica e la scalabilit\u00e0, ma possono portare problemi di prestazioni e aumentare la complessit\u00e0 d\u2019implementazione.<\/p>\n\n\n\n I microservizi<\/strong> possono aiutare con la modularit\u00e0, la flessibilit\u00e0 e la tolleranza ai guasti, ma introducono anche latenza di rete, coerenza dei dati e aumentano la difficolt\u00e0 nell’effettuare i test. <\/p>\n\n\n\n Ecco alcuni esempi di container e lambda che non possono essere identificati come microservizi. <\/p>\n\n\n\n Ci sono molti esempi e sicuramente potete pensare a qualcosa nel vostro lavoro quotidiano.<\/p>\n\n\n\n Non ci concentreremo sul discutere se un\u2019architettura orientata ai microservizi sia migliore e per quale caso d\u2019uso perch\u00e9 miriamo a semplificare la nostra vita mentre gestiamo le infrastrutture che eseguiranno le nostre applicazioni.<\/p>\n\n\n\n Ricordate che quando usiamo i container e le lambda per implementare una strategia a microservizi, dobbiamo aggiungere almeno tre componenti alla nostra architettura: un runtime, un orchestrator e un discovery service. <\/p>\n\n\n\n AWS offre diversi servizi gestiti tra cui scegliere per andare nella direzione dei microservizi, semplificandoci la vita..<\/p>\n\n\n\n Si tratta della parte pi\u00f9 ovvia. Possiamo utilizzare EC2, Fargate (per ECS o EKS), Lambda. EC2 sembra controintuitivo, ma ricordiamo che i microservizi riguardano il design, non la tecnologia.<\/p>\n\n\n\n Lambda e Fargate offrono piattaforme di calcolo serverless, quindi la spesa si basa esclusivamente sull\u2019uso. Sono la soluzione perfetta per un approccio a microservizi: se un microservizio basato su Lambda viene raramente invocato, il suo costo sar\u00e0 marginale.<\/p>\n\n\n\n L\u2019uso di Fargate e Lambda aiuta anche ad adattarsi ai modelli di utilizzo: la scalabilit\u00e0 orizzontale delle risorse orizzontali utilizzando piccole unit\u00e0 di calcolo ottimizza la scalabilit\u00e0. <\/p>\n\n\n\n L\u2019orchestrazione \u00e8 un componente critico di un\u2019architettura a microservizi perch\u00e9 aiuta ad automatizzare i rilasci, aggiunge scalabilit\u00e0, consente il coordinamento e introduce la tolleranza ai guasti dei microservizi, gestendo anche il ciclo di vita del servizio e i flussi di esecuzione.<\/p>\n\n\n\n ECS e EKS (su EC2 e Fargate) offrono libert\u00e0 di scelta per il mondo dei container e minimizzano l\u2019effort di gestione; API Gateway e Step Functions aiutano con l\u2019esecuzione e l\u2019integrazione di Lambda e altri servizi AWS.<\/p>\n\n\n\n AWS AppMesh pu\u00f2 anche essere utilizzato per gestire il routing e l\u2019autorizzazione tra i servizi, aggiungendo un ulteriore strato di osservabilit\u00e0.<\/p>\n\n\n\n In un ambiente dinamico, utilizzare le risorse senza fare affidamento a nomi o indirizzi IP fissi \u00e8 obbligatorio (questo requisito in realt\u00e0 si applica a ogni ambiente cloud). <\/p>\n\n\n\n I microservizi dovrebbero anche essere in grado di notificare automaticamente la loro presenza a un registro centrale, che tiene traccia di cosa si trova dove e facilita la comunicazione.<\/p>\n\n\n\n Il discovery service mantiene un registro dei servizi disponibili e fornisce un meccanismo per gli utilizzatori per l’interrogazione e la scoperta, gestendo i cambiamenti dovuti alla scalabilit\u00e0, ai guasti o agli aggiornamenti.<\/p>\n\n\n\n EKS utilizza il DNS interno integrato di Kubernetes, mentre ECS pu\u00f2 fare affidamento su Amazon ECS Service Connect (questi due servizi possono essere utilizzati insieme).<\/p>\n\n\n\n Per distribuire i microservizi in modo indipendente, avremo bisogno di pipelin. Inoltre sar\u00e0 necessario impostare un sistema di logging efficiente per monitorare i container. Non dimentichiamoci poi dei componenti di comunicazione (come code, bilanciatori di carico e trigger di eventi) per disaccoppiare l’applicazione.<\/p>\n\n\n\n Questi componenti aumenteranno sicuramente la complessit\u00e0 dell’architettura, quindi \u00e8 fondamentale sceglierli con attenzione: a volte insistiamo nell’uso di una tecnologia specifica, piegando le esigenze aziendali e il design della soluzione alla nostra fantasia o curiosit\u00e0. Scegliere il design in base alla tecnologia \u00e8 pericoloso e pu\u00f2 portare un progetto a lfallimento. design sbagliato influisce sulla disponibilit\u00e0, sulla gestibilit\u00e0 e, quindi, sul costo della soluzione.<\/p>\n\n\n\n Come sempre, non esiste una soluzione perfetta: ci sono casi d\u2019uso che si adattano perfettamente ai microservizi, mentre, a volte, suddividere ogni componente in servizi diversi pu\u00f2 solo aumentare la complessit\u00e0 del progetto: c’\u00e8 davvero bisogno di un servizio di registrazione utente per l’e-commerce di un negozio di animali di paese? <\/p>\n\n\n\n Iniziare con un monolite per accelerare il tempo di sviluppo e rilasciare il prodotto pi\u00f9 velocemente potrebbe essere un approccio migliore rispetto al perdere il momento giusto per mettere sul mercato la soluzione.<\/p>\n\n\n\n In quale situazione e caso d’uso siete? State mantenendo un monolite legacy, cercando di scomporlo, o progettando un nuovo sistema completamente da zero? Fateci sapere nei commenti!<\/p>\n\n\n\n Nel frattempo, se state pensando di rifattorizzare un\u2019architettura monolitica in microservizi, questo articolo<\/a> di Alessandro e Simone pu\u00f2 darvi pi\u00f9 informazioni.\u00a0<\/p>\n\n\n\n Buona fortuna con i vostri microservizi!<\/p>\n\n\n\nBenefici e sfide dell\u2019uso di queste tecnologie<\/h2>\n\n\n\n
\n
Compute <\/h2>\n\n\n\n
Orchestrazione<\/h2>\n\n\n\n
Discovery Service<\/h2>\n\n\n\n
Altri aspetti da tenere in considerazione<\/h2>\n\n\n\n
Per Concludere<\/h2>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n