Op 25 april hielden wij bij Mail.ru Group een conferentie over wolken en rond - . Een paar hoogtepunten:
- De belangrijkste — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center en Yandex.Cloud spraken over de specifieke kenmerken van onze cloudmarkt en hun diensten;
- Collega's van Bitrix24 vertelden hoe zij dat deden ;
- Leroy Merlin, Otkritie, Burger King en Schneider Electric zorgden voor interessant materiaal — welke taken hun bedrijf stelt aan IT en welke technologieën, inclusief cloudtechnologieën, zij als het meest veelbelovend beschouwen.
Je kunt alle video's van de mailto:CLOUD conferentie bekijken , en hier lees je hoe de discussie over microservices verliep. Alexander Deulin, hoofd van het onderzoeks- en ontwikkelingscentrum MegaFon voor bedrijfssystemen, en Sergey Sergeev, directeur informatietechnologie van de M.Video-Eldorado-groep, deelden hun succesvolle voorbeelden van het wegwerken van monolieten. We bespraken ook aanverwante kwesties op het gebied van IT-strategie, processen en zelfs HR.
Panelleden
- Sergej Sergejev, Groep-CIO "M.Video-Eldorado";
- Alexander Deulin, hoofd van het centrum voor onderzoek en ontwikkeling van bedrijfssystemen MegaFon;
- Moderator — Dmitry Lazarenko, Hoofd PaaS-directie Mail.ru Cloud-oplossingen.
Na de toespraak van Alexander Deulin Hij wordt bijgestaan door Sergey Sergeev van M.Video-Eldorado en discussiemoderator Dmitry Lazarenko, Mail.ru Cloud Solutions.
Hieronder hebben we een transcriptie van de discussie voor je gemaakt, maar je kunt ook de video bekijken:
De transitie naar microservices is een reactie op de marktbehoeften
Dmitri:
Heeft u succesvolle ervaringen gehad met de migratie naar microservices? En in het algemeen: waar ziet u het grootste zakelijke voordeel bij het gebruik van microservices of bij de overstap van monolieten naar microservices?
Sergej:
We zijn al een eind op weg in de transitie naar microservices en gebruiken deze aanpak al ruim drie jaar. De eerste behoefte die de behoefte aan microservices rechtvaardigde was de eindeloze integratie van verschillende front-end producten met de backoffice. En elke keer werden we gedwongen om extra integratie en ontwikkeling uit te voeren, waarbij we onze eigen regels implementeerden voor de werking van deze of gene dienst.
Op een gegeven moment realiseerden we ons dat we de werking van onze systemen en de output van functionaliteit moesten versnellen. Op dat moment bestonden concepten als microservices en een microservice-aanpak al op de markt, en we besloten het te proberen. Dit begon in 2016. Vervolgens werd het platform gelegd en werden de eerste 10 diensten door een apart team geïmplementeerd.
Eén van de eerste diensten, het zwaarst beladen, was de prijsberekeningsdienst. Elke keer dat u naar een kanaal komt, naar de M.Video-Eldorado-bedrijvengroep, of het nu een website of een winkel is, selecteert u daar een product, bekijkt u de prijs op de website of in het "Winkelmandje", worden de kosten automatisch berekend door één dienst. Waarom is dit nodig: voorheen had elk systeem zijn eigen principes voor het werken met promoties - met kortingen enzovoort. Onze backoffice verzorgt de prijsstelling, de kortingsfunctionaliteit is in een ander systeem geïmplementeerd. Dit moest gecentraliseerd worden en er moest een unieke, scheidbare dienst gecreëerd worden in de vorm van een bedrijfsproces waarmee we dit konden implementeren. Dat is ongeveer hoe we begonnen zijn.
De waarde van de eerste resultaten was zeer groot. Ten eerste zijn we erin geslaagd scheidbare entiteiten te creëren die ons in staat stellen afzonderlijk en op een geaggregeerde manier te werken. Ten tweede hebben we de eigendomskosten verlaagd in termen van integratie met meer systemen.
De afgelopen drie jaar hebben we drie frontlijnsystemen toegevoegd. Ze waren moeilijk te onderhouden met dezelfde hoeveelheid middelen die het bedrijf zich kon veroorloven. Daarom ontstond de taak om op zoek te gaan naar nieuwe afzetmogelijkheden, die op de markt zouden reageren in termen van snelheid, in termen van interne kosten en efficiëntie.
Hoe u het succes van de migratie naar microservices kunt meten
Dmitri:
Hoe wordt succes bij de migratie naar microservices bepaald? Wat was de ‘before’ in elk bedrijf? Welke maatstaf heb je gebruikt om het succes van de transitie te bepalen, en wie heeft dat feitelijk bepaald?
Sergej:
In de eerste plaats werd het binnen de IT geboren als een enabler – het ‘ontsluiten’ van nieuwe mogelijkheden. We hadden de behoefte om alles sneller te doen voor relatief hetzelfde geld, als reactie op de uitdagingen van de markt. Nu wordt succes uitgedrukt in het aantal diensten dat door verschillende systemen wordt hergebruikt, de unificatie van processen onderling. Nu is dat zo, maar op dat moment was het een kans om een platform te creëren en de hypothese te bevestigen dat we dit kunnen doen, het zal effect hebben en de business case berekenen.
Alexander:
Succes is eerder een intern gevoel. Het bedrijfsleven wil altijd meer, en de diepte van onze achterstand is het bewijs van succes. Dat lijkt mij zo.
Sergej:
Ja, ik ben het ermee eens. In drie jaar tijd hebben we al ruim tweehonderd diensten en achterstanden. De behoefte aan middelen binnen het team groeit alleen maar: jaarlijks met 30%. Dit gebeurt omdat mensen voelden: het is sneller, het is anders, er zijn verschillende technologieën, dit alles is in ontwikkeling.
Er zullen microservices komen, maar de kern zal blijven bestaan
Dmitri:
Het is als een nooit eindigend proces waarbij je investeert in ontwikkeling. Is de transitie naar microservices voor bedrijven al voorbij of niet?
Sergej:
Het is heel gemakkelijk te beantwoorden. Wat denk jij: het vervangen van telefoons is een eindeloos proces? Zelf kopen wij elk jaar telefoons. En hier is het dan: zolang er behoefte is aan snelheid, aan aanpassing aan de markt, zullen er enkele veranderingen nodig zijn. Dit betekent niet dat we standaardzaken achterwege laten.
Maar we kunnen niet alles in één keer afdekken en opnieuw doen. We hebben oude, standaardintegratiediensten die al eerder bestonden: bedrijfsbussen enzovoort. Maar er is een achterstand, en er is ook behoefte. Het aantal mobiele applicaties en hun functionaliteit groeit. Tegelijkertijd zegt niemand dat u 30% meer geld krijgt. Dat wil zeggen: er zijn altijd behoeften aan de ene kant en een zoektocht naar efficiëntie aan de andere kant.
Dmitri:
Het leven is in goede vorm. (Lacht)
Alexander:
Over het algemeen wel. We hebben geen revolutionaire benaderingen om het kerngedeelte uit het landschap te verwijderen. Er wordt systematisch gewerkt aan het ontbinden van systemen, zodat ze meer consistent zijn met de microservice-architectuur, om de invloed van systemen op elkaar te verminderen.
Maar we zijn van plan het kerngedeelte te behouden, omdat er in het landschap van de exploitant altijd een aantal platforms zullen zijn die we kopen. Nogmaals, we hebben een gezond evenwicht nodig: we moeten niet overhaast de kern wegsnijden. We plaatsen de systemen naast elkaar en nu blijkt dat we op veel kernonderdelen al bovenop zitten. Verder ontwikkelen we de functionaliteit en creëren we de nodige representaties voor alle kanalen die met onze communicatiediensten werken.
Hoe microservices aan bedrijven te verkopen
Dmitri:
Ik ben ook geïnteresseerd – voor degenen die nog niet zijn overgestapt, maar dat wel van plan zijn: hoe gemakkelijk was het om dit idee aan het bedrijfsleven te verkopen en was het een avontuur, een investeringsproject? Of was het een bewuste strategie: nu gaan we naar microservices en dat is alles, niets houdt ons tegen. Hoe was het voor jou?
Sergej:
We verkochten geen aanpak, maar een zakelijk voordeel. Er was een probleem in het bedrijfsleven en we probeerden het op te lossen. Op dat moment kwam dit tot uiting in het feit dat verschillende kanalen verschillende principes gebruikten voor het berekenen van prijzen - afzonderlijk voor promoties, voor promoties, enzovoort. Het was moeilijk te onderhouden, er deden zich fouten voor en we luisterden naar klachten van klanten. Dat wil zeggen: we verkochten een oplossing voor een probleem, maar we kwamen met het feit dat we geld nodig hadden om een platform te creëren. En ze lieten een business case zien aan de hand van het voorbeeld van de eerste investeringsfase: hoe we dit zullen blijven terugverdienen en wat we hierdoor kunnen doen.
Dmitri:
Heb je op de een of andere manier de tijd van de eerste etappe vastgelegd?
Sergej:
Ja tuurlijk. We hebben zes maanden de tijd genomen om de kern als platform te creëren en de pilot te testen. Gedurende deze tijd probeerden we een platform te creëren waarop de piloot kon skaten. Toen werd de hypothese bevestigd, en omdat het werkt, kunnen we doorgaan. Ze begonnen het team te repliceren en te versterken - ze brachten het naar een aparte divisie die precies dat doet.
Vervolgens komt systematisch werk op basis van zakelijke behoeften, kansen, beschikbaarheid van middelen en alles wat momenteel in de maak is.
Dmitri:
OK. Alexander, wat zeg je ervan?
Alexander:
Onze microservices zijn ontstaan uit het ‘schuim van de zee’ – door het besparen van middelen, door wat overblijft in de vorm van servercapaciteit en herverdeling van krachten binnen het team. In eerste instantie hebben we dit project niet aan het bedrijfsleven verkocht. Dit was een project waarin we zowel onderzoek deden als dienovereenkomstig ontwikkelden. We zijn begin 2018 begonnen en hebben deze richting simpelweg met enthousiasme ontwikkeld. De verkoop is net begonnen en we zijn bezig.
Dmitri:
Komt het voor dat een bedrijf je toestaat zulke dingen als Google te doen – op één vrije dag in de week? Heb jij zo’n richting?
Alexander:
Naast onderzoek hebben we ook zakelijke problemen aangepakt, dus al onze microservices zijn oplossingen voor zakelijke problemen. Pas in het begin bouwden we microservices die een klein deel van het abonneebestand bestreken, en nu zijn we aanwezig in bijna alle vlaggenschipproducten.
En de materiële impact is al duidelijk: we kunnen al worden geteld, de snelheid van productlanceringen en verloren inkomsten kunnen worden geschat als we het oude pad hadden gevolgd. Dit is waar wij de zaak op voortbouwen.
Microservices: hype of noodzaak?
Dmitri:
Cijfers zijn cijfers. En de inkomsten of het bespaarde geld zijn erg belangrijk. Wat als je naar de andere kant kijkt? Het lijkt erop dat microservices een trend, een hype zijn en dat veel bedrijven er misbruik van maken? Hoe duidelijk maakt u onderscheid tussen wat u wel en niet vertaalt naar microservices? Als u nu een erfenis heeft, heeft u dan over vijf jaar nog steeds een erfenis? Hoe oud zullen de informatiesystemen zijn die bij M.Video-Eldorado en MegaFon werken over 5 jaar? Zullen er informatiesystemen van tien of vijftien jaar oud zijn of zal het een nieuwe generatie zijn? Hoe zie je dit?
Sergej:
Het lijkt mij dat het moeilijk is om heel ver weg te denken. Als we terugkijken, wie had dan gedacht dat de technologiemarkt zich op deze manier zou ontwikkelen, inclusief machine learning en gebruikersidentificatie via gezicht? Maar als je naar de komende jaren kijkt, lijkt het mij dat kernsystemen, enterprise ERP-klasse systemen in bedrijven, al een hele tijd werken.
Onze bedrijven zijn samen 25 jaar oud, met klassieke ERP zeer diep in het systeemlandschap. Het is duidelijk dat we een aantal onderdelen eruit halen en proberen deze samen te voegen tot microservices, maar de kern zal blijven bestaan. Ik kan me nu moeilijk voorstellen dat we alle kernsystemen daar zullen vervangen en snel naar de andere, positieve kant van de nieuwe systemen zullen gaan.
Ik ben een voorstander van het feit dat alles wat dichter bij de klant en consument staat daar het grootste zakelijke voordeel en de grootste waarde biedt, waar aanpassingsvermogen en focus op snelheid, op verandering, op “proberen, annuleren, hergebruiken, iets anders doen” belangrijk zijn. nodig “-dat is waar het landschap zal veranderen. En producten in dozen passen daar niet zo goed in. Wij zien het tenminste niet. Daar zijn de gemakkelijkste, eenvoudigste oplossingen nodig.
Wij zien deze ontwikkeling:
- kerninformatiesystemen (meestal backoffice);
- middelste lagen in de vorm van microservices verbinden de kern, aggregeren, creëren een cache, enzovoort;
- frontlijnsystemen zijn gericht op de consument;
- een integratielaag die over het algemeen is geïntegreerd in marktplaatsen, andere systemen en ecosystemen. Deze laag is zo licht mogelijk, eenvoudig en bevat een minimum aan bedrijfslogica.
Maar tegelijkertijd ben ik er een voorstander van om de oude principes te blijven hanteren, als ze op de juiste manier worden toegepast.
Stel dat u een klassiek bedrijfssysteem heeft. Het bevindt zich in het landschap van één leverancier en bestaat uit twee modules die met elkaar samenwerken. Er is ook een standaard integratie-interface. Waarom het opnieuw doen en daar een microservice brengen?
Maar als er in de backoffice 5 modules aanwezig zijn, waaruit stukjes informatie worden verzameld in een bedrijfsproces, dat vervolgens door 8 tot 10 frontlijnsystemen wordt gebruikt, is het voordeel meteen merkbaar. Je neemt uit vijf backofficesystemen en creëert een dienst, een geïsoleerde dienst, die gericht is op het bedrijfsproces. Maak de service technologisch geavanceerd, zodat deze informatie in de cache opslaat, fouttolerant is en ook werkt met documenten of zakelijke entiteiten. En je integreert het volgens één principe met alle frontlineproducten. Ze annuleerden het eerstelijnsproduct - ze schakelden simpelweg de integratie uit. Morgen moet je een mobiele applicatie schrijven of een kleine website maken en slechts één onderdeel in functionaliteit omzetten - alles is eenvoudig: je hebt het als een constructor in elkaar gezet. Ik zie meer ontwikkeling in deze richting – tenminste in ons land.
Alexander:
Sergey heeft onze aanpak volledig beschreven, bedankt. Ik zal alleen zeggen waar we zeker niet heen zullen gaan: naar het kerngedeelte, naar het onderwerp online facturering. Dat wil zeggen dat beoordeling en opladen in feite een ‘grote’ dorsmachine zullen blijven die op betrouwbare wijze geld zal afschrijven. En dit systeem zal gecertificeerd blijven door onze regelgevende instanties. Al het andere dat naar klanten kijkt, is natuurlijk microservices.
Dmitri:
Certificering is hier één verhaal. Waarschijnlijk meer steun. Als u weinig uitgeeft aan ondersteuning of het systeem geen ondersteuning en aanpassing nodig heeft, kunt u er beter niet aan komen. Een redelijk compromis.
Hoe betrouwbare microservices te ontwikkelen
Dmitri:
Prima. Maar ik ben nog steeds geïnteresseerd. Nu vertel je een succesverhaal: alles was in orde, we zijn overgestapt op microservices, hebben het idee tegenover de business verdedigd en alles is gelukt. Maar ik heb andere verhalen gehoord.
Een paar jaar geleden sloot een Zwitsers bedrijf dat twee jaar had geïnvesteerd in de ontwikkeling van een nieuw microserviceplatform voor banken het project uiteindelijk af. Volledig ingestort. Er werden vele miljoenen Zwitserse franken uitgegeven, en uiteindelijk raakte het team uiteen - het lukte niet.
Heb jij soortgelijke verhalen gehad? Waren of zijn er moeilijkheden? Het onderhouden van microservices en monitoring is bijvoorbeeld ook een hoofdpijnpunt in de operationele activiteiten van het bedrijf. Het aantal componenten neemt immers tientallen keren toe. Hoe zie jij het, zijn er hier mislukte voorbeelden van investeringen geweest? En wat kun je mensen adviseren zodat ze dergelijke problemen niet tegenkomen?
Alexander:
Mislukte voorbeelden waren onder meer bedrijven die hun prioriteiten veranderden en projecten annuleerden. Toen het bedrijf zich in een goed stadium van paraatheid bevond (in feite is de MVP klaar), zei het bedrijf: “We hebben nieuwe prioriteiten, we gaan door naar een ander project en we sluiten dit project af.”
We hebben geen wereldwijde problemen gehad met microservices. We slapen rustig, we hebben een 24/7 dienst die het hele BSS [business support system] bedient.
En nog één ding: we verhuren microservices volgens de regels die van toepassing zijn op verpakte producten. De sleutel tot succes is dat je in de eerste plaats een team moet samenstellen dat de microservice volledig gereedmaakt voor productie. De ontwikkeling zelf bedraagt, voorwaardelijk, 40%. De rest is analytics, DevSecOps-methodologie, de juiste integraties en de juiste architectuur. We besteden speciale aandacht aan de principes van het bouwen van veilige applicaties. Vertegenwoordigers van informatiebeveiliging nemen deel aan elk project, zowel in de architectuurplanningsfase als tijdens het implementatieproces. Ze beheren ook systemen voor het analyseren van code op kwetsbaarheden.
Laten we zeggen dat we onze staatloze services inzetten: we hebben ze in Kubernetes. Hierdoor kan iedereen rustig slapen dankzij het automatisch opschalen en verhogen van diensten, en de dienstdienst pikt incidenten op.
In het hele bestaan van onze microservices zijn er slechts één of twee incidenten geweest die onze lijn hebben bereikt. Nu zijn er geen problemen met de bediening. We hebben natuurlijk geen 200, maar ongeveer 50 microservices, maar ze worden gebruikt in vlaggenschipproducten. Mocht dit niet lukken, dan zijn wij de eersten die hiervan op de hoogte zijn.
Microservices en HR
Sergej:
Ik ben het met mijn collega eens over de overdracht naar ondersteuning: dat het werk goed georganiseerd moet worden. Maar ik zal je vertellen over de problemen die er natuurlijk zijn.
Ten eerste is de technologie nieuw. Dit is op een goede manier een hype, en het vinden van een specialist die dit begrijpt en kan creëren is een grote uitdaging. De concurrentie om hulpbronnen is waanzinnig, dus experts zijn hun gewicht in goud waard.
Ten tweede moet met de creatie van bepaalde landschappen en een groeiend aantal diensten het probleem van hergebruik voortdurend worden opgelost. Zoals ontwikkelaars graag doen: “Laten we hier nu een heleboel interessante dingen schrijven...” Hierdoor groeit het systeem en verliest het zijn effectiviteit in termen van geld, eigendomskosten, enzovoort. Dat wil zeggen dat het noodzakelijk is om hergebruik op te nemen in de systeemarchitectuur, het op te nemen in de routekaart voor het introduceren van diensten en het overbrengen van legacy naar een nieuwe architectuur.
Een ander probleem – hoewel dit op zichzelf goed is – is de interne concurrentie. "Oh, er zijn hier nieuwe modieuze jongens verschenen, ze spreken een nieuwe taal." Mensen zijn natuurlijk verschillend. Er zijn mensen die gewend zijn om in Java te schrijven, en mensen die Docker en Kubernetes schrijven en gebruiken. Dit zijn totaal verschillende mensen, ze spreken anders, gebruiken andere termen en begrijpen elkaar soms niet. Het wel of niet kunnen delen van de praktijk, het delen van kennis, is in deze zin ook een probleem.
Nou ja, het opschalen van hulpbronnen. "Goed laten we gaan! En nu willen we sneller, meer. Wat, dat kun je niet? Is het niet mogelijk om in een jaar twee keer zoveel te leveren? En waarom?" Dergelijke groeipijnen zijn waarschijnlijk standaard voor veel dingen, veel benaderingen, en je kunt ze voelen.
Wat betreft monitoring. Het lijkt mij dat services of industriële monitoringtools al leren of kunnen werken met zowel Docker als Kubernetes in een andere, niet-standaard modus. Zodat je bijvoorbeeld niet met 500 Java-machines komt te zitten waar dit allemaal op draait, namelijk: het aggregeert. Maar deze producten zijn nog steeds niet volwassen; ze moeten hier doorheen. Het onderwerp is echt nieuw, het zal zich blijven ontwikkelen.
Dmitri:
Ja, heel interessant. En dat geldt ook voor HR. Misschien zijn uw HR-proces en HR-merk de afgelopen drie jaar enigszins veranderd. Je begon andere mensen met andere competenties te werven. En er zijn waarschijnlijk zowel voor- als nadelen. Vroeger waren blockchain en data science de hype, en de specialisten daarin waren miljoenen waard. Nu de kosten dalen, raakt de markt verzadigd en is er een vergelijkbare trend in microservices.
Sergej:
Ja absoluut.
Alexander:
HR stelt de vraag: “Waar is jouw roze eenhoorn tussen de backend en frontend?” HR begrijpt niet wat een microservice is. We vertelden hen het geheim en vertelden hen dat de backend alles deed, en dat er geen eenhoorn is. Maar HR verandert, leert snel en werft mensen aan die basiskennis van IT hebben.
De evolutie van microservices
Dmitri:
Als je naar de doelarchitectuur kijkt, zien microservices eruit als zo’n monster. Je reis duurde meerdere jaren. Anderen hebben een jaar, anderen drie jaar. Had je alle problemen voorzien, de doelarchitectuur, is er iets veranderd? Bij microservices verschijnen nu bijvoorbeeld weer gateways en service meshes. Heb je ze in het begin gebruikt of heb je de architectuur zelf veranderd? Heeft u zulke uitdagingen?
Sergej:
We hebben al verschillende communicatieprotocollen herschreven. Eerst was er één protocol, nu zijn we overgestapt op een ander. Wij verhogen de veiligheid en betrouwbaarheid. We zijn begonnen met bedrijfstechnologieën - Oracle, Web Logic. Nu stappen we af van technologische ondernemingsproducten op het gebied van microservices en gaan we over op open source of volledig open technologieën. We verlaten databases en gaan over op wat in dit model effectiever voor ons werkt. We hebben geen Oracle-technologieën meer nodig.
We zijn simpelweg begonnen als een service, zonder na te denken over hoeveel we een cache nodig hadden, wat we zouden doen als er geen verbinding was met een microservice, maar wel data nodig waren, etc. Nu ontwikkelen we een platform zodat de architectuur kan worden beschreven niet in de taal van diensten, en in zakelijke taal: breng de bedrijfslogica naar een hoger niveau als we in woorden beginnen te praten. Nu hebben we geleerd om in letters te spreken, en het volgende niveau is wanneer de diensten worden verzameld in een soort aggregaat, terwijl dit al een woord is, bijvoorbeeld een hele productkaart. Het is samengesteld uit microservices, maar het is een API die daarbovenop is gebouwd.
Veiligheid is erg belangrijk. Zodra je toegankelijk begint te worden en je een dienst hebt waarmee je veel interessante dingen kunt krijgen, en heel snel, in een fractie van een seconde, dan is er een verlangen om dit op een niet de meest veilige manier te krijgen. Om hier vanaf te komen, moesten we de aanpak van testen en monitoren veranderen. We moesten het team, de leveringsbeheerstructuur en CI/CD veranderen.
Dit is een evolutie - net als bij telefoons, maar dan veel sneller: eerst waren er telefoons met drukknoppen, daarna verschenen er smartphones. Ze herschreven en herontworpen het product omdat de markt een andere behoefte had. Dit is hoe we evolueren: eerste leerjaar, tiende leerjaar, werk.
Iteratief wordt er per jaar iets vastgelegd vanuit het oogpunt van technologie, iets anders vanuit het oogpunt van de achterstand en behoeften. Wij verbinden het één met het ander. Het team besteedt 20% aan technische schulden en technische ondersteuning voor het team, en 80% aan de bedrijfsentiteit. En we bewegen met een goed begrip van waarom we het doen, waarom we deze technologische verbeteringen doorvoeren, en waar ze toe zullen leiden. Zoals dat.
Dmitri:
Koel. Wat zit er in MegaFon?
Alexander:
De grootste uitdaging toen we bij microservices kwamen, was om niet in chaos te vervallen. Het architectenbureau van MegaFon sloot zich meteen bij ons aan, werd zelfs initiatiefnemer en aanjager – nu hebben we een hele sterke architectuur. Zijn taak was om te begrijpen naar welk doelmodel we gaan en welke technologieën moeten worden getest. Bij architectuur hebben we deze pilots zelf uitgevoerd.
De volgende vraag was: “Hoe kunnen we dit allemaal dan exploiteren?” En nog één: “Hoe zorg je voor transparante interactie tussen microservices?” Service mesh heeft ons geholpen de laatste vraag te beantwoorden. We hebben Istio getest en waren tevreden over de resultaten. Nu bevinden we ons in de fase van de uitrol naar productieve zones. We hebben een positieve houding ten opzichte van alle uitdagingen - het feit dat we voortdurend de stapel moeten veranderen, iets nieuws moeten leren. Wij zijn geïnteresseerd in het ontwikkelen, niet in het exploiteren van oude oplossingen.
Dmitri:
Gouden woorden! Dergelijke uitdagingen houden het team en het bedrijf scherp en creëren de toekomst. De AVG heeft Chief Data Protection Officers in het leven geroepen, en de huidige uitdagingen hebben Chief Microservices en Architecture Officers gecreëerd. En het bevalt.
We hebben veel besproken. Het belangrijkste is dat je met een goed ontwerp van microservices en de architectuur zelf veel fouten kunt voorkomen. Natuurlijk is het proces iteratief en evolutionair, maar het is de toekomst.
Dank aan alle deelnemers, dank aan Sergei en Alexander!
Vragen uit het publiek
Vraag uit het publiek (1):
Sergey, hoe is het IT-beheer in jouw bedrijf veranderd? Ik begrijp dat als er een grote stapel van verschillende systemen is, de manier waarop deze wordt beheerd een redelijk duidelijk en logisch proces is. Hoe heb je het beheer van de IT-component opnieuw opgebouwd nadat in zo korte tijd een zeer groot aantal microservices was geïntegreerd?
Sergej:
Ik ben het met mijn collega eens dat architectuur heel belangrijk is als aanjager van verandering. We zijn begonnen met een architecturale afdeling. Architecten zijn tegelijkertijd eigenaar van de verdeling van functionaliteit en de eisen aan hoe deze in het landschap zal verschijnen. Zij treden dus ook op als coördinator van deze veranderingen. Als gevolg hiervan vonden er specifieke wijzigingen plaats in een specifiek leveringsproces toen we een CI/CD-platform creëerden.
Maar de standaard, basisprincipes van ontwikkeling, bedrijfsanalyse, testen en ontwikkeling zijn niet geannuleerd. We hebben zojuist snelheid toegevoegd. Voorheen duurde de cyclus zoveel, terwijl de installatie op testomgevingen zoveel meer kostte. Nu ziet het bedrijfsleven het voordeel en zegt: “Waarom kunnen we niet hetzelfde op andere plaatsen doen?”
Het is, op een goede manier, een injectie in de vorm van een vaccin die liet zien: je kunt het op deze manier doen, maar je kunt het ook op een andere manier doen. Natuurlijk is er een probleem in het personeel, in de competenties, in de kennis, in de weerstand.
Vraag uit het publiek (2):
Critici van de microservice-architectuur zeggen dat testen en ontwikkelen moeilijk zijn. Dit is logisch als het ingewikkeld wordt. Met welke uitdagingen werd uw team geconfronteerd en hoe heeft u deze overwonnen? Vraag voor iedereen.
Alexander:
Er zijn problemen bij de overstap van microservices naar een platform, maar deze kunnen worden opgelost.
We maken bijvoorbeeld een product dat uit 5-7 microservices bestaat. We moeten integratietests aanbieden voor de hele microservices-stack om groen licht te geven om naar de master branch te verhuizen. Deze taak was voor ons niet nieuw: we deden dit al lang bij BSS, toen de leverancier ons reeds geleverde oplossingen aanleverde.
En ons probleem zit alleen in het kleine team. Voor één voorwaardelijk product is één QA-engineer nodig. En dus leveren we een product van 5-7 microservices, waarvan er 2-3 door derden kunnen worden ontwikkeld. We hebben bijvoorbeeld een product in de ontwikkeling waaraan onze factureringssysteemleverancier, Mail.ru Group en MegaFon R&D deelnemen. We moeten dit met tests afdekken voordat we het naar productie verzenden. De QA-ingenieur heeft anderhalve maand aan dit product gewerkt en de rest van het team zit zonder zijn steun.
Deze complexiteit wordt alleen veroorzaakt door schaalvergroting. Wij begrijpen dat microservices niet in een vacuüm kunnen bestaan; absolute isolatie bestaat niet. Bij het wisselen van één dienst proberen wij altijd het API-contract te behouden. Als er onder de motorkap iets verandert, blijft de frontservice bestaan. Als de veranderingen fataal zijn, vindt er een soort architecturale transformatie plaats en gaan we over op een compleet ander data-metamodel, dat volledig incompatibel is. Alleen dan praten we over de v2-service-API-specificatie die verschijnt. We ondersteunen de eerste en tweede versie tegelijkertijd, en nadat alle consumenten overstappen naar de tweede versie, sluiten we gewoon de eerste af.
Sergej:
Ik wil toevoegen. Ik ben het absoluut eens over complicaties - ze gebeuren. Het landschap wordt complexer en de overheadkosten stijgen, vooral voor testen. Hoe hiermee om te gaan: stap over op geautomatiseerd testen. Ja, u zult extra moeten investeren in het schrijven van autotests en unittests. Zodat ontwikkelaars zich niet konden binden zonder de test te doorstaan, konden ze de code niet wijzigen. Zodat zelfs de drukknop niet werkt zonder autotest, unit-test.
Het is belangrijk om de oude functionaliteit te behouden, en dit brengt extra overhead met zich mee. Als je een technologie herschrijft naar een ander protocol, dan herschrijf je deze totdat je alles volledig afsluit.
Soms doen we expres niet end-to-end testen, omdat we de ontwikkeling niet willen stoppen, ook al hebben we ook het een na het ander. Het landschap is erg groot, complex, er zijn veel systemen. Soms zijn het maar stompjes - ja, je verlaagt de veiligheidsmarge, er ontstaan meer risico's. Maar tegelijkertijd laat je het aanbod los.
Alexander:
Ja, met autotests en unittests kunt u een hoogwaardige dienstverlening creëren. Wij zijn voor een pijplijn die niet kan worden doorstaan zonder unit- en integratietests. Vaak moeten we emulators en commerciële systemen naar testzones en ontwikkelomgevingen slepen, omdat niet alle systemen in testzones geplaatst kunnen worden. Bovendien worden ze niet alleen nat: we genereren een volwaardige reactie van het systeem. Dit is een serieus onderdeel van het werken met microservices en we investeren er ook in. Zonder dit zal er chaos ontstaan.
Vraag uit het publiek (3):
Voor zover ik het begrijp, zijn microservices aanvankelijk vanuit een apart team gegroeid en bestaan ze nu in dit model. Wat zijn de voor- en nadelen ervan?
Wij hebben net een soortgelijk verhaal: er ontstond een soort microservicesfabriek. Nu zijn we conceptueel op het punt gekomen dat we deze benadering uitbreiden naar productie via stromen en via systemen. Met andere woorden: we stappen af van de gecentraliseerde ontwikkeling van microservices, microservicemodellen, en komen steeds dichter bij systemen.
Dienovereenkomstig gaat onze operatie ook naar systemen, dat wil zeggen dat we dit onderwerp decentraliseren. Wat is uw aanpak en wat is uw doelverhaal?
Alexander:
Je hebt de naam ‘microservices fabriek’ zo uit je mond laten vallen – we willen ook opschalen. Ten eerste hebben we nu echt één team. We willen alle ontwikkelingsteams waarover MegaFon beschikt de mogelijkheid bieden om in een gemeenschappelijk ecosysteem te werken. We willen niet alle ontwikkelfunctionaliteit die we nu hebben volledig overnemen. De lokale taak is om op te schalen, de globale taak is om de ontwikkeling naar alle teams in de microservicelaag te leiden.
Sergej:
Ik zal je vertellen welk pad we hebben gevolgd. We zijn echt als één team gaan werken, maar nu zijn we niet alleen. Ik ben voorstander van het volgende: er moet een eigenaar zijn van het proces. Iemand moet het ontwikkelingsproces van microservices begrijpen, beheren, controleren en bouwen. Hij moet eigenaar zijn van hulpbronnen en zich bezighouden met hulpbronnenbeheer.
Deze bronnen, die technologieën en details kennen en begrijpen hoe microservices moeten worden gebouwd, kunnen in productteams worden ondergebracht. We hebben een mix waarbij mensen van het microserviceplatform in het productteam zitten dat de mobiele applicatie maakt. Ze zijn er wel, maar werken volgens het proces van de afdeling microserviceplatformbeheer met hun ontwikkelingsmanager. Binnen deze divisie is er een apart team dat zich bezighoudt met techniek. Dat wil zeggen: we mengen een gemeenschappelijke voorraad middelen onder elkaar, verdelen deze en geven ze aan teams.
Tegelijkertijd blijft het proces algemeen en gecontroleerd, het verloopt volgens algemene technologische principes, met unit-tests enzovoort - alles wat daar bovenop is gebouwd. Er kunnen kolommen zijn in de vorm van bronnen die zijn verzameld uit verschillende afdelingen van de productbenadering.
Alexander:
Sergey, jij bent eigenlijk de eigenaar van het proces, toch? Wordt de taakachterstand gedeeld? Wie is verantwoordelijk voor de distributie ervan?
Sergej:
Kijk: hier is de mix nog een keer. Er is een achterstand die wordt gevormd op basis van technologische verbeteringen - dit is één verhaal. Er is een achterstand, die wordt geformuleerd vanuit projecten, en er is een achterstand vanuit producten. Maar de volgorde van introductie in elk van de serviceproducten of de creatie van deze service wordt ontwikkeld door een productspecialist. Hij zit niet in de IT-directie; hij is er speciaal uit verwijderd. Maar mijn mensen werken zeker volgens hetzelfde proces.
De eigenaar van de achterstand in verschillende richtingen - de achterstand van veranderingen - zullen verschillende mensen zijn. De verbinding van technologische diensten, hun organiserende principe - dit alles zal in IT plaatsvinden. Ik ben ook eigenaar van het platform en de bronnen. Bovenaan staat wat de achterstand en functionele veranderingen betreft, en de architectuur in deze zin.
Laten we zeggen dat een bedrijf zegt: "We willen deze functie, we willen een nieuw product creëren - een lening opnieuw maken." Wij antwoorden: “Ja, we zullen het opnieuw doen.” Architecten zeggen: “Laten we eens nadenken: waar in de lening gaan we microservices schrijven en hoe gaan we dat doen?” Vervolgens splitsen we het op in projecten, producten of een technologiestapel, plaatsen het in teams en implementeren het. Heeft u intern een product gemaakt en besloten om microservices in dit product te gebruiken? Wij zeggen: “Nu moeten de oude systemen die we hadden, of frontlijnsystemen, overschakelen naar deze microservices.” De architecten zeggen: “Dus: in de technologische achterstand binnen de frontlinieproducten – de overgang naar microservices. Gaan". En productspecialisten of bedrijfseigenaren begrijpen hoeveel capaciteit wordt toegewezen, wanneer dit zal gebeuren en waarom.
Het einde van de discussie, maar niet alles
De mailto:CLOUD conferentie werd georganiseerd .
We doen ook andere evenementen - b.v. @Kubernetes Meetup, waar we altijd op zoek zijn naar geweldige sprekers:
- Volg @Kubernetes en ander @Meetup-nieuws in ons Telegram-kanaal
- Interesse om te spreken op een van de @Meetups? Laat een verzoek achter voor
Bron: www.habr.com