Come posso garantire la coerenza tra i nuovi microservizi?

La mia organizzazione sta vivendo un'esplosione di microservizi. Al momento non esiste un modo formale di avviare il bootstrap di nuovi progetti. Sto scoprendo che un team verrà da me con un bug nel suo processo di distribuzione o compilazione, e ci passerò del tempo solo per rendermi conto di averlo già risolto in un altro progetto. C'è anche molta incoerenza tra i progetti che vorrei vedere standardizzati.

Le modifiche spesso coinvolgono un singolo file (ad es. Serverless.yml o un Makefile), pertanto una soluzione che coinvolge librerie condivise, ad esempio i sottomoduli git, non sembra praticabile. Ogni progetto avrà una propria serie di configurazioni che devono essere mantenute, ad esempio Dockerfiles o serverless.yml, quindi le soluzioni di gestione della configurazione centralizzata per VM non sono realmente applicabili.

Come posso garantire che i nuovi microservizi siano conformi agli standard dell'organizzazione e includano correzioni / funzionalità di progetti esistenti in modo semplice e intuitivo per gli sviluppatori che vogliono avviare nuovi progetti? Quali sono alcune best practice per risolvere questi problemi?

L'attuale flusso di lavoro che abbiamo è di chiedere alla persona accanto a te "da quale progetto dovrei clonare per usare come modello?" e quindi eliminare tutto ciò che non è necessario per quel progetto.

Aggiungerò una risposta su quale sia la mia soluzione finora, ma sono ancora veramente interessato a sapere come altre organizzazioni stanno risolvendo questo problema e le migliori pratiche che hanno.

Per risolvere il problema di non avere una base coerente per la creazione di progetti, la mia idea è quella di creare un repository (repository?) Di piastre / modelli di caldaie e utilizzare cookiecutter come strumento per impilare nuovi microservizi. In questo modo, ogni progetto viene creato da una base standard con tutte le lezioni che abbiamo imparato come organizzazione integrata al suo interno. Eventuali modifiche apportate possono essere integrate a monte nel repository boilerplate. Immagino che avremo modelli per immagini Nodejs Docker, Serverless SPA, Python lambdas, ecc.

Per risolvere il problema delle modifiche apportate ai modelli propagandati a valle di ogni progetto, la mia soluzione è quella di implementare un processo in cui i proprietari dei microservizi sono resi consapevoli delle modifiche al modello e sono quindi responsabili della propagazione di tali modifiche al loro microservizio.

Utilizzare un sistema di gestione della configurazione / distribuzione automatica. Questo è ciò per cui sono stati progettati. Cose come Kubernetes, Puppet, Chef, Ansible e Salt Stack sono progettate proprio per questo scopo e possono essere utilizzate con modelli Golden Master, script kickstart, AMI Amazon o semplicemente un contenitore Docker. Ciò consente di utilizzare modelli di base predefiniti e quindi sovrapporre ruoli aggiuntivi. Ciò garantirà che le build siano completamente documentate (come codice) e che saranno veloci e facili da distribuire alla produzione e saranno distribuite esattamente in modo identico a ciò che è stato progettato o distribuito istanze aggiuntive quando si presenta la necessità di scalabilità o ridondanza o si rompe qualcosa. Modifiche / aggiornamenti possono anche essere integrati in questo modo. Proprio come rilasci aggiornamenti software, puoi rilasciare aggiornamenti alla tua configurazione e il codice di configurazione può essere gestito proprio come il tuo codice software è gestito - negli stessi repository e con gli stessi flussi di lavoro. E quando arriva il momento dell'aggiornamento, non c'è mistero su come sia costruita la cosa, basta guardare la sceneggiatura.

Un modo in cui i sistemi di gestione della configurazione lo fanno è attraverso un uso intenso del modello per i file di configurazione. Ad esempio, ci sono generalmente molte linee che saranno uguali o simili nel tuo ambiente. SaltStack utilizza modelli jinja e Puppet utilizza modelli Ruby incorporati . Usando AWS come esempio, potrebbe essere necessario impostare una chiave api, un ruolo IAM, una regione (o selezionare casualmente una regione da un elenco di regioni), un VPC, ecc. Che è lo stesso in tutte le istanze. Ma poi devi avere le tue funzioni e le tue uscite uniche. O meglio ancora potresti scrivere un modulo fantoccio o una formula salt che definisce i "contratti" e utilizzare quei contratti (definizioni api) sia per gli ingressi che per le uscite, evitando di dover configurare i tuoi microservizi in due o tre posti.

SaltStack, ad esempio, recentemente ha avuto un incontro per discutere di questo particolare scenario . Inoltre, SaltStack è anche in grado di gestire e distribuire nativamente container docker . (Puppet ha anche un modulo per Docker ) Allo stesso modo Ansible ha playbook e documenti per lavorare con distribuzioni senza server e contenitori Docker .

Inoltre, se desideri continuare con il tuo tema / paradigma serverless, Puppet , Ansible e saltstack sono tutti senza master o supportano una modalità senza master, se desideri continuare questo tema.

Questa domanda è ampia, quindi se la mia risposta è un po 'off-base sentiti libero di aggiungere contesto ed esempi specifici in modo da avere una migliore comprensione.

L'utilizzo di un'immagine macchina come AMI di AWS ti consentirebbe di creare un'immagine di base o dorata, che potresti quindi mantenere e distribuire o implementare nella tua consegna continua. Usando questa architettura, si garantisce che ogni microservizio sia distribuito su hardware coerente con una configurazione identica, quindi tutti i problemi che si incontrano sono correlati alla configurazione microservizio / applicazione.

È possibile promuovere questa immutabilità con l'aggiunta di strumenti di configurazione come Ansible e Packer. Utilizzando la gestione della configurazione è possibile eseguire il provisioning dell'immagine della macchina con tutto ciò che si desidera su di essa (inclusa l'applicazione). Packer ti consentirebbe quindi di scattare un'istantanea dell'immagine di quella macchina e ogni distribuzione sarebbe identica.

Utilizzando questo esempio è possibile "creare" un AMI di base con i pacchetti, gli aggiornamenti e la configurazione corretti installati con l'aiuto di Ansible e Packer. Inoltre, è possibile guardare 'Ansible-Pull' per completare la distribuzione estraendo il codice dell'applicazione, apportando eventuali modifiche e distribuendo il microservizio sull'immagine di base.

Tuttavia, il consiglio più importante che posso dare è quello di trovare una soluzione che l'intera organizzazione possa supportare e mantenere. Vale la pena provare a stabilire un SDLC che risolva il tuo particolare insieme di problemi, abbina la cultura e l'atteggiamento della leadership e abbraccia le pratiche dell'architettura moderna.

Sono stato con tre organizzazioni e abbiamo adottato tre approcci molto diversi.

In bocca al lupo!