Me Mail.ru Groupissa pidimme 25. huhtikuuta konferenssin pilvistä ja sen ympäristöstä - . Muutama kohokohta:
- Pää — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center ja Yandex.Cloud puhuivat pilvimarkkinamme erityispiirteistä ja palveluistaan;
- Kollegat Bitrix24:stä kertoivat kuinka he ;
- Leroy Merlin, Otkritie, Burger King ja Schneider Electric tarjosivat mielenkiintoisia — mitä tehtäviä heidän liiketoimintansa asettaa IT:lle ja mitä teknologioita, mukaan lukien pilviteknologiat, he pitävät lupaavimpana.
Voit katsoa kaikki videot mailto:CLOUD-konferenssista , ja täältä voit lukea kuinka keskustelu mikropalveluista eteni. MegaFonin liiketoimintajärjestelmien tutkimus- ja kehityskeskuksen johtaja Alexander Deulin ja M.Video-Eldorado-konsernin tietotekniikkajohtaja Sergey Sergeev jakoivat onnistuneita tapauksiaan monoliiteista eroon pääsemiseksi. Keskustelimme myös IT-strategiaan, prosesseihin ja jopa HR:ään liittyvistä aiheista.
Panelistit
- Sergei Sergeev, konsernin tietohallintojohtaja "M.Video-Eldorado";
- Aleksanteri Deulin, liiketoimintajärjestelmien tutkimus- ja kehityskeskuksen johtaja MegaFon;
- Moderaattori - Dmitri Lazarenko, PaaS-suunnan johtaja Mail.ru Pilviratkaisut.
Alexander Deulinin puheen jälkeen hänen kanssaan keskusteluun osallistuvat Sergey Sergeev M.Video-Eldoradosta ja keskustelun moderaattori Dmitry Lazarenko, Mail.ru Cloud Solutions.
Alla olemme laatineet sinulle keskustelun tekstin, mutta voit myös katsoa videon:
Siirtyminen mikropalveluihin on vastaus markkinoiden tarpeisiin
Dmitri:
Onko sinulla ollut onnistuneita kokemuksia siirtymisestä mikropalveluihin? Ja ylipäätään: missä näette suurimman yrityshyödyn mikropalvelujen käytöstä tai siirtymisestä monoliitteistä mikropalveluihin?
Sergey:
Olemme jo edenneet siirtymisessämme mikropalveluihin ja olemme käyttäneet tätä lähestymistapaa yli kolme vuotta. Ensimmäinen mikropalveluiden tarpeen perustellut tarve oli erilaisten front-end-tuotteiden loputon integrointi taustatoimistoon. Ja joka kerta meidän oli pakko tehdä lisäintegraatiota ja -kehitystä toteuttamalla omia sääntöjämme tämän tai tuon palvelun toiminnalle.
Jossain vaiheessa ymmärsimme, että meidän on nopeutettava järjestelmien toimintaa ja toiminnallisuuden tuottamista. Tuolloin markkinoilla oli jo olemassa sellaisia konsepteja kuin mikropalvelut ja mikropalvelulähestymistapa, ja päätimme kokeilla sitä. Tämä alkoi vuonna 2016. Sitten alusta luotiin ja ensimmäiset 10 palvelua toteutettiin erillisen tiimin toimesta.
Yksi ensimmäisistä, eniten kuormitetuista palveluista oli hintalaskentapalvelu. Joka kerta kun tulet jollekin kanavalle, M.Video-Eldorado-yritysryhmään, olipa kyseessä verkkosivusto tai vähittäiskauppa, valitse sieltä tuote, katso hinta nettisivuilta tai "Korista", hinta lasketaan automaattisesti yhden palvelun mukaan laskettuna. Miksi tämä on tarpeen: ennen tätä jokaisella järjestelmällä oli omat periaatteensa kampanjoiden kanssa työskennellä - alennuksilla ja niin edelleen. Back office hoitaa hinnoittelun, alennustoiminto on toteutettu toisessa järjestelmässä. Tämä piti keskittää ja luoda liiketoimintaprosessin muodossa ainutlaatuinen, erotettavissa oleva palvelu, joka mahdollistaisi tämän toteuttamisen. Suunnilleen näin aloitimme.
Ensimmäisten tulosten arvo oli erittäin suuri. Ensinnäkin pystyimme luomaan erotettavia kokonaisuuksia, joiden avulla voimme työskennellä erikseen ja koottuna. Toiseksi olemme vähentäneet omistuskustannuksia integroimalla useampiin järjestelmiin.
Viimeisten kolmen vuoden aikana olemme lisänneet kolme etulinjajärjestelmää. Niitä oli vaikea ylläpitää samoilla resursseilla kuin yrityksellä oli varaa. Tästä syystä syntyi tehtävä etsiä uusia toimipisteitä, jotka vastaavat markkinoita nopeudella, sisäisillä kustannuksilla ja tehokkuudella.
Kuinka mitata mikropalveluihin siirtymisen onnistumista
Dmitri:
Miten mikropalveluihin siirtymisen onnistuminen määräytyy? Mikä oli "ennen" kussakin yrityksessä? Mitä mittaria käytit siirtymän onnistumisen määrittämiseen ja kuka sen itse asiassa määritti?
Sergey:
Ensinnäkin se syntyi IT:ssä mahdollistajaksi - "avaa" uusia ominaisuuksia. Meillä oli tarve tehdä kaikki nopeammin suhteellisen samalla rahalla markkinoiden haasteisiin vastaamiseksi. Nyt menestys näkyy eri järjestelmien uudelleenkäytettävien palvelujen määrässä, prosessien yhtenäistämisessä keskenään. Nyt se on, mutta sillä hetkellä oli mahdollisuus luoda alusta ja vahvistaa hypoteesi, että voimme tehdä tämän, se antaa vaikutuksen ja laskee liiketoimintamallin.
Alexander:
Menestys on pikemminkin sisäinen tunne. Liiketoiminta haluaa aina enemmän, ja tilauskannan syvyys on todiste menestyksestä. Minusta näyttää siltä.
Sergey:
Kyllä olen samaa mieltä. Kolmessa vuodessa meillä on jo yli kaksisataa palvelua ja tilauskanta. Resurssien tarve tiimissä vain kasvaa - 30 % vuosittain. Tämä tapahtuu, koska ihmiset tunsivat: se on nopeampaa, se on erilaista, on olemassa erilaisia tekniikoita, kaikki tämä kehittyy.
Mikropalvelut tulevat, mutta ydin jää
Dmitri:
Se on kuin loputon prosessi, jossa panostat kehitykseen. Onko siirtyminen yritysten mikropalveluihin jo ohi vai ei?
Sergey:
Siihen on erittäin helppo vastata. Mitä mieltä olet: puhelimien vaihtaminen on loputon prosessi? Ostamme itse puhelimia joka vuosi. Ja tässä se on: niin kauan kuin tarvitaan nopeutta, markkinoille sopeutumista, joitain muutoksia tarvitaan. Tämä ei tarkoita, että hylkäämme standardiasioita.
Emme kuitenkaan voi kattaa ja tehdä uudelleen kaikkea kerralla. Meillä on vanhat standardiintegraatiopalvelut, jotka olivat olemassa aiemmin: yritysbussit ja niin edelleen. Mutta ruuhkaa on ja myös tarvetta. Mobiilisovellusten määrä ja niiden toimivuus kasvavat. Samaan aikaan kukaan ei sano, että sinulle annetaan 30% enemmän rahaa. Toisin sanoen toisaalta aina on tarpeita ja toisaalta tehokkuuden etsintää.
Dmitri:
Elämä on hyvässä kunnossa. (nauraa)
Alexander:
Yleisesti ottaen kyllä. Meillä ei ole vallankumouksellisia lähestymistapoja ydinosan poistamiseen maisemasta. Meneillään on systemaattinen työ järjestelmien hajottamiseksi niin, että ne ovat johdonmukaisempia mikropalveluarkkitehtuurin kanssa, järjestelmien keskinäisen vaikutuksen vähentämiseksi.
Mutta aiomme säilyttää ydinosan, koska operaattorin maisemassa tulee aina olemaan joitain alustoja, joita ostamme. Tarvitsemme jälleen terveen tasapainon: meidän ei pitäisi kiirehtiä leikkaamaan ydintä pois. Asetamme järjestelmät vierekkäin, ja nyt käy ilmi, että olemme jo monen ydinosan päällä. Lisäksi toiminnallisuutta kehittämällä luomme tarvittavat esitykset kaikille viestintäpalveluidemme kanssa toimiville kanaville.
Kuinka myydä mikropalveluita yrityksille
Dmitri:
Olen myös kiinnostunut - niille, jotka eivät ole vaihtaneet, mutta suunnittelevat: kuinka helppoa tämän idean myyminen yrityksille oli ja oliko se seikkailu, investointiprojekti? Vai oliko se tietoinen strategia: nyt siirrymme mikropalveluihin ja siinä kaikki, mikään ei estä meitä. Miten se oli sinulle?
Sergey:
Emme myyneet lähestymistapaa, vaan liiketoimintaetua. Liiketoiminnassa oli ongelma, ja yritimme ratkaista sen. Tuolloin se ilmaistui siinä, että eri kanavat käyttivät erilaisia hintojen laskentaperiaatteita - erikseen kampanjoille, kampanjoille ja niin edelleen. Sitä oli vaikea ylläpitää, tapahtui virheitä ja kuuntelimme asiakkaiden valituksia. Eli myymme ratkaisua ongelmaan, mutta tulimme siihen tosiasiaan, että tarvitsimme rahaa alustan luomiseen. Ja he esittelivät liiketoimintaa esimerkkinä investointien ensimmäisestä vaiheesta: kuinka saamme sen takaisin ja mitä tämä antaa meille mahdollisuuden.
Dmitri:
Tallensitko jotenkin ensimmäisen vaiheen ajan?
Sergey:
Toki. Varasimme 6 kuukautta ytimen luomiseen alustana ja pilotin testaamiseen. Tänä aikana yritimme luoda alustan, jolla lentäjän luistelimme. Sitten hypoteesi vahvistettiin, ja koska se toimii, se tarkoittaa, että voimme jatkaa. He alkoivat kopioida ja vahvistaa joukkuetta - he siirsivät sen erilliseen divisioonaan, joka tekee juuri sitä.
Seuraavaksi tulee systemaattinen työ, joka perustuu liiketoiminnan tarpeisiin, mahdollisuuksiin, resurssien saatavuuteen ja kaikkeen, mikä tällä hetkellä on työn alla.
Dmitri:
OK. Alexander, mitä sanot?
Alexander:
Mikropalvelumme syntyivät "meren vaahdosta" - resurssien säästämisen, palvelinkapasiteetin ylijäämien ja tiimin sisäisten voimien uudelleenjaon vuoksi. Aluksi emme myyneet tätä projektia yrityksille. Tämä oli projekti, jossa sekä tutkimme että kehitimme sen mukaisesti. Aloitimme vuoden 2018 alussa ja kehitimme tätä suuntaa yksinkertaisesti innostuneesti. Myynti on juuri alkanut ja olemme prosessissa.
Dmitri:
Onko mahdollista, että yritys sallii sinun tehdä sellaisia asioita, kuten Google - yhtenä vapaapäivänä viikossa? Onko sinulla sellainen suunta?
Alexander:
Tutkimuksen kanssa käsiteltiin myös liiketoiminnan ongelmia, joten kaikki mikropalvelumme ovat ratkaisuja liiketoiminnan ongelmiin. Vasta alussa rakensimme mikropalveluita, jotka kattoivat pienen osan tilaajakannasta, ja nyt olemme läsnä lähes kaikissa lippulaivatuotteissa.
Ja aineellinen vaikutus on jo selvä - meidät voidaan jo laskea, tuotteiden lanseerausten nopeutta ja tulonmenetyksiä voidaan arvioida, jos olisimme seuranneet vanhaa polkua. Tähän rakennamme tapausta.
Mikropalvelut: hype vai välttämättömyys?
Dmitri:
Numerot ovat numeroita. Ja tulot tai säästetyt rahat ovat erittäin tärkeitä. Mitä jos katsoisit toiselta puolelta? Vaikuttaa siltä, että mikropalvelut ovat trendi, hype ja monet yritykset käyttävät sitä väärin? Kuinka selvästi erotat sen, mitä teet ja mitä et käännä mikropalveluiksi? Jos perintö nyt, onko sinulla vielä perintöä 5 vuoden kuluttua? Minkä ikäisiä M.Video-Eldoradolla ja MegaFonilla toimivat tietojärjestelmät ovat 5 vuoden kuluttua? Tuleeko kymmenen, viisitoista vuotta vanhoja tietojärjestelmiä vai tuleeko se uusi sukupolvi? Miten näet tämän?
Sergey:
Minusta tuntuu, että on vaikea ajatella kovin kauas. Jos katsomme taaksepäin, kuka kuvitteli teknologiamarkkinoiden kehittyvän tällä tavalla, mukaan lukien koneoppiminen ja käyttäjän kasvojen tunnistaminen? Mutta jos katsoo tulevia vuosia, minusta näyttää siltä, että ydinjärjestelmät, yritysten ERP-luokan järjestelmät yrityksissä - ne ovat toimineet melko pitkään.
Yrityksemme ovat yhdessä 25 vuotta vanhoja, ja niissä on klassinen ERP erittäin syvällä järjestelmämaailmassa. On selvää, että otamme sieltä joitain paloja ja yritämme koota ne mikropalveluiksi, mutta ydin säilyy. Minun on nyt vaikea kuvitella, että vaihdamme siellä kaikki ydinjärjestelmät ja siirrymme nopeasti uusien järjestelmien toiselle, valoisalle puolelle.
Kannatan sitä, että kaikki, mikä on lähempänä asiakasta ja kuluttajaa, on siellä, missä on suurin liiketoiminnallinen hyöty ja arvo, missä sopeutumiskyky ja keskittyminen nopeuteen, muutokseen, "kokeile, peruuta, käytä uudelleen, tee jotain toisin" ovat. tarvitaan "- siellä maisema muuttuu. Ja laatikkotuotteet eivät sovi sinne kovin hyvin. Emme ainakaan näe sitä. Siellä tarvitaan helpoimpia ja yksinkertaisimpia ratkaisuja.
Näemme tämän kehityksen:
- ydintietojärjestelmät (enimmäkseen back office);
- keskikerrokset mikropalvelujen muodossa yhdistävät ytimen, yhdistävät, luovat välimuistin ja niin edelleen;
- etulinjan järjestelmät on suunnattu kuluttajalle;
- integraatiokerros, joka on yleensä integroitu markkinapaikkoihin, muihin järjestelmiin ja ekosysteemeihin. Tämä kerros on mahdollisimman kevyt, yksinkertainen ja sisältää vähän liiketoimintalogiikkaa.
Mutta samalla kannatan vanhojen periaatteiden käytön jatkamista, jos niitä käytetään asianmukaisesti.
Oletetaan, että sinulla on klassinen yritysjärjestelmä. Se sijaitsee yhden toimittajan maisemassa ja koostuu kahdesta moduulista, jotka toimivat keskenään. Siellä on myös standardi integrointirajapinta. Miksi tehdä se uudelleen ja tuoda mikropalvelu sinne?
Mutta kun taustatoimistossa on 5 moduulia, joista kerätään tietoa liiketoimintaprosessiin, jota sitten käyttää 8-10 etulinjan järjestelmää, hyöty on heti havaittavissa. Otat viidestä taustatoimistojärjestelmästä ja luot palvelun, erillisen, joka keskittyy liiketoimintaprosessiin. Tee palvelusta teknisesti edistyksellinen - niin, että se tallentaa tiedot välimuistiin ja on vikasietoinen ja toimii myös asiakirjojen tai yrityskokonaisuuksien kanssa. Ja integroit sen yhden periaatteen mukaisesti kaikkiin etulinjan tuotteisiin. He peruuttivat etulinjan tuotteen - he yksinkertaisesti sammuttivat integroinnin. Huomenna sinun täytyy kirjoittaa mobiilisovellus tai tehdä pieni verkkosivusto ja laittaa vain yksi osa toimivuuteen - kaikki on yksinkertaista: kokosit sen kuin rakentaja. Näen kehitystä tähän suuntaan - ainakin meidän maassamme.
Alexander:
Sergey kuvaili täysin lähestymistapaamme, kiitos. Sanon vain, mihin emme todellakaan mene - ydinosaan, verkkolaskutuksen aiheeseen. Eli luokitus ja veloitus pysyvät itse asiassa "isona" puimakoneena, joka poistaa rahat luotettavasti. Ja tämän järjestelmän sertifioivat edelleen sääntelyviranomaisemme. Kaikki muu, mikä katsotaan asiakkaisiin, on tietysti mikropalveluita.
Dmitri:
Tässä sertifiointi on yksi tarina. Varmaan enemmän tukea. Jos käytät vähän tukea tai järjestelmä ei vaadi tukea ja muutoksia, on parempi olla koskematta siihen. Kohtuullinen kompromissi.
Kuinka kehittää luotettavia mikropalveluita
Dmitri:
Hieno. Mutta olen silti kiinnostunut. Nyt kerrot menestystarinan: kaikki oli hyvin, siirryimme mikropalveluihin, puolustimme ideaa yritykselle ja kaikki sujui. Mutta olen kuullut muitakin tarinoita.
Pari vuotta sitten sveitsiläinen yritys, joka oli investoinut kaksi vuotta uuden pankkien mikropalvelualustan kehittämiseen, päätti lopulta projektin. Täysin romahtanut. Useita miljoonia Sveitsin frangeja käytettiin, ja lopulta joukkue hajosi - se ei toiminut.
Onko sinulla ollut vastaavia tarinoita? Oliko tai onko vaikeuksia? Esimerkiksi mikropalvelujen ja valvonnan ylläpito on myös päänsärky yrityksen operatiivisessa toiminnassa. Loppujen lopuksi komponenttien määrä kasvaa kymmeniä kertoja. Miten näet, onko täällä ollut esimerkkejä epäonnistuneista investoinneista? Ja mitä voit neuvoa ihmisille, jotta he eivät kohtaa tällaisia ongelmia?
Alexander:
Epäonnistuneita esimerkkejä olivat yritykset, jotka muuttivat prioriteetteja ja peruivat projekteja. Hyvässä valmiusvaiheessa (itse asiassa MVP on valmis), yritys sanoi: "Meillä on uudet prioriteetit, siirrymme toiseen projektiin ja lopetamme tämän."
Meillä ei ollut globaaleja vikoja mikropalvelujen kanssa. Nukumme rauhassa, meillä on 24/7 päivystysvuoro, joka palvelee koko BSS:ää [liiketoiminnan tukijärjestelmä].
Ja vielä yksi asia - vuokraamme mikropalveluita laatikkotuotteita koskevien sääntöjen mukaisesti. Menestyksen avain on, että sinun on ensin koottava tiimi, joka valmistelee mikropalvelun täysin tuotantoa varten. Itse kehitys on ehdollisesti 40 %. Loput ovat analytiikkaa, DevSecOps-metodologiaa, oikeat integraatiot ja oikea arkkitehtuuri. Kiinnitämme erityistä huomiota turvallisten sovellusten rakentamisen periaatteisiin. Tietoturvan edustajat osallistuvat jokaiseen projektiin sekä arkkitehtuurin suunnitteluvaiheessa että toteutusprosessissa. He myös hallinnoivat järjestelmiä haavoittuvuuksien analysoimiseksi.
Oletetaan, että otamme käyttöön kansalaisuudettomat palvelumme – meillä on ne Kubernetesissa. Näin kaikki voivat nukkua rauhassa palvelujen automaattisen skaalauksen ja automaattisen nostamisen ansiosta, ja päivystys poimii tapauksia.
Koko mikropalveluidemme olemassaolon aikana on vain yksi tai kaksi tapausta, jotka ovat päässeet linjallemme. Nyt käytössä ei ole ongelmia. Meillä ei tietenkään ole 200, vaan noin 50 mikropalvelua, mutta niitä käytetään lippulaivatuotteissa. Jos he epäonnistuvat, saisimme siitä ensimmäisenä tietää.
Mikropalvelut ja HR
Sergey:
Olen kollegani kanssa samaa mieltä tukiin siirtymisestä - siitä, että työ on organisoitava oikein. Mutta kerron teille ongelmista, joita tietysti on.
Ensinnäkin tekniikka on uutta. Tämä on hyvällä tavalla hypeä, ja tämän ymmärtävän ja luovan asiantuntijan löytäminen on iso haaste. Kilpailu resursseista on hullua, joten asiantuntijat ovat kullan arvoisia.
Toiseksi tiettyjen maisemien luomisen ja palveluiden lisääntymisen myötä uudelleenkäytön ongelmaa on jatkuvasti ratkaistava. Kuten kehittäjät haluavat tehdä: "Kirjoitetaanpa tänne nyt paljon mielenkiintoisia asioita..." Tämän vuoksi järjestelmä kasvaa ja menettää tehokkuutensa rahassa, omistuskustannuksissa ja niin edelleen. Eli uudelleenkäyttö on tarpeen sisällyttää järjestelmäarkkitehtuuriin, sisällyttää se tiekarttaan palveluiden käyttöönottamiseksi ja perinnön siirtämiseksi uuteen arkkitehtuuriin.
Toinen ongelma - vaikka tämä on omalla tavallaan hyvä - on sisäinen kilpailu. "Voi, tänne on ilmestynyt uusia muodikkaita miehiä, he puhuvat uutta kieltä." Ihmiset ovat tietysti erilaisia. On niitä, jotka ovat tottuneet kirjoittamaan Javalla, ja niitä, jotka kirjoittavat ja käyttävät Dockeria ja Kubernetesia. Nämä ovat täysin erilaisia ihmisiä, he puhuvat eri tavalla, käyttävät eri termejä eivätkä joskus ymmärrä toisiaan. Kyky tai kyvyttömyys jakaa käytäntöjä, tiedon jakamista, tässä mielessä on myös ongelma.
No, skaalataan resursseja. "Hienoa mennään! Ja nyt haluamme nopeammin, enemmän. Mitä, et voi? Eikö ole mahdollista toimittaa kaksi kertaa niin paljon vuodessa? Ja miksi?" Tällaiset kasvukivut ovat luultavasti standardi monille asioille, monille lähestymistavoille, ja voit tuntea ne.
Mitä tulee seurantaan. Minusta näyttää siltä, että palvelut tai teollisuuden valvontatyökalut ovat jo oppimassa tai pystyvät toimimaan sekä Dockerin että Kubernetesin kanssa eri, ei-standarditilassa. Jotta et esimerkiksi päädy 500 Java-koneeseen, joiden alla kaikki tämä toimii, eli se aggregoituu. Mutta näiltä tuotteilta puuttuu vielä kypsyys, niiden on käytävä läpi tämä. Aihe on todella uusi, se kehittyy edelleen.
Dmitri:
Kyllä, erittäin mielenkiintoista. Ja tämä koskee HR:ää. Ehkä HR-prosessisi ja HR-brändisi ovat muuttuneet hieman näiden kolmen vuoden aikana. Aloit rekrytoida muita ihmisiä, joilla on eri pätevyys. Ja luultavasti on sekä hyviä että huonoja puolia. Aiemmin lohkoketju ja datatiede olivat hype, ja niiden asiantuntijat olivat miljoonien arvoisia. Nyt kustannukset laskevat, markkinat kyllästyvät ja mikropalveluissa on samanlainen trendi.
Sergey:
Kyllä ehdottomasti.
Alexander:
HR kysyy kysymyksen: "Missä on vaaleanpunainen yksisarvisi tausta- ja käyttöliittymän välissä?" HR ei ymmärrä mitä mikropalvelu on. Kerroimme heille salaisuuden ja kerroimme, että taustaosa teki kaiken, eikä yksisarvista ole olemassa. Mutta HR muuttuu, oppii nopeasti ja rekrytoi ihmisiä, joilla on IT-perustiedot.
Mikropalvelujen kehitys
Dmitri:
Jos tarkastellaan kohdearkkitehtuuria, mikropalvelut näyttävät sellaiselta hirviöltä. Matkanne kesti useita vuosia. Toisilla on vuosi, toisilla kolme vuotta. Ennakoitko kaikki ongelmat, kohdearkkitehtuurin, muuttuiko mikään? Esimerkiksi mikropalveluissa yhdyskäytävät ja palveluverkot näkyvät nyt jälleen. Käytitkö niitä alussa vai vaihdoitko itse arkkitehtuuria? Onko sinulla tällaisia haasteita?
Sergey:
Olemme jo kirjoittaneet useita viestintäprotokollia uudelleen. Aluksi oli yksi protokolla, nyt vaihdoimme toiseen. Lisäämme turvallisuutta ja luotettavuutta. Aloitimme yritysteknologioista - Oracle, Web Logic. Nyt ollaan siirtymässä pois teknologisista yritystuotteista mikropalveluissa ja siirtymässä avoimeen lähdekoodiin tai täysin avoimiin teknologioihin. Hylämme tietokannat ja siirrymme siihen, mikä tässä mallissa toimii meille tehokkaammin. Emme enää tarvitse Oracle-tekniikoita.
Aloitimme yksinkertaisesti palveluna, ajattelematta kuinka paljon tarvitsemme välimuistia, mitä tekisimme, kun mikropalveluun ei ole yhteyttä, mutta tarvittiin dataa jne. Nyt kehitämme alustaa, jotta arkkitehtuuria voidaan kuvata ei palvelujen kielellä, ja liikekielellä vie bisneslogiikka uudelle tasolle, kun alamme puhua sanoilla. Nyt on opittu puhumaan kirjaimin, ja seuraava taso on, kun palvelut kerätään jonkinlaiseksi kokonaisuudeksi, kun tämä on jo sana - esimerkiksi kokonainen tuotekortti. Se on koottu mikropalveluista, mutta se on tämän päälle rakennettu API.
Turvallisuus on erittäin tärkeää. Heti kun alat olla tavoitettavissa ja sinulla on palvelu, jonka kautta saat paljon mielenkiintoista, ja hyvin nopeasti, sekunnin murto-osassa, on halu saada se ei kaikkein turvallisimmalla tavalla. Päästäksemme eroon tästä meidän oli muutettava lähestymistapaa testaukseen ja seurantaan. Jouduimme muuttamaan tiimiä, toimitusjohtamisrakennetta, CI/CD:tä.
Tämä on evoluutio - kuten puhelimien kanssa, vain paljon nopeampaa: ensin syntyi painonapin puhelimet, sitten älypuhelimet. He kirjoittivat ja suunnittelivat tuotteen uudelleen, koska markkinoilla oli erilainen tarve. Näin me kehitymme: ensimmäinen luokka, kymmenes luokka, työ.
Iteratiivisesti hahmotellaan vuodessa jotain tekniikan näkökulmasta, jotain muuta ruuhkan ja tarpeiden näkökulmasta. Yhdistämme yhden asian toiseen. Tiimi käyttää 20 % tekniseen velkaan ja tekniseen tukeen tiimille, 80 % liiketoimintakokonaisuuteen. Ja ymmärrämme, miksi teemme niin, miksi teemme näitä teknisiä parannuksia ja mihin ne johtavat. niin.
Dmitri:
Viileä. Mitä MegaFonissa on?
Alexander:
Suurin haaste, kun tulimme mikropalveluihin, oli olla kaaos. MegaFonin arkkitehtitoimisto liittyi heti joukkoomme, siitä tuli jopa aloitteentekijä ja kuljettaja - nyt meillä on erittäin vahva arkkitehtuuri. Hänen tehtävänsä oli ymmärtää, mihin kohdemalliin olemme menossa ja mitä teknologioita pitää pilotoida. Arkkitehtuurin osalta teimme nämä pilotit itse.
Seuraava kysymys oli: "Kuinka sitten hyödyntää kaikkea tätä?" Ja vielä yksi: "Miten varmistetaan läpinäkyvä vuorovaikutus mikropalvelujen välillä?" Palveluverkko auttoi meitä vastaamaan viimeiseen kysymykseen. Pilotimme Istiota ja pidimme tuloksista. Nyt olemme siirtymässä tuotantoalueille. Suhtaudumme positiivisesti kaikkiin haasteisiin - siihen, että meidän on jatkuvasti vaihdettava pinoa, opittava jotain uutta. Olemme kiinnostuneita kehittämään, emme hyödyntämään vanhoja ratkaisuja.
Dmitri:
Kultaiset sanat! Tällaiset haasteet pitävät tiimin ja yrityksen varpaillaan ja luovat tulevaisuutta. GDPR loi tietosuojavastaavat, ja nykyiset haasteet luovat mikropalvelu- ja arkkitehtuuripäälliköt. Ja se miellyttää.
Keskustelimme paljon. Tärkeintä on, että hyvä mikropalvelujen suunnittelu ja itse arkkitehtuuri mahdollistavat monien virheiden välttämisen. Prosessi on tietysti iteratiivinen ja evoluutionaalinen, mutta se on tulevaisuutta.
Kiitos kaikille osallistujille, kiitos Sergeille ja Alexanderille!
Kysymyksiä yleisöltä
Kysymys yleisöltä (1):
Sergey, miten IT-johtaminen on muuttunut yrityksessäsi? Ymmärrän, että kun useita järjestelmiä on suuri pino, sen hallinta on melko selkeä ja looginen prosessi. Miten rakensit IT-komponentin hallinnan uudelleen sen jälkeen, kun hyvin suuri määrä mikropalveluita integroitiin niin lyhyessä ajassa?
Sergey:
Olen samaa mieltä kollegani kanssa siitä, että arkkitehtuuri on erittäin tärkeä muutoksen veturina. Aloitimme perustamalla arkkitehtiosaston. Arkkitehdit ovat samanaikaisesti toiminnallisuuden jakelun ja sen maisemaan näyttäytymisen vaatimusten omistajia. He toimivat siis myös näiden muutosten koordinaattoreina. Tämän seurauksena tiettyyn toimitusprosessiin tehtiin erityisiä muutoksia, kun loimme CI/CD-alustan.
Mutta standardia, kehittämisen perusperiaatteita, liiketoiminta-analyysiä, testausta ja kehitystä ei ole peruttu. Lisäsimme vain nopeutta. Aikaisemmin sykli vei niin paljon, asennus testiympäristöihin vei paljon enemmän. Nyt liike näkee hyödyn ja sanoo: "Miksi emme voi tehdä samaa muissa paikoissa?"
Se on hyvällä tavalla kuin injektio rokotteen muodossa, joka osoitti: voit tehdä sen tällä tavalla, mutta voit tehdä sen toisin. Tietysti ongelma on henkilöstössä, pätevyyksissä, tiedossa, vastustuksessa.
Kysymys yleisöltä (2):
Mikropalveluarkkitehtuurin kriitikot sanovat, että testaus ja kehittäminen ovat vaikeita. Tämä on loogista, jos asiat monimutkaistuvat. Millaisia haasteita tiimisi kohtasi ja miten selvisit niistä? Kysymys kaikille.
Alexander:
Mikropalveluista alustalle siirtymisessä on vaikeuksia, mutta ne voidaan ratkaista.
Teemme esimerkiksi tuotteen, joka koostuu 5-7 mikropalvelusta. Meidän on tarjottava integrointitestejä koko mikropalvelupinolle, jotta voimme antaa vihreää valoa siirtyä päähaaraan. Tämä tehtävä ei ollut meille uusi: olimme tehneet tätä pitkään BSS:llä, kun toimittaja toimitti meille jo toimitettuja ratkaisuja.
Ja ongelmamme on vain pienessä joukkueessa. Yhtä ehdollista tuotetta varten tarvitaan yksi laadunvarmistusinsinööri. Ja niin, toimitamme tuotteen 5-7 mikropalvelusta, joista 2-3 voi olla kolmansien osapuolien kehittämiä. Meillä on esimerkiksi tuote, jonka kehittämiseen osallistuvat laskutusjärjestelmän toimittajamme Mail.ru Group ja MegaFon R&D. Meidän on tehtävä tämä testeillä ennen sen lähettämistä tuotantoon. Laadunvarmistusinsinööri on työskennellyt tämän tuotteen parissa puolitoista kuukautta, ja muu tiimi on jäänyt ilman hänen tukeaan.
Tämä monimutkaisuus johtuu vain skaalauksesta. Ymmärrämme, että mikropalvelut eivät voi olla olemassa tyhjiössä; absoluuttista eristäytymistä ei ole olemassa. Yhtä palvelua vaihdettaessa pyrimme aina säilyttämään API-sopimuksen. Jos konepellin alla jotain muuttuu, etuhuolto säilyy. Jos muutokset ovat kohtalokkaita, tapahtuu jonkinlainen arkkitehtoninen muutos ja siirrytään täysin toiseen datametamalliin, joka on täysin yhteensopimaton - vasta sitten puhutaan v2-palvelun API-spesifikaatiosta. Tuemme ensimmäistä ja toista versiota samanaikaisesti, ja kun kaikki kuluttajat ovat siirtyneet toiseen versioon, suljemme yksinkertaisesti ensimmäisen.
Sergey:
Haluan lisätä. Olen täysin samaa mieltä komplikaatioista - niitä tapahtuu. Maisema muuttuu monimutkaisemmaksi, ja yleiskustannukset nousevat, etenkin testaamisesta. Kuinka käsitellä tätä: vaihda automaattiseen testaukseen. Kyllä, sinun on panostettava lisäksi automaattisten ja yksikkötestien kirjoittamiseen. Jotta kehittäjät eivät voineet sitoutua läpäisemättä testiä, he eivät voineet muuttaa koodia. Jotta edes painike ei toimi ilman automaattista testiä, yksikkötestiä.
On tärkeää säilyttää aiemmat toiminnot, ja tämä on lisäkustannuksia. Jos kirjoitat tekniikan uudelleen toiseen protokollaan, kirjoitat sitä uudelleen, kunnes suljet kaiken kokonaan.
Emme toisinaan tee päästä päähän -testausta tarkoituksella, koska emme halua pysäyttää kehitystä, vaikka meilläkin on asioita toisensa jälkeen. Maisema on erittäin suuri, monimutkainen, järjestelmiä on monia. Joskus se on vain tynkä - kyllä, alennat turvamarginaalia, lisää riskejä. Mutta samalla vapautat tarjonnan.
Alexander:
Kyllä, autotesteillä ja yksikkötesteillä voit luoda laadukkaan palvelun. Haluamme putkilinjan, jota ei voida läpäistä ilman yksikkö- ja integrointitestejä. Usein joudumme vetäämään emulaattoreita ja kaupallisia järjestelmiä testivyöhykkeisiin ja kehitysympäristöihin, koska kaikkia järjestelmiä ei voi sijoittaa testivyöhykkeille. Lisäksi ne eivät vain kastu – luomme järjestelmältä täyden vastauksen. Tämä on vakava osa mikropalveluiden parissa työskentelemistä, ja siihen myös panostetaan. Ilman tätä syntyy kaaos.
Kysymys yleisöltä (3):
Ymmärtääkseni mikropalvelut kasvoivat alun perin erillisestä tiimistä ja ovat nyt olemassa tässä mallissa. Mitkä ovat sen hyvät ja huonot puolet?
Meillä on vain samanlainen tarina: eräänlainen mikropalvelutehdas syntyi. Nyt olemme käsitteellisesti päässeet siihen pisteeseen, että laajennamme tätä lähestymistapaa tuotantoon virtojen ja järjestelmien mukaan. Toisin sanoen olemme siirtymässä pois keskitetystä mikropalveluiden, mikropalvelumallien kehittämisestä ja lähentymässä järjestelmiä.
Näin ollen toimintamme menee myös järjestelmiin, eli hajautamme tätä aihetta. Mikä on lähestymistapasi ja mikä on kohdetarinasi?
Alexander:
Pudotit nimen "mikropalvelutehdas" suoraan suustasi – haluamme myös skaalata. Ensinnäkin meillä on nyt todella yksi joukkue. Haluamme tarjota kaikille MegaFonin kehitystiimeille mahdollisuuden työskennellä yhteisessä ekosysteemissä. Emme halua ottaa kokonaan haltuumme kaikkia nyt olemassa olevia kehitystoimintoja. Paikallinen tehtävä on skaalata, globaali tehtävänä on johtaa kehitystä kaikille mikropalvelukerroksen tiimeille.
Sergey:
Kerron teille polun, jonka olemme valinneet. Aloimme todella työskennellä yhtenä tiiminä, mutta nyt emme ole yksin. Kannatan seuraavaa: prosessilla on oltava omistaja. Jonkun on ymmärrettävä, hallittava, ohjattava ja rakennettava mikropalvelujen kehitysprosessi. Hänen tulee omistaa resursseja ja osallistua resurssien hallintaan.
Nämä resurssit, jotka tuntevat teknologiat, erityispiirteet ja ymmärtävät kuinka rakentaa mikropalveluita, voidaan sijoittaa tuoteryhmiin. Meillä on sekoitus, jossa mikropalvelualustan ihmiset ovat mobiilisovelluksen tekevässä tuotetiimissä. He ovat siellä, mutta he työskentelevät mikropalvelualustan hallintaosaston prosessin mukaisesti kehitysjohtajansa kanssa. Tässä divisioonassa on erillinen tiimi, joka käsittelee teknologiaa. Toisin sanoen yhdistämme yhteisen resurssien keskenämme ja jaamme ne tiimeille.
Samalla prosessi pysyy yleisenä, kontrolloituna, se etenee yleisten teknisten periaatteiden mukaan, yksikkötestauksella ja niin edelleen - kaiken päälle rakennetun. Saattaa olla sarakkeita resurssien muodossa, jotka on kerätty tuotelähestymistavan eri osastoilta.
Alexander:
Sergey, olet itse asiassa prosessin omistaja, eikö niin? Onko tehtäväruuhka jaettu? Kuka on vastuussa sen jakelusta?
Sergey:
Katso: tässä on taas sekoitus. Teknisten parannusten pohjalta muodostuu ruuhkaa - tämä on yksi tarina. On ruuhkaa, joka muodostuu projekteista, ja on ruuhkaa tuotteista. Mutta kunkin palvelutuotteen käyttöönoton tai tämän palvelun luomisen järjestyksen kehittää tuoteasiantuntija. Hän ei ole IT-osastolla, vaan hänet erotettiin siitä erikseen. Mutta minun ihmiset työskentelevät ehdottomasti saman prosessin mukaan.
Eri suuntien ruuhkan - muutosruuhkan - omistaja tulee olemaan eri ihmisiä. Teknologisten palveluiden yhdistäminen, niiden organisointiperiaate - kaikki tämä tulee olemaan IT:ssä. Omistan myös alustan ja resurssit. Huipulla on se, mikä koskee ruuhkaa ja toiminnallisia muutoksia ja tässä mielessä arkkitehtuuria.
Oletetaan, että yritys sanoo: "Haluamme tämän toiminnon, haluamme luoda uuden tuotteen - lainata uudelleen." Vastaamme: "Kyllä, teemme sen uudelleen." Arkkitehdit sanovat: "Mietitään: mihin lainaan kirjoitamme mikropalvelut ja miten se tehdään?" Jaotamme sen sitten projekteihin, tuotteisiin tai teknologiapinoon, laitamme ryhmiin ja toteutamme sen. Oletko luonut tuotteen sisäisesti ja päättänyt käyttää mikropalveluita tässä tuotteessa? Sanomme: "Nyt meidän vanhojen järjestelmien tai etulinjan järjestelmien on vaihdettava näihin mikropalveluihin." Arkkitehdit sanovat: "Joten: teknologisessa ruuhkassa etulinjan tuotteiden sisällä - siirtyminen mikropalveluihin. Mennä". Ja tuoteasiantuntijat tai yritysten omistajat ymmärtävät, kuinka paljon kapasiteettia on varattu, milloin se tehdään ja miksi.
Keskustelun loppu, mutta ei kaikki
mailto:CLOUD-konferenssi järjestettiin .
Järjestämme myös muita tapahtumia - mm. @Kubernetes Meetup, jossa etsimme aina upeita kaiuttimia:
- Seuraa @Kubernetes ja muita @Meetup-uutisia Telegram-kanavallamme
- Oletko kiinnostunut puhumaan yhdessä @Meetupsista? Jätä pyyntö
Lähde: will.com