kasvua microservice hyväksyminen on aiheuttanut elpyminen suosio aiemmin-unohdetaan ohjelmistojen suunnittelu kuvioita. Monet näistä kuvioista on louhittu Eric Evansin Domain Driven Design-kirjasta, joka käsittelee yhtä paljon tiimirakennetta kuin ohjelmistoarkkitehtuuriakin.

ja näistä kuvioista rajattu konteksti on ehkä tärkein ymmärtää. Insinööreinä olemme alkaneet pitää rajoitettua Kontekstia tietojärjestelmäarkkitehtuurin suunnittelukuviona. Mutta se johtuu siitä, että olemme valinneet sen hieman alkuperäisestä käytöstä. Evansin käyttämä rajattu asiayhteys on yhtä paljon organisatorinen kuin tekninen.

Siksi olen alkanut pitää rajattua Kontekstimallia lynchpininä mikropalveluiden ymmärtämisessä. Ei vain miten rakentaa niitä, vaan oikeastaan miksi me rakennamme niitä ylipäätään, ja miten ne voivat tehdä organisaatioistamme menestyksekkäämpiä. Jos ymmärrämme, mitä rajatut asiayhteydet ovat — jos hyväksymme rajatun asiayhteyden ajattelutapa sekä teknisesti että organisatorisesti-niin voimme todella onnistua rakentamaan meidän microservices arkkitehtuuri.

miksi siirtyä mikropalveluihin?

aluksi tehdään pieni harjoitus. Kysy itseltäsi tämä kysymys: Miksi ylipäätään rakennamme mikropalveluja?

mieti asiaa hetki. Mitkä ovat edut, jotka tulevat ensimmäisenä mieleen? Mitkä ovat tärkeimmät ongelmat, jotka meidän pitäisi toivoa voivamme ratkaista? Kirjoita ylös vastauksia, jotta pysyt rehellisenä.

…

onko sinulla vastaus? Hyvä. Lue se itsellesi. Osuitko standarditeknisiin etuihin? Jatkuva toimitus, skaalautuvuus, polyglottiympäristöt, Kontit ja pilvet, ja kaikki se hyvä juttu? Suuri.

mutta sisältyikö päällimmäiseen vastaukseesi mitään organisaatiosi tehokkaamman toiminnan mahdollistamisesta? Sen pitäisi. Mikropalvelujen rakentamisessa ei ole kyse teknisistä hyödyistä. Oikeasti kyse on järjestöetujen hankkimisesta. Kaikki muu on yksityiskohtaista täytäntöönpanoa.

Monoliths = coupled code and coupled teams

kun monolithimme kasvavat yhä suuremmiksi, tuottavuus alkaa heiketä. Siihen on ainakin kaksi suurta syytä.

jarruttaen nopeuttamme

ensin jokainen insinööriryhmä osallistuu yhteen jättikoodebaasiin. Näin ollen joukkueilla on yhä suurempi todennäköisyys, että heidän koodinsa on ristiriidassa muiden sääntöjen kanssa. Lieventääksemme mahdollisia ongelmia, joita tämä voi aiheuttaa, otamme käyttöön menettelyt – koodin jäätymiset, laadunvarmistuksen testausajat, junien vapauttaminen jne. – jotka on suunniteltu hidastamaan tuottavuuttamme.

nämä menettelyt estävät tietysti ominaisuuksien ja parannusten nopean käyttöönoton. Ne heikentävät myös insinöörien kykyä keskittyä tiimiensä prioriteetteihin. Jos vika löytyy testijakson aikana, vastuullisen tiimin on siirryttävä kontekstiin ja keskityttävä kyseisen vian korjaamiseen. Jos tuotannosta löytyy vakava vika, joukkueen on paitsi korjattava vika, myös hypättävä vanteiden läpi saadakseen sen käyttöönsä seuraavassa julkaisujunassa.

päivystysvuoro muuttuu puuduttavaksi. Jos jokin menee vikaan monoliitissamme, jonkun on oltava käytettävissä-päivällä tai yöllä-ongelman ratkaisemiseksi. Mutta kuka? Suuret organisaatiot, joilla on suuria monoliitteja, ovat yleensä kahden vaihtoehdon edessä:

• vaaratilanteiden johtoryhmä, jonka ainoa, surullinen, surullinen tehtävä organisaatiossa on vastata muiden insinöörien koodin aiheuttamiin ongelmiin ja selvittää, miten ne ratkaistaan.
• pyörivä päivystysaikataulu, jossa joka viikko joku mielivaltainen insinööri saa surullisen, surkean tehtävän tulla vastuuseen sellaisten ongelmien ratkaisemisesta, jotka todennäköisimmin johtuvat jonkun toisen insinöörin kirjoittamasta koodista jossain muussa insinööritiimissä.

