# Il viaggio di Shoprocket verso i microservizi, parte 1: cosa ho sbagliato nello smontare il monolite

> Un articolo del team di ingegneria dei primi anni di Shoprocket sul primo tentativo di estrarre un servizio da un monolite PHP. Perché ho scelto il primo servizio sbagliato, cosa mi ha insegnato l'accoppiamento stretto e il consiglio di Newman che avrei dovuto seguire prima.

Winston Berty  - 17 marzo 2016 - 5 min di lettura

Dopo qualche mese di lavoro in Shoprocket, cominciavo a essere frustrato. Avevamo un'applicazione PHP seguita da un piccolo team di sviluppatori in gamba sparsi per il mondo, e a me sembrava che le correzioni dei bug ne generassero altri, che integrare nuove funzioni non fosse semplice come dovrebbe e che i rilasci fossero rari e stressanti. Il motivo: codice fortemente accoppiato.

Avevamo un'applicazione monolitica, quasi tutta in un unico repository GitHub. Aggiornare o correggere una funzione richiedeva spesso modifiche in più punti. Per i test avevamo un processo di revisione tra pari in cui almeno altri due sviluppatori dovevano approvare un branch prima che venisse unito a master e rilasciato. Tutto questo significava che quando un bug passava, spesso era difficile individuare la modifica che aveva rotto qualcosa. Una volta trovata, la correzione seguiva lo stesso processo, e l'intera applicazione doveva essere rilasciata di nuovo.

Da giovane sviluppatore entusiasta e sempre a caccia di novità, quando mi sono imbattuto nei microservizi ho pensato che avrebbero risolto tutti i nostri problemi.

## Cosa pensavo fossero i microservizi

Non esiste una definizione formale di microservizi, ma dalle mie ricerche ho ricavato che l'architettura a microservizi è un modo di progettare le applicazioni software come sistemi distribuiti di servizi indipendenti, ciascuno altamente specializzato e con un proprio ciclo di vita. Per un'introduzione dettagliata, l'[articolo](https://martinfowler.com/articles/microservices.html) di Martin Fowler è eccellente.

Due aspetti mi avevano conquistato. Il primo, l'idea di dividere l'applicazione in servizi con confini rigidi. Questo riduce la probabilità che la logica specifica di un contesto di business si infiltri tra i componenti, perché le interfacce tra i confini vanno pianificate con cura. Non è semplice come fare chiamate a funzioni locali. Il secondo, ogni componente può avere un ciclo di vita indipendente. I team possono essere responsabili del proprio codice e usare lo stack più adatto al servizio, e le modifiche possono essere rilasciate un servizio alla volta e annullate senza toccare il resto.

Ero convinto. Shoprocket avrebbe smontato il monolite. Questa è la parte 1 di una breve serie che segue il percorso. Spero che i lettori che stanno pianificando o attraversando una transizione simile imparino dai nostri successi e dai nostri errori.

## La prima sfida è stata umana, non tecnica

Dovevo vendere l'idea al resto del team. Erano curiosi ma non condividevano il mio entusiasmo, ed erano riluttanti a rinunciare a ore di sviluppo in questa fase iniziale della vita del prodotto. Per fortuna il CTO voleva che mi occupassi della nostra gestione delle sessioni, così ho colto l'occasione: l'ho convinto che potevo separare un servizio per le sessioni.

