Pe 25 aprilie, noi, cei de la Mail.ru Group, am ținut o conferință despre nori și în jur - . Câteva puncte importante:
- Principalul — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center și Yandex.Cloud au vorbit despre specificul pieței noastre de cloud și serviciile acestora;
- Colegii de la Bitrix24 au povestit cum ;
- Leroy Merlin, Otkritie, Burger King și Schneider Electric au oferit interesante — ce sarcini le stabilește afacerea pentru IT și ce tehnologii, inclusiv cele cloud, consideră că sunt cele mai promițătoare.
Puteți viziona toate videoclipurile de la conferința mailto:CLOUD , iar aici puteți citi cum a decurs discuția despre microservicii. Alexander Deulin, șeful centrului de cercetare și dezvoltare a sistemelor de afaceri MegaFon, și Sergey Sergeev, director de tehnologie informațională al grupului M.Video-Eldorado, și-au împărtășit cazurile de succes de a scăpa de monoliți. Am discutat, de asemenea, probleme legate de strategia IT, procese și chiar HR.
Paneliştii
- Serghei Sergheev, CIO al grupului „M.Video-Eldorado”;
- Alexandru Deulin, șeful centrului de cercetare și dezvoltare a sistemelor de afaceri MegaFon;
- Moderator - Dmitri Lazarenko, șeful direcției PaaS Mail.ru Cloud Solutions.
După discursul lui Alexandru Deulin i se alătură pentru discuție Sergey Sergeev de la M.Video-Eldorado și moderatorul discuției Dmitry Lazarenko, Mail.ru Cloud Solutions.
Mai jos v-am pregătit o transcriere a discuției, dar puteți urmări și videoclipul:
Tranziția la microservicii este un răspuns la nevoile pieței
Dmitriy:
Ați avut vreo experiență de succes în migrarea la microservicii? Și, în general: unde vedeți cel mai mare beneficiu de afaceri din utilizarea microserviciilor sau trecerea de la monoliți la microservicii?
Serghei:
Am parcurs deja un drum în tranziția la microservicii și am folosit această abordare de mai bine de trei ani. Prima nevoie care a justificat nevoia de microservicii a fost integrarea nesfârșită a diverselor produse front-end cu back office-ul. Și de fiecare dată am fost forțați să facem integrare și dezvoltare suplimentară, implementând propriile reguli pentru funcționarea cutare sau cutare serviciu.
La un moment dat, ne-am dat seama că trebuie să grăbim funcționarea sistemelor noastre și rezultatul funcționalității. În acel moment, pe piață existau deja concepte precum microservicii și o abordare cu microservicii și am decis să încercăm. Acest lucru a început în 2016. Apoi a fost pusă platforma și primele 10 servicii au fost implementate de o echipă separată.
Unul dintre primele servicii, cel mai încărcat, a fost serviciul de calcul al prețurilor. De fiecare dată când veniți pe orice canal, la grupul de companii M.Video-Eldorado, fie că este un site web sau un magazin de vânzare cu amănuntul, selectați un produs acolo, vedeți prețul pe site sau în „Coș”, costul este automat calculat de un serviciu. De ce este necesar acest lucru: înainte de aceasta, fiecare sistem avea propriile sale principii de lucru cu promoții - cu reduceri și așa mai departe. Back Office-ul nostru se ocupă de stabilirea prețurilor; funcționalitatea de reducere este implementată într-un alt sistem. Acest lucru trebuia centralizat și un serviciu unic, separabil, creat sub forma unui proces de afaceri care să ne permită să implementăm acest lucru. Cam așa am început.
Valoarea primelor rezultate a fost foarte mare. În primul rând, am reușit să creăm entități separabile care ne permit să lucrăm separat și într-o manieră agregată. În al doilea rând, am redus costul de proprietate în ceea ce privește integrarea cu mai multe sisteme.
În ultimii trei ani, am adăugat trei sisteme de primă linie. A fost dificil să le întreținem cu aceeași cantitate de resurse pe care și le putea permite compania. Prin urmare, a apărut sarcina de a căuta noi debușee, care să răspundă pieței din punct de vedere al vitezei, al costurilor interne și al eficienței.
Cum să măsurați succesul migrării la microservicii
Dmitriy:
Cum se determină succesul migrării către microservicii? Care a fost „înainte” în fiecare companie? Ce măsură ați folosit pentru a determina succesul tranziției și cine a determinat-o de fapt?
Serghei:
În primul rând, s-a născut în IT ca un enabler - „deblocarea” de noi capabilități. Aveam nevoie să facem totul mai rapid pentru aceiași bani, răspunzând provocărilor pieței. Acum succesul se exprimă în numărul de servicii reutilizate de diferite sisteme, unificarea proceselor între ele. Acum este, dar în acel moment a fost o oportunitate de a crea o platformă și de a confirma ipoteza că putem face acest lucru, va da efect și va calcula cazul de afaceri.
Alexandru:
Succesul este mai degrabă un sentiment interior. Afacerea își dorește întotdeauna mai mult, iar profunzimea restanțelor noastre este dovada succesului. Așa mi se pare.
Serghei:
Da sunt de acord. În trei ani, avem deja peste două sute de servicii și restanțe. Nevoia de resurse în cadrul echipei este în creștere - cu 30% anual. Acest lucru se întâmplă pentru că oamenii au simțit: este mai rapid, este diferit, există tehnologii diferite, toate acestea se dezvoltă.
Microserviciile vor veni, dar nucleul va rămâne
Dmitriy:
Este ca un proces fără sfârșit în care investești în dezvoltare. Tranziția la microservicii pentru afaceri este deja încheiată sau nu?
Serghei:
Este foarte ușor să răspunzi. Ce părere aveți: înlocuirea telefoanelor este un proces fără sfârșit? Noi înșine cumpărăm telefoane în fiecare an. Și iată: atâta timp cât este nevoie de rapiditate, de adaptare la piață, vor fi necesare unele modificări. Asta nu înseamnă că abandonăm lucrurile standard.
Dar nu putem acoperi și reface totul deodată. Avem moștenire, servicii de integrare standard care erau disponibile înainte: autobuze de întreprindere și așa mai departe. Dar există un restanțe și există și o nevoie. Numărul de aplicații mobile și funcționalitatea acestora este în creștere. În același timp, nimeni nu spune că vi se vor da cu 30% mai mulți bani. Adică, există întotdeauna nevoi pe de o parte și căutarea eficienței pe de altă parte.
Dmitriy:
Viața este într-o formă bună. (râde)
Alexandru:
În general, da. Nu avem abordări revoluționare pentru a îndepărta partea centrală din peisaj. Se lucrează sistematic pentru a descompune sistemele astfel încât acestea să fie mai conforme cu arhitectura microserviciilor, pentru a reduce influența sistemelor unul asupra celuilalt.
Dar intenționăm să păstrăm partea de bază, deoarece în peisajul operatorului vor exista întotdeauna niște platforme pe care le cumpărăm. Din nou, avem nevoie de un echilibru sănătos: nu ar trebui să ne grăbim să tăiem miezul. Așezăm sistemele unul lângă altul și acum se dovedește că suntem deja deasupra multor părți de bază. În plus, dezvoltând funcționalitatea, creăm reprezentările necesare pentru toate canalele care funcționează cu serviciile noastre de comunicare.
Cum să vinzi microservicii către companii
Dmitriy:
De asemenea, sunt interesat - pentru cei care nu au trecut, dar intenționează să: cât de ușor a fost să vândă această idee afacerilor și a fost o aventură, un proiect de investiții? Sau a fost o strategie conștientă: acum mergem la microservicii și gata, nimic nu ne va opri. Cum a fost pentru tine?
Serghei:
Nu vindeam o abordare, ci un beneficiu de afaceri. A fost o problemă în afaceri și am încercat să o rezolvăm. În acel moment, s-a exprimat în faptul că diferite canale foloseau principii diferite pentru calcularea prețurilor - separat pentru promoții, pentru promoții și așa mai departe. A fost dificil de întreținut, au apărut erori și am ascultat plângerile clienților. Adică vindeam o soluție la o problemă, dar am venit cu faptul că aveam nevoie de bani pentru a crea o platformă. Și au prezentat un caz de afaceri folosind exemplul primei etape a investiției: cum vom continua să o recuperăm și ce ne va permite acest lucru să facem.
Dmitriy:
Ai înregistrat cumva ora primei etape?
Serghei:
Da sigur. Am alocat 6 luni pentru a crea nucleul ca platformă și a testa pilotul. În acest timp, am încercat să creăm o platformă pe care să patineze pilotul. Apoi ipoteza a fost confirmată și, din moment ce funcționează, înseamnă că putem continua. Au început să reproducă și să întărească echipa - au mutat-o într-o divizie separată care face exact asta.
Urmează munca sistematică bazată pe nevoile de afaceri, oportunități, disponibilitatea resurselor și tot ceea ce este în prezent în lucru.
Dmitriy:
BINE. Alexandru, ce spui?
Alexandru:
Microserviciile noastre s-au născut din „spuma mării” - datorită economisirii resurselor, datorită unor resturi sub formă de capacitate de server și redistribuirii forțelor în cadrul echipei. Inițial, nu am vândut acest proiect întreprinderilor. Acesta a fost un proiect în care am cercetat și dezvoltat în consecință. Am început la începutul lui 2018 și pur și simplu am dezvoltat această direcție cu entuziasm. Vânzările tocmai au început și suntem în proces.
Dmitriy:
Se întâmplă ca o afacere să vă permită să faceți astfel de lucruri precum Google - într-o singură zi liberă pe săptămână? Ai o astfel de direcție?
Alexandru:
Concomitent cu cercetarea, ne-am ocupat și de probleme de afaceri, așa că toate microserviciile noastre sunt soluții la problemele de afaceri. Abia la început am construit microservicii care acopereau o mică parte din baza de abonați, iar acum suntem prezenți în aproape toate produsele emblematice.
Iar impactul material este deja clar - putem fi deja numărați, viteza lansărilor de produse și veniturile pierdute pot fi estimate dacă am fi urmat vechea cale. Pe asta construim cazul.
Microservicii: hype sau necesitate?
Dmitriy:
Numerele sunt numere. Și veniturile sau banii economisiți sunt foarte importante. Dacă te uiți în cealaltă parte? Se pare că microserviciile sunt o tendință, un hype și multe companii abuzează de el? Cât de clar faceți diferența între ceea ce faceți și ceea ce nu traduceți în microservicii? Dacă veți avea moștenire acum, veți mai avea moștenire peste 5 ani? Care va fi vârsta sistemelor informaționale care funcționează la M.Video-Eldorado și MegaFon peste 5 ani? Vor exista sisteme informatice vechi de zece, cincisprezece ani sau va fi o nouă generație? Cum vezi asta?
Serghei:
Mi se pare că e greu să gândești foarte departe. Dacă ne uităm în urmă, cine și-a imaginat că piața tehnologiei se va dezvolta în acest fel, inclusiv învățarea automată și identificarea utilizatorului pe față? Dar dacă te uiți la următorii ani, mi se pare că sistemele de bază, sistemele de clasă ERP pentru întreprinderi din companii - funcționează de destul de mult timp.
Companiile noastre au, în mod colectiv, 25 de ani, cu ERP clasic foarte adânc în peisajul sistemelor. Este clar că scoatem câteva piese de acolo și încercăm să le agregam în microservicii, dar nucleul va rămâne. Îmi este greu acum să-mi imaginez că vom înlocui toate sistemele de bază de acolo și că vom trece rapid la cealaltă parte bună a noilor sisteme.
Sunt un susținător al faptului că tot ceea ce este mai aproape de client și consumator este acolo unde se află cel mai mare beneficiu și valoare de afaceri, unde adaptabilitatea și concentrarea pe viteză, pe schimbare, pe „încercați, anulați, reutilizați, faceți ceva diferit” sunt necesar „—acolo se va schimba peisajul. Și produsele din cutie nu se potrivesc foarte bine acolo. Cel puțin noi nu o vedem. Acolo sunt necesare cele mai simple, mai simple soluții.
Vedem această evoluție:
- sistemele informaționale de bază (mai ales back office);
- straturile de mijloc sub formă de microservicii conectează nucleul, agregează, creează un cache și așa mai departe;
- sistemele de primă linie sunt destinate consumatorului;
- un strat de integrare care este în general integrat în piețe, alte sisteme și ecosisteme. Acest strat este cât se poate de ușor, simplu și conține un minim de logică de afaceri.
Dar, în același timp, sunt un susținător al folosirii în continuare a vechilor principii dacă sunt folosite corespunzător.
Să presupunem că aveți un sistem clasic de întreprindere. Este situat în peisajul unui furnizor și constă din două module care funcționează unul cu celălalt. Există, de asemenea, o interfață de integrare standard. De ce să o refaceți și să aduceți un microserviciu acolo?
Dar când există 5 module în back office, din care informații sunt colectate într-un proces de afaceri, care este apoi utilizat de 8-10 sisteme de primă linie, beneficiul este imediat vizibil. Luați din cinci sisteme de back-office și creați un serviciu, unul izolat, care se concentrează pe procesul de afaceri. Faceți serviciul avansat din punct de vedere tehnologic - astfel încât să memoreze informații în cache și să fie tolerant la erori și să funcționeze, de asemenea, cu documente sau entități comerciale. Și îl integrezi după un singur principiu cu toate produsele de primă linie. Au anulat produsul de primă linie - pur și simplu au oprit integrarea. Mâine trebuie să scrieți o aplicație mobilă sau să faceți un site web mic și să puneți o singură parte în funcționalitate - totul este simplu: l-ați asamblat ca un constructor. Văd mai multă dezvoltare în această direcție – cel puțin la noi.
Alexandru:
Sergey a descris complet abordarea noastră, mulțumesc. Voi spune doar unde cu siguranță nu vom ajunge - la partea de bază, la subiectul facturării online. Adică, ratingul și taxarea vor rămâne, de fapt, un „mare” treierator care va șterge banii în mod fiabil. Și acest sistem va continua să fie certificat de autoritățile noastre de reglementare. Tot ceea ce privește clienții, desigur, sunt microservicii.
Dmitriy:
Aici certificarea este o poveste. Probabil mai mult sprijin. Dacă cheltuiți puțin pe suport sau sistemul nu necesită suport și modificare, este mai bine să nu îl atingeți. Un compromis rezonabil.
Cum să dezvoltați microservicii de încredere
Dmitriy:
Amenda. Dar tot sunt interesat. Acum spuneți o poveste de succes: totul a fost bine, am trecut la microservicii, am apărat ideea în fața afacerii și totul a funcționat. Dar am mai auzit și alte povești.
În urmă cu câțiva ani, o companie elvețiană care a investit doi ani în dezvoltarea unei noi platforme de microservicii pentru bănci a închis în cele din urmă proiectul. Prăbușit complet. Au fost cheltuite multe milioane de franci elvețieni, iar în cele din urmă echipa a fost dispersată - nu a funcționat.
Ați avut povești similare? Au fost sau au existat dificultăți? De exemplu, menținerea microserviciilor și monitorizarea este, de asemenea, o durere de cap în activitățile operaționale ale companiei. La urma urmei, numărul componentelor crește de zeci de ori. Cum vedeți, au existat exemple de investiții nereușite aici? Și ce poți sfătui oamenii ca să nu întâmpine astfel de probleme?
Alexandru:
Exemplele nereușite au inclus companiile care își schimbă prioritățile și anulează proiecte. Când se află într-un stadiu bun de pregătire (de fapt, MVP-ul este gata), afacerea a spus: „Avem noi priorități, trecem la alt proiect și îl închidem pe acesta”.
Nu am avut defecțiuni globale cu microservicii. Dormim liniștiți, avem o tură de serviciu 24/7 care deservește întregul BSS [sistem de asistență pentru afaceri].
Și încă un lucru - închiriem microservicii conform regulilor care se aplică produselor în cutie. Cheia succesului este că trebuie, în primul rând, să aduni o echipă care să pregătească pe deplin microserviciul pentru producție. Dezvoltarea în sine este, condiționat, de 40%. Restul este analiză, metodologia DevSecOps, integrările potrivite și arhitectura potrivită. Acordăm o atenție deosebită principiilor construirii de aplicații sigure. Reprezentanții de securitate a informațiilor participă la fiecare proiect atât la etapa de planificare a arhitecturii, cât și în timpul procesului de implementare. De asemenea, gestionează sisteme pentru analiza codului pentru vulnerabilități.
Să presupunem că implementăm serviciile noastre fără stat - le avem în Kubernetes. Acest lucru permite tuturor să doarmă liniștit datorită scalarii automate și creșterii automate a serviciilor, iar tura de serviciu preia incidente.
În întreaga existență a microserviciilor noastre, au existat doar unul sau două incidente care au ajuns în linia noastră. Acum nu sunt probleme cu operarea. Noi, desigur, nu avem 200, ci aproximativ 50 de microservicii, dar sunt folosite în produse emblematice. Dacă nu reușesc, am fi primii care află despre asta.
Microservicii și HR
Serghei:
Sunt de acord cu colegul meu în privința transferului în sprijin - că munca trebuie organizată corect. Dar vă voi povesti despre problemele care, desigur, există.
În primul rând, tehnologia este nouă. Acesta este hype într-un mod bun, iar găsirea unui specialist care va înțelege și poate crea acest lucru este o mare provocare. Competiția pentru resurse este nebună, așa că experții își merită greutatea în aur.
În al doilea rând, odată cu crearea anumitor peisaje și un număr tot mai mare de servicii, problema reutilizării trebuie rezolvată constant. Așa cum le place dezvoltatorilor să facă: „Să scriem o mulțime de lucruri interesante aici acum...” Din această cauză, sistemul crește și își pierde eficiența în ceea ce privește banii, costul de proprietate și așa mai departe. Adică, este necesar să se includă reutilizarea în arhitectura sistemului, să o includă în foaia de parcurs pentru introducerea serviciilor și transferul moștenirii către o nouă arhitectură.
O altă problemă - deși acest lucru este bun în felul său - este concurența internă. „Oh, noi băieți la modă au apărut aici, vorbesc o limbă nouă.” Oamenii, desigur, sunt diferiți. Sunt cei care sunt obișnuiți să scrie în Java și cei care scriu și folosesc Docker și Kubernetes. Aceștia sunt oameni complet diferiți, vorbesc diferit, folosesc termeni diferiți și uneori nu se înțeleg. Abilitatea sau incapacitatea de a împărtăși practica, împărtășirea cunoștințelor, în acest sens este, de asemenea, o problemă.
Ei bine, scalarea resurselor. "Minunat, hai să mergem! Și acum vrem mai repede, mai mult. Ce, nu poți? Nu se poate livra de două ori mai mult într-un an? Și de ce?" Astfel de dureri de creștere sunt probabil standard pentru multe lucruri, multe abordări și le puteți simți.
Referitor la monitorizare. Mi se pare că serviciile sau instrumentele de monitorizare industrială învață deja sau sunt capabile să lucreze atât cu Docker, cât și cu Kubernetes într-un mod diferit, non-standard. Pentru ca, de exemplu, să nu ajungeți cu 500 de mașini Java sub care rulează toate acestea, și anume, se adună. Dar acestor produse încă le lipsește maturitatea; trebuie să treacă prin asta. Subiectul este cu adevărat nou, va continua să se dezvolte.
Dmitriy:
Da, foarte interesant. Și acest lucru este valabil și pentru HR. Poate că procesul dvs. de resurse umane și marca dvs. de resurse umane s-au schimbat puțin în acești 3 ani. Ai început să recrutezi alți oameni cu competențe diferite. Și probabil există atât argumente pro și contra. Anterior, blockchain-ul și știința datelor erau hype, iar specialiștii în acestea valorau milioane. Acum costul scade, piața devine saturată și există o tendință similară în cazul microserviciilor.
Serghei:
Da, absolut.
Alexandru:
HR pune întrebarea: „Unde este unicornul tău roz între backend și front?” HR nu înțelege ce este un microserviciu. Le-am spus secretul și le-am spus că backend-ul a făcut totul și că nu există unicorn. Dar HR se schimbă, învață rapid și recrutează oameni care au cunoștințe de bază IT.
Evoluția microserviciilor
Dmitriy:
Dacă te uiți la arhitectura țintă, microserviciile arată ca un astfel de monstru. Călătoria ta a durat câțiva ani. Alții au un an, alții trei ani. Ai prevăzut toate problemele, arhitectura țintă, s-a schimbat ceva? De exemplu, în cazul microserviciilor, gateway-urile și rețelele de servicii apar acum din nou. Le-ai folosit la început sau ai schimbat arhitectura în sine? Aveți astfel de provocări?
Serghei:
Am rescris deja mai multe protocoale de comunicare. La început a fost un protocol, acum am trecut la altul. Creștem siguranța și fiabilitatea. Am început cu tehnologiile enterprise - Oracle, Web Logic. Acum ne îndepărtăm de produsele tehnologice de întreprindere în microservicii și trecem la tehnologii open source sau complet deschise. Renunțăm la bazele de date și trecem la ceea ce funcționează mai eficient pentru noi în acest model. Nu mai avem nevoie de tehnologii Oracle.
Am început pur și simplu ca un serviciu, fără să ne gândim la cât de mult avem nevoie de un cache, ce am face atunci când nu exista conexiune cu un microserviciu, dar era nevoie de date etc. Acum dezvoltăm o platformă pentru a putea fi descrisă arhitectura. nu în limbajul serviciilor și în limbajul afacerilor, ducem logica afacerii la următorul nivel atunci când începem să vorbim în cuvinte. Acum am învățat să vorbim cu litere, iar următorul nivel este când serviciile vor fi colectate într-un fel de agregat, când acesta este deja un cuvânt - de exemplu, un întreg card de produs. Este asamblat din microservicii, dar este un API construit pe deasupra.
Siguranța este foarte importantă. De îndată ce începi să fii accesibil și ai un serviciu prin care poți obține o mulțime de lucruri interesante și foarte repede, într-o fracțiune de secundă, atunci apare dorința de a-l obține într-un mod nu cel mai sigur. Pentru a scăpa de asta, a trebuit să schimbăm abordările de testare și monitorizare. A trebuit să schimbăm echipa, structura de management al livrărilor, CI/CD.
Aceasta este o evoluție – ca și la telefoane, doar mult mai rapidă: mai întâi au apărut telefoanele cu buton, apoi au apărut smartphone-urile. Au rescris și reproiectat produsul pentru că piața avea o nevoie diferită. Așa evoluăm: clasa întâi, clasa a zecea, muncă.
În mod iterativ, ceva este stabilit pe an din punct de vedere al tehnologiei, altceva din punct de vedere al restanțelor și al nevoilor. Conectăm un lucru la altul. Echipa cheltuiește 20% pe datoria tehnică și suport tehnic pentru echipă, 80% pe entitatea de afaceri. Și ne mișcăm cu înțelegerea de ce o facem, de ce facem aceste îmbunătățiri tehnologice, la ce vor duce ele. Ca asta.
Dmitriy:
Misto. Ce este în MegaFon?
Alexandru:
Principala provocare când am ajuns la microservicii a fost să nu cădem în haos. Biroul de arhitectură al MegaFon ni s-a alăturat imediat, chiar a devenit inițiator și șofer – acum avem o arhitectură foarte puternică. Sarcina lui a fost să înțeleagă ce model țintă ne îndreptăm și ce tehnologii trebuie pilotate. Cu arhitectura, noi înșine am condus acești piloți.
Următoarea întrebare a fost: „Atunci cum să exploatez toate acestea?” Și încă unul: „Cum să asigurăm o interacțiune transparentă între microservicii?” Serviciul de plasă ne-a ajutat să răspundem la ultima întrebare. Am pilotat Istio și ne-au plăcut rezultatele. Acum suntem în faza de a ne extinde în zone productive. Avem o atitudine pozitivă față de toate provocările - faptul că trebuie să schimbăm constant stiva, să învățăm ceva nou. Suntem interesați să dezvoltăm, nu să exploatăm soluții vechi.
Dmitriy:
Cuvinte de aur! Astfel de provocări țin echipa și afacerile pe degete și creează viitorul. GDPR a creat ofițeri șefi de protecție a datelor, iar provocările actuale creează ofițeri șefi de microservicii și arhitectură. Și face plăcere.
Am discutat mult. Principalul lucru este că un design bun al microserviciilor și arhitectura în sine vă permit să evitați multe greșeli. Desigur, procesul este iterativ și evolutiv, dar este viitorul.
Mulțumiri tuturor participanților, mulțumiri lui Serghei și Alexandru!
Întrebări din partea publicului
Întrebare din partea publicului (1):
Sergey, cum s-a schimbat managementul IT în compania ta? Înțeleg că atunci când există o stivă mare de mai multe sisteme, modul în care este gestionat este un proces destul de clar și logic. Cum ați reconstruit managementul componentei IT după ce un număr foarte mare de microservicii au fost integrate într-un timp atât de scurt?
Serghei:
Sunt de acord cu colegul meu că arhitectura este foarte importantă ca motor al schimbării. Am început prin a avea o divizie de arhitectură. Arhitecții sunt simultan proprietarii distribuției funcționalității și cerințelor pentru modul în care aceasta va apărea în peisaj. Deci ei acționează și ca coordonatori ai acestor schimbări. Ca rezultat, au existat modificări specifice unui anumit proces de livrare atunci când am creat o platformă CI/CD.
Dar standardele, principiile de bază ale dezvoltării, analizei afacerii, testării și dezvoltării nu au fost anulate. Am adăugat doar viteză. Anterior, ciclul a durat atât de mult, instalarea în medii de testare a durat mult mai mult. Acum, afacerile văd beneficiile și spun: „De ce nu putem face același lucru în alte locuri?”
Este ca, într-un sens bun, o injecție sub formă de vaccin care a arătat: o poți face așa, dar o poți face în alt mod. Desigur, există o problemă în personal, în competențe, în cunoștințe, în rezistență.
Întrebare din partea publicului (2):
Criticii arhitecturii microservicii spun că testarea și dezvoltarea sunt dificile. Este logic atunci când lucrurile se complică. Cu ce provocări s-a confruntat echipa ta și cum le-ai depășit? Întrebare pentru toată lumea.
Alexandru:
Există dificultăți la trecerea de la microservicii la o platformă, dar acestea pot fi rezolvate.
De exemplu, facem un produs care constă din 5-7 microservicii. Trebuie să oferim teste de integrare în întreaga stivă de microservicii pentru a da undă verde pentru a trece la ramura principală. Această sarcină nu era nouă pentru noi: făceam asta de mult timp la BSS, când furnizorul ne-a furnizat soluții deja livrate.
Și problema noastră este doar în echipa mică. Este necesar un inginer QA pentru un produs condiționat. Și astfel, livrăm un produs de 5-7 microservicii, dintre care 2-3 pot fi dezvoltate de terți. De exemplu, avem un produs la dezvoltarea căruia participă furnizorul nostru de sistem de facturare, Mail.ru Group și MegaFon R&D. Trebuie să acoperim acest lucru cu teste înainte de a-l expedia în producție. Inginerul QA lucrează la acest produs de o lună și jumătate, iar restul echipei a rămas fără sprijinul lui.
Această complexitate este cauzată doar de scalare. Înțelegem că microserviciile nu pot exista în vid; izolarea absolută nu există. Când schimbăm un serviciu, încercăm întotdeauna să păstrăm contractul API. Dacă se schimbă ceva sub capotă, serviciul față rămâne. Dacă modificările sunt fatale, are loc un fel de transformare arhitecturală și trecem la un metamodel de date complet diferit, care este complet incompatibil - abia atunci vorbim despre apariția specificației API-ului serviciului v2. Acceptăm prima și a doua versiune simultan și, după ce toți consumatorii trec la a doua versiune, pur și simplu o închidem pe prima.
Serghei:
vreau sa adaug. Sunt absolut de acord cu privire la complicații - se întâmplă. Peisajul devine din ce în ce mai complex, iar costurile generale cresc, în special pentru testare. Cum să remediați acest lucru: treceți la testarea automată. Da, va trebui să investiți suplimentar în scrierea autotestelor și a testelor unitare. Pentru ca dezvoltatorii să nu poată comite fără să treacă testul, nu au putut schimba codul. Pentru ca nici măcar butonul să nu funcționeze fără autotest, test unitar.
Este important să se mențină funcționalitatea anterioară, iar aceasta este o suprasolicitare suplimentară. Dacă rescrieți o tehnologie într-un alt protocol, atunci o rescrieți până când închideți totul complet.
Uneori nu facem testare end-to-end intenționat, pentru că nu vrem să oprim dezvoltarea, deși avem și un lucru după altul. Peisajul este foarte mare, complex, sunt multe sisteme. Uneori sunt doar cioturi - da, reduceți marja de siguranță, apar mai multe riscuri. Dar în același timp eliberați aprovizionarea.
Alexandru:
Da, autotestele și testele unitare vă permit să creați un serviciu de înaltă calitate. Suntem pentru o conductă care nu poate fi trecută fără teste unitare și de integrare. De multe ori trebuie să tragem emulatorii și sistemele comerciale în zonele de testare și mediile de dezvoltare, deoarece nu toate sistemele pot fi plasate în zone de testare. Mai mult decât atât, ele nu se udă doar - generăm un răspuns cu drepturi depline din partea sistemului. Aceasta este o parte serioasă a lucrului cu microservicii și, de asemenea, investim în ea. Fără aceasta, va apărea haosul.
Întrebare din partea publicului (3):
Din câte am înțeles, microserviciile au crescut inițial dintr-o echipă separată și acum există în acest model. Care sunt avantajele și dezavantajele sale?
Avem doar o poveste similară: a apărut un fel de fabrică de microservicii. Acum am ajuns conceptual la punctul în care extindem această abordare a producției pe fluxuri și pe sisteme. Cu alte cuvinte, ne îndepărtăm de dezvoltarea centralizată a microserviciilor, modelelor de microservicii și ne apropiem de sisteme.
În consecință, funcționarea noastră merge și la sisteme, adică descentralizăm acest subiect. Care este abordarea ta și care este povestea ta țintă?
Alexandru:
Ați scăpat din gură numele „fabrică de microservicii” – vrem și noi să creștem. În primul rând, avem cu adevărat o echipă acum. Dorim să oferim tuturor echipelor de dezvoltare pe care MegaFon le are oportunitatea de a lucra într-un ecosistem comun. Nu vrem să preluăm complet toată funcționalitatea de dezvoltare pe care o avem acum. Sarcina locală este de a scala, sarcina globală este de a conduce dezvoltarea tuturor echipelor din stratul de microservicii.
Serghei:
Îți voi spune calea pe care am urmat-o. Am început să lucrăm într-adevăr ca o singură echipă, dar acum nu suntem singuri. Sunt un susținător a următoarelor: trebuie să existe un proprietar al procesului. Cineva trebuie să înțeleagă, să gestioneze, să controleze și să construiască procesul de dezvoltare a microserviciilor. El trebuie să dețină resurse și să se angajeze în managementul resurselor.
Aceste resurse, care cunosc tehnologii, specificul și înțeleg cum să construiască microservicii, pot fi localizate în echipele de produse. Avem un mix în care oamenii din platforma de microservicii sunt în echipa de produs care realizează aplicația mobilă. Sunt acolo, dar lucrează conform procesului departamentului de management al platformei de microservicii cu managerul lor de dezvoltare. În cadrul acestei divizii există o echipă separată care se ocupă de tehnologie. Adică amestecăm un bazin comun de resurse între noi și le împărțim, dându-le echipelor.
În același timp, procesul rămâne general, controlat, se derulează după principii tehnologice generale, cu teste unitare și așa mai departe - tot ce este construit deasupra. Pot exista coloane sub formă de resurse colectate de la diferite departamente ale abordării produsului.
Alexandru:
Sergey, tu ești de fapt proprietarul procesului, nu? Este partajat stocul de sarcini? Cine este responsabil de distribuirea acestuia?
Serghei:
Uite: iată din nou amestecul. Există un restanțe care se formează pe baza îmbunătățirilor tehnologice - aceasta este o poveste. Există un întârziere, care este formulat din proiecte, și există un restanță din produse. Dar succesiunea introducerii în fiecare dintre produsele de serviciu sau crearea acestui serviciu este dezvoltată de un specialist în produs. Nu este în direcția IT, a fost scos special din ea. Dar oamenii mei lucrează cu siguranță după același proces.
Proprietarul restanțelor în direcții diferite - stocul de modificări - va fi oameni diferiți. Conectarea serviciilor tehnologice, principiul lor de organizare - toate acestea vor fi în IT. Dețin platforma și resursele. În vârf se află ceea ce privește backlog-ul și modificările funcționale, precum și arhitectura în acest sens.
Să presupunem că o companie spune: „Vrem această funcție, vrem să creăm un produs nou - să refacem un împrumut.” Răspundem: „Da, o vom reface”. Arhitecții spun: „Să ne gândim: unde în împrumut vom scrie microservicii și cum o vom face?” Apoi îl împărțim în proiecte, produse sau o stivă de tehnologie, îl punem în echipe și îl implementăm. Ați creat un produs intern și ați decis să utilizați microservicii în acest produs? Spunem: „Acum, sistemele moștenite pe care le aveam, sau sistemele de primă linie, trebuie să treacă la aceste microservicii.” Arhitecții spun: „Deci: în restanța tehnologică din interiorul produselor de primă linie - tranziția la microservicii. Merge". Și specialiștii de produse sau proprietarii de afaceri înțeleg câtă capacitate este alocată, când se va face și de ce.
Sfârșitul discuției, dar nu toate
A fost organizată conferința mailto:CLOUD .
Facem și alte evenimente - de ex. @Kubernetes Meetup, unde căutăm mereu difuzoare grozave:
- Urmărește @Kubernetes și alte știri @Meetup pe canalul nostru Telegram
- Vă interesează să vorbiți la unul dintre @Meetups? Lăsați o cerere pentru
Sursa: www.habr.com