Halusin kirjoittaa artikkelin mikropalveluarkkitehtuurista pitkään, mutta kaksi asiaa pysäytti minut - mitä syvemmälle aiheeseen syvennyin, sitä enemmän minusta tuntui, että se, mitä tiedän, on itsestään selvää ja mitä en t tiedä tarvitsee tutkia ja tutkia. Toisaalta uskon, että laajalla yleisöllä on jo jotain keskusteltavaa. Vaihtoehtoiset mielipiteet ovat siis tervetulleita.
Conwayn laki ja liiketoiminnan, organisaation ja tietojärjestelmän välinen suhde
Jälleen kerran sallin itseni lainata:
"Jokainen organisaatio, joka suunnittelee järjestelmän (laajassa merkityksessä), saa suunnittelun, jonka rakenne jäljittelee organisaation tiimien rakennetta."
- Melvyn Conway, 1967
Mielestäni tämä laki liittyy todennäköisemmin yrityksen organisoinnin toteutettavuuteen kuin suoraan tietojärjestelmään. Selitän esimerkin avulla. Oletetaan, että meillä on melko vakaa liiketoimintamahdollisuus, jonka elinkaaren pituus on niin pitkä, että yrityksen perustaminen on järkevää (tämä ei ole kirjoitusvirhe, mutta pidän todella tästä varastamastani termistä.) Luonnollisesti tämän liiketoiminnan tukijärjestelmä vastaa organisatorisesti ja prosessillisesti tätä liiketoimintaa .
Tietojärjestelmien liiketoimintalähtöisyys
Selitän esimerkin avulla. Oletetaan, että on liiketoimintamahdollisuus perustaa pizzaa myyvä yritys. V1-versiossa (kutsutaanko sitä ennakkotiedoksi) yritys oli pizzeria, kassakone ja jakelupalvelu. Tämä versio oli pitkäikäinen olosuhteissa, joissa ympäristön vaihtelu oli vähäistä. Sitten versio 2 korvasi sen - edistyneemmän ja pystyi käyttämään ytimessä olevaa tietojärjestelmää monoliittisella arkkitehtuurilla. Ja tässä on mielestäni yksinkertaisesti kauhea epäoikeudenmukaisuus suhteessa monoliitteihin - väitetty monoliittinen arkkitehtuuri ei vastaa toimialueen liiketoimintamallia. Kyllä, jos näin olisi, järjestelmä ei voisi toimia ollenkaan - vastoin samaa Conwayn lakia ja tervettä järkeä. Ei, monoliittinen arkkitehtuuri on täysin yhdenmukainen liiketoimintamallin kanssa tässä liiketoiminnan kehitysvaiheessa - tarkoitan tietysti vaihetta, jolloin järjestelmä on jo luotu ja otettu käyttöön. On aivan mahtavaa, että arkkitehtonisesta lähestymistavasta riippumatta sekä palvelukeskeisen arkkitehtuurin versio 3 että mikropalveluarkkitehtuurin versio N toimivat yhtä hyvin. Mikä on juju?
Kaikki virtaa, kaikki muuttuu vai ovatko mikropalvelut keino torjua monimutkaisuutta?
Ennen kuin jatkamme, katsotaanpa joitain väärinkäsityksiä mikropalveluarkkitehtuurista.
Mikropalvelulähestymistavan kannattajat väittävät usein, että monoliitin jakaminen mikropalveluihin yksinkertaistaa kehityslähestymistapaa vähentämällä yksittäisten palveluiden koodipohjaa. Minusta tämä väite on täyttä hölynpölyä. Vakavasti, ilmeinen vuorovaikutus monoliitin ja homogeenisen koodin sisällä näyttää monimutkaiselta? Jos näin todella olisi, kaikki hankkeet rakennettaisiin aluksi mikropalveluiksi, kun taas käytäntö osoittaa, että siirtyminen monoliitista mikropalveluihin on paljon yleisempää. Monimutkaisuus ei katoa, se yksinkertaisesti siirtyy yksittäisistä moduuleista rajapintoihin (olipa kyseessä sitten dataväylät, RPC, API ja muut protokollat) ja organisointijärjestelmiin. Ja tämä on vaikeaa!
Heterogeenisen pinon käytön etu on myös kyseenalainen. En väitä, että tämä on myös mahdollista, mutta todellisuudessa sitä tapahtuu harvoin (Eteenpäin katsottuna - tämän pitäisi tapahtua - mutta pikemminkin seurauksena kuin etu).
Tuotteen elinkaari ja palvelun elinkaari
Katso vielä kerran yllä olevaa kaaviota. Ei ole sattumaa, että panin merkille yrityksen erillisen version lyhenevän elinkaaren - nykyaikaisissa olosuhteissa yrityksen menestyksen kannalta ratkaisevaa on siirtymisen nopeuttaminen versioiden välillä. Tuotteen menestys määräytyy sen mukaan, kuinka nopeasti siinä testataan liiketoimintahypoteesia. Ja tässä on mielestäni mikropalveluarkkitehtuurin tärkein etu. Mutta mennään järjestyksessä.
Siirrytään tietojärjestelmien kehityksen seuraavaan vaiheeseen - SOA:n palvelukeskeiseen arkkitehtuuriin. Joten jossain tietyssä kohdassa korostimme tuotteessamme pitkäikäisiä palveluita - pitkäikäinen siinä mielessä, että tuotteen versioiden välillä liikkuessa on mahdollista, että palvelun elinkaari on pidempi kuin tuotteen seuraavan version elinkaari. Olisi loogista olla muuttamatta niitä ollenkaan - me Tärkeää on seuraavaan versioon siirtymisen nopeus. Mutta valitettavasti meidän on pakko tehdä jatkuvia muutoksia palveluihin - ja täällä kaikki toimii meille, DevOps-käytännöt, kontit ja niin edelleen - kaikki mitä mieleen tulee. Mutta nämä eivät silti ole mikropalveluita!
Mikropalvelut keinona torjua monimutkaisuutta... kokoonpanon hallinta
Ja tässä voimme vihdoin siirtyä mikropalveluiden määräävään rooliin - tämä on lähestymistapa, joka yksinkertaistaa tuotteen kokoonpanon hallintaa. Yksityiskohtaisemmin kunkin mikropalvelun toiminto kuvaa tarkasti tuotteen sisäistä liiketoimintatoimintoa domain-mallin mukaan - ja nämä ovat asioita, jotka eivät elä lyhytikäisessä versiossa, vaan pitkäikäisessä liiketoimintamahdollisuudessa. Ja siirtyminen tuotteen seuraavaan versioon tapahtuu kirjaimellisesti huomaamatta - muutat/lisäät yhden mikropalvelun ja ehkä vain niiden vuorovaikutussuunnitelman, ja yhtäkkiä huomaat olevasi tulevaisuudessa, jättäen taaksesi itkevät kilpailijat, jotka jatkavat hyppäämistä versioiden välillä. niiden monoliitit. Kuvittele nyt, että on olemassa melko suuri määrä mikropalveluita ennalta määritetyillä rajapinnoilla ja liiketoimintaominaisuuksilla. Ja tulet rakentamaan tuotteesi rakenteen valmiista mikropalveluista - vaikka piirtämällä kaavion. Onnittelut - sinulla on alusta - ja nyt voit houkutella liiketoimintaa itsellesi. Unelmia Unelmia.
Tulokset
- Järjestelmän arkkitehtuuri tulee määrittää sen komponenttien elinkaaren mukaan. Jos komponentti elää tuoteversiossa, ei ole mitään järkeä lisätä järjestelmän monimutkaisuutta käyttämällä mikropalvelulähestymistapaa.
- Mikropalveluarkkitehtuurin tulee perustua domain-malliin - koska liiketoimintamahdollisuus on pisin toimialue
- Toimituskäytännöt (DevOps-käytännöt) ja orkestrointi ovat mikropalveluarkkitehtuurille yksi tärkeimmistä - siitä syystä, että komponenttien vaihtonopeuden lisääntyminen asettaa lisääntyviä vaatimuksia toimituksen nopeudelle ja laadulle.
Lähde: will.com