Video: Vlog: Tietoturvaa arkeen (Lokakuu 2024)
Yritysohjelmistoympäristö on täynnä buzzy-tekniikoita. Olemme kirjoittaneet niistä runsaasti, olipa kyse sitten blockchainista, matalan koodin kehityksestä tai muista nousevista suuntauksista, jotka muuttavat työskentelytapojamme. Yksi uusi buzzword, josta et ehkä ole ennen kuullut, on "mikropalvelut".
Se on suunnittelussa. Mikropalvelut ovat erilainen tapa arkkitehtuuriohjelmiin, jotka perustuvat keskenään kudottuihin modulaarisiin komponentteihin, eikä perinteiseen "monoliitin" ajatukseen - sovellukseen, joka koostuu yhä kasvavasta koodivirrasta. Mikropalvelupohjaiset sovellukset eivät näytä eroavan käyttöliittymän (UI) puolelta riippumatta siitä, onko kyseessä monimutkaisessa datakeskuksessa vai Web- tai mobiilisovelluksessa, jota ylläpidetään skaalautuvassa pilviinfrastruktuurissa.
Syy, jonka yritysten pitäisi välittää mikropalveluista, on se, että kulissien takana arkkitehtuuri voi auttaa kehitys- ja IT-ryhmiäsi työskentelemään ja innovoimaan nopeammin, hallitsemaan infrastruktuuria ja vähentämään uusien ominaisuuksien ja toiminnallisuuksien lisäämiseen sovellukseen liittyviä kustannuksia ja monimutkaisuutta. IDC: n sovelluskehitysohjelmistotutkimuksen ohjelmajohtaja Al Hilwa selitti, kuinka hän suunnaisi mikropalvelut toimeenpanijalle pitäen samalla mielessä sekä kulttuuriset että tekniset haasteet.
"Uusia järjestelmiä rakennettaessa on todennäköisesti tärkeintä huomata, että pienen ryhmän tulee rakentaa yksi mikropalvelu", Hilwa sanoi. "Toiseksi, monimuotoisuuden suvaitsevaisuus ohjelmointikielissä ja kehittäjien työnkulkuissa johtuu usein kokonaisen mikropalvelukulttuurin itsenäisestä luonteesta. Tärkein askel toimeenpanijalle on ohjelmiston rakentaminen asteittain pieniä ryhmiä käyttäen, jolloin jokainen rakentaa yhtenäisen moduulin julkaisemallaan julkaisulla. käyttöliittymä. Etuna on, että riippumattomia moduuleja voidaan kehittää paljon nopeammin itsenäisesti, kunhan julkaistuja sovellusliittymiä hallitaan organisoidusti."
Mitä oikeasti ovat mikropalvelut?
Hilwa kirjoitti vuoden 2015 IDC-raportin, jonka otsikko on "Mikropalvelujen syntyminen uutena arkkitehtonisena lähestymistapana uusien ohjelmistojärjestelmien rakentamiseen". Hän määrittelee raportissa mikropalvelut rakeisena ohjelmistoarkkitehtuurina, jossa sovelluskomponentit suunnitellaan ja kehitetään itsenäisesti vastaamaan API: n määrittelemiä yhteentoimivuusvaatimuksia (tarkoitetaan sidottuina sovellukseen kokonaisuutena). Mikropalveluita ei kuitenkaan ole tyhjiössä. Uusi arkkitehtuuri vaatii vahvaa organisatorista tukea ja muutosta IT-kulttuurissa.
Mikropalveluita ei myöskään määrittele yksikään erityinen tekniikka, vaan palveluiden suuntautuneen arkkitehtuurin (SOA) pitkäaikaisen konseptin kehityksenä, jota täydentävät konttien tulo ja automaation nousu kehittämislähestymistapojen, kuten jatkuvan toimituksen (CD) ja jatkuvan integroinnin, avulla (CI).
"Mikropalveluita käyttäviä organisaatioita motivoi tyypillisesti halu nopeuttaa palvelun kehitystä", Hilwa sanoi. "Siksi useimmissa tällaisissa tapauksissa mikropalvelut käyttävät CI / CD-automaatiota suuressa määrin. Tosiasiallinen käyttöönotonopeus voi kuitenkin olla erilainen palveluiden välillä. Mielestäni avain on tarkastella hyvää sisäistä kulttuuria ja olla Varmista, että olet valmis suvaitsemaan suurempaa hajauttamista ja monimuotoisuutta tekniikan pinossa."
"Sisäisellä kulttuurilla" Hilwa viittaa suurelta osin DevOpsiin, filosofiaan, joka yhdistää ohjelmistokehityksen, IT-toiminnot ja laadunvarmistuksen (QA) yhdeksi, yhteistyöhön perustuvaksi työnkuluksi. DevOps-ohjelmiston käynnistys HashiCorp ja sen perustajat ovat jo pitkään olleet mikropalvelujen kannattajia. Yhtiö, joka sai äskettäin 24 miljoonan dollarin kierroksen B-sarjan rahoitusta, laskee Ciscon, DigitalOceenen, Mozillan ja Stripen kaltaiset yritykset avoimen lähdekoodin käyttäjien ja yritysasiakkaiden joukkoon.
Mikropalvelut ovat keskeisiä siinä, miten HashiCorp lähestyy DevOps-infrastruktuurin kehittämistä ja sovellusten työnkulkuja suosituissa avoimen lähdekoodin työkaluissa ja kasvavassa yritystuotepaketissa. Armon Dadgar, CTO ja HashiCorpin perustaja, hajotti eron monoliittien ja mikropalvelujen välillä käyttämällä yksinkertaista analogiaa: Amazon ja eBay.
"Ajattele Amazonia ja eBaya yhtenä sovelluksena. Loppukäyttäjän näkökulmasta ne näyttävät samanlaisilta, mutta kulissien takana yritykset käyttivät päinvastaista lähestymistapaa sovellusten rakentamisessa ja suunnittelussa", Dadgar sanoi. "Amazon on alusta alkaen ollut paketti mikropalveluita; se toimii yhtenä sovelluksena. Mutta jos otat haun, tuoteluettelon, ostoskorin, laskut, tilausvirrat ja jaat nämä toiminnot, nämä kaksi sovellusta toimivat eri tavoin koneita."
Amazonin analogia ulottuu myös siihen, kuinka Amazon itse on rakennettu. Dadgar selittää, että teknologiset lähestymistavat, kuten mikropalvelut, ovat työkaluja tukemaan suurempaa prosessiliikettä kohti DevOpsia. Jeff Bezosin "Two Pizza Rule" toimii niin, että vain viidestä kahdeksaan ihmistä on missä tahansa Amazon-joukkueessa. Jos joukkue kasvaa, silloin se jakautuu kahteen osaan.
Amazonin organisaatiohierarkia alkaa kartoittaa sitä, mitä Dadgar kuvaa "toiminnallisuuden hajoamiseksi". Jokaisella joukkueella, joka on erotettu sekä organisaation että modulaarisen arkkitehtuurin tasolla, on sitten mahdollisuus kehittää ja kokeilla vapaammin ilman tarvetta koordinoida jokaista muutosta - samalla kun se toimii yhtenä yhtenäisenä sovelluksena.
"eBay otti monoliittisen lähestymistavan; he rakensivat koko eBayn pitkän, 50 miljoonan koodin sovelluslinjana", Dadgar sanoi. "Mikropalvelulähestymistapa on aluksi tuskallisempi, koska modulaarisuuteen ja yhteentoimivuuteen liittyvät ongelmat ovat sellaisia, joita ei ole monoliitissa. Mutta asiat alkavat hajottua, kun sovellus kasvaa liian suureksi. Monoliitissa hajoamista ei tapahdu.
"Ajattele satoja tai tuhansia kehittäjiä, jotka tekevät yhteistyötä yhdessä kooditietokannassa ja yrittävät koordinoida toimintaa. Sovelluksen yhdelle puolelle toiminnallisuutta lisäävä laadunvarmistusryhmä voi rikkoa jotain toisella puolella, koska rooleja ja vastuita ei ole selvästi erotettu toisistaan. Korjaaminen se, tarvitset yhä enemmän koordinaatiota projektipäälliköiden välillä ja laadunvarmistusprosessin, joka voi viedä viikkoja ja pullonkaulakehityksen riippumatta siitä, kuinka nopeasti tämä tiimi toimii. Liian paljon kokkeja keittiössä."
Kontit ja mikropalvelut DevOps-maailmassa
Tapa, jolla yrityksesi toteuttaa mikropalveluarkkitehtuurin, menee pitkälle kohti määrittämistä, kannattaako sijoitus vai ei. Mikropalvelut ovat paljon työtä eteenpäin, etenkin sovellusliittymien integroinnissa, joka tarvitaan varmistamaan, että kaikki palvelut puhuvat keskenään. Hilwa selitti, että se on vielä monimutkaisempaa, kun yritetään integroida mikropalveluita olemassa olevaan järjestelmään; hän suosittelee, että yritykset rakentavat uusia järjestelmiä aina kun se on mahdollista, sen sijaan, että suunnitellaan uudelleen vanha monoliittinen sovellus mikropalveluihin.
"Perinteisiin järjestelmäarkkitehtuureihin sisältyy tyypillisesti suuria, monimutkaisia tietokantajärjestelmiä, joissa on yksityiskohtaiset normalisoidut mallit", Hilwa sanoi. "Tällaisten järjestelmien asettaminen pienemmiksi komponenteiksi omilla itsenäisillä järjestelmillään vaatii paljon tietokannan suunnittelutyötä ja suurimman osan sovelluslogiikan tehokkaasta uudelleenkirjoittamisesta. Tämä on useimmissa tapauksissa yleensä kustannus- ja aikakielto."
Jos suunnittelet vanhan sovelluksen uudelleen, Hilwa neuvoo sinua tekemään sen asteittain. Vaikka mikropalvelut ovat jopa tärkeämpiä kuin API-integrointi, ne eivät toimi ilman sen takana olevaa DevOps-kulttuuria. HashiCorpin Dadgar kertoi, että kun kyse on DevOpsin suuremmasta sateenvarjosta, mikropalveluista tulee työkalu helpottamaan suurempaa prosessin siirtymistä kohti perustavanlaatuista muutosta työnkulkuihin, joiden avulla toimitamme sovelluksia. Hän viittasi HashiCorpin Taoon, joka esitettiin, kun hän ja perustajajäsenet Mitchell Hashimoto perustivat yrityksen: yksinkertainen, modulaarinen ja muokattava.
"DevOps on jossain mielessä jopa ylikuormitetumpi termi kuin mikropalvelut", Dadgar sanoi. "Mutta yritys koostuu ihmisistä, joilla on erilaisia erikoisosaamisia: kehittäjiä, operaattoreita, turvallisuushenkilöitä. Ja sitten sinulla on prosessi, tapa, jolla organisoit nämä ihmiset. Sitten sinulla on työkalut tukee tätä prosessia, missä mikropalvelut ja säilytystilat ovat. käy peremmälle."
Kontit, joita on suosittu Dockerin avoimen lähdekoodin räjähdyksellä, eivät ole kaukana ainoista työkaluyrityksistä, joita yritykset voivat käyttää helpottamaan mikropalveluita. IDC: n Hilwan mukaan säilöjä käytetään nykyaikaisissa sovelluksissa osana CI / CD-työnkulkuja ja joissain tapauksissa niiden käyttöönottoa tuotantoon. Mutta hän sanoi, että mikropalvelut voivat hyödyntää myös virtuaalikoneita (VM) myös ilman kontteja.
Toisin sanoen, kun kyse on liiketoimintapilvien kehittymistavista, Docker-säilöt ja mikropalvelut ovat voimakas työkaluyhdistelmä, joka on kaiken muotoisten ja kokoisten yritysten omaksuma - aloittavista yrityksistä, kuten HashiCorp, yritystoimintajätteille, kuten Oracle. HashiCorpin Dadgar sanoi, että kontit ovat kätevä tapa, jolla Dev ja Ops (ja yhdistyksenä eri ryhmät ja palvelut) kommunikoivat keskenään.
"Mitä esineitä kuljemme kehittäjien ja operaattoreiden välillä? Mitä me kuljemme perusteellisesti ja rakennamme ympäri? Kontit ovat kätevä yksikkö kuljettamaan ympäri", Dadgar sanoi. "Ajattele globaalia yritystoimitustuotetta ympäri maailmaa. Olipa kyseessä rahtialus, tavarajuna tai kuorma-auto, se on sama yksikkö, joka virtaa koko järjestelmän läpi."
DevOps ja mikropalvelut ovat edelleen kaukana laajasta yrityskäytöstä, mutta markkinat kasvavat vain. IDC-raportin mukaan mikropalveluarkkitehtuuri siirtyy kypsymisvaiheeseen seuraavan viiden vuoden aikana. Tämä kypsyys tapahtuu DevOps-kulttuurin kantapäällä saavuttaen 50 prosenttia organisaatioista vuoteen 2020 mennessä, ohjelmistojen automaatiotyökalujen jatkuva kehitys ja halvan, skaalautuvan pilviinfrastruktuurin hallitseminen, jota tarjoavat Amazon Web Services (AWS) ja Microsoft Azure.
Dadgar kertoi, että vaikka pienellä osalla yrityksiä on tällä hetkellä DevOps ja mikropalvelut, HashiCorp on jo huomattavasti ylimerkitty. Se saavutti ensimmäisen seitsemän luvun liikevaihtonsa vain yhdeksän kuukauden yritysmyynnin jälkeen useiden miljoonien kuukausittaisten aktiivisten käyttäjien avoimen lähdekoodin yhteisön lisäksi GitHubilla. Mikropalvelut ovat vain osa HashiCorpin työnkulun sovellusten työkaluputkistoa ja suurempaa DevOps-infrastruktuurin etenemissuunnitelmaa. Yrityksen rakentaman modulaarisuus ja yhteentoimivuus ovat kuitenkin edistäneet Piilaakson yhden kuumimpien ohjelmistoyritysten meteorista nousua.
"Neljä vuotta sitten, kun aloitimme, menisimme kokouksiin ja piirsimme visioamme infrastruktuurin hallinnasta", Dadgar sanoi. "Meitä ei nauroitu tarkalleen huoneesta; tiesimme, että se oli jo varhaisessa vaiheessa. Mutta nyt Terraformin kaltaiset työkalumme ovat matkalla kohti alan standardeja. Näemme kilpailupaineen dominovaikutuksen ja Pitkällä aikavälillä tehtävämme on työskennellä CIO: n ja CTO: n kanssa ymmärtääksemme prosessin muutosta, joka heidän on toteutettava.
"Ajattele Toyotaa takaisin päivässä", Dadgar jatkoi. "Sinulla oli joukko autoyhtiöitä, jotka rakensivat tuotteita, mutta kustannukset olivat korkeammat kuin sen pitäisi olla. Toyota ei keksinyt uudestaan mitä auto oli. He olivat vain tiukempia ja inkrementaalimpia prosessissa ja siirtyivät nauravaksi voimanpesäksi pakottaen Muut teollisuudenalat noudattavat samoja käytäntöjä kilpailukyvyn säilyttämiseksi. Tällä hetkellä alan johtajat kysyvät, miten he voivat saada kilpailuetua, ja heidän vastauksensa on markkinoiden Googlesin ja amazonien käytäntöjen omaksuminen. kohta, se osuu kriittiseen massaan."
