{"id":5852,"date":"2023-05-12T08:17:54","date_gmt":"2023-05-12T06:17:54","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5852"},"modified":"2023-05-10T11:24:33","modified_gmt":"2023-05-10T09:24:33","slug":"3-modi-per-disaccoppiare-i-tuoi-microservizi-code-sqs-load-balancing-elb-e-sistema-di-notifiche-sns","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/3-modi-per-disaccoppiare-i-tuoi-microservizi-code-sqs-load-balancing-elb-e-sistema-di-notifiche-sns\/","title":{"rendered":"3 modi per disaccoppiare i tuoi microservizi: code SQS, load balancing ELB e sistema di notifiche SNS"},"content":{"rendered":"\n

Perch\u00e9 \u00e8 cos\u00ec importante disaccoppiare i servizi? E perch\u00e9 dovremmo evitare architetture tightly coupled? <\/h2>\n\n\n\n

Le care vecchie architetture monolitiche ci hanno servito bene e hanno avuto i loro momenti di gloria. Questo perch\u00e9 nei primi periodi di vita di internet le aziende necessitavano di un unico grande sistema che permettesse di gestire e distribuire il contenuto del loro sito o della loro applicazione. Un\u2019architettura monolitica, per\u00f2, fornisce una soluzione all-in-one, fortemente \u201caccoppiata\u201d, ovvero con un\u2019unica architettura in grado di gestire e pubblicare tutto il contenuto sul web. <\/p>\n\n\n\n

In questo modo tutti i processi funzionano come un singolo servizio.<\/p>\n\n\n\n

Aggiungere o migliorare le funzionalit\u00e0 di un’applicazione monolitica diventa pi\u00f9 complesso man mano che questa cresce di dimensione. Utilizzarle, inoltre, comporta un rischio dal punto di vista della disponibilit\u00e0 costante dell’applicazione poich\u00e9, essendo formata da molteplici processi dipendenti e strettamente accoppiati, aumenta l’impatto che un guasto di un singolo processo pu\u00f2 avere. <\/p>\n\n\n\n

Quindi, ecco il problema: se il grande cervello monolitico si guasta, si guasta tutto.<\/p>\n\n\n\n

Per risolvere questo problema possiamo trasformare la cara vecchia architettura monolitica in un\u2019architettura moderna costituita da microservizi<\/strong>. Questi non sono altro che un approccio architettonico e organizzativo allo sviluppo del software che diventa composto da piccoli servizi indipendenti, i quali comunicano attraverso API ben definite e svolgono una singola funzione.<\/p>\n\n\n\n

Essendo gestiti in modo indipendente, ogni servizio pu\u00f2 essere aggiornato, distribuito e scalato per soddisfare la domanda di specifiche necessit\u00e0 di un applicativo, il tutto senza influenzare il funzionamento degli altri servizi. Inoltre, lavorando su un singolo servizio, pi\u00f9 sviluppatori possono contribuire allo sviluppo del codice e, se questo diventa troppo complesso nel tempo, pu\u00f2 essere suddiviso, a sua volta, in servizi pi\u00f9 piccoli.<\/p>\n\n\n\n

In questo articolo spiegheremo un caso d’uso ispirato a uno scenario reale. Dimostreremo come risolvere alcuni problemi comuni utilizzando tre servizi AWS con l’obiettivo di disaccoppiare la nostra architettura.<\/p>\n\n\n\n

Li utilizzeremo in diverse combinazioni per superare diversi problemi.<\/p>\n\n\n\n