(Mis)organisoimassa joukkueitamme

Monoliths sotkee organisaatiomme vielä toisella tavalla. Koko organisaatiomme työskentelee saman, suuren tuotteen parissa. Organisaatio pitää silti hajottaa hallittaviin joukkueisiin. Joten meillä on tapana etsiä toimivia rooleja löytääksemme tiimirajat:

valitettavasti tällainen organisaatiorakenne rajoittaa yhteistyötä. Sen sijaan, että työskentelisimme yhdessä ratkaistaksemme käsillä olevan todellisen ongelman (esim. miten suunnittelemme, rakennamme ja ylläpidämme ominaisuutta X?) eri toiminnallisten alueiden jäsenet keskittyvät vain omaan osaansa, heittäen kuvaannollisesti työnsä aidan yli, kun ne on tehty. Yhteistyö – ja synergiapotentiaali — jossa joukkueen ponnistelujen yhteenlaskettu laatu on paljon enemmän kuin yksittäisten tiimin jäsenten summa — menetetään.

siellä on myös pullonkauloja. Kun järjestämme tiimimme toiminnallisen alueen mukaan, prioriteetit ovat luonnollisesti vinoutuneet. Sanotaan, että tuotejohtoryhmä päätti, että Monolithin kassaprosessia on uudistettava. Suunnittelutiimin kanssa varataan aikaa pilkan kasaamiseen. Jossain vaiheessa Pilat viimeistellään ja luovutetaan frontend-tiimin toteutettavaksi. Tietenkin, frontend joukkue tarvitsee API toteutetaan backend joukkue, joten ne estetään, kunnes se on valmis. Kun taustatiimi priorisoi työnsä uusissa kassapalveluissa, se huomaa tarvitsevansa apua tietokannan Hallintatiimiltä (DBA). Jolla on tietysti omat prioriteettinsa. Joten taustajoukot ovat tukossa, kunnes DBA on vapautettu.

tavallaan tämä organisaatiorakenne tuntuu vähän huonosti suunnitellulta, liian yhteen kytketyltä ohjelmistoarkkitehtuurilta… eikö niin?

Microservices = decoupled code, decoupled teams

sitä vastoin microservices-arkkitehtuuri mahdollistaa tiimin autonomian. On paljon helpompaa muodostaa tiimejä, jotka ovat itsenäisiä, jotka toimivat tehokkaasti yhdessä ja joita ei jatkuvasti estä riippuvuudet muista joukkueista.

tiimit voivat ottaa täyden vastuun työstään suunnittelusta kehittämiseen ja käyttöönottoon. Jokainen jäsen jakaa vastuun joukkueensa tavoitteen saavuttamisesta, joten heitä kannustetaan osallistumaan muuhunkin kuin vain ”omaan osaansa”. Olen työskennellyt tiimeissä, joissa tuotepäälliköt, suunnittelijat, front-end, back-end ja mobile insinöörit ovat saaneet yhdessä suunnitella tuotteen ominaisuuksia, tuottaen paljon parempia tuloksia kuin yksi henkilö olisi voinut saavuttaa.

tiimi saa vastuun omista esineistään, kun ne otetaan tuotantoon. Tämä johtaa yleensä laadukkaampaan koodiin, jonka vianmääritys on helpompaa. Miksi? Toisin kuin monoliitilla, tiimeillä on yleensä kokonaisvaltainen näkemys omistamistaan mikropalveluista. Joten tiimin on paljon helpompi ennakoida ongelmia, lisätä hyviä kirjauksia ja mittareita ongelmien vianmääritykseen, kun niitä ilmenee, ja hyödyntää asianmukaisesti sietokykyä (esim.retries, katkaisijat ja varasuunnitelmat jne.) ongelmien välttämiseksi.

lisäksi, koska tiimeillä on täysi omistajuuden tunne heidän työstään, heidän palvelujensa pitäminen terveinä ja tuotannon pyörittäminen muuttuu vähemmän painajaismaiseksi julkaisuaikatauluksi, vaan enemmän heidän luomisensa vaalimiseksi.

lopulta joukkueet pyrkivät samaan päämäärään, samalla aikajanalla. Tämä tarkoittaa enää estää yksi henkilö, kun he odottavat jonkun toisen toiminnallisen alueen vapauttaa.

meidän täytyy olla intentionaalisia autonomian suhteen

, mutta emme saa näitä etuja ilmaiseksi yksinkertaisesti hajottamalla monoliittimme mikrospalveluihin. Tarkastelkaamme ensimmäistä, naiivia näkymäämme mikroservisioarkkitehtuurista:

/div>

