Il 25 aprile, noi del Mail.ru Group abbiamo tenuto una conferenza sulle nuvole e dintorni - . Alcuni punti salienti:
- Il principale — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center e Yandex.Cloud hanno parlato delle specificità del nostro mercato cloud e dei loro servizi;
- I colleghi di Bitrix24 hanno raccontato come ;
- Leroy Merlin, Otkritie, Burger King e Schneider Electric si sono rivelati interessanti - quali compiti la loro azienda assegna all'IT e quali tecnologie, comprese quelle cloud, considerano le più promettenti.
Puoi guardare tutti i video della conferenza mailto:CLOUD e qui puoi leggere come è andata la discussione sui microservizi. Alexander Deulin, capo del centro di ricerca e sviluppo dei sistemi aziendali MegaFon, e Sergey Sergeev, direttore della tecnologia informatica del gruppo M.Video-Eldorado, hanno condiviso i loro casi di successo di eliminazione dei monoliti. Abbiamo anche discusso questioni correlate alla strategia IT, ai processi e persino alle risorse umane.
Panelisti
- Sergey Sergeev, CIO del Gruppo "M.Video-Eldorado";
- Alessandro Deulin, responsabile del centro ricerca e sviluppo dei sistemi aziendali Megafon;
- Moderatore — Dmitrij Lazarenko, Responsabile della direzione PaaS Mail.ru soluzioni cloud.
Dopo il discorso di Alexander Deulin a lui si uniscono per la discussione Sergey Sergeev di M.Video-Eldorado e il moderatore della discussione Dmitry Lazarenko, Mail.ru Cloud Solutions.
Di seguito abbiamo preparato per voi una trascrizione della discussione, ma potete anche guardare il video:
La transizione ai microservizi è una risposta alle esigenze del mercato
Dmitry:
Hai avuto esperienze di successo con la migrazione ai microservizi? E in generale: dove vedete i maggiori vantaggi per il business derivanti dall’utilizzo dei microservizi o dal passaggio dai monoliti ai microservizi?
Sergey:
Abbiamo già fatto un passo avanti nella transizione ai microservizi e utilizziamo questo approccio da più di tre anni. La prima esigenza che giustificava la necessità dei microservizi era l’integrazione infinita di vari prodotti front-end con il back office. E ogni volta siamo stati costretti a fare ulteriore integrazione e sviluppo, implementando le nostre regole per il funzionamento di questo o quel servizio.
Ad un certo punto, ci siamo resi conto che dovevamo accelerare il funzionamento dei nostri sistemi e l'output delle funzionalità. A quel tempo sul mercato esistevano già concetti come i microservizi e l’approccio basato sui microservizi e abbiamo deciso di provarli. Tutto è iniziato nel 2016. Successivamente è stata posata la piattaforma e i primi 10 servizi sono stati implementati da un team separato.
Uno dei primi servizi, il più carico, è stato il servizio di calcolo dei prezzi. Ogni volta che accedi a qualsiasi canale, al gruppo di società M.Video-Eldorado, sia esso un sito Web o un negozio al dettaglio, selezioni un prodotto lì, vedi il prezzo sul sito Web o nel "Carrello", il costo viene automaticamente calcolato da un servizio. Perché è necessario: prima ogni sistema aveva i propri principi per lavorare con le promozioni, con sconti e così via. Il nostro back office gestisce i prezzi; la funzionalità di sconto è implementata in un altro sistema. Questo doveva essere centralizzato e creare un servizio unico e separabile sotto forma di processo aziendale che ci permettesse di implementarlo. È più o meno così che abbiamo iniziato.
Il valore dei primi risultati è stato molto grande. Innanzitutto siamo riusciti a creare entità separabili che ci permettono di lavorare separatamente e in modo aggregato. In secondo luogo, abbiamo ridotto i costi di proprietà in termini di integrazione con più sistemi.
Negli ultimi tre anni abbiamo aggiunto tre sistemi in prima linea. Era difficile mantenerli con la stessa quantità di risorse che l’azienda poteva permettersi. Si è posto quindi il compito di cercare nuovi sbocchi, rispondendo al mercato in termini di rapidità, in termini di costi interni ed efficienza.
Come misurare il successo della migrazione ai microservizi
Dmitry:
Come viene determinato il successo della migrazione ai microservizi? Qual è stato il “prima” in ciascuna azienda? Quale metrica hai utilizzato per determinare il successo della transizione e chi lo ha effettivamente determinato?
Sergey:
Innanzitutto, è nato all'interno dell'IT come abilitatore, "sbloccando" nuove funzionalità. Avevamo la necessità di fare tutto più velocemente con la stessa somma di denaro, rispondendo alle sfide del mercato. Ora il successo si esprime nel numero di servizi riutilizzati da diversi sistemi e nell'unificazione dei processi tra loro. Adesso lo è, ma in quel momento è stata l'occasione per creare una piattaforma e confermare l'ipotesi che possiamo farlo, darà un effetto e calcolerà il business case.
Alexander:
Il successo è piuttosto un sentimento interno. Il business vuole sempre di più e l’entità del nostro portafoglio ordini è la prova del successo. Mi sembra di sì.
Sergey:
Si, sono d'accordo. In tre anni abbiamo già più di duecento servizi e arretrati. La necessità di risorse all'interno del team cresce solo del 30% all'anno. Questo accade perché le persone sentono: è più veloce, è diverso, ci sono tecnologie diverse, tutto questo si sta sviluppando.
Arriveranno i microservizi, ma il nucleo rimarrà
Dmitry:
È come un processo infinito in cui investi nello sviluppo. La transizione ai microservizi per le imprese è già terminata oppure no?
Sergey:
È molto facile rispondere. Cosa ne pensi: sostituire i telefoni è un processo infinito? Noi stessi compriamo telefoni ogni anno. Ed eccolo qui: finché ci sarà bisogno di velocità, di adattamento al mercato, qualche cambiamento sarà necessario. Ciò non significa che abbandoniamo le cose standard.
Ma non possiamo coprire e rifare tutto in una volta. Disponiamo di servizi di integrazione standard legacy che esistevano prima: bus aziendali e così via. Ma c’è un arretrato e c’è anche una necessità. Il numero di applicazioni mobili e le loro funzionalità sono in crescita. Allo stesso tempo, nessuno dice che ti verrà dato il 30% in più di denaro. Cioè ci sono sempre i bisogni da un lato e la ricerca dell’efficienza dall’altro.
Dmitry:
La vita è in buona forma. (Ride)
Alexander:
In generale, sì. Non abbiamo approcci rivoluzionari per rimuovere la parte centrale dal paesaggio. È in corso un lavoro sistematico per scomporre i sistemi in modo che siano più coerenti con l’architettura dei microservizi, per ridurre l’influenza reciproca dei sistemi.
Ma intendiamo mantenere la parte fondamentale, poiché nel panorama degli operatori ci saranno sempre alcune piattaforme che acquisteremo. Ancora una volta, abbiamo bisogno di un sano equilibrio: non dobbiamo affrettarci a eliminare il nucleo centrale. Mettiamo i sistemi uno accanto all'altro e ora si scopre che siamo già al di sopra di molte parti fondamentali. Inoltre, sviluppando la funzionalità, creiamo le rappresentazioni necessarie per tutti i canali che funzionano con i nostri servizi di comunicazione.
Come vendere microservizi alle imprese
Dmitry:
Mi interessa anche, per coloro che non sono passati, ma stanno pianificando di farlo: quanto è stato facile vendere questa idea alle imprese ed è stata un'avventura, un progetto di investimento? Oppure era una strategia consapevole: ora andiamo ai microservizi e basta, niente ci fermerà. Com'è stato per te?
Sergey:
Non stavamo vendendo un approccio, ma un vantaggio aziendale. C'era un problema negli affari e abbiamo cercato di risolverlo. In quel momento, ciò si esprimeva nel fatto che diversi canali utilizzavano principi diversi per il calcolo dei prezzi: separatamente per le promozioni, per le promozioni e così via. Era difficile da mantenere, si verificavano errori e ascoltavamo i reclami dei clienti. Cioè, stavamo vendendo una soluzione a un problema, ma siamo arrivati alla conclusione che avevamo bisogno di soldi per creare una piattaforma. E hanno mostrato un business case usando l'esempio della prima fase di investimento: come continueremo a recuperarlo e cosa questo ci consentirà di fare.
Dmitry:
Hai registrato in qualche modo il tempo della prima tappa?
Sergey:
Si certo. Abbiamo assegnato 6 mesi per creare il nucleo come piattaforma e testare il progetto pilota. Durante questo periodo, abbiamo provato a creare una piattaforma su cui far pattinare il pilota. Poi l’ipotesi è stata confermata, e visto che funziona vuol dire che possiamo continuare. Hanno iniziato a replicare e rafforzare la squadra: l'hanno spostata in una divisione separata che fa proprio questo.
Poi viene il lavoro sistematico basato sulle esigenze aziendali, sulle opportunità, sulla disponibilità delle risorse e su tutto ciò che è attualmente in cantiere.
Dmitry:
OK. Alessandro, che ne dici?
Alexander:
I nostri microservizi sono nati dalla “schiuma del mare” - a causa del risparmio di risorse, a causa di alcuni avanzi sotto forma di capacità del server e della ridistribuzione delle forze all'interno del team. Inizialmente, non abbiamo venduto questo progetto alle imprese. Questo è stato un progetto in cui entrambi abbiamo ricercato e sviluppato di conseguenza. Abbiamo iniziato all’inizio del 2018 e abbiamo semplicemente sviluppato questa direzione con entusiasmo. Le vendite sono appena iniziate e siamo nel processo.
Dmitry:
Succede che un'azienda ti permetta di fare cose come Google - in un giorno libero alla settimana? Hai una direzione del genere?
Alexander:
Contemporaneamente alla ricerca ci siamo occupati anche di problemi aziendali, quindi tutti i nostri microservizi sono soluzioni a problemi aziendali. Solo all’inizio abbiamo costruito microservizi che coprivano una piccola parte della base abbonati, e ora siamo presenti in quasi tutti i prodotti di punta.
E l’impatto materiale è già chiaro: possiamo già essere contati, la velocità del lancio dei prodotti e la perdita di entrate possono essere stimate se avessimo seguito il vecchio percorso. Questo è ciò su cui stiamo costruendo il caso.
Microservizi: illusione o necessità?
Dmitry:
I numeri sono numeri. E le entrate o il denaro risparmiato sono molto importanti. E se guardassi dall'altra parte? Sembra che i microservizi siano una tendenza, una montatura e molte aziende ne stiano abusando? Quanto chiaramente distingui ciò che fai e ciò che non traduci in microservizi? Se l'eredità è ora, ne avrai ancora tra 5 anni? Quale sarà l'età dei sistemi informativi che funzionano su M.Video-Eldorado e MegaFon tra 5 anni? Ci saranno sistemi informativi vecchi di dieci, quindici anni o si tratterà di una nuova generazione? Come lo vedi?
Sergey:
Mi sembra che sia difficile pensare molto lontano. Se guardiamo indietro, chi immaginava che il mercato della tecnologia si sarebbe sviluppato in questo modo, includendo l’apprendimento automatico e l’identificazione dell’utente tramite volto? Ma se guardi ai prossimi anni, mi sembra che i sistemi core, i sistemi aziendali di classe ERP nelle aziende, funzionino da molto tempo.
Le nostre aziende hanno complessivamente 25 anni e l'ERP classico è molto inserito nel panorama dei sistemi. È chiaro che stiamo togliendo alcuni pezzi da lì e cercando di aggregarli in microservizi, ma il nucleo rimarrà. È difficile per me ora immaginare che sostituiremo tutti i sistemi principali e passeremo rapidamente all’altro lato positivo dei nuovi sistemi.
Sono un sostenitore del fatto che tutto ciò che è più vicino al cliente e al consumatore è dove si trova il maggior vantaggio e valore aziendale, dove si trovano l'adattabilità e l'attenzione alla velocità, al cambiamento, al “provare, annullare, riutilizzare, fare qualcosa di diverso”. necessario”: ecco dove il panorama cambierà. E i prodotti confezionati non si adattano molto bene. Almeno non lo vediamo. Lì sono necessarie le soluzioni più facili e semplici.
Vediamo questo sviluppo:
- sistemi informativi fondamentali (principalmente back office);
- gli strati intermedi sotto forma di microservizi collegano il core, aggregano, creano una cache e così via;
- i sistemi front-line sono rivolti al consumatore;
- uno strato di integrazione che è generalmente integrato nei mercati, in altri sistemi ed ecosistemi. Questo livello è il più leggero possibile, semplice e contiene un minimo di logica aziendale.
Allo stesso tempo, però, sono favorevole a continuare a utilizzare i vecchi principi, se utilizzati in modo appropriato.
Supponiamo che tu abbia un sistema aziendale classico. Si trova nel panorama di un fornitore ed è composto da due moduli che funzionano tra loro. C'è anche un'interfaccia di integrazione standard. Perché rifarlo e portare lì un microservizio?
Ma quando ci sono 5 moduli nel back office, da cui le informazioni vengono raccolte in un processo aziendale, che viene poi utilizzato da 8-10 sistemi di front-line, il vantaggio è immediatamente evidente. Prendi da cinque sistemi di back-office e crei un servizio, isolato, focalizzato sul processo aziendale. Rendi il servizio tecnologicamente avanzato, in modo che memorizzi le informazioni nella cache, sia tollerante ai guasti e funzioni anche con documenti o entità aziendali. E lo integri secondo un unico principio con tutti i prodotti di prima linea. Hanno annullato il prodotto in prima linea: hanno semplicemente disattivato l'integrazione. Domani dovrai scrivere un'applicazione mobile o creare un piccolo sito Web e mettere in funzionalità solo una parte: tutto è semplice: l'hai assemblato come un costruttore. Vedo un maggiore sviluppo in questa direzione, almeno nel nostro Paese.
Alexander:
Sergey ha descritto completamente il nostro approccio, grazie. Dirò solo dove sicuramente non andremo: alla parte fondamentale, al tema della fatturazione online. Cioè, la valutazione e l'addebito rimarranno, in effetti, una "grande" trebbiatrice che cancellerà in modo affidabile il denaro. E questo sistema continuerà a essere certificato dalle nostre autorità di regolamentazione. Tutto il resto che riguarda i clienti, ovviamente, sono microservizi.
Dmitry:
Qui la certificazione è una storia. Probabilmente più supporto. Se si spende poco per il supporto o il sistema non necessita di supporto e modifiche è meglio non toccarlo. Un compromesso ragionevole.
Come sviluppare microservizi affidabili
Dmitry:
Bene. Ma sono ancora interessato. Ora stai raccontando una storia di successo: è andato tutto bene, siamo passati ai microservizi, abbiamo difeso l'idea all'azienda e tutto ha funzionato. Ma ho sentito altre storie.
Un paio di anni fa, un’azienda svizzera che aveva investito due anni nello sviluppo di una nuova piattaforma di microservizi per le banche alla fine ha chiuso il progetto. Completamente crollato. Sono stati spesi molti milioni di franchi svizzeri e alla fine la squadra è stata dispersa: non ha funzionato.
Hai avuto storie simili? Ci sono state o ci sono delle difficoltà? Ad esempio, anche il mantenimento dei microservizi e il monitoraggio rappresentano un grattacapo nelle attività operative dell’azienda. Dopotutto, il numero di componenti aumenta decine di volte. Come la vede, ci sono stati esempi di investimenti infruttuosi qui? E cosa puoi consigliare alle persone in modo che non incontrino tali problemi?
Alexander:
Esempi infruttuosi includono aziende che cambiano priorità e annullano progetti. Quando si trovava in una buona fase di preparazione (in effetti, l'MVP è pronto), l'azienda ha dichiarato: "Abbiamo nuove priorità, stiamo passando a un altro progetto e stiamo chiudendo questo".
Non abbiamo riscontrato errori globali con i microservizi. Dormiamo sonni tranquilli, abbiamo un turno di lavoro 24 ore su 7, XNUMX giorni su XNUMX, che serve l'intero BSS [sistema di supporto aziendale].
E ancora una cosa: affittiamo microservizi secondo le regole che si applicano ai prodotti in scatola. La chiave del successo è che è necessario, in primo luogo, mettere insieme un team che preparerà completamente il microservizio per la produzione. Lo sviluppo stesso è, condizionatamente, del 40%. Il resto è analisi, metodologia DevSecOps, giuste integrazioni e giusta architettura. Prestiamo particolare attenzione ai principi della creazione di applicazioni sicure. I rappresentanti della sicurezza informatica partecipano a ciascun progetto sia nella fase di pianificazione dell'architettura che durante il processo di implementazione. Gestiscono anche sistemi per l'analisi del codice per le vulnerabilità.
Diciamo che distribuiamo i nostri servizi stateless: li abbiamo in Kubernetes. Ciò consente a tutti di dormire sonni tranquilli grazie al ridimensionamento automatico e all'aumento automatico dei servizi e il turno di servizio rileva gli incidenti.
Nell’intera esistenza dei nostri microservizi si sono verificati solo uno o due incidenti che hanno raggiunto la nostra linea. Ora non ci sono problemi con il funzionamento. Ovviamente non abbiamo 200, ma circa 50 microservizi, ma vengono utilizzati nei prodotti di punta. Se fallissero, saremmo i primi a saperlo.
Microservizi e risorse umane
Sergey:
Sono d'accordo con il mio collega riguardo al trasferimento al sostegno: il lavoro deve essere organizzato correttamente. Ma vi parlerò dei problemi che, ovviamente, esistono.
Innanzitutto la tecnologia è nuova. Questa è una pubblicità in senso positivo e trovare uno specialista che capisca e possa crearla è una grande sfida. La competizione per le risorse è pazzesca, quindi gli esperti valgono oro.
In secondo luogo, con la creazione di determinati paesaggi e un numero crescente di servizi, il problema del riuso deve essere costantemente risolto. Come piace fare agli sviluppatori: “Scriviamo un sacco di cose interessanti qui adesso...” Per questo motivo, il sistema cresce e perde la sua efficacia in termini di denaro, costi di proprietà e così via. Cioè, è necessario includere il riutilizzo nell'architettura del sistema, includerlo nella tabella di marcia per l'introduzione dei servizi e il trasferimento dell'eredità in una nuova architettura.
Un altro problema, anche se a suo modo positivo, è la concorrenza interna. "Oh, qui sono apparsi nuovi ragazzi alla moda, parlano una nuova lingua." Le persone, ovviamente, sono diverse. C'è chi è abituato a scrivere in Java e chi scrive e usa Docker e Kubernetes. Queste sono persone completamente diverse, parlano in modo diverso, usano termini diversi e talvolta non si capiscono. Anche la capacità o l’incapacità di condividere la pratica, la condivisione della conoscenza, in questo senso è un problema.
Bene, ridimensionare le risorse. "Grande andiamo! E ora vogliamo più velocemente, di più. Cosa, non puoi? Non è possibile consegnare il doppio in un anno? E perché?" Tali dolori della crescita sono probabilmente standard per molte cose, molti approcci e puoi sentirli.
Per quanto riguarda il monitoraggio. Mi sembra che i servizi o gli strumenti di monitoraggio industriale stiano già imparando o siano in grado di lavorare sia con Docker che con Kubernetes in una modalità diversa e non standard. In modo che, ad esempio, non ci si ritrovi con 500 macchine Java sotto le quali tutto questo gira, cioè si aggrega. Ma questi prodotti non sono ancora maturi e devono passare attraverso questo. L'argomento è davvero nuovo, continuerà a svilupparsi.
Dmitry:
Sì, molto interessante. E questo vale per le risorse umane. Forse il tuo processo HR e il tuo marchio HR sono leggermente cambiati in questi 3 anni. Hai iniziato a reclutare altre persone con competenze diverse. E probabilmente ci sono sia pro che contro. In precedenza, blockchain e scienza dei dati erano l’hype e i loro specialisti valevano milioni. Ora i costi stanno diminuendo, il mercato si sta saturando e si osserva una tendenza simile anche per i microservizi.
Sergey:
Sì, assolutamente.
Alexander:
Le risorse umane pongono la domanda: "Dov'è il tuo unicorno rosa tra il backend e il frontend?" Le risorse umane non capiscono cosa sia un microservizio. Abbiamo rivelato loro il segreto e detto loro che il backend ha fatto tutto e che non esiste un unicorno. Ma le risorse umane stanno cambiando, imparando rapidamente e reclutando persone con conoscenze IT di base.
L'evoluzione dei microservizi
Dmitry:
Se guardi l’architettura di destinazione, i microservizi sembrano un vero mostro. Il tuo viaggio è durato diversi anni. Altri hanno un anno, altri tre anni. Avevi previsto tutti i problemi, l'architettura target, è cambiato qualcosa? Nel caso dei microservizi, ad esempio, ricompaiono gateway e service mesh. Li hai usati all'inizio o hai cambiato l'architettura stessa? Hai queste sfide?
Sergey:
Abbiamo già riscritto diversi protocolli di comunicazione. All'inizio c'era un protocollo, ora siamo passati a un altro. Aumentiamo la sicurezza e l'affidabilità. Abbiamo iniziato con le tecnologie aziendali: Oracle, Web Logic. Ora ci stiamo allontanando dai prodotti tecnologici aziendali nei microservizi e passando a tecnologie open source o completamente aperte. Abbandoniamo i database e passiamo a ciò che funziona più efficacemente per noi in questo modello. Non abbiamo più bisogno delle tecnologie Oracle.
Abbiamo iniziato semplicemente come servizio, senza pensare a quanto avremmo avuto bisogno di cache, cosa avremmo fatto quando non ci fosse connessione con un microservizio, ma fossero necessari dati, ecc. Ora stiamo sviluppando una piattaforma in modo che l'architettura possa essere descritta non nel linguaggio dei servizi, ma nel linguaggio degli affari, portiamo la logica aziendale al livello successivo quando iniziamo a parlare a parole. Ora abbiamo imparato a parlare in lettere e il livello successivo è quando i servizi verranno raccolti in una sorta di aggregato, quando questa è già una parola, ad esempio un'intera scheda prodotto. È assemblato da microservizi, ma è un'API costruita sopra.
La sicurezza è molto importante. Non appena inizi ad essere accessibile e hai un servizio attraverso il quale puoi ottenere molte cose interessanti, e molto rapidamente, in una frazione di secondo, allora c'è il desiderio di ottenerlo nel modo non più sicuro. Per uscire da questo, abbiamo dovuto cambiare l’approccio ai test e al monitoraggio. Abbiamo dovuto cambiare il team, la struttura di gestione della consegna, CI/CD.
Si tratta di un'evoluzione, come con i telefoni, solo molto più veloce: prima c'erano i telefoni a pulsanti, poi sono comparsi gli smartphone. Hanno riscritto e ridisegnato il prodotto perché il mercato aveva un’esigenza diversa. Evolviamo così: prima elementare, seconda media, lavoro.
In modo iterativo, all'anno viene preparato qualcosa dal punto di vista della tecnologia, qualcos'altro dal punto di vista dell'arretrato e dei bisogni. Colleghiamo una cosa all'altra. Il team spende il 20% per il debito tecnico e il supporto tecnico per il team, l'80% per l'entità aziendale. E ci muoviamo con la consapevolezza del motivo per cui lo stiamo facendo, perché stiamo apportando questi miglioramenti tecnologici, a cosa porteranno. Come quello.
Dmitry:
Freddo. Cosa c'è in MegaFon?
Alexander:
La sfida principale quando si è arrivati ai microservizi è stata quella di non cadere nel caos. Lo studio di architettura MegaFon si è immediatamente unito a noi, diventando addirittura un iniziatore e promotore: ora abbiamo un'architettura molto forte. Il suo compito era capire a quale modello target stiamo andando e quali tecnologie devono essere pilotate. Con l'architettura, abbiamo condotto noi stessi questi progetti pilota.
La domanda successiva era: “Allora come sfruttare tutto questo?” E ancora: “Come garantire un’interazione trasparente tra i microservizi?” La rete di servizi ci ha aiutato a rispondere all'ultima domanda. Abbiamo sperimentato Istio e i risultati ci sono piaciuti. Ora siamo nella fase di implementazione nelle zone produttive. Abbiamo un atteggiamento positivo verso tutte le sfide: dobbiamo cambiare costantemente lo stack, imparare qualcosa di nuovo. A noi interessa sviluppare, non sfruttare vecchie soluzioni.
Dmitry:
Parole d'oro! Tali sfide mantengono il team e l’azienda all’erta e creano il futuro. Il GDPR ha creato i responsabili della protezione dei dati, mentre le sfide attuali creano i responsabili dei microservizi e dell’architettura. E fa piacere.
Abbiamo discusso molto. La cosa principale è che una buona progettazione dei microservizi e dell'architettura stessa consente di evitare molti errori. Naturalmente, il processo è iterativo ed evolutivo, ma è il futuro.
Grazie a tutti i partecipanti, grazie a Sergei e Alexander!
Domande dal pubblico
Domanda del pubblico (1):
Sergey, come è cambiata la gestione IT nella tua azienda? Capisco che quando c'è una grande pila di diversi sistemi, il modo in cui viene gestito è un processo abbastanza chiaro e logico. Come avete ricostruito la gestione della componente IT dopo aver integrato un numero molto elevato di microservizi in così poco tempo?
Sergey:
Sono d'accordo con il mio collega che l'architettura è molto importante come motore del cambiamento. Abbiamo iniziato con una divisione architettonica. Gli architetti sono contemporaneamente i proprietari della distribuzione delle funzionalità e dei requisiti per come apparirà nel paesaggio. Quindi agiscono anche come coordinatori di questi cambiamenti. Di conseguenza, sono state apportate modifiche specifiche a uno specifico processo di distribuzione quando abbiamo creato una piattaforma CI/CD.
Ma i principi standard e basilari di sviluppo, analisi aziendale, test e sviluppo non sono stati cancellati. Abbiamo solo aggiunto velocità. In precedenza, il ciclo richiedeva così tanto tempo, l'installazione negli ambienti di test richiedeva molto di più. Ora le imprese vedono il vantaggio e dicono: “Perché non possiamo fare lo stesso in altri posti?”
È come, in senso buono, un’iniezione sotto forma di vaccino che ha dimostrato: puoi farlo in questo modo, ma puoi farlo in un altro modo. Certo, c’è un problema di personale, di competenze, di conoscenza, di resistenza.
Domanda del pubblico (2):
I critici dell’architettura dei microservizi affermano che il test e lo sviluppo sono difficili. Questo è logico laddove le cose si complicano. Quali sfide ha dovuto affrontare il tuo team e come le hai superate? Domanda per tutti.
Alexander:
Ci sono difficoltà nel passaggio dai microservizi a una piattaforma, ma possono essere risolte.
Ad esempio, stiamo realizzando un prodotto composto da 5-7 microservizi. Dobbiamo fornire test di integrazione sull'intero stack di microservizi per dare il via libera al passaggio al ramo principale. Questo compito non era nuovo per noi: lo svolgevamo già da tempo in BSS, quando il fornitore ci forniva soluzioni già spedite.
E il nostro problema è solo nella piccola squadra. Per un prodotto condizionale è necessario un tecnico QA. E così, spediamo un prodotto composto da 5-7 microservizi, di cui 2-3 possono essere sviluppati da terze parti. Ad esempio, abbiamo un prodotto allo sviluppo del quale partecipano il nostro fornitore di sistemi di fatturazione, Mail.ru Group e MegaFon R&D. Dobbiamo coprire questo aspetto con dei test prima di spedirlo alla produzione. L'ingegnere del QA ha lavorato su questo prodotto per un mese e mezzo e il resto del team è rimasto senza il suo supporto.
Questa complessità è causata solo dal ridimensionamento. Comprendiamo che i microservizi non possono esistere nel vuoto; l’isolamento assoluto non esiste. Quando modifichiamo un servizio, cerchiamo sempre di preservare il contratto API. Se cambia qualcosa sotto il cofano, resta il servizio anteriore. Se le modifiche sono fatali, avviene una sorta di trasformazione dell'architettura e si passa a un metamodello di dati completamente diverso, che è completamente incompatibile: solo allora si parla della comparsa della specifica API del servizio v2. Supportiamo la prima e la seconda versione contemporaneamente e, dopo che tutti i consumatori sono passati alla seconda versione, chiudiamo semplicemente la prima.
Sergey:
Voglio aggiungere. Sono assolutamente d'accordo sulle complicazioni: accadono. Il panorama sta diventando più complesso e i costi generali stanno aumentando, soprattutto per i test. Come affrontare questo problema: passa ai test automatizzati. Sì, dovrai investire ulteriormente nella scrittura di autotest e unit test. In modo che gli sviluppatori non potessero impegnarsi senza superare il test, non potevano modificare il codice. In modo che anche il pulsante non funzioni senza autotest, test unitario.
È importante mantenere la funzionalità precedente e ciò comporta un sovraccarico aggiuntivo. Se riscrivi una tecnologia su un altro protocollo, la riscrivi finché non chiudi tutto completamente.
A volte non eseguiamo test end-to-end di proposito, perché non vogliamo interrompere lo sviluppo, anche se abbiamo una cosa dopo l'altra. Il paesaggio è molto vasto, complesso, ci sono tanti sistemi. A volte sono solo abbozzi: sì, abbassi il margine di sicurezza, compaiono più rischi. Ma allo stesso tempo rilasci la fornitura.
Alexander:
Sì, gli autotest e gli unit test ti consentono di creare un servizio di alta qualità. Siamo a favore di una pipeline che non può essere superata senza test unitari e di integrazione. Spesso dobbiamo trascinare emulatori e sistemi commerciali in zone di test e ambienti di sviluppo, perché non tutti i sistemi possono essere collocati in zone di test. Inoltre, non si limitano a bagnarsi: generiamo una risposta completa dal sistema. Questa è una parte importante del lavoro con i microservizi e stiamo investendo anche in essa. Senza questo, ne deriverà il caos.
Domanda del pubblico (3):
Per quanto ho capito, i microservizi inizialmente sono cresciuti da un team separato e ora esistono in questo modello. Quali sono i suoi pro e contro?
Abbiamo semplicemente una storia simile: è nata una sorta di fabbrica di microservizi. Ora siamo concettualmente arrivati al punto di estendere questo approccio alla produzione per flussi e per sistemi. In altre parole, ci stiamo allontanando dallo sviluppo centralizzato di microservizi, modelli di microservizi, e ci stiamo avvicinando ai sistemi.
Di conseguenza, il nostro intervento va anche ai sistemi, cioè decentralizziamo questo argomento. Qual è il tuo approccio e qual è la tua storia target?
Alexander:
Ti è caduto di bocca il nome "fabbrica di microservizi": anche noi vogliamo crescere. Innanzitutto, ora abbiamo davvero una squadra. Vogliamo fornire a tutti i team di sviluppo di MegaFon l'opportunità di lavorare in un ecosistema comune. Non vogliamo assumere completamente il controllo di tutte le funzionalità di sviluppo di cui disponiamo ora. Il compito locale è quello di scalare, il compito globale è guidare lo sviluppo a tutti i team nel livello dei microservizi.
Sergey:
Ti racconto il percorso che abbiamo intrapreso. Abbiamo davvero iniziato a lavorare come una squadra, ma ora non siamo soli. Sono un sostenitore di quanto segue: deve esserci un proprietario del processo. Qualcuno deve comprendere, gestire, controllare e costruire il processo di sviluppo dei microservizi. Deve possedere risorse e impegnarsi nella gestione delle risorse.
Queste risorse, che conoscono tecnologie, specifiche e capiscono come creare microservizi, possono essere collocate nei team di prodotto. Abbiamo un mix in cui le persone della piattaforma di microservizi fanno parte del team di prodotto che realizza l'applicazione mobile. Sono presenti, ma lavorano secondo il processo del dipartimento di gestione della piattaforma di microservizi con il loro responsabile dello sviluppo. All'interno di questa divisione c'è un team separato che si occupa della tecnologia. Cioè, mescoliamo tra noi un pool comune di risorse e le dividiamo, donandole ai team.
Allo stesso tempo, il processo rimane generale, controllato, procede secondo principi tecnologici generali, con test unitari e così via - tutto ciò che è costruito sopra. Potrebbero esserci colonne sotto forma di risorse raccolte da diversi dipartimenti dell'approccio al prodotto.
Alexander:
Sergey, in realtà sei tu il proprietario del processo, giusto? Il backlog delle attività è condiviso? Chi è responsabile della sua distribuzione?
Sergey:
Guarda: ecco di nuovo il mix. C'è un arretrato che si forma sulla base dei miglioramenti tecnologici: questa è una storia. C'è un arretrato, che è formato dai progetti, e c'è un arretrato dai prodotti. Ma la sequenza di introduzione in ciascuno dei prodotti di servizio o la creazione di questo servizio è sviluppata da uno specialista di prodotto. Non fa parte della direzione IT, ne è stato appositamente rimosso. Ma la mia gente lavora sicuramente secondo lo stesso processo.
I proprietari dell'arretrato in diverse direzioni - l'arretrato dei cambiamenti - saranno persone diverse. La connessione dei servizi tecnologici, il loro principio organizzativo: tutto questo sarà nell'IT. Possiedo anche la piattaforma e le risorse. In cima c'è ciò che riguarda il backlog e i cambiamenti funzionali, e l'architettura in questo senso.
Supponiamo che un'azienda dica: "Vogliamo questa funzione, vogliamo creare un nuovo prodotto - rifare un prestito". Rispondiamo: "Sì, lo rifaremo". Gli architetti dicono: “Pensiamo: dove scriveremo i microservizi nel prestito e come lo faremo?” Quindi lo scomponiamo in progetti, prodotti o stack tecnologico, lo inseriamo in team e lo implementiamo. Hai creato un prodotto internamente e hai deciso di utilizzare i microservizi in questo prodotto? Diciamo: “Ora i sistemi legacy che avevamo, o i sistemi di prima linea, devono passare a questi microservizi”. Gli architetti dicono: “Quindi: nell'arretrato tecnologico all'interno dei prodotti di prima linea - la transizione ai microservizi. Andare". E gli specialisti di prodotto o gli imprenditori capiscono quanta capacità viene assegnata, quando verrà eseguita e perché.
Fine della discussione, ma non solo
È stata organizzata la conferenza mailto:CLOUD .
Organizziamo anche altri eventi, ad es. @Kubernetes Meetup, dove siamo sempre alla ricerca di ottimi relatori:
- Segui @Kubernetes e le altre notizie di @Meetup nel nostro canale Telegram
- Ti interessa parlare a uno dei @Meetups? Lascia una richiesta per
Fonte: habr.com