Col senno di poi, è stata una pessima scelta di primo servizio. Il nostro prodotto include un widget JavaScript che [abilita l'ecommerce su qualsiasi sito web](https://v3.shoprocket.io/it/funzionalita/vendere-su-qualsiasi-sito-web.md). Trattiamo le sessioni come una risorsa, salvando le informazioni di sessione nel database per analizzare l'abbandono del carrello e altri KPI. Ma questa risorsa non è tangibile come gli ordini o le righe d'ordine, e usavamo le sessioni a quasi ogni cambiamento di stato dell'applicazione. Questo significava che il servizio sarebbe stato inevitabilmente molto loquace con il resto dell'applicazione, cosa che non avevo previsto e che ha reso il mio compito più difficile.

## Cosa ho imparato costruendolo davvero

Ho intensificato la ricerca. Accanto a Fowler, **Building Microservices** di Sam Newman si è rivelato una risorsa indispensabile.

Il consiglio di Newman, col senno di poi, era quello che avrei dovuto seguire: prima ristruttura l'applicazione esistente in moduli che riflettano i contesti delimitati del dominio. Quando gli sviluppatori sono soddisfatti dei confini, *allora* separa i moduli in servizi propri. Il motivo è che è molto più facile smontare e riscrivere moduli con confini sbagliati che smontare e riscrivere interi servizi con tutto il loro codice di supporto e le loro risorse persistenti.

Non ho seguito quel consiglio. Smanioso di costruire un componente tutto mio, sono andato avanti con il servizio delle sessioni.

Ho scelto uno stack solo di poco diverso da quello del monolite e ho cominciato a costruire. Il servizio in sé si è messo insieme in fretta: poche settimane per produrre un'applicazione autonoma con un'API REST. Non era lì la parte difficile. La parte difficile era far parlare il servizio con il monolite.

La gestione delle sessioni si è rivelata strettamente accoppiata al resto del codice. Sostituire le chiamate a funzione con chiamate API è stato un lavoro lento. Poiché il servizio delle sessioni e il monolite avevano schemi di database separati, ho dovuto riscrivere tutta la logica del monolite che usava le risorse di sessione dal vecchio database, ristrutturando i dati al confine dell'applicazione per mantenere compatibili client come il nostro widget JavaScript.

Integrare ha richiesto più tempo che costruire. E questo senza contare la maggior parte del carico che i microservizi di solito portano: service discovery, logging, monitoraggio, tracciamento distribuito. Peggio ancora, l'accoppiamento stretto faceva sì che le modifiche si diffondessero in molte aree del codice. Poiché nel frattempo il team aveva lavorato in parallelo, unire tutto e portare in produzione il servizio delle sessioni avrebbe richiesto molto più coordinamento di quanto avessi stimato.

## Il giudizio onesto

Il servizio potrebbe presto andare in produzione. Ma ora sento che avrei dovuto seguire il consiglio di Newman e dedicare i miei sforzi prima a modularizzare l'applicazione esistente. Il vantaggio di avere un solo servizio che vive per conto suo è marginale. Il vero vantaggio viene dallo spezzare l'intero sistema, almeno in servizi a grana grossa che parlino il meno possibile tra loro. Per farlo servono confini dei componenti ben ponderati, e noi non eravamo ancora lì.

Credo ancora nei microservizi come idea. Vedo il mio tentativo come un utile esperimento. Ho imparato moltissimo su architettura applicativa, modellazione del dominio e principi REST, e quelle lezioni hanno avuto effetti a catena su altre parti del nostro codice.

Per chi pensa a una transizione simile, le mie raccomandazioni oneste:

- Informati il più possibile sull'argomento prima di impegnarti
- Rimanda il lavoro finché non sei davvero sicuro del tuo codice esistente e del tuo modello di dominio
- Ricorda che ci sono altri modi per dare stabilità e resilienza a un monolite. I test unitari e funzionali automatizzati aiutano enormemente. Lo sviluppo guidato dai test riduce le regressioni. La scalabilità orizzontale rende i rilasci meno dolorosi
- Comincia modularizzando il monolite prima di estrarre i servizi

Shoprocket continuerà il suo viaggio. La parte 2 è dove le cose si fanno più interessanti.

---

*Pubblicato originariamente come primo di una breve serie che documenta la prima migrazione di Shoprocket lontano da un monolite PHP. Il percorso completo, compresi gli errori corretti nelle iterazioni successive, è proseguito attraverso ogni grande riscrittura della piattaforma da allora.*

---

- HTML version: https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite
- Language: Italiano (it)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)