Jos olemme kuten useimmat insinöörit, alkuperäinen käsityksemme mikroarkkitehtuurista on, no, joukko mikropalveluita. Jokainen altistaa jonkinlaisen API: n (lepo, ehkä), jotta mikä tahansa muu palvelu voi lukea siitä ja kirjoittaa siihen.

kokemuksen karttuessa opimme, etteivät kaikki mikropalvelut palvele samaa tarkoitusta — tai ainakaan niiden ei pitäisi. Ja siksi, paljolti samalla tavalla kuin monoliittimme oli järjestetty kerroksittain, niin me järjestämme mikroserviksemme:

/div>

tässä vaiheessa olemme määritelleet erityyppiset mikropalvelut ja sovellukset, joita haluamme rakentaa. Suuri. Emme ole edistyneet joukkueen autonomian suhteen. Jokaisen mikropalvelun on oltava jonkun tiimin omistuksessa. Ja niin herää kysymys: mitkä tiimit omistavat mitkä mikropalvelut?

Cross functional teams

ensimmäinen naiivi lähestymistapamme voisi olla järjestää joukkueemme monoliittista org-rakennettamme jäljittelemällä:

täällä nähdään tiimejä (purppurassa) tehtävittäin järjestettyinä: UX design, frontend engineering, backend engineering, data Engineers, DBAs, QA jne.

Tämä saattaa ainakin aluksi tuntua oikealta. Mutta otetaan askel taaksepäin ja katsotaan, mitä arvoa Yritämme tarjota asiakkaillemme. Onko tavoitteenamme rakentaa asiakkaillemme seuraavanlaisia asioita?

• joukko tietokantahuijauksia
• joukko käyttöliittymähuijauksia
• joukko mikropalveluita, jotka voivat puhua MySQL-tietokantaan?

ei oikeastaan. Ne ovat vain työkaluja, joiden avulla luomme arvoa asiakkaillemme. Todellinen arvo, että tarjoamme asiakkaillemme / käyttäjille tulee muodossa ominaisuuksia ja toimintoja, kuten:

• tuotekatalogi, josta voi etsiä
• mekanismin, jolla tavarat voi laittaa ostoskärryyn ja myöhemmin ostaa ne
• ilmoitusjärjestelmä ilmoittaa asiakkaille ostosten tilasta

vastaavasti emme halua järjestää tiimiämme toiminnallisen alueen mukaan. Pikemminkin meidän pitäisi määritellä tiimimme sen arvon mukaan, jonka ne luovat asiakkaille; toisin sanoen funktioiden välillä, (osuvasti nimetyissä) cross-functional-tiimeissä.

cross functional tiimien kanssa kaikki rakentavat yhdessä tiettyä tuotetta tai ominaisuutta alusta loppuun. Kaikilla joukkueella on samat tavoitteet ja prioriteetit, joten mitään toiminnallista aluetta toinen ei estä. Vaatiiko Uusi backend API-palvelu jonkin verran tietokannan suunnittelutyötä? Hyvä on; tiimin taustainsinööri ja DBA voivat molemmat priorisoida työnsä yhdessä.

parhaimmillaan cross functional-tiimit kannustavat jäseniä yhteistyöhön projektin jokaisessa vaiheessa. Jokainen tiimin jäsen osallistuu toiminnon kokonaissuunnitteluun. Frontend, backend ja mobile insinöörit yhdessä määritellä API sopimukset. Kaikki testaavat. Ja jokainen alkaa tulla hyvin perehtynyt oman toimialansa.

ja näin joukkueemme rakenteet saattavat alkaa näyttää joltain tältä:

div>

näin on parempi. Jokin ei silti tunnu oikealta.

toki olemme muodostaneet tiimejä, jotka todennäköisesti ovat tehokkaampia omistamaan tuotteita. Mutta olemme silti ottaneet ylhäältä alas lähestymistapa tunnistaa topologia mikropalveluja, että organisaatiomme aikoo rakentaa. Jäljelle jää laaja kokoelma toisistaan riippuvaisia mikropalveluita, joista suurin osa on kytketty yhteen. Olemme vain määränneet heidät eri tiimeihin rakentamaan.

Tämä johtaa seuraaviin huolenaiheisiin:

• miten voimme luoda sovellusliittymiä, jotka täyttävät kaikki nykyiset ja tulevat tarpeet, joita asiakkaalla saattaa olla? Voimmeko kiteyttää tietomme, kun minkä tahansa muun tiimin palvelut saattavat kutsua palveluitamme?
• kuinka paljon aikaa tuhlaamme odottaessamme, että muut tiimit toteuttavat riippuvuutemme?
• mitä järjestelmiemme vikoja voivat aiheuttaa muiden järjestelmien viat (ryöppyävät viat)?
• Voimmeko valvoa niiden puhelujen määrää, joihin palvelumme saattavat osallistua? Voimmeko varmistaa, että organisaatiomme ei pääty luomaan rajattomia synkronisia puheluita palvelujen välillä, mikä johtaa tähtitieteellisiin vasteaikoihin, tai pahempaa (ja kyllä, olen nähnyt tämän tapahtuvan) äärettömän rekursiivisia puheluita eri palveluissa?
• mitä jos tiimimme erityisominaisuus tai ongelmatila ei sovi hyvin ennalta suunniteltuun microservicen topologiaan?

