Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Motivo a fico Strangler I modelli di progettazione discussi finora in questa guida si applicano alle applicazioni di scomposizione per progetti greenfield. Che dire dei progetti dismessi che coinvolgono applicazioni monolitiche di grandi dimensioni? Applicarvi i modelli di progettazione precedenti sarà difficile, perché suddividerli in pezzi più piccoli mentre vengono utilizzati attivamente è un compito arduo. Il [motivo a fichi strangolatori](https://martinfowler.com/bliki/StranglerFigApplication.html) è un modello di design popolare introdotto da Martin Fowler, che si è ispirato a un certo tipo di fico che si semina tra i rami superiori degli alberi. L'albero esistente diventa inizialmente una struttura di supporto per il nuovo fico. Il fico poi affonda le sue radici al suolo, avvolgendo gradualmente l'albero originale e lasciando al suo posto solo il nuovo fico autoportante. Questo modello viene comunemente utilizzato per trasformare in modo incrementale un'applicazione monolitica in microservizi sostituendo una particolare funzionalità con un nuovo servizio. L'obiettivo è far coesistere la versione precedente e quella nuova e modernizzata. Il nuovo sistema è inizialmente supportato dal sistema esistente e lo integra. Questo supporto dà al nuovo sistema il tempo necessario per crescere e potenzialmente sostituire completamente il vecchio sistema. Il processo di transizione da un'applicazione monolitica ai microservizi mediante l'implementazione del pattern strangler fig prevede tre fasi: trasformazione, coesistenza ed eliminazione: + *Trasformazione*: identifica e crea componenti modernizzati portandoli o riscrivendoli in parallelo con l'applicazione precedente. + *Coesistenza*: mantieni l'applicazione monolitica per il rollback. Intercetta le chiamate di sistema esterne incorporando un proxy HTTP (ad esempio [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)) sul perimetro del monolite e reindirizza il traffico verso la versione modernizzata. Questo ti aiuta a implementare le funzionalità in modo incrementale. + *Eliminazione: elimina* le vecchie funzionalità dal monolite poiché il traffico viene reindirizzato dal monolite precedente al servizio modernizzato. La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo del pattern Strangler Fig. **** | Vantaggi | Svantaggi | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) | L'illustrazione seguente mostra come un monolite può essere suddiviso in microservizi applicando lo strangler fig pattern a un'architettura applicativa. Entrambi i sistemi funzionano in parallelo, ma inizierai a spostare le funzionalità al di fuori del codice base di Monolith e a migliorarla con nuove funzionalità. Queste nuove funzionalità ti offrono l'opportunità di progettare i microservizi nel modo più adatto alle tue esigenze. Continuerai a eliminare le funzionalità dal monolite finché non saranno tutte sostituite dai microservizi. A quel punto, puoi eliminare l'applicazione Monolith. Il punto chiave da notare qui è che sia il monolite che i microservizi vivranno insieme per un periodo di tempo. ![\[Scomposizione dei monoliti in microservizi utilizzando lo schema Strangler Fig\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)