Come implementare il tuo progetto di microservizi (parte 3)
In questa serie in sei parti sullo sviluppo di applicazioni di microservizi, forniremo un contesto per definire un progetto pilota basato su cloud che si adatta al meglio alle esigenze attuali e ti prepara per l'adozione cloud a lungo termine.
Nella parte 3, ti forniremo un metodo per implementare i tuoi progetti di microservizi.
Evoluzione di un'applicazione esistente
Ora spiegheremo come tracciare un percorso per sviluppare un'applicazione di microservizi specifica di diversa scala, in vista di una possibile progressione da trasformazioni su scala minore a scala maggiore per le applicazioni esistenti.
Sebbene creare progetti di microservizi senza un'applicazione precedente sia rilevante o importante, quando si costruiscono microservizi concordiamo tutti su un approccio "monolite first". In breve, questo significa che prima dovrai sviluppare la tua applicazione in qualsiasi modo possibile per convalidare la tua idea. Quindi, applica i principi di questa serie di blog per scalare ed evolvere il tuo monolite iniziale in un progetto di microservizio. Creare microservizi architettonicamente puri che non offrono valore all'azienda non ha nessun senso.
Per implementare con successo un progetto di microservizi, è necessario comprendere tre aspetti: la propria attività, la propria cultura e competenza, e la propria tecnologia.
Comprendere e definire le esigenze della tua azienda
Perché stai pensando di passare ai microservizi? Per molte aziende, sono necessarie pratiche di sviluppo e operazioni software più efficienti per fornire valore all'azienda in modo più rapido e offrire esperienze migliori agli utenti.
Prima di poter comprendere l'impatto di un progetto di microservizi sulle applicazioni esistenti e sull'infrastruttura, è necessario comprendere quali parti dell'azienda si stanno muovendo troppo lentamente per produrre risultati soddisfacenti. In molti casi, i sistemi di interazione (SOE) dell'organizzazione sono la causa di questa lentezza. Questi sistemi sono disponibili attraverso molti canali: web, mobile, API e simili. La mancanza di velocità è il motivo principale per passare a un'architettura basata su microservizi.
Prima di adottare un approccio orientato ai microservizi, tu e i tuoi stakeholder aziendali dovete sapere cos'è che non arriva sul mercato abbastanza velocemente. Quali parti dell'applicazione necessitano di miglioramenti e modifiche per diventare più veloci? Rispondere a questa domanda implica quali parti del monolite esistente devono essere destinate all'evoluzione del microservizio.
Utilizza i flussi di esperienza o i diagrammi di architettura per aiutare il team a ritagliare rapidamente le sezioni del monolite esistente tramite annotazioni in stile heat map. Ad esempio, utilizzando la scala rosso-giallo-verde per la priorità dei punti deboli, ecco un archivio di applicazioni web per una vetrina:
A questo punto, senza essere esaustivi e rimanendo aperti all'iterazione, gli obiettivi chiave della valutazione sono:
Identificare le funzioni aziendali separate fornite dal tuo monolito
Capire la velocità relativa e la complessità necessaria per cambiare queste funzioni aziendali.
Comprendere il desiderio del proprietario dell'azienda di vedere cicli di feedback più rapidi per quelle specifiche funzioni aziendali.
Comprendere la tua cultura e le tue competenze
Sebbene non sia specifico per le architetture basate su microservizi, una comprensione approfondita dei team, della cultura e delle competenze di un'organizzazione è fondamentale per una trasformazione digitale di successo.
In genere, nei monoliti ingegneristici, la maggior parte delle organizzazioni è integrata in silo, con i team che partecipano secondo necessità lungo il ciclo di vita dello sviluppo software. Questo spesso crea confini ben definiti, con ruoli e responsabilità restrittivi.
Le architetture di microservizi possono avere successo solo quando i team hanno il controllo sull'intero ciclo di vita dello sviluppo software e delle operazioni. La creazione di team interfunzionali che rappresentino tutti i ruoli e le responsabilità è fondamentale per implementare architetture basate su microservizio. Tutti, dal design allo sviluppo, dalle operazioni alla dirigenza, lavorano a stretto contatto e spesso sono collocati in sedi diverse.
Dal momento che ogni stakeholder è rappresentato nel team di design, sviluppo e operazioni, il lavoro può muoversi in modo più rapido, efficiente e concentrandosi con chiarezza sul miglioramento dell'esperienza per raggiungere gli obiettivi aziendali.
Un team interfunzionale supporta anche la crescita rapida delle competenze individuali in tutto il team. Quando un team ha il controllo su tutto ciò di cui il microservizio è responsabile, dalla progettazione alle operazioni ai dati di tempo di esecuzione, nessun membro svolge una sola unica attività. Spesso, gli ingegneri front-end sviluppano competenze di amministrazione del database, mentre i membri del team orientato alle operazioni imparano a conoscere le differenze tra i framework dell'interfaccia utente. Ampliare il set di competenze in questo modo aiuta l'organizzazione IT ad avere successo con i microservizi, in quanto è molto più facile creare nuovi team ben assortiti, invece di cercare costantemente specialisti per ricoprire ruoli molto specifici.
Comprendere la tecnologia
A meno che non si affrontino il problema aziendale, la cultura e le competenze del team, non sarai in grado di implementare efficacemente la tecnologia dei microservizi e manterrai gli stessi processi e le stesse strutture.
La corretta analisi degli stack tecnologici esistenti varia notevolmente da organizzazione a organizzazione, ma l'approccio semplificato che descriviamo aiuterà a garantire sia il successo iniziale che il successo duraturo dei tuoi progetti di microservizi. Iniziare in piccolo e definire successi iterativi e progressivi è un approccio molto più realizzabile e fruttuoso rispetto a un approccio esplosivo che trasforma tutto in una volta.
La prima fase della comprensione della tecnologia consiste nell'identificare i servizi a grana grossa presenti nel monolite esistente. La loro identificazione consente di comprendere la complessità delle strutture di dati, il livello di accoppiamento tra componenti correnti, i team responsabili di questi nuovi servizi di base e così via. Una recensione di successo dei servizi basilari offre una chiara comprensione dei confini, sia all'interno di un determinato servizio che tra più servizi.
Una volta identificati i servizi a grana grossa, è necessario creare un piano per la loro evoluzione in microservizi a granularità fine. Questi microservizi, basati sul lavoro precedente, devono lavorare tutti con dati simili, possedere dati propri e comprendere quali dati leggere da dove e scrivere in altri servizi. Da qui, è possibile identificare e implementare la resilienza, la scalabilità e l'agilità dei singoli microservizi
Le API e i microservizi sono due parti di un insieme più ampio. Una volta acquisita una migliore comprensione dei tuoi microservizi a grana fine, avrai anche una migliore comprensione delle tue interfacce, di quali si trovano sul percorso critico, quali sono facoltative e quali non ti servono più. Se non è possibile eseguire la mappatura di un'interfaccia o di un'API esistente a uno dei tuoi microservizi con granularità grossolana o fine, è molto probabile che sia possibile eliminarla.
Ridimensionamento dello sforzo dei microservizi
L'impegno profuso nel comprendere il business, la struttura del team e la tecnologia garantisce che i team e l'organizzazione in senso più ampio siano preparati a comprendere l'intera evoluzione dei microservizi di qualsiasi monolito, sia che si tratti di un ambito proof-of-concept, di un ambito pilota o di un'evoluzione su larga scala.
Una volta completato il lavoro di analisi e pianificazione, il prossimo passo consiste nel definire le tempistiche, le velocità di consegna e i risultati.
Nel prossimo post, prenderemo in considerazione i modelli di sviluppo e le operazioni che è possibile applicare nell'intraprendere una trasformazione dei microservizi.
Cosa fare ora:
Per modernizzare e rifattorizzare un'applicazione monolitica, visita progressione architettonica dettagliata.
Roland Barcia (IBM Distinguished Engineer/CTO) e Rick Osowski (Senior Technical Staff Member) hanno collaborato con Kyle per scrivere questo post.