tarvitsemme vielä toisenlaisen ajattelutavan. Ehkä on jo olemassa malli, jota voimme noudattaa?

Anna rajattu asiayhteys

rajattu asiayhteys on domain driven designin eli DDD: n keskeinen suunnittelukuvio. Rajatun asiayhteyden ymmärtäminen auttaa meitä muodostamaan autonomisia tiimejä ja sitä kautta autonomisia mikroarkkitehtuureja.

DDD itse kuvaa ohjelmistokehityksen metodologiaa, jossa organisaation sisällä olevat henkilöt työskentelevät yhdessä määritelläkseen yhteisen kielen. Kirjassaan Domain Driven Design Eric Evans kuvaa usein insinöörejä, jotka työskentelevät tuotteiden omistajien kanssa luodakseen sovitun sanaston kuvaamaan asioita, kuten tuotteita, tuotteiden komponentteja, toimia, joita tuote voi suorittaa (tai joita voidaan suorittaa tuotteelle), työnkulkujen osia jne. Tämä sanasto kattaa organisaation toimialueen.

monissa suurissa organisaatioissa yhden yhtenäisen sanaston määritteleminen käy kuitenkin mahdottomaksi. Näissä tapauksissa murramme verkkotunnuksemme aliverkkotunnuksiksi. Esimerkkejä aliverkkotunnuksista voivat olla:

• Varastonhallinta

uotteiden löytyminen

• Tilausten hallinta
• ostoskärryt ja kassat

kun suunnittelijat, insinöörit, tuotepäälliköt jne kokoontuvat rakentamaan aliverkkoa, he muodostavat oman tapansa ajatella ja puhua aliverkkotunnuksesta ja sen komponenteista.

tässä DDD kohtaa poikkitoiminnallisen ryhmärakenteen. Vaikka tiimin jäsenet ovat eri toiminta-alueilta, he ovat vastuussa omasta alialueestaan, lopulta heistä tulee resident-asiantuntijoita. Lisäksi tiimi on vastuussa siitä, mitä esineitä-mikrosovelluksia, verkkosovelluksia, mobiilisovelluksia, tietokantoja ja niihin liittyvää infrastruktuuria — tarvitaan aliverkkotunnuksen herättämiseksi eloon ja organisaation asiakkaille.

voimme ajatella ryhmän ja sen artefaktien koostuvan rajatusta kontekstista.

rajatun Kontekstin määritteleminen

vaikka Evans käsittelee kirjassaan usein rajattuja Konteksteja, hän ei varsinaisesti määrittele kaavaa eksplisiittisesti. So I ’ll try to do it here:

Bounded Context:

sisäisesti johdonmukainen järjestelmä, jossa on huolellisesti suunnitellut rajat, jotka välittävät sitä, mitä järjestelmään voi tulla ja mitä siitä voi poistua.

toisin sanoen rajattu Konteksti edustaa kontekstia — pohjimmiltaan järjestelmää, joka kiteyttää yhteistoiminnalliset komponentit — ja jossa on selkeästi määritellyt rajat, jotka määräävät, mitä järjestelmään voi tulla ja mitä siitä voi poistua.

solut (ne pienet asiat, jotka kollektiivisesti muodostavat kaikki elävät olennot) tarjoavat mukavan analogian. Solun sisällä on kaikenlaisia komponentteja (Tuma, ribosomit, sytoplasma, sytoskeletonit jne.), jotka kaikki koteloituvat solun sisälle. Jokaisen solun ympärillä on kuitenkin kalvo, joka toimii esteenä solun sisäosien ja muun eliön välillä. Kalvo suojaa solua ympäristöstään, päästää sinne tiettyjä ravintoaineita ja päästää erilaisia sivutuotteita.

samassa yhteydessä rajattu asiayhteys koostuu useista osista (mikropalvelut, verkkosovellukset, mobiilisovellukset, tietokannat, viestijonot jne.). Se toimii myös loogisena esteenä, joka kiteyttää nämä komponentit. Sisäisesti komponentit voidaan kytkeä, ja ne voivat vapaasti siirtää tietoja toisilleen. Mutta rajattu yhteydessä auttaa täytäntöönpanemaan löysä kytkentä ulkoisesti, määrittelemällä nimenomaisia kohtia, joissa:

• ulkoiset tiedot voivat tulla sisään (ehkä Kafka-aiheisen kuluttajan kautta)
• sisäiset tiedot voivat poistua (ehkä toisen Kafka-aiheen kautta tai kaivo-ohjelmoidun GET API: n kautta, joka on huolellisesti muotoiltu piilottamaan kaikki järjestelmän sisäiset tiedot)

rajattu asiayhteys edustaa myös sen poikkitoiminnallista tiimiä. Tiimi koostuu eri tiimin jäsenistä (suunnittelijat, frontend/backend/mobile insinöörit, tuotepäälliköt, data insinöörit ja QA insinöörit, jne). Sisäisesti nämä jäsenet työskentelevät yhteistyössä samojen yhtenäisten tavoitteiden saavuttamiseksi. Lisäksi nämä joukkueen jäsenet on (tai pitäisi) kapseloitu niin, että heillä on minimaalinen riippuvuus muista joukkueista.

sen sijaan, että aloittaisimme organisaatiotasolta ja määrittelisimme kaikki sovellukset ja mikropalvelut, joita odotamme rakentavamme, rakennamme tiimejä alialueidemme ympärille, antaen näille tiimeille mahdollisuuden kasvattaa alialueitaan ja määritellä, mitä on rakennettava. Oikein tehtynä meillä on taipumus nähdä erilaiset rajatut kontekstit organisaatiossa orgaanisesti kasvavina eikä jäykinä, ennalta määriteltyinä rakenteina.

Implications on breaking the monolith

Conwayn laki kertoo, että organisaatiot suunnittelevat ohjelmistojärjestelmiä, jotka jäljittelevät organisaationsa viestintärakennetta. Tämä osoittautuu usein todeksi, joten meidän tulisi olla huomaavaisia sen suhteen, miten rakennamme organisaatiomme, kun alamme rakentaa mikropalveluja.

itse asiassa jo kuvan pitäisi olla nousemassa mieleesi. Kun siirrymme monolithista mikroservices, meidän pitäisi alkaa ajatella vertikaalisesti (jakamalla monolith sen alidomains) sijaan horisontaalisesti (jakamalla monolith sen toiminnallisia kerroksia).

toisin sanoen, meidän ei pitäisi aloittaa korvaamalla Monolithin datayhteyskerros datamikrospalveluilla. Pikemminkin, meidän pitäisi aloittaa jakamalla koko ominaisuus (kuten kassalla, tai ehkä tuotteen haku). Jokainen ominaisuus edustaa rajatussa yhteydessä. Ja jokainen jaetaan omistautuneella poikkitoiminnallisella tiimillä.

lisäksi kyseisen tiimin tulisi keskittyä käsillä olevaan tehtäväänsä, joka on joko:

• toistaa uskollisesti olemassa olevat toiminnot,
• tai (paremmin) rakentaa kokonaan uusi, parempi kokemus asiakkailleen.

osana prosessia tiimin tulisi suunnitella tehtävään parhaiten soveltuva järjestelmä.

saatamme esimerkiksi päättää kuoria tuotteen hakutoiminnon pois monoliitistamme. Tuotteen hakuryhmä saattaa lopulta suunnitella järjestelmän, joka sisältää:

• Kafkan kuluttajat, jotka kuuntelevat useita ulkoisia Kafka-aiheita päivittääkseen omaa sisäistä tallennusjärjestelmäänsä (SoR) tuotteille.
• Kafka-julkaisija, joka työntää muutoksia SoR: ään sisäiseen Kafka-aiheeseen
• toinen Kafka-kuluttaja, joka kuuntelee kyseistä sisäistä aihetta ja päivittää elastisen Hakuindeksin
• GraphQL-loppupiste vapaisiin hakuihin, jotka tiedustelevat elastista hakua
• Lepopiste, joka hakee yksittäisiä tuotteita ID: llä
• uudistettu verkkosovellus, joka käyttää näitä päätepisteitä, jotta asiakkaat voivat etsiä tuotteita ja tutkia tuotetietoja
• näytöistä mobiilisovelluksissamme, jotka käyttävät näitä päätepisteitä
• Kafkan julkaisija, joka työntää viestejä, edustavat asiakkaiden tekemiä erillisiä kyselyjä ulkoiseen Kafka-aiheeseen, käytettäväksi missä tahansa muussa rajatussa kontekstissa (vaikkapa analytiikka), jota saattaa kiinnostaa

kun alamme kuoria yhä useampia vertikaalisia osia monoliitistamme, muut tiimit rakentavat omia rajattuja yhteyksiään. Nämä rajatut asiayhteydet saattavat lopulta näyttää aivan erilaisilta.

