Op 25 April het ons by Mail.ru Group 'n konferensie gehou oor wolke en rondom - . 'n Paar hoogtepunte:
- Op dieselfde verhoog versamel die hoof — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center en Yandex.Cloud het gesels oor die besonderhede van ons wolkmark en hul dienste;
- Kollegas van Bitrix24 het vertel hoe hulle ;
- Leroy Merlin, Otkritie, Burger King en Schneider Electric het gesorg vir 'n interessante - watter take hul besigheid vir IT stel en watter tegnologieë, insluitend wolke, beskou hulle as die mees belowende.
Alle video's van die mailto:CLOUD-konferensie kan bekyk word , en hier kan jy lees hoe die bespreking oor mikrodienste verloop het. Alexander Deulin, hoof van die navorsing- en ontwikkelingsentrum vir besigheidstelsels by MegaFon, en Sergey Sergeev, direkteur van inligtingstegnologie by die M.Video-Eldorado-groep, het hul suksesvolle gevalle gedeel om van monoliete ontslae te raak. Hulle het ook verwante kwessies van IT-strategie, prosesse en selfs HR bespreek.
Deelnemers van die bespreking
- Sergey Sergeev, Groep Hoofinligtingsbeampte "M.Video-Eldorado";
- Alexander Deulin, Hoof van die Sentrum vir Navorsing en Ontwikkeling van Besigheidstelsels MegaFon;
- Moderator - Dmitri Lazarenko, Hoof van PaaS Mail.ru Wolkoplossings.
Na Alexander Deulin se toespraak Sergey Sergeev van M.Video-Eldorado en gespreksmoderator Dmitry Lazarenko, Mail.ru Cloud Solutions sluit by hom aan vir bespreking.
Hieronder het ons 'n transkripsie van die bespreking vir jou voorberei, maar jy kan ook die video kyk:
Oorgang na mikrodienste - reaksie op markbehoeftes
Dmitriy:
Het jy 'n suksesvolle ervaring gehad om na mikrodienste te migreer? En in die algemeen: waar sien jy die grootste besigheidsvoordeel uit die gebruik van mikrodienste of om van monoliete na mikrodienste te beweeg?
Sergey:
Ons het reeds 'n pad gegaan om na mikrodienste te migreer en gebruik hierdie benadering al meer as drie jaar. Die eerste behoefte wat die behoefte aan mikrodienste geregverdig het, was die eindelose integrasie van verskeie front-end produkte met die back-office. En elke keer is ons gedwing om bykomende integrasie, ontwikkeling te doen, ons eie reëls vir die werking van 'n spesifieke diens te implementeer.
Op 'n stadium het ons besef dat ons die werking van ons stelsels en die uitvoer van funksionaliteit moet bespoedig. Op daardie oomblik het konsepte soos mikrodienste, 'n mikrodiensbenadering, reeds op die mark bestaan, en ons het besluit om dit te probeer. Dit het in 2016 begin. Toe is die platform gelê en die eerste 10 dienste is deur 'n aparte span geïmplementeer.
Een van die eerste dienste, die swaarste gelaai, was die prysberekeningsdiens. Elke keer as jy enige kanaal besoek, die M.Video-Eldorado groep van maatskappye, of dit nou 'n webwerf of 'n kleinhandelwinkel is, 'n produk daar afhaal, die prys op die webwerf of in die "Cart" sien, word die koste outomaties bereken deur een diens. Waarom dit nodig is: voor dit het elke stelsel sy eie beginsels gehad om met promosies te werk – met afslag en so meer. Ons back office handel oor pryse, die afslagfunksie word in 'n ander stelsel geïmplementeer. Dit moes gesentraliseer word en so 'n unieke, skeibare diens skep in die vorm van 'n besigheidsproses wat ons in staat sou stel om dit te implementeer. Dit is omtrent hoe ons begin het.
Die waarde van die eerste resultate was baie groot. Eerstens kon ons skeibare entiteite maak wat ons in staat stel om apart te werk, saamgevoeg. Tweedens het ons die koste van eienaarskap verminder in terme van integrasie met meer stelsels.
Oor die afgelope drie jaar het ons drie frontliniestelsels bygevoeg. Hulle was moeilik om te onderhou met dieselfde hoeveelheid hulpbronne as wat die maatskappy kon bekostig. Daarom het die taak ontstaan om nuwe uitgange te soek, wat op die mark reageer in terme van spoed, in terme van interne koste en doeltreffendheid.
Hoe om die sukses van die oorgang na mikrodienste te evalueer
Dmitriy:
Hoe word sukses met die migreer na mikrodienste bepaal? Wat was "voor" in elke maatskappy? Watter maatstaf het jy gebruik om die sukses van die oorgang te bepaal, wie het dit eintlik bepaal?
Sergey:
Eerstens, dit is binne IT gebore as 'n instaatsteller - wat nuwe kenmerke "ontsluit". Ons het 'n behoefte gehad om alles vinniger te doen vir dieselfde bedrag geld, om op die uitdagings van die mark te reageer. Nou word sukses uitgedruk in die aantal dienste wat deur verskillende stelsels hergebruik word, die eenwording van prosesse onderling. Nou is dit, maar op daardie oomblik was dit 'n geleentheid om 'n platform te skep en die hipotese te bevestig dat ons dit kan doen, dit sal 'n effek gee en die besigheidsgeval bereken.
Alexander:
Sukses is meer 'n innerlike gevoel. Besighede wil altyd meer hê, en die diepte van ons agterstand is 'n bewys van ons sukses. Dit lyk vir my so.
Sergey:
Ja, ek stem saam. Vir drie jaar het ons reeds meer as tweehonderd dienste en agterstande gehad. Die behoefte aan hulpbronne binne die span groei net – met 30% jaarliks. Dit gebeur omdat mense gevoel het: dit is vinniger, anders, ander tegnologieë, dit alles is besig om te ontwikkel.
Mikrodienste sal kom, maar die kern sal bly
Dmitriy:
Dit is soos 'n nimmereindigende proses waar jy in ontwikkeling belê. Is die oorgang na mikrodienste vir besigheid reeds verby of nie?
Sergey:
Dit is baie maklik om te antwoord. Dink jy dat die vervanging van fone 'n eindelose proses is? Ons koop self elke jaar selfone. En hier is dit: solank daar 'n behoefte aan spoed is, sal 'n paar veranderinge nodig wees om by die mark aan te pas. Dit beteken nie dat ons standaard dinge weier nie.
Maar ons kan nie dadelik alles omhels en oordoen nie. Ons het erfenis, standaard integrasie dienste wat ons voorheen gehad het: onderneming bande en so aan. Maar daar is 'n agterstand, en daar is ook 'n behoefte. Die aantal mobiele toepassings en hul funksionaliteit groei. Terselfdertyd sê niemand dat jy 30% meer geld gegee sal word nie. Dit wil sê, aan die een kant is daar altyd behoeftes, en aan die ander kant die soeke na doeltreffendheid.
Dmitriy:
Lewe in goeie toestand. (Lag)
Alexander:
Oor die algemeen, ja. Ons het nie revolusionêre benaderings om die kerndeel uit die landskap te verwyder nie. Sistematiese werk is aan die gang om stelsels te ontbind sodat dit meer in lyn is met die mikrodiensargitektuur, om die invloed van stelsels op mekaar te verminder.
Maar ons beplan om die kerndeel te behou, aangesien daar altyd 'n paar platforms sal wees wat ons in die operateurlandskap koop. Weereens, 'n gesonde balans is nodig: ons moenie haastig wees om die kern uit te sny nie. Ons sit die stelsels langs mekaar, en nou blyk dit dat hulle reeds bo baie kerndele is. Verder, deur die funksionaliteit te ontwikkel, maak ons die nodige vertoë vir alle kanale wat met ons kommunikasiedienste werk.
Hoe om mikrodienste aan 'n besigheid te verkoop
Dmitriy:
Ek wonder steeds – vir diegene wat nie oorgeskakel het nie, maar gaan: hoe maklik was dit om hierdie idee aan 'n besigheid te verkoop en was dit 'n waagstuk, 'n beleggingsprojek? Of dit was 'n bewuste strategie: nou gaan ons na mikrodienste en dis dit, niks sal ons keer nie. Hoe was dit vir jou?
Sergey:
Ons het nie 'n benadering verkoop nie, maar 'n besigheidsvoordeel. Daar was 'n probleem in besigheid, en ons het probeer om dit te verwyder. Op daardie oomblik is dit uitgedruk in die feit dat verskillende kanale verskillende beginsels gebruik het vir die berekening van die prys - afsonderlik vir promosies, vir promosies, ensovoorts. Dit was moeilik om in stand te hou, daar was foute, ons het na klagtes van kliënte geluister. Dit wil sê, ons het die uitskakeling van die probleem verkoop, maar het gekom met die feit dat ons geld nodig gehad het om 'n platform te skep. En hulle het 'n sakegeval gewys deur die voorbeeld van die eerste fase van belegging te gebruik: hoe ons sal voortgaan om daarvoor te betaal en wat dit ons sal toelaat om te doen.
Dmitriy:
Het jy op een of ander manier die tyd van die eerste fase vasgestel?
Sergey:
Ja seker. Ons het 6 maande geneem om die kern as 'n platform te skep en die loods te toets. Gedurende hierdie tyd het ons probeer om 'n platform te skep waarop die vlieënier geskaats het. Toe is die hipotese bevestig, en aangesien dit werk, dan kan ons voortgaan. Hulle het begin repliseer en die span versterk - hulle het dit na 'n aparte eenheid gebring, wat presies dit doen.
Vervolgens kom sistematiese werk gebaseer op die behoeftes van die onderneming, geleenthede, beskikbaarheid van hulpbronne en alles wat tans in die werke is.
Dmitriy:
OK. Alexander, wat sê jy?
Alexander:
Ons mikrodienste is gebore uit die "skuim van die see" - as gevolg van besparing van hulpbronne, as gevolg van sommige oorblyfsels in die vorm van bedienerkapasiteit en die herverdeling van kragte binne die span. Aanvanklik het ons nie hierdie projek aan die besigheid verkoop nie. Dit was 'n projek waar ons beide nagevors en daarvolgens ontwikkel het. Ons het aan die begin van 2018 begin en hierdie rigting bloot op entoesiasme ontwikkel. Verkope het pas begin en ons is in die proses.
Dmitriy:
Gebeur dit dat ’n besigheid jou toelaat om sulke dinge volgens die Google-beginsel te doen – op een gratis dag per week? Het jy sulke rigting?
Alexander:
Gelyktydig met navorsing het ons ook sakeprobleme hanteer, daarom is al ons mikrodienste 'n oplossing vir besigheidsprobleme. Eers aan die begin het ons mikrodienste gebou wat 'n klein deel van die intekenaarbasis dek, en nou is ons in byna alle vlagskipprodukte.
En die wesenlike impak is reeds duidelik - ons kan reeds getel word, ons kan die spoed van uitset van produkte en verlore inkomste skat as ons die ou manier gegaan het. Dit is waar ons die saak bou.
Mikrodienste: hype of noodsaaklikheid?
Dmitriy:
Getalle is getalle. En die inkomste of geld wat bespaar word, is baie belangrik. Wat as jy na die ander kant kyk? Dit blyk dat mikrodienste 'n neiging is, 'n hype en baie maatskappye misbruik dit? Hoe duidelik onderskei jy tussen wat jy vertaal en nie in mikrodienste vertaal nie? As nalatenskap nou is, sal jy oor 5 jaar nog 'n nalatenskap hê? Wat sal die ouderdom wees van die inligtingstelsels wat in M.Video-Eldorado en MegaFon werk oor 5 jaar? Sal daar tien jaar oue, vyftien jaar oue inligtingstelsels wees of sal dit 'n nuwe generasie wees? Hoe sien jy dit?
Sergey:
Dit lyk vir my dis baie moeilik om ver te raai. As jy terugkyk, wie het dan verwag dat die mark vir tegnologieë en dieselfde masjienleer, gebruikersidentifikasie deur gesig op hierdie manier sou ontwikkel? Maar as jy kyk na die komende jare, lyk dit vir my dat kernstelsels, onderneming ERP-klas stelsels in maatskappye - hulle werk al lank.
Ons maatskappye is gesamentlik 25 jaar oud, waar klassieke ERP baie diep in die stelsellandskap is. Dit is duidelik dat ons 'n paar stukke daarvandaan uithaal en dit in mikrodienste probeer saamvoeg, maar die kern sal bly. Dit is nou vir my moeilik om te dink dat ons al die kernstelsels daar sal vervang en vinnig na die ander, blink kant van die nuwe stelsels sal beweeg.
Ek is 'n voorstander van die feit dat alles wat nader aan die kliënt en die verbruiker is waar die grootste besigheidsvoordeel en waarde is, waar aanpasbaarheid en fokus op spoed, verandering, "probeer, kanselleer, hergebruik, doen iets anders" nodig is. ' - dis waar die landskap sal verander. En doosprodukte pas nie baie goed in nie. Ons sien dit darem nie. Dit vereis die mees ligte, eenvoudige oplossings.
Ons sien hierdie ontwikkeling:
- kerninligtingstelsels (meestal back office);
- middellae in die vorm van mikrodienste verbind die kern, versamel, skep 'n kas, ensovoorts;
- voorlynstelsels is op die verbruiker gerig;
- 'n integrasielaag wat oor die algemeen in markplekke, ander stelsels en ekosisteme geïntegreer is. Hierdie laag is so lig as moontlik, eenvoudig, dit het 'n minimum besigheidslogika.
Maar terselfdertyd is ek ’n voorstander daarvan om voort te gaan om die ou beginsels te gebruik, as dit op die regte plek gebruik word.
Kom ons sê jy het 'n klassieke ondernemingstelsel. Dit is geleë in die landskap van een verkoper, bestaan uit twee modules wat met mekaar werk. Daar is ook 'n standaard integrasie-koppelvlak. Hoekom dit oordoen en 'n mikrodiens soontoe bring?
Maar wanneer daar 5 modules in die agterkantoor is, waaruit stukkies inligting in 'n besigheidsproses ingesamel word, wat dan deur 8-10 voorlynstelsels gebruik word, is die voordeel hier dadelik merkbaar. Jy neem uit vyf agterkantoorstelsels, skep 'n diens en 'n geïsoleerde een wat op 'n besigheidsproses gefokus is. Jy maak die diens tegnologies gevorderd – sodat dit inligting kas en foutverdraagsaam is, en ook met dokumente of sake-entiteite werk. En jy integreer dit volgens 'n enkele beginsel met alle voorlynprodukte. Hulle het die front-end produk gekanselleer - hulle het net die integrasie afgeskakel. Môre moet jy 'n mobiele toepassing skryf of 'n klein webwerf maak en net een deel in funksionaliteit land - alles is eenvoudig: jy sit dit saam soos 'n konstruktor. Ek sien ontwikkeling in hierdie rigting meer, ten minste in ons land.
Alexander:
Sergey het ons benadering volledig beskryf, dankie. Ek sal net sê waarheen ons beslis nie sal gaan nie - na die kerndeel, na die onderwerp van aanlyn faktuur. Dit wil sê, die gradering en heffing sal in werklikheid 'n "sish" dorsmasjien bly, wat geld betroubaar sal afskryf. En hierdie stelsel sal steeds deur ons regulerende owerhede gesertifiseer word. Alles anders wat na kliënte kyk, is natuurlik mikrodienste.
Dmitriy:
Hier is net sertifisering een storie. Waarskynlik meer ondersteuning. As jy 'n bietjie aan ondersteuning spandeer of die stelsel nie ondersteuning en verbetering benodig nie, is dit beter om nie daaraan te raak nie. Redelike kompromie.
Hoe om robuuste mikrodienste te ontwikkel
Dmitriy:
Goed. Maar ek stel steeds belang. Nou vertel jy 'n suksesverhaal: alles was reg, ons het oorgeskakel na mikrodienste, die idee voor die besigheid verdedig, en alles het uitgewerk. Maar ek het ander stories gehoor.
'n Paar jaar gelede het 'n Switserse maatskappy wat twee jaar belê het in die ontwikkeling van 'n nuwe mikrodiensteplatform vir banke, uiteindelik die projek gesluit. Heeltemal omgedraai. Baie miljoene Switserse frank is bestee, maar op die ou end het hulle die span versprei - dit het nie gewerk nie.
Het jy soortgelyke stories gehad? Was daar enige probleme? Byvoorbeeld, instandhouding van mikrodienste, dieselfde monitering is ook 'n kopseer in die maatskappy se bedrywighede. Die aantal komponente vermeerder immers tienvoudig. Hoe sien jy dit, was daar onsuksesvolle voorbeelde van beleggings hier? En wat kan mense aangeraai word sodat hulle nie soortgelyke probleme ondervind nie?
Alexander:
Ongelukkige voorbeelde was dat die onderneming prioriteite verander het en projekte gekanselleer het. Toe die onderneming in 'n goeie stadium van gereedheid is (in werklikheid is die MVP gereed), het die onderneming gesê: "Ons het nuwe prioriteite, ons gaan na 'n ander projek, en ons sluit hierdie een."
Ons het nie globale mislukkings met mikrodienste gehad nie. Ons slaap lekker, ons het 'n 24/7 diensskof wat die hele BSS [besigheidsondersteuningstelsel] bedien.
En nog een ding - ons verhuur mikrodienste volgens die reëls waarvolgens boksprodukte verhuur word. Die sleutel tot sukses is dat jy eerstens 'n span moet saamstel wat die mikrodiens ten volle vir produksie sal voorberei. Die ontwikkeling self is, voorwaardelik, 40%. Die res is analise, DevSecOps-metodologie, die regte integrasies en die regte argitektuur. Ons gee spesiale aandag aan die beginsels van die bou van veilige toepassings. Verteenwoordigers van inligtingsekuriteit neem deel aan elke projek, beide in die stadium van die beplanning van die argitektuur en tydens die implementeringsproses. Hulle bestuur ook kode-analisestelsels vir kwesbaarhede.
Kom ons sê ons ontplooi ons staatlose dienste – ons het dit in Kubernetes. Dit laat almal toe om rustig te slaap as gevolg van outoskaling en outo-verhogingsdienste, en die skof aan diens tel voorvalle op.
Gedurende die hele bestaan van ons mikrodienste was daar net een of twee voorvalle wat ons lyn bereik het. Nou is daar geen operasionele probleme nie. Natuurlik het ons nie 200 nie, maar ongeveer 50 mikrodienste, maar hulle word in vlagskipprodukte gebruik. As hulle misluk, sou ons die eerste wees om te weet.
Mikrodienste en HR
Sergey:
Ek stem saam met my kollega oor die oordrag na ondersteuning - dat jy die werk behoorlik moet organiseer. Maar ek sal jou vertel van die probleme, wat daar natuurlik is.
Eerstens is die tegnologie nuut. Dit is 'n hype in 'n goeie sin, en om 'n spesialis te vind wat dit sal verstaan en kan skep, is 'n groot uitdaging. Die mededinging om hulpbronne is mal, so kundiges is hul gewig in goud werd.
Tweedens, met die skepping van sekere landskappe en 'n groeiende aantal dienste, moet die probleem van hergebruik voortdurend opgelos word. Soos ontwikkelaars graag doen: "Kom ons skryf nou baie interessante dinge hier ..." As gevolg hiervan groei die stelsel en verloor dit sy doeltreffendheid in terme van geld, koste van eienaarskap, ensovoorts. Dit wil sê, dit is nodig om hergebruik in die argitektuur van stelsels te lê, sluit in die padkaart die implementering van dienste en die oordrag van nalatenskap na 'n nuwe argitektuur.
Nog 'n probleem - hoewel dit op sy eie manier goed is - is interne mededinging. "O, nuwe modieuse ouens het by ons verskyn, hulle praat 'n nuwe taal." Mense is natuurlik anders. Daar is diegene wat gewoond is om in Java te skryf en diegene wat Docker en Kubernetes skryf en gebruik. Dit is heeltemal verskillende mense, hulle praat anders, gebruik verskillende terme en verstaan mekaar soms nie. Die vermoë of onvermoë om praktyk te deel, kennisdeling, in hierdie sin, is ook 'n probleem.
Wel, skaal hulpbronne. "Haai, kom ons gaan! En nou wil ons vinniger, meer hê. Wat, jy kan nie? Is dit nie moontlik om twee keer soveel in 'n jaar te wed nie? En waarom?" Sulke groeiprobleme is waarskynlik standaard vir baie dinge, baie benaderings, en hulle word gevoel.
Oor monitering. Dit lyk vir my dat dienste of industriële monitering gereedskap reeds leer of kan werk met beide Docker en Kubernetes in 'n ander, nie-standaard modus. Sodat jy byvoorbeeld nie 500 Java-masjiene het waaronder dit alles loop nie, naamlik dit saamvoeg. Maar hierdie produkte het nog nie volwassenheid nie, hulle moet hierdeur gaan. Die onderwerp is regtig nuut, dit sal nog ontwikkel word.
Dmitriy:
Ja, baie interessant. En dit geld vir HR. Miskien het jou HR-proses en HR-handelsmerk 'n bietjie verander in hierdie 3 jaar. Jy het ander mense met verskillende bevoegdhede begin werf. En daar is waarskynlik plus- en minusse. Voorheen was blokketting en datawetenskap hype, en spesialiste daarin het net miljoene gekos. Nou daal die koste, die mark is versadig, en daar is 'n soortgelyke neiging in mikrodienste.
Sergey:
Ja, natuurlik.
Alexander:
HR vra die vraag: "Waar is jou pienk eenhoorn tussen backend en frontend?" HR verstaan nie wat 'n mikrodiens is nie. Ons het die geheim aan hulle onthul en gesê dat dit die agterkant was wat alles gedoen het, en daar is geen eenhoorn daar nie. Maar HR verander, leer vinnig en werf mense wat basiese IT-kennis het.
Die evolusie van mikrodienste
Dmitriy:
As jy na die teikenargitektuur kyk, dan lyk mikrodienste na so 'n monster. Jou pad het etlike jare geneem. Ander het 'n jaar, ander drie jaar. Het jy al die probleme, die teikenargitektuur, voorsien, het enigiets verander? Byvoorbeeld, in die geval van mikrodienste, poorte, verskyn diensmaskers nou weer. Het jy hulle aan die begin gebruik of het jy die argitektuur self verander? Het jy sulke uitdagings?
Sergey:
Ons het reeds verskeie interaksieprotokolle herskryf. Eers een protokol, nou het hulle oorgeskakel na 'n ander. Ons verbeter veiligheid en betroubaarheid. Ons het begin met ondernemingstegnologieë – Oracle, Web Logic. Nou beweeg ons weg van tegnologiese ondernemingsprodukte in mikrodienste en beweeg ons na oopbron- of heeltemal oop tegnologieë. Ons weier databasisse, ons gaan oor na wat meer effektief vir ons werk in hierdie model. Ons het nie meer Oracle-tegnologie nodig nie.
Ons het net as 'n diens begin, sonder om te dink aan hoeveel ons 'n kas benodig, wat ons sal doen wanneer daar geen verbinding met die mikrodiens is nie, maar data benodig word, ens. Nou ontwikkel ons die platform sodat die argitektuur beskryf kan word nie in die taal van dienste nie, en in saketaal, neem besigheidslogika na die volgende vlak wanneer ons in woorde begin praat. Nou het ons geleer om in letters te praat, en die volgende vlak is wanneer dienste saamgestel sal word in 'n soort totaal, wanneer dit reeds 'n woord is - byvoorbeeld 'n hele produkkaart. Dit word saamgestel uit mikrodienste, maar dit is so 'n API wat bo-op hierdie gebou is.
Sekuriteit is baie belangrik. Sodra jy begin om beskikbaar te wees en jy het 'n diens waardeur jy baie interessante dinge kan kry, en baie vinnig, in 'n breukdeel van 'n sekonde, dan is daar 'n begeerte om dit op 'n nie die veiligste manier te kry nie. Om hiervan weg te kom, moes ons benaderings tot toetsing en monitering verander. Ek moes die span, die aanbodbestuurstruktuur, CI/CD verander.
Dit is 'n evolusie, net soos met fone, net baie vinniger: eers was daar drukknoppie-fone, toe het slimfone verskyn. Hulle het die produk herskryf, herontwerp omdat die mark 'n ander behoefte gehad het. Dit is hoe ons ontwikkel: graad eerste, graad tiende, werk.
Iteratief, in 'n jaar, word iets gelê in terme van tegnologie, iets anders in terme van agterstand en behoeftes. Ons verbind die een met die ander. Die span bestee 20% aan die tegniese skuld en tegniese ondersteuning van die span, 80% aan die besigheidsentiteit. En ons beweeg, met 'n begrip van hoekom ons dit doen, hoekom ons hierdie tegnologiese verbeterings doen, waarna dit sal lei. Soos dit.
Dmitriy:
Koel. En wat van MegaFon?
Alexander:
Die grootste uitdaging tydens ons aankoms in mikrodienste is om nie in chaos te verval nie. Die argitektuurkantoor van MegaFon het dadelik by ons aangesluit, selfs die inisieerder en drywer geword - nou het ons 'n baie sterk argitektuur. Sy taak was om te verstaan watter teikenmodel ons inbeweeg en watter tegnologieë geloods moet word. Met argitektuur het ons self hierdie loodsings uitgevoer.
Die volgende vraag was: “En dan hoe om dit alles uit te buit?”. En nog een: "Hoe om deursigtige interaksie tussen mikrodienste te verseker?". Die diensnetwerk het ons gehelp om die laaste vraag te beantwoord. Ons het Istio geloods en ons het van die resultate gehou. Nou is ons in die stadium van inrol in produktiewe sones. Ons het 'n positiewe houding teenoor alle uitdagings - tot die feit dat jy voortdurend die stapel moet verander, iets nuuts moet leer. Ons stel daarin belang om ou oplossings te ontwikkel, nie om ou oplossings te ontgin nie.
Dmitriy:
Goue woorde! Sulke uitdagings hou die span en besigheid in goeie vorm en skep die toekoms. GDPR het hoofdatabeskermingsbeamptes geskep, en huidige uitdagings skep hoofmikrodienste en argitektuur. En dit behaag.
Ons het baie bespreek. Die belangrikste ding is dat 'n goeie studie van mikrodienste en die argitektuur self jou toelaat om baie foute te vermy. Natuurlik is die proses iteratief en evolusionêr, maar dit is die toekoms.
Dankie aan alle deelnemers, dankie aan Sergey en Alexander!
Vrae uit die gehoor
Vraag uit die gehoor (1):
Sergey, hoe het IT-bestuur in jou maatskappy verander? Ek verstaan dat wanneer daar 'n groot stapel van verskeie stelsels is, hoe dit bestuur word 'n redelik verstaanbare en logiese proses is. Hoe het jy die bestuur in die IT-komponent herbou nadat 'n baie groot aantal mikrodienste in so 'n kort tyd geïntegreer is?
Sergey:
Ek sal by my kollega sê dat argitektuur baie belangrik is as 'n drywer van verandering. Ons het begin met die feit dat ons 'n argitektoniese afdeling gehad het. Argitekte is terselfdertyd eienaars van die verspreiding van funksionaliteit en vereistes vir hoe dit in die landskap sal lyk. Hulle tree dus ook op as koördineerders van hierdie veranderinge. As gevolg hiervan was daar spesifieke veranderinge in die spesifieke afleweringsproses toe ons die CI/CD-platform geskep het.
Maar die standaard, basiese beginsels van ontwikkeling, besigheid analise, toetsing en ontwikkeling - niemand het gekanselleer. Ons het net spoed bygevoeg. Voorheen het die siklus soveel gekos, installasie op toetsomgewings het soveel meer gekos. Nou sien besigheid die voordeel en sê: "Hoekom kan jy nie dieselfde op ander plekke doen nie?"
Dit is soos, op 'n goeie manier, 'n inspuiting in die vorm van 'n entstof, wat gewys het: jy kan dit so doen, maar jy kan dit anders doen. Natuurlik is daar 'n probleem in personeel, in bevoegdhede, in kennis, in weerstand.
Vraag uit die gehoor (2):
Kritici van mikrodiensargitektuur sê dat daar probleme is met toetsing en ontwikkeling. Dit is logies waar dinge ingewikkeld raak. Watter uitdagings het jou span in die gesig gestaar en hoe het jy dit oorkom? Vraag aan almal.
Alexander:
Daar is probleme wanneer van mikrodienste na 'n platform beweeg word, maar dit is oplosbaar.
Ons maak byvoorbeeld 'n produk wat uit 5-7 mikrodienste bestaan. Ons moet integrasietoetse oor die hele mikrodienste-omvang voorsien om die groen lig aan die meestertak te gee. Hierdie taak was nie nuut vir ons nie: ons doen dit al lank by BSS, toe die verkoper ons voorsien het van reeds gestuurde oplossings.
En ons probleem is net in 'n klein span. Een voorwaardelike produk vereis een QA-ingenieur. En dus stuur ons 'n produk van 5-7 mikrodienste, waarvan 2-3 deur derdeparty-mense ontwikkel kan word. Ons het byvoorbeeld 'n produk wat ontwikkel is deur ons faktureringstelselverskaffer, Mail.ru Group en MegaFon R&D. Ons moet dit met toetse dek voordat dit na produksie gestuur word. 'n QA-ingenieur werk al 'n maand en 'n half aan hierdie produk, en die res van die span sit sonder sy ondersteuning.
Hierdie kompleksiteit word slegs deur skaal veroorsaak. Ons verstaan dat mikrodienste nie in 'n vakuum kan bestaan nie, daar is geen absolute isolasie nie. Wanneer ons een diens verander, probeer ons altyd om die API-kontrak te behou. As iets onder die enjinkap verander, bly die diensfront. As die veranderinge noodlottig is, is daar 'n soort argitektoniese transformasie en ons skakel oor die algemeen oor na 'n ander data-metamodel wat heeltemal onversoenbaar is - eers dan sê ons dat die v2-diens API-spesifikasie verskyn. Ons ondersteun die eerste en tweede weergawes terselfdertyd, en na die oorgang van alle verbruikers na die tweede weergawe, sluit ons eenvoudig die eerste een.
Sergey:
Ek wil byvoeg. Ek stem absoluut saam oor die komplikasies – dit gebeur. Die landskap word meer kompleks, en bokoste styg, veral vir toetsing. Hoe om dit te hanteer: skakel oor na outotoetsing. Ja, jy sal bykomend moet belê in die skryf van outotoetse en eenheidstoetse. Sodat ontwikkelaars nie kon verbind sonder om die toets te slaag nie, kon hulle nie die kode verander nie. Sodat selfs die drukknop nie werk sonder 'n outotoets, 'n eenheidstoets nie.
Dit is belangrik om die vorige funksionaliteit te handhaaf, en dit is 'n bykomende oorkoste. As jy tegnologie na 'n ander protokol herskryf, dan herskryf jy dit totdat jy alles heeltemal toemaak.
Soms doen ons nie doelbewus end-tot-end-toetsing nie, want ons wil nie ontwikkeling stop nie, alhoewel ons ook aan mekaar vasklou. Die landskap is baie groot, kompleks, daar is baie stelsels. Soms net stompies - ja, jy verlaag die sekuriteitsmarge, meer risiko's verskyn. Maar terselfdertyd stel jy die voorraad vry.
Alexander:
Ja, outotoetse en eenheidstoetse laat jou toe om 'n kwaliteit diens te lewer. Ons is vir 'n pyplyn wat nie geslaag kan word sonder eenheid- en integrasietoetse nie. Ons moet dikwels emulators, stelsels van die verkoop na toetssones en ontwikkelingsomgewings sleep, want nie alle stelsels kan in toetssones geplaas word nie. Boonop word hulle nie net nat nie - ons genereer 'n volwaardige reaksie vanaf die stelsel. Dit is 'n ernstige deel van die werk met mikrodienste, en ons belê ook daarin. Daarsonder sal daar chaos wees.
Vraag uit die gehoor (3):
Sover ek verstaan, het mikrodienste aanvanklik uit 'n aparte span gegroei en bestaan dit nou in hierdie model. Wat is haar voor- en nadele?
Dit is net dat ons 'n soortgelyke storie het: 'n sekere mikrodienste-fabriek het ontstaan. Nou het ons konseptueel die feit benader dat ons hierdie benadering tot produksie deur strome en deur stelsels uitbrei. Met ander woorde, ons beweeg weg van die gesentraliseerde ontwikkeling van presies mikrodienste, mikrodiensmodelle, en kom nader aan stelsels.
Gevolglik gaan ons operasie ook na die stelsels, dit wil sê ons desentraliseer hierdie onderwerp. Wat is jou benadering en wat is die teikenstorie vir jou?
Alexander:
Jy het die naam “mikrodiensfabriek” van die tong afgehaal – ons wil ook skaal. Eerstens, ons het nou regtig een span. Ons wil al die ontwikkelingspanne wat MegaFon het die geleentheid gee om in 'n gemeenskaplike ekosisteem te werk. Ons wil nie al die ontwikkelingsfunksies wat ons nou het heeltemal oorneem nie. Die plaaslike taak is om te skaal, die globale taak is om alle spanne in die mikrodienslaag te ontwikkel.
Sergey:
Kom ek vertel jou die pad wat ons geneem het. Ons het regtig as een span begin werk, maar nou is dit nie alleen nie. Ek is 'n voorstander van die volgende: daar moet 'n eienaar van die proses wees. Iemand moet die mikrodienste-ontwikkelingsproses verstaan, bestuur, beheer en bou. Hy moet hulpbronne besit en by hulpbronbestuur betrokke raak.
Hierdie hulpbronne wat die tegnologie ken, die besonderhede ken en verstaan hoe om mikrodienste te bou, kan in produkspanne wees. Ons het 'n mengsel waar mense van die mikrodiensplatform in die produkspan is wat die mobiele toepassing maak. Hulle is daar, maar hulle werk saam met hul ontwikkelingsbestuurder aan die proses van die mikrodiensplatformbestuursafdeling. Binne hierdie afdeling is daar 'n aparte span wat met tegnologie te doen het. Dit wil sê, ons meng 'n gemeenskaplike poel van hulpbronne saam en deel dit, gee hulle binne die opdragte.
Terselfdertyd bly die proses algemeen, beheer, dit verloop volgens algemene tegnologiese beginsels, met eenheidstoetsing, ensovoorts – alles wat bo-op gebou is. Daar kan kolomme wees in die vorm van hulpbronne wat van verskillende departemente van die produkbenadering ingesamel is.
Alexander:
Sergey, jy is eintlik die eienaar van die proses, reg? Agterstandtake gedeel? Wie versprei dit?
Sergey:
Kyk: hier is die mengsel weer. Daar is 'n agterstand wat gevorm word op grond van tegnologiese verbeterings - dit is een storie. Daar is 'n agterstand wat uit projekte geformuleer word, en daar is 'n agterstand van produkte. Maar die volgorde van die inbring van elk van die produkte van die diens of die skepping van hierdie diens word ontwikkel deur die produkbestuurder. Hy is nie in die IT-afdeling nie, hy is spesiaal daaruit verwyder. Maar my mense werk beslis aan dieselfde proses.
Die eienaar van die agterstand in verskillende rigtings - agterstand van veranderinge - sal verskillende mense wees. Konnektiwiteit van tegnologiese dienste, hul beginsel van organisasie - dit alles sal in IT wees. Ek besit die platform, ek besit ook die hulpbronne. Aan die bokant is wat die agterstand en funksionele veranderinge betref, en die argitektuur in hierdie sin.
Gestel 'n besigheid sê: "Ons wil so 'n funksie hê, ons wil 'n nuwe produk skep - 'n lening hermaak." Ons antwoord: "Ja, ons sal dit oordoen." Argitekte sê: “Kom ons dink: waar kan ons mikrodienste op krediet skryf en hoe kan ons dit doen?”. Dan ontbind ons dit in projekte, produkte of 'n tegnologiese stapel, verlaag dit in spanne en implementeer dit. Het jy 'n produk binne geskep en besluit om mikrodienste in hierdie produk te gebruik? Ons sê: "Nou moet die nalatenskapstelsels wat ons gehad het, of die voorste linies, na hierdie mikrodienste oorskakel." Argitekte sê: “Dus: in die tegnologiese agterstand binne die front-end produkte - die oorgang na mikrodienste. Gaan". En produkspesialiste of sake-eienaars verstaan hoeveel kapasiteit toegeken word, wanneer dit gedoen sal word en hoekom.
Einde van bespreking, maar nog nie
Die mailto:CLOUD-konferensie is gereël .
Ons doen ook ander aktiwiteite – bv. @Kubernetes Meetupwaar ons altyd op soek is na wonderlike sprekers:
- Volg @Kubernetes en ander @Meetup-nuus in ons Telegram-kanaal
- Stel jy belang om by een van die @Meetups op te tree? Laat 'n versoek vir
Bron: will.com