La documentazione di Google, Docker e Kubernetes, quando parla di best practices, promuove l’adozione del concetto di “un’applicazione(o concern) per un container“. Applicazione o Concern rappresentano in modo simile lo stesso aspetto; mentre trovi la parola “application” nella documentazione di Google trovi invece “concern” all’interno della documentazione di Docker dove viene usata per indicare un insieme di processi di tipo parent/child che insieme formano un’unica applicazione.
Per rendere più semplice il concetto immagina un processo come un servizio web Apache o Nginx, questo processo Apache o Nginx avvierà una serie di processi “figli” che faranno sempre riferimento allo stesso processo “padre”. Pertanto l’applicazione è unica ma con diversi processi che la rendono effettivamente operativa.
Perchè è nato il modello One Concern One Container
Il razionale dietro questa semplice regola è quello di ridurre la complessità in un unico singolo modulo o servizio così da essere anche aderente ai continui cambiamenti di codice cui oggi sono soggetti i servizi, in poche parole, nell’ambito delle Cloud Native Application, c’è il massimo sforzo per disaccoppiare i servizi rendendone indipendente lo sviluppo ed il deploy così permettendone una crescita verticale ed esponenziale con casi in cui potresti dedicare un singolo sviluppatore ad una singola applicazione o microservizio (come ha illustrato anche l’azienda TrueLayer in una recente intervista). Disaccoppiando, oltre ad ottenere miglioramento continuo, si soddisfano le esigenze in termini di performance che possono essere effettivamente attagliate allo specifico servizio o applicazione.
I 7 vantaggi del modello One Concern One Container
Riprendendo quanto illustrato nell’articolo “Containers: one single process, or multiple processes?” di cui ne condividiamo i contenuti, possiamo affermare che i vantaggi del modello One Concern One Container sono:
- Isolation: quando i processi sono confinati all’interno di un singolo container non possono interferire gli uni con gli altri e sono protetti;
- Scalabilità: se si ha un singolo container con un unico processo è chiaramente più semplice da scalare, inoltre se più processi( e quindi container) fanno parte di un’applicazione più complessa, ogni singolo processo può seguire policy di scalabilità differenti così ottimizzando le risorse ed i costi;
- Testabilità: è più semplice fare troubleshooting o bugfixing su un singolo processo, inoltre vengono semplificati i test.
- Capacità di Deployment: anche in questo caso, lavorare su unico processo semplifica la vita nell’ambito degli upgrade e degli update rendendoli più semplici, immediati e con minori rischi;
- Riutilizzabilità: essendo un unico micro cosmo, il modello One Concern One Container permette di riutilizzare i container ed i processi così abbattendo i costi di sviluppo e rendendo adattabile ogni processo anche per futuri sviluppi e/o per altri progetti;
- Logging: è più semplice analizzare, collezionare, gestire i log di un singolo processo piuttosto che di molti. La suddivisione ed il disaccoppiamento aiutano a processare ed a definire policy di log allineate con le tue necessità di business.
- Orchestrazione: gestire il lifecycle di più processi viene reso immediato, funzionale ed efficiente grazie a strumenti di orchestrazione come Kubernetes Engine.
L’interoperabilità e la capacità evolutiva dei container che seguono il modello “One Concern One Container” rende agili gli sviluppi applicativi e perfettamente in linea con logiche di contenimento della spesa e riutilizzo del lavoro svolto.
Glue Labs ed i Container
Abbiamo progettato ed implementato Cluster di Container in ambiente Offline, On-Premise e Cloud. Utilizziamo i container dallo loro nascita. Grazie alle competenze specialistiche maturate in tantissimi settori e con numerosi Clienti ti forniamo assistenza e supporto, eroghiamo formazione avanzata sui container e realizziamo architetture complesse con garanzia 12 mesi da qualsiasi bug. Contattaci subito e senza impegno per maggiori informazioni.
