{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"Servizi orfani: il rovescio della medaglia dell'architettura dei microservizi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il direttore delle operazioni del portale Banki.ru, Andrey Nikolsky, ha parlato alla conferenza dell'anno scorso DevOpsDays Mosca<\/a><\/noindex> sui servizi orfani: come identificare un orfano nell'infrastruttura, quali siano i problemi dei servizi orfani, cosa fare e come comportarsi se non c'\u00e8 altra soluzione.<\/p>\n

Di seguito troverete la versione testuale della relazione. <\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nSalve, colleghi! Mi chiamo Andrey e mi occupo delle operazioni in Banki.ru.<\/p>\n

Abbiamo grandi servizi, ci sono monolith-service, ci sono servizi in una comprensione pi\u00f9 classica e ci sono quelli molto piccoli. Nella mia terminologia di lavoro dico che se un servizio \u00e8 semplice e piccolo, \u00e8 micro, se non \u00e8 molto semplice e non \u00e8 piccolo, \u00e8 semplicemente un servizio. <\/p>\n

Vantaggi dei servizi<\/b><\/h3>\n

\nDar\u00f2 un rapido sguardo ai vantaggi dei servizi. <\/p>\n

\"Servizi
\n
\nPrimo: scalabilit\u00e0. Puoi rapidamente fare qualcosa su un servizio e avviarlo in produzione. Se ricevi traffico, cloni il servizio. Se ricevi altro traffico, lo cloni di nuovo e continui cos\u00ec. Questo \u00e8 un buon vantaggio e, in effetti, quando abbiamo iniziato, era considerato il motivo principale per cui facciamo tutto questo.<\/p>\n

\"Servizi
\n
\nIn secondo luogo, lo sviluppo isolato, quando hai pi\u00f9 team di sviluppo, diversi sviluppatori in ogni team, e ogni team sviluppa il proprio servizio.<\/p>\n

Con i team ci sono delle sfide. Gli sviluppatori sono diversi. Esistono, ad esempio, persone uniche<\/a><\/noindex>. L'ho visto per la prima volta da Maxim Dorofeev. A volte, le persone uniche sono presenti in alcuni team, mentre in altri no. Questo rende i diversi servizi utilizzati in azienda un po' disomogenei. <\/p>\n

\"Servizi
\n
\nGuarda l'immagine: questo \u00e8 un buon sviluppatore, ha grandi mani e pu\u00f2 fare molte cose. Il problema principale \u00e8 capire da dove provengono queste mani. <\/p>\n

\"Servizi
\n
\nI servizi offrono la possibilit\u00e0 di utilizzare diversi linguaggi di programmazione, pi\u00f9 adatti a compiti specifici. Alcuni servizi sono in Go, altri in Erlang, altri in Ruby, alcuni in PHP, altri in Python. Insomma, si pu\u00f2 spaziare molto. Anche qui ci sono delle sfide.<\/p>\n

\"Servizi
\n
\nL'architettura orientata ai servizi riguarda soprattutto il devops. Cio\u00e8, se non hai automazione, non hai un processo di deployment, se configuri manualmente, le tue configurazioni possono cambiare da una istanza all'altra e devi entrare per fare qualcosa, sei nei guai. <\/p>\n

Ad esempio, hai 20 servizi e devi deployare manualmente, hai 20 console, e premi contemporaneamente 'invio', come un ninja. Non \u00e8 una situazione molto ideale. <\/p>\n

Se hai un servizio dopo il testing (se ovviamente ci sono stati test) e hai ancora bisogno di perfezionarlo per farlo funzionare in produzione, ho anche brutte notizie per te. <\/p>\n

Se fai affidamento su specifici servizi di Amazon e lavori in Russia, due mesi fa anche tu avevi 'tutto intorno brucia, sto bene, va tutto alla grande'.<\/p>\n

\"Servizi
\n
\nUtilizziamo Ansible per automatizzare il deploy, Puppet per la convergenza, Bamboo per l'automazione del deployment, Confluence per documentare tutto questo.<\/p>\n

Non ci approfondir\u00f2 perch\u00e9 la presentazione riguarda pi\u00f9 le pratiche di interazione piuttosto che l'implementazione tecnica. <\/p>\n

\"Servizi
\n
\nCi sono state volte in cui, ad esempio, Puppet sul server funziona con Ruby 2, mentre un'applicazione \u00e8 scritta per Ruby 1.8, e insieme non funzionano. Si verifica qualche problema. Quando devi mantenere pi\u00f9 versioni di Ruby su una sola macchina, in genere iniziano i guai. <\/p>\n

Noi, ad esempio, forniamo a ogni sviluppatore un ambiente in cui ci sono pi\u00f9 o meno tutti i servizi disponibili, cos\u00ec che abbia un ambiente isolato, possa romperlo e ricostruirlo come desidera. <\/p>\n

A volte serve un pacchetto compilato specificamente con supporto per alcune funzionalit\u00e0. \u00c8 una questione piuttosto rigida. Ho ascoltato una presentazione il cui'immagine Docker pesa 45 GB. Certo, su Linux \u00e8 pi\u00f9 semplice, tutto \u00e8 pi\u00f9 leggero, ma comunque non ci sar\u00e0 mai abbastanza spazio. <\/p>\n

Inoltre, ci sono dipendenze conflittuali, quando un pezzo del progetto dipende da una versione di una libreria, mentre un altro pezzo dipende da un'altra versione, e queste librerie non possono essere installate insieme in alcun modo. <\/p>\n

\"Servizi
\n
\nAbbiamo siti e servizi su PHP 5.6, di cui ci vergogniamo, ma che ci possiamo fare. Questa \u00e8 una delle nostre piattaforme. Abbiamo siti e servizi su PHP 7, che sono di pi\u00f9 e di cui non ci vergogniamo. E ogni sviluppatore ha il suo database, dove lavora felice. <\/p>\n

Se scrivete in azienda in un'unica lingua, tre macchine virtuali per sviluppatore suona normale. Se avete diversi linguaggi di programmazione, la situazione peggiora.<\/p>\n

\"Servizi
\n
\nAvete siti e servizi su questo, su quello, poi un'altra piattaforma per Go, una piattaforma per Ruby, e qualche Redis aggiuntivo. Alla fine, tutto ci\u00f2 si trasforma in un grande campo di supporto, e qualcosa potrebbe rompersi in qualsiasi momento.<\/p>\n

\"Servizi
\n
\nPerci\u00f2 abbiamo sostituito le comodit\u00e0 del linguaggio di programmazione con l'uso di diversi framework, poich\u00e9 i framework su PHP sono abbastanza diversi, con varie possibilit\u00e0, comunit\u00e0 e supporto. E si pu\u00f2 scrivere un servizio in modo tale che ci sia gi\u00e0 qualcosa di pronto per esso. <\/p>\n

Ogni servizio ha il proprio team.<\/b><\/h3>\n

\n\"Servizi
\n
\nIl nostro principale vantaggio, che si \u00e8 cristallizzato nel corso degli anni, \u00e8 che ogni servizio ha il proprio team. Questo \u00e8 comodo per grandi progetti, poich\u00e9 consente di risparmiare tempo sulla documentazione, e i manager conoscono bene il loro progetto. <\/p>\n

\u00c8 possibile gestire facilmente i compiti di supporto. Ad esempio, se un servizio di assicurazione si guasta, immediatamente il team che si occupa delle assicurazioni interviene per ripararlo. <\/p>\n

Nuove funzionalit\u00e0 vengono implementate rapidamente, perch\u00e9 quando avete un servizio atomico, \u00e8 possibile integrare qualcosa di operativo in modo tempestivo. <\/p>\n

E quando il vostro servizio si guasta, cosa che inevitabilmente succede, non toccate i servizi di altri, e i programmatori di altri team non vengono da voi impugnando mazze dicendo: \u00abAh-ah, non fare cos\u00ec\u00bb. <\/p>\n

\"Servizi
\n
\nCome sempre, ci sono delle sfide. Abbiamo team stabili, i manager sono ben legati ai loro team. Ci sono documenti chiari, e i manager monitorano attentamente tutto. Ogni team ha diversi servizi assegnati al manager, e c'\u00e8 un punto di competenza definito. <\/p>\n

Se i team sono fluttuanti (questo a volte accade anche da noi), c'\u00e8 un buon metodo chiamato 'mappa stellare'.<\/p>\n

\"Servizi
\n
\nHai un elenco di servizi e persone. L'asterisco indica che una persona \u00e8 un esperto in quel servizio, mentre il libro indica che una persona sta studiando quel servizio. L'obiettivo della persona \u00e8 cambiare il libro in un asterisco. Se non c'\u00e8 nulla scritto accanto al servizio, allora ci sono problemi di cui parler\u00f2 pi\u00f9 avanti. <\/p>\n

Come nascono i servizi orfani?<\/b><\/h3>\n

\n\"Servizi
\n
\nIl primo problema, il primo modo per avere un servizio orfano nella propria infrastruttura, \u00e8 il licenziamento delle persone. Qualcuno ha mai vissuto il momento in cui scadenze aziendali arrivano prima della valutazione delle attivit\u00e0? A volte ci sono scadenze rigide e non c'\u00e8 nemmeno tempo per la documentazione. 'Devi consegnare il servizio in produzione, poi lo completeremo.' <\/p>\n

Se il team \u00e8 piccolo, pu\u00f2 capitare che ci sia un solo sviluppatore che scrive tutto, mentre gli altri sono a supporto. \u00abHo scritto l'architettura principale, tu occupati delle interfacce\u00bb. Poi, a un certo punto, il manager se ne va. E in quel periodo, quando il manager \u00e8 andato via e non \u00e8 ancora stato nominato un nuovo, gli sviluppatori decidono da soli in quale direzione va il servizio, cosa sta succedendo. E come sappiamo (torniamo indietro di qualche slide), in alcuni team ci sono persone-uniche, a volte una persona-unica \u00e8 il team leader. Poi si dimette, e ci troviamo con un servizio-orfano. <\/p>\n

\"Servizi
\n
\nNel frattempo, le richieste di supporto e quelle aziendali non scompaiono, si accumulano nel backlog. Se durante lo sviluppo del servizio ci sono stati errori architettonici, anch'essi si accumulano nel backlog. Il servizio degrada lentamente. <\/p>\n

Come riconoscere un orfano?<\/b> <\/h3>\n

\nQuesta lista descrive abbastanza bene la situazione. Chi ha riconosciuto qualcosa nella propria infrastruttura?<\/p>\n

\"Servizi
\n
\nRiguardo ai work-around documentati: c'\u00e8 un servizio che, in generale, funziona, ha un manuale di due pagine su come utilizzarlo, ma come funziona internamente, nessuno lo sa. <\/p>\n

Oppure, ad esempio, ci sono dei servizi di accorciamento link. Noi, per esempio, attualmente utilizziamo tre diversi servizi di accorciamento link per scopi diversi in vari servizi. Sono queste le conseguenze. <\/p>\n

\"Servizi
\n
\nOra sar\u00f2 il capitano dell'ovviet\u00e0. Cosa bisogna fare? Prima di tutto, \u00e8 necessario trasferire il servizio a un altro manager, a un altro team. Se il tuo team leader non si \u00e8 ancora dimesso, allora in questo altro team, quando capisci che il servizio \u00e8 simile a un orfano, bisogna includere qualcuno che ne comprenda almeno un po'. <\/p>\n

La cosa principale: devono esserci procedure di trasferimento scritte come inchiostro. Nel nostro caso, di solito mi occupo di questo, perch\u00e9 ho bisogno che tutto funzioni. I manager hanno bisogno che venga consegnato rapidamente, e quel che accadr\u00e0 dopo non \u00e8 pi\u00f9 cos\u00ec importante per loro. <\/p>\n

\"Servizi
\n
\nIl modo successivo per creare un orfano \u00e8: \"Facciamolo in outsourcing, sar\u00e0 pi\u00f9 veloce, e poi lo daremo al team\". \u00c8 chiaro che tutti hanno dei piani nel team, una lista d'attesa. Spesso il cliente aziendale pensa che l'outsourcing far\u00e0 le cose allo stesso modo del tech team presente nell'azienda. Anche se i motivatori sono diversi. In outsourcing ci possono essere soluzioni tecnologiche strane e soluzioni algoritmiche bizzarre.<\/p>\n

\"Servizi
\n
\nAd esempio, avevamo un servizio in cui Sphinx si trovava in posti inaspettati. Pi\u00f9 tardi spiegher\u00f2 cosa ho dovuto fare. <\/p>\n

Gli outsourcer utilizzano framework scritti da loro. \u00c8 semplicemente PHP puro con copia-incolla da un progetto precedente, dove si pu\u00f2 trovare di tutto. Grandi patch nei script di deployment, quando \u00e8 necessario modificare alcune righe in un file utilizzando complesse script Bash, mentre questi script di deployment vengono chiamati da un terzo script. Alla fine, cambi il sistema di deployment, scegli qualcosa di diverso, e puff, il tuo servizio smette di funzionare. Perch\u00e9 dovevi anche impostare 8 link tra diverse cartelle. Oppure pu\u00f2 succedere che mille record funzionano, mentre centomila no. <\/p>\n

Continuer\u00f2 a fare da capitano. L'accettazione del servizio dall'outsourcing \u00e8 una procedura necessaria. A chi \u00e8 capitato che un servizio esternalizzato arrivi e non venga accettato? Non \u00e8 cos\u00ec popolare come un servizio orfano, ma comunque. <\/p>\n

\"Servizi
\n
\n\u00c8 necessario controllare il servizio, \u00e8 necessario rivedere il servizio, \u00e8 necessario cambiare le password. Abbiamo avuto un caso in cui ci \u00e8 stato presentato un servizio con un pannello di amministrazione dove c'era scritto 'if login == \u2018admin\u2019 && password == \u2018admin\u2019...'. Stiamo qui a riflettere, e queste cose vengono scritte da persone nel 2018?<\/p>\n

Testare lo spazio di archiviazione \u00e8 fondamentale. Bisogna vedere cosa succede con centomila registrazioni, prima di lanciare questo servizio in produzione. <\/p>\n

\"Servizi
\n
\nNon dovrebbe essere imbarazzante inviare un servizio per ulteriori miglioramenti. Quando dici: 'Non accetteremo questo servizio, abbiamo 20 compiti, completate questi e lo accetteremo', \u00e8 normale. La coscienza non dovrebbe pesare nel mettere in difficolt\u00e0 un manager o nel spendere soldi per un business. Alla fine il business spender\u00e0 di pi\u00f9.<\/p>\n

Abbiamo avuto un caso in cui abbiamo deciso di avviare un progetto pilota in outsourcing.<\/p>\n

\"Servizi
\n
\n\u00c8 stato consegnato in tempo, ed \u00e8 stato l'unico criterio di qualit\u00e0. Cos\u00ec abbiamo realizzato un altro progetto pilota, non proprio pi\u00f9 pilota. Questi servizi sono stati accolti, hanno detto per vie amministrative, ecco il vostro codice, ecco il team, ecco il vostro manager. I servizi hanno gi\u00e0 iniziato a generare profitto. Tuttavia, di fatto, sono rimasti ancora orfani, nessuno capisce come funzionano, e i manager si dissociano in tutti i modi dai loro compiti. <\/p>\n

\"Servizi
\n
\nC'\u00e8 un altro concetto interessante: lo sviluppo partigiano. Quando qualche dipartimento, di solito quello marketing, vuole testare un'ipotesi e fa un ordine per un servizio interamente in outsourcing. Inizia a ricevere traffico, chiudono i documenti, firmano contratti con il fornitore, entrano in produzione e dicono: \u00abRagazzi, abbiamo qui un servizio, ha gi\u00e0 traffico, ci sta generando entrate, accettiamolo\u00bb. E noi diciamo: \u00abEcco, come mai?\u00bb<\/p>\n

\"Servizi
\n
\nUn altro modo per ottenere un servizio orfano \u00e8 quando un team si trova all'improvviso sovraccarico; la direzione dice: \u00abTrasferiamo il servizio di questo team a un altro team, che ha meno lavoro\u00bb. Poi lo trasferiamo a un terzo team, cambiando anche il manager. Alla fine ci ritroviamo di nuovo con un orfano.<\/p>\n

Qual \u00e8 il problema con gli orfani?<\/b><\/h3>\n

\n\"Servizi
\n
\nChi non lo sa, \u00e8 la nave da guerra Wasa, costruita in Svezia, famosa per essere affondato cinque minuti dopo essere stata varata. E il re di Svezia, tra l'altro, non ha fatto giustiziare nessuno per questo. \u00c8 stata costruita da due generazioni di ingegneri che non sapevano costruire tali navi. Un effetto prevedibile.<\/p>\n

La nave avrebbe potuto affondare, per esempio, in modo molto peggiore, ad esempio se il re ci fosse salito per andare da qualche parte durante una tempesta. Cos\u00ec, \u00e8 affondata subito, il che \u00e8 positivo in un'ottica agile: il fallimento precoce \u00e8 buono. <\/p>\n

Se falliamo presto, di solito non ci sono problemi. Ad esempio, durante l'accettazione, viene rimandato per le modifiche. Ma se falliamo gi\u00e0 in produzione, quando sono stati investiti dei soldi, potrebbero sorgere dei problemi. Conseguenze, come vengono chiamate in ambito commerciale.<\/p>\n

Quali sono i pericoli dei servizi orfani:<\/p>\n