huomaa, että tietyn rajatun kontekstin komponentit saattavat olla tiukasti kytkettyinä toisiinsa; pidämme kuitenkin rajatut yhteytemme erillään toisistaan. Esimerkissämme kaikki rajattujen asiayhteyksien välinen viestintä tapahtuu välittämällä viestejä Kafka-viestijonon kautta. Tärkeää on, että vältämme synkronisia pyyntö – / vastauspuheluja rajoitettujen asiayhteyksien välillä.

Tämä pätee myös siihen, mitä monoliitista on jäljellä. Emme todellakaan halua tiivistä kytkentää uusien mikropalvelujemme ja perinteikkään monoliittimme välille. Kuoriessamme osia monoliitista pois, – hyödynnämme viestin välittämistä, jotta loput osat voivat kommunikoida uusien rajoitettujen yhteyksiemme kanssa.

Reality check on all of this decouplizing

tässä vaiheessa voimme kysyä itseltämme, onko todella mahdollista pitää rajatut yhteytemme irroitettuina.

reaalimaailmassa, voimmeko todella pitää tiimimme suojassa ulkoisilta riippuvuuksilta? Eikö koskaan tule tapauksia, joissa toisen joukkueen on estettävä joukkue saadakseen työnsä tehtyä?

ja voimmeko todella luoda aliverkkotunnuksillemme palveluarkkitehtuureja, jotka ovat täysin erillään muista aliverkkotunnuksista? Onko todella mitään tarvetta sovelluksen yhdessä rajatussa yhteydessä koskaan synkronisesti soittaa palvelua toisessa?

todellisuudessa voi olla mahdotonta pitää rajattuja Asiayhteyksiämme 100-prosenttisesti tuotannosta irrotettuina. Mutta voimme päästä lähelle, paljon lähemmäksi kuin useimmat meistä luulevat.

tosielämän arkkitehtuurit

aloitetaan tarkastelemalla irrallisia arkkitehtuureja. Usein uskomme harhaluuloon, että tietyntyyppisten tietojen pitäisi elää täsmälleen yhdessä paikassa, ja että minkä tahansa muun järjestelmän täytyy suoraan soittaa tuohon yhteen paikkaan päästäkseen käsiksi tietoihin.

kutsumme tätä yhden totuuden lähteen (SSoT) osoittamiseksi tietoihimme. Mutta kuten tässä artikkelissa, joka dissects ajatus SSoTs, että hyvin käsite on, yleensä, anti-malli. Sen sijaan useimpien rajoitettujen asiayhteyksien tulisi tallentaa oma paikallinen kopio kaikesta tarvitsemastaan datasta.

tästä on esimerkkinä tuotehaun rajoittama Konteksti edellisestä osiosta. Tämä rajattu asiayhteys perustuu tietenkin vahvasti organisaatiomme tuotekatalogin tietoihin. Mutta kertoimet ovat, että data syntyy eri rajattu yhteydessä (me kutsumme sitä tuote-merkintä rajattu yhteydessä).

ensimmäinen (naiivi) lähestymistapamme voisi olla ReST API: n paljastaminen Tuotesyöttöä rajoittavasta kontekstista ja pakottaa tuotesyöttöä rajoittavan Kontekstin palvelut kutsumaan kyseistä API: a. Mutta pystymme parempaan. Voimme sen sijaan pitää järjestelmät irrallaan julkaisemalla Kafkaan Tuotesyöttöpalvelujen tekemät muutokset. Meidän tuote-haku Kafka kuluttajat sitten poimia nämä viestit ja päivittää Tuotehaku tietokannat.

huomaa, että nämä kaksi rajattua asiayhteyttä ovat lopulta-yhtäpitäviä. Tämä tarkoittaa sitä, että on olemassa lyhyitä ajanjaksoja, jolloin tietty tieto saattaa olla ristiriidassa Tuotteen syöttämisen ja tuotteen haun välillä. Esimerkiksi, jos hinta valkoinen vompatti widgetit nostetaan $1.99 $ 2.49, siellä on lyhyt aika (usein muutamassa sekunnissa, jos ei millisekunnit), jossa on 50¢ ero valkoinen Wombat Widget hinta poikki kaksi rajattu yhteyksissä.

Tämä johtaa reaalimaailman tapauksiin, joissa meillä ei ole muuta vaihtoehtoa kuin parisuhdekontekstit. Joissakin tapauksissa lopullinen johdonmukaisuus ei ole hyväksyttävää. Esimerkiksi ennen kuin asiakas voi suorittaa online-ostoksensa, meidän on ehkä varmistettava, että jokainen tuote hänen ostoskorissaan on itse asiassa saatavilla sillä hetkellä. Silloinkin voimme usein minimoida kahden rajatun asiayhteyden välisen yhteyden.

vuorovaikutuksemme voi näyttää tältä:

