Una modifica a un monolite richiede la distribuzione dell'intera applicazione?

Una modifica può richiedere l'implementazione dell'intero progetto e, in alcuni casi, ciò non avviene.

Molte volte un'applicazione per monoliti è suddivisa in più librerie / file jar / assiemi.

Un'applicazione web monolite, ad esempio, potrebbe avere le seguenti librerie:

• Una libreria "business logic"
• Una libreria "accesso ai dati"
• Un "sito Web"
  • E il "sito Web" potrebbe avere un sacco di file modello per ogni pagina

Se si effettua una modifica compatibile con le versioni precedenti della libreria "business logic" che non provoca la ricompilazione di altro codice, è possibile ricompilare quella libreria e distribuirla. Un esempio potrebbe essere una correzione di errori che non influisce sull'interfaccia pubblica o protetta di qualsiasi classe nella libreria.

Se si apportano modifiche di qualsiasi tipo che richiedono la ricompilazione di altri progetti, è necessario distribuire l'intera operazione.

Se si dispone di un progetto "sito Web" con file modello (come i modelli JSP o Razor per applicazioni .NET), potrebbe essere sufficiente copiare il file modello nei server Web.

Quindi la vera risposta è "varia" e non dovresti lasciare che la necessità di implementare un intero monolite sia il tuo fattore decisivo per suddividere le cose in micro servizi o anche in un'architettura orientata ai servizi più tradizionale.

L'autore è corretto, ma quel punto è irrilevante. Ad esempio, consideriamo un'applicazione server monolitica. Cosa dobbiamo fare se una libreria cambia che fa parte della nostra applicazione server?

• crea una nuova build per il nostro server (che è potenzialmente abbastanza economico dato che stiamo solo modificando una libreria)
• avvia un nuovo processo del server con quella build
• passa le nuove richieste al nuovo processo
• chiude con grazia il vecchio processo del server

Le modifiche alle librerie in-process non sono generalmente possibili, ma non sono nemmeno necessarie se puoi semplicemente passare a un nuovo processo utilizzando un meccanismo di bilanciamento del carico.

La ridistribuzione di un monolite non è fondamentalmente più difficile o pericolosa della ridistribuzione di un microservizio.

C'è un avvertimento: molti processi server beneficiano del caching e hanno bisogno di tempo per riscaldarsi. Se si distribuisce molto spesso, il processo non può raggiungere le prestazioni ottimali. Separare le parti che sono sviluppate indipendentemente in modo che possano essere schierate in modo indipendente potrebbe quindi essere utile.

C'è anche una divisione tra teoria e pratica. Mentre un'architettura di microservizi è impossibile o almeno molto dolorosa senza una distribuzione abbastanza automatizzata, questo è meno vero per i monoliti. Quindi, se una distribuzione di monoliti è manuale, ogni implementazione sarà molto macchinosa e verrà evitata. Ma questo non è un problema dei monoliti, è un problema di strumenti e cultura.

In realtà, è vero. Perché un'applicazione monolitica è una singola applicazione autonoma senza alcuna modularità di cui parlare. Le applicazioni monolitiche non condividono alcun codice con altre applicazioni. Ma questi non sono unicorni. Esistono in molte basi di codice legacy, principalmente come programmi monolitici, anche se devo ancora vedere un'applicazione monolitica da un milione di righe. Sarebbe un incubo di proporzioni epiche. La maggior parte delle applicazioni legacy e moderne, anche quelle scritte in lingue che precedono Java raramente sono completamente monolitiche quando fanno chiamate ad altri programmi o procedure, e questo consente loro di essere aggiornati senza aggiornare l'intera applicazione. È possibile che questo libro che difende i micro-servizi è solo costruire un uomo di paglia, così da poterlo più facilmente abbattere.

Se stai usando moduli e DLL, l'applicazione non è più monolitica.