{"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 lato opposto dell'architettura a (micro)servizi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il direttore per l'esercizio del portale Banki.ru, Andrey Nikol'skiy, ha parlato alla conferenza dello scorso anno DevOpsDays Moscow<\/a><\/noindex> sui servizi orfani: come riconoscere un orfano nell'infrastruttura, quali problemi comportano i servizi orfani, cosa fare con loro e come procedere se niente funziona.<\/p>\n

Sotto il post troverete la versione testuale della relazione. <\/p>\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nSalve, colleghi! Mi chiamo Andrey, e sono responsabile dell'esercizio presso Banki.ru.<\/p>\n

Abbiamo grandi servizi, che sono dei monoliti, abbiamo servizi in un'accezione pi\u00f9 classica e abbiamo anche servizi molto piccoli. Nella mia terminologia da lavoratore, dico che se un servizio \u00e8 semplice e piccolo, allora \u00e8 micro, e se non \u00e8 molto semplice e non \u00e8 piccolo, allora \u00e8 semplicemente un servizio. <\/p>\n

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

\nPasser\u00f2 rapidamente sui vantaggi dei servizi. <\/p>\n

\"Servizi
\n
\nPrimo \u2014 scalabilit\u00e0. Puoi rapidamente realizzare qualcosa su un servizio e lanciarlo in produzione. Ti arriva del traffico, quindi cloni il servizio. Ti arriva altro traffico, clonano di nuovo e con questo vivi. Questo \u00e8 un buon bonus e, fondamentalmente, quando abbiamo iniziato, era considerato il nostro motivo principale per fare tutto questo.<\/p>\n

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

Con le squadre ci sono delle sfide. Gli sviluppatori possono essere diversi. E esistono, ad esempio, persone-fiocco di neve<\/a><\/noindex>. L'ho visto per la prima volta da Maksim Dorofeev. A volte ci sono persone-fiocco di neve in alcune squadre, e in altre no. Questo rende i diversi servizi utilizzati nell'azienda un po' disomogenei. <\/p>\n

\"Servizi
\n
\nGuarda l'immagine: questo \u00e8 un buon sviluppatore, ha grandi mani, pu\u00f2 fare molte cose. Il problema principale \u00e8 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 diversi. Alcuni servizi sono in Go, altri in Erlang, altri in Ruby, alcuni in PHP, altri in Python. In generale, si pu\u00f2 spaziare molto. Anche qui ci sono delle sfide.<\/p>\n

\"Servizi
\n
\nL'architettura orientata ai servizi riguarda soprattutto il devops. Quindi, se non hai automazione, non hai un processo di deployment, se configuri manualmente, le tue configurazioni possono variare da un'istanza all'altra del servizio, e devi andare a fare qualcosa, allora sei nei guai. <\/p>\n

Ad esempio, hai 20 servizi e devi fare il deployment manualmente, hai 20 console e premi \u00abenter\u00bb simultaneamente come un ninja. Non \u00e8 un buon modo di lavorare. <\/p>\n

Se hai un servizio dopo il collaudo (se c'\u00e8 collaudo, naturalmente) e devi ancora rifinirlo affinch\u00e9 funzioni in produzione, ho anche per te brutte notizie. <\/p>\n

Se ti affidi a servizi specifici di Amazon e lavori in Russia, due mesi fa anche tu avevi \u00abTutto intorno brucia, sto bene, tutto \u00e8 fantastico\u00bb.<\/p>\n

\"Servizi
\n
\nNoi utilizziamo Ansible per automatizzare il deployment, Puppet per la convergenza, Bamboo per l'automazione del deployment, Confluence per descrivere tutto ci\u00f2 in qualche modo.<\/p>\n

Non mi fermer\u00f2 a questo in dettaglio, perch\u00e9 la presentazione riguarda pi\u00f9 le pratiche di interazione che non la realizzazione tecnica. <\/p>\n

\"Servizi
\n
\nAvevamo, ad esempio, problemi in cui Puppet sul server funziona con Ruby 2, mentre un'applicazione \u00e8 scritta per Ruby 1.8 e insieme non funzionano. L\u00ec si verifica qualche problema. E quando devi mantenere diverse versioni di Ruby su una sola macchina, di solito sorgono problemi. <\/p>\n

Noi, ad esempio, forniamo a ogni sviluppatore un ambiente, dove c'\u00e8 circa tutto ci\u00f2 che abbiamo, tutti i servizi che possono essere sviluppati, in modo che abbia un ambiente isolato dove pu\u00f2 distruggerlo e costruirlo come vuole. <\/p>\n

A volte \u00e8 necessario un pacchetto compilato appositamente con supporto per qualcosa. \u00c8 abbastanza rigoroso. Ho ascoltato una presentazione in cui l'immagine Docker pesa 45 GB. In Linux, ovviamente, \u00e8 pi\u00f9 semplice, tutto \u00e8 pi\u00f9 leggero, ma comunque non ci sar\u00e0 mai abbastanza spazio. <\/p>\n

E ci sono dipendenze contraddittorie, quando un pezzo del progetto dipende da una versione di una libreria, e un altro pezzo del progetto da un'altra versione, e le 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 nostra piattaforma. Ci sono siti e servizi su PHP 7, ce ne sono di pi\u00f9 e per quelli non ci vergogniamo. E ogni sviluppatore ha il suo database, dove lavora felicemente. <\/p>\n

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

\"Servizi
\n
\nEmergono siti e servizi su questo, su questo, poi un'altra piattaforma per Go, una piattaforma per Ruby, e un Redis a fianco. Alla fine, tutto ci\u00f2 si trasforma in un grande campo di supporto, e c'\u00e8 sempre qualcosa che pu\u00f2 rompersi.<\/p>\n

\"Servizi
\n
\nPer questo motivo, abbiamo sostituito i vantaggi del linguaggio di programmazione con l\u2019uso di diversi framework, poich\u00e9 i framework su PHP sono abbastanza diversi, hanno diverse capacit\u00e0, diverse comunit\u00e0 e supporto. E si pu\u00f2 scrivere un servizio in modo 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 utile per un grande progetto, permette di risparmiare tempo nella documentazione, i manager conoscono bene il loro progetto. <\/p>\n

I compiti di supporto possono essere gestiti facilmente. Ad esempio, se un servizio di assicurazione si rompe. E subito il team che si occupa dell'assicurazione va a ripararlo. <\/p>\n

Si possono realizzare rapidamente nuove funzionalit\u00e0, perch\u00e9 quando hai un servizio atomico, puoi facilmente integrare qualcosa. <\/p>\n

E quando hai rotto il tuo servizio, ed \u00e8 inevitabile che accada, non danneggi gli altri servizi, e gli sviluppatori delle altre squadre non vengono da te con i bastoni dicendo: \u00abOh no, non farlo\u00bb. <\/p>\n

\"Servizi
\n
\nCome sempre, ci sono delle sfumature. Abbiamo team stabili, i manager sono ben ancorati ai team. Ci sono documenti chiari e i manager controllano attentamente tutto. Ogni team ha diversi servizi insieme al manager, e c'\u00e8 un punto di competenza specifico. <\/p>\n

Se i team sono fluttuanti (anche questo avviene di tanto in tanto), c'\u00e8 un buon metodo, chiamato 'mappa stellare'.<\/p>\n

\"Servizi
\n
\nHai una lista di servizi e di persone. Una stellina significa che la persona \u00e8 un esperto in quel servizio, un libro significa che la persona sta studiando quel servizio. Il compito della persona \u00e8 quello di cambiare il libro in stellina. E se non \u00e8 scritto nulla di fronte al servizio, iniziano i 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. A qualcuno \u00e8 mai capitato che dall'azienda arrivassero scadenze prima di aver valutato i compiti? A volte le scadenze sono rigide e non c'\u00e8 tempo per la documentazione. \u00abDevi consegnare il servizio in produzione, poi lo completiamo\u00bb. <\/p>\n

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

\"Servizi
\n
\nNel frattempo, i compiti del supporto e dell'azienda non svaniscono, si accumulano nel backlog. Se durante lo sviluppo del servizio ci sono stati errori architetturali, anche questi si accumulano nel backlog. Il servizio degrada lentamente. <\/p>\n

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

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

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

O, per esempio, c'\u00e8 un qualche accorciatore di link. Per noi, ad esempio, ora abbiamo tre accorciatori di link in uso per scopi diversi in vari servizi. Queste sono le conseguenze. <\/p>\n

\"Servizi
\n
\nOra sar\u00f2 il capitano dell'evidenza. Cosa bisogna fare? Prima di tutto, bisogna trasferire il servizio a un altro manager, a un altro team. Se il vostro team leader non si \u00e8 ancora dimesso, allora in questo altro team, quando comprendete che il servizio assomiglia a un orfano, dovete includere qualcuno che abbia almeno una comprensione di esso. <\/p>\n

La cosa principale: dovete avere procedure di trasferimento scritte in modo chiaro. Nel nostro caso, di solito seguo io questo aspetto, perch\u00e9 ho bisogno che tutto funzioni. Ai manager serve che venga consegnato rapidamente e quello che succeder\u00e0 dopo non \u00e8 cos\u00ec importante per loro. <\/p>\n

\"Servizi
\n
\nIl modo successivo per creare un orfano \u00e8: \u00abFarlo in outsourcing, sar\u00e0 pi\u00f9 veloce, e poi lo passeremo al team\u00bb. \u00c8 chiaro che ognuno ha dei piani e delle priorit\u00e0 all'interno del team. Spesso il cliente aziendale pensa che un esternalizzatore far\u00e0 le cose allo stesso modo del dipartimento tecnico presente in azienda. Anche se i loro motivi sono diversi. Nell'outsourcing si possono trovare soluzioni tecnologiche strane e algoritmi bizzarri.<\/p>\n

\"Servizi
\n
\nAd esempio, noi avevamo un servizio in cui Sphinx si trovava in posti inaspettati. Ti racconter\u00f2 pi\u00f9 avanti cosa abbiamo dovuto fare. <\/p>\n

Gli esternalizzatori possono avere framework proprietari. Si tratta semplicemente di PHP nudo con del copia e incolla da un progetto precedente, dove si possono trovare di tutto. Grandi pasticci negli script di distribuzione, quando devi cambiare alcune righe in qualche file usando complicati script Bash, e questi script di distribuzione vengono richiamati da qualche terzo script. Alla fine cambi il sistema di distribuzione, scegli qualcosa di diverso, e puff, il tuo servizio smette di funzionare. Perch\u00e9 l\u00ec dovevi anche mettere altre 8 link tra diverse cartelle. Oppure, pu\u00f2 capitare che mille registrazioni funzionano, ma centomila no. <\/p>\n

Continuo a capitaneare. L'accettazione di un servizio esternalizzato \u00e8 una procedura obbligatoria. A chi \u00e8 capitato che un servizio esternalizzato arrivi, ma non venga accettato da nessuna parte? Non \u00e8 cos\u00ec popolare come il servizio orfano, ma c'\u00e8 comunque. <\/p>\n

\"Servizi
\n
\nIl servizio deve essere controllato, il servizio deve essere rivisto, \u00e8 necessario cambiare le password. Abbiamo avuto un caso in cui ci hanno proposto un servizio, dove l'admin panel riportava \"if login == 'admin' && password == 'admin'\u2026\", scritto direttamente nel codice. Stiamo qui a riflettere, e questo viene scritto da persone nel 2018?<\/p>\n

Il test del volume di storage \u00e8 anche una cosa necessaria. \u00c8 importante vedere cosa succede con centomila registrazioni, anche prima di lanciare questo servizio in produzione. <\/p>\n

\"Servizi
\n
\nNon dovrebbe essere imbarazzante inviare un servizio per la rifinitura. Quando dici: \u00abNon accetteremo questo servizio, abbiamo 20 compiti, completateli e allora lo accetteremo\u00bb, \u00e8 normale. La coscienza non dovrebbe soffrire perch\u00e9 stai mettendo in difficolt\u00e0 un manager o perch\u00e9 l'azienda spender\u00e0 dei soldi. L'azienda spender\u00e0 di pi\u00f9 in seguito.<\/p>\n

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

\"Servizi
\n
\n\u00c8 stato consegnato in tempo, ed era l'unico criterio di qualit\u00e0. Perci\u00f2 \u00e8 stato creato un altro progetto pilota, che in realt\u00e0 non era pi\u00f9 completamente pilota. Questi servizi sono stati accettati, tramite modalit\u00e0 amministrative \u00e8 stato detto: ecco il vostro codice, ecco il team, ecco il vostro manager. I servizi hanno gi\u00e0 iniziato a generare profitti. Tuttavia, di fatto, sono rimasti ancora orfani, nessuno capisce come funzionano e i manager si disconnettono in ogni modo dai loro compiti. <\/p>\n

\"Servizi
\n
\nC'\u00e8 anche un ottimo concetto: lo sviluppo partigiano. Quando qualche dipartimento, di solito il dipartimento marketing, vuole testare un'ipotesi e ordina un servizio interamente in outsourcing. Inizia a ricevere traffico, chiudono i documenti, firmano i contratti con il fornitore, entra in esercizio e dicono: \u00abRagazzi, abbiamo un servizio qui, ha gi\u00e0 del traffico, ci sta generando soldi, accettiamolo\u00bb. Noi siamo tipo: \u00abAspetta, come \u00e8 possibile\u00bb.<\/p>\n

\"Servizi
\n
\nUn altro modo per ottenere un servizio orfano \u00e8 quando un certo team si trova improvvisamente sopraffatto, e la direzione dice: \u00abPassiamo il servizio di questo team a un altro team, che ha meno carico\u00bb. E poi lo passeremo a un terzo team e cambiamo il manager. E alla fine, abbiamo di nuovo un orfano.<\/p>\n

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

\n\"Servizi
\n
\nPer chi non lo sa, si tratta della nave da guerra Wasa, costruita in Svezia, famosa perch\u00e9 \u00e8 affondata cinque minuti dopo il varo. E il re di Svezia, tra l'altro, non ha giustiziato nessuno per questo. \u00c8 stata costruita da due generazioni di ingegneri che non sapevano costruire navi simili. Un effetto prevedibile.<\/p>\n

La nave poteva affondare, tra l'altro, in maniera molto peggiore, ad esempio, quando a bordo ci sarebbe stato il re in mezzo a una tempesta. Invece, \u00e8 affondata subito, secondo l'approccio agile questo \u00e8 positivo \u2014 fallire presto. <\/p>\n

Se falliamo presto, di solito non ci sono problemi. Ad esempio, durante l'accettazione viene rimandata per modifiche. Ma se falliamo gi\u00e0 in produzione, quando sono stati investiti dei soldi, allora possono esserci problemi. Le conseguenze, come si dice nel business.<\/p>\n

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