• koska asiakas käyttää tuotehaun käyttöliittymää tuotteiden etsimiseen, tuotehaun tietokantoja käytetään tiedon hakemiseen (kuten tyylit, Asiakasarviot, hinnoittelu jne.) tuotteista
• vielä asiakkaan aloittaessa kassan, käytämme Tuotehakutietokantoja hakeaksemme näytettävän tiedon.
• lopuksi, kun asiakas napsauttaa tätä lopullista ”täydellinen osto”-painiketta, soitamme yhden, synkronisen puhelun Tuotteen merkintää rajoittavaan kontekstiin vahvistaaksemme tuotteiden saatavuuden ennen oston suorittamista.

toinen yleinen esimerkki, joka vaatii välitöntä johdonmukaisuutta valtuutukseen liittyen. Monissa järjestelmissä turvasanakkeet on haettava tai validoitava jokaisen pyynnön yhteydessä. Näissä tapauksissa meidän on todennäköisesti annettava rajoitettujen Asiayhteyksiemme kutsua toista, turvallisuuteen keskittyvää rajoitettua asiayhteyttä.

tosielämän org-rakenteet

miten olisi itsenäiset, poikkitoiminnalliset tiimit? Kuinka mahdollista ne ovat oikeassa maailmassa?

todellisuudessa kyse on jatkuvasta liikkeestä kohti täysin itsenäisiä joukkueita. Harvoin saavutamme koskaan 100-prosenttista itsenäisyyttä joukkueidemme kanssa. Mutta jos aloitamme organisoimalla tiimimme älykkäästi ja tunnistamme pullonkaulat ja reagoimme niihin, voimme päästä lähelle.

alkajaisiksi meidän tulisi maksimoida vertikaalinen, poikkitoiminnallinen joukkueemme ja minimoida horisontaalisten, yksitoimisten joukkueiden määrä. Tämä tarkoittaa sitä, että vastustamme halua muodostaa niin sanottuja ydinryhmiä — joiden tehtävänä on rakentaa yhteisiä datapalveluja, joita muut tuotekeskeiset tiimit kuluttavat-ja sen sijaan muodostaa tiimimme niiden tarjoaman liikearvon ympärille.

monet organisaatiot hiiviskelevät kohti tätä tavoitetta ja muodostavat ensin tuotepäälliköiden ja etu-ja taustainsinöörien toimialakohtaisia tiimejä. Se on alku. Mutta keitä muita näihin joukkueisiin pitäisi kuulua? Tarkka jäsenyys voi vaihdella eri tiimeissä, joilla on erilaisia tarpeita. Mutta meidän pitäisi harkita asioita, kuten:

• Jos tiimissämme on front-end-insinöörejä, niin todennäköistä on, että heidän pitäisi tehdä tiivistä yhteistyötä graafisen suunnittelijan kanssa, joka on omistautunut domainille.
• Mobile engineers — usein eristettynä omalle org — alueelleen-olisi sisällytettävä verkkotunnuksiin, joissa on mobiilikomponentti.
• valistavassa dataverkkoja käsittelevässä artikkelissaan Zhamak Dehghani valittelee, että datainsinöörit jätetään usein poikkitoimintoryhmien ulkopuolelle-datainsinöörien ja itse poikkitoimintoryhmien vahingoksi.

kun joukkueiden kokoonpano on selvitetty, kannattaa varoa pullonkauloja. Onko muita joukkueita, jotka yleensä estävät poikkitoiminnallisten joukkueidemme tuottavuuden?

esimerkiksi monilla organisaatioilla on oma Turvatiimi. Tämä on tietenkin hyvä käytäntö; järjestöt tarvitsevat yhtenäisen turvallisuusstrategian ja tavan varmistaa strategian hallinta. On kuitenkin myös tavallista, että tiimit pysäyttävät työnsä eri vaiheissa, jotta heidän työnsä turvallisuusarvioidaan. Parhaissakin tilanteissa tämä muodostaa tiesulkuja tiimeillemme rutiininomaisena liiketoimintakäytäntönä. Lisäksi se johtaa usein siihen, että tiimit joutuvat romuttamaan työnsä kokonaan tai osittain ja aloittamaan alusta, koska ne paljastavat turvallisuusvaatimukset, joita ei ollut täytetty.

Tämä on selvästi paha haju. Mutta miten voimme valvoa organisaatiomme turvallisuusstandardeja samalla kun tiimit voivat pysyä itsenäisinä ja tuottavina?

voimme tehdä tämän lisäämällä turvallisuusinsinöörejä poikkitoiminnallisiin tiimeihimme. Voimme ottaa kolme lähestymistapaa:

• Jos meillä on onni, että meillä on suhteellisen suuri Turvatiimi, voimme määrätä jokaiselle poikkitoiminnalliselle ryhmälle päätoimisen turvallisuusinsinöörin (se).
• pienemmillä turvatiimeillä jokainen SE voidaan jakaa osa-aikaisesti usealle poikkitoimintajoukkueelle. Tämä antaisi SEs: lle edelleen mahdollisuuden ymmärtää ryhmien tavoitteet ja mallit ja työskennellä tiimin kanssa org: n turvallisuusstandardien noudattamiseksi koko prosessin ajan.
• Jos meillä ei ole tarpeeksi turvaresursseja kummallekaan, voimme siirtyä päinvastaiseen suuntaan. Sen sijaan, että tuomme turvallisuusryhmän jäseniä poikkitoiminnallisiin tiimeihimme, voimme tuoda poikkitoiminnallisten joukkueiden jäseniä ulos turvallisuusryhmään. Jokainen poikkitoiminnallinen ryhmä nimeäisi yhden tai kaksi turvallisuusedustajaa. Edustajat kohtaisivat ajoittain turvallisuutta ja pysyisivät järjestön turvallisuusvaatimusten ja-standardien tasalla. He eivät välttämättä ole itse turvallisuusasiantuntijoita. Mutta he voivat palvella turvallisuusinsinöörin roolia, varmistaen, että heidän tiiminsä noudattavat organisaation turvallisuuskäytäntöjä.

killat

tämä nivoutuu toiseen organisaatiomalliin, joka on saanut vetoapua: kiltoihin. Kiltamalli syntyi cross-functional team-mallista. Luonteeltaan nämä joukkueet ovat täynnä jäseniä, jotka ovat erikoistuneet eri tehtäviin. Silti se on usein järkevää ihmiset, jotka ovat erikoistuneet tiettyyn tehtävään tavata yhdessä samoin; esimerkiksi:

• hioivat taitojaan ja oppivat toisiltaan
• Tutustu ja luo parhaat käytännöt omaan tehtäväänsä
• riippuen tehtävästä, luo yrityksen standardeja ja vaatimuksia

viimeinen turvallisuusratkaisumme muodosti käytännössä ”turvakillan”. Tiimin jäsenet työskentelivät pääasiassa vertikaalisten joukkueidensa kanssa, mutta ajoittain osa heistä tapasi turvallisuus ”killan” keskustellakseen organisaation turvallisuuskäytännöistä ja standardeista.

killan malli toimii erityisen hyvin myös ohjelmistoarkkitehtuurin osalta. Erityisesti mikropalveluarkkitehtuurissa tarvitaan jonkinasteista organisaation laajuista teknistä hallintoa. Kuitenkin se, että ryhmä arkkitehtejä istuu vertauskuvallisessa norsunluutornissa jakamassa sääntöjä ryhmille, on yleensä haitallista. Sen sijaan poikkitoiminnallisten tiimiemme senior/lead-insinöörit voivat ajoittain tavata arkkitehtuurikillassa. Siellä he voivat nostaa tiimeistään esiin asioita, työstää ratkaisuja sekä luoda patteneja ja standardeja.

kiltoja voidaan laajentaa myös lähes kaikkiin muihin tehtäviin. Loppujen lopuksi haluamme ulos suunnittelijat kehittää, ja työskentelevät, yhteinen UI tyyliopas. Haluamme, että frontend-insinöörimme käyttävät samoja käyttöliittymäelementtejä. QA-insinöörien tulisi olla linjassa sen kanssa, miten testaus tehdään organisaatioissamme. Tuotepäälliköiden tulisi noudattaa organisaation kokonaisvaltaista tuotesuunnitelmaa.

Bring it all together

siirtyminen mikropalveluihin voi merkittävästi parantaa tiimiemme tuottavuutta. Mutta meidän täytyy ymmärtää, miten hyödyntää mikropalvelujen arkkitehtuuri saada meidät sinne. Kaikista suunnittelumalleista ja käsitteistä, jotka liittyvät mikropalveluihin, rajattu konteksti on kiistatta tärkein yksittäinen asia, joka antaa meille tämän ymmärryksen.

, joilla on vankka käsitys rajatusta asiayhteydestä, ymmärrämme, että:

• organisaatiorakenteemme ja tekninen arkkitehtuurimme kulkevat käsi kädessä
• tuotekeskeisten tiimiemme tulee olla mahdollisimman vähäisessä määrin riippuvaisia muista tiimeistä, aivan kuten heidän rakentamiensa järjestelmien tulisi olla erillään muista järjestelmistä

yleensä ottaen huomioon rajattu konteksti, joka asettaa ajattelutavan, että meidän on menestyttävä mikropalveluarkkitehtuurissamme. Varmista, että ymmärrät tämän tärkeän kuvion, ennen kuin aloitat microservices-matkasi!