Monolityske tsjin microservices-softwarearsjitektuer

Gearfetting

Dizze wike bin ik nei Gotenburg flein om minsken fan in grut ynternasjonaal skipfeartmaatskippij te moetsjen, om te praten oer de ûntwikkeling fan software op ûndernimmingsnivo. Yn de gearkomste siet in oantal saakkundigen, en ien fan harren frege my oer it kiezen fan de krekte softwarearsjitektuer (foar grutte, komplekse apps op ûndernimmingsnivo). In tige goede fraach, wol wurdich foar in blogberjocht.

Folsleine tekst

Softwarearsjitektuer

As do apps ûntwerpst moatst net allinnich tinke oan it uterlik en it gefoel, goed ûntwerp omfettet ek hoe't alles gearwurket. Softwarearsjitektuer ferwiist nei de fûnemintele struktueren fan in softwaresysteem, elke struktuer bestiet út eleminten, relaasjes tusken harren, en eigenskippen fan sawol de eleminten as harren relaasjes.

It is te fergelykjen mei de arsjitektuer fan in gebou. As in arsjitektuer ienris fêststiet en ymplemintearre is, wurdt it djoer om it efterôf te feroarjen. It is dêrom in goed idee om de krekte softwarearsjitektuer te kiezen foardat do begjinst te bouwen.

Foar ienfâldige apps kin de softwarearsjitektuer fanselssprekkend wêze, mar as dyn applikaasje grutter wurdt en mear funksjes kriget, kin it tal struktueren yn in systeem rap groeie. Dat kin mei de tiid barre, as de behoeften fan dyn klant grutter wurde. Hoe mear struktueren, hoe mear relaasjes tusken harren, hoe yngewikkelder it wurdt.

Omgean mei komplekse softwareûntwerpen

As do ferwachtest dat dyn software in soad ferskillende dingen ôfhannelje moat, is de kâns grut datst te meitsjen krigest mei kompleksiteit. Fan in arsjitektoanysk eachpunt út binne der ferskillende oanpakken om mei dizze softwarekompleksiteit om te gean.

Monolityske arsjitektuer

It bêste te beskriuwen as ‘ien grut blok’ is de monolityske arsjitektuer. Hjir is alles wat dyn app docht diel fan deselde koadebasis.

Yn in “monolityske arsjitektuer” is de software faak yn lagen opdield, wêrby't elke laach bestiet út ferskillende soarten komponinten:

• presintaasjelaach: ferantwurdlik foar de brûkers- en/of applikaasjeprogrammearynterface (UI / API).
• bedriuwslogika: dit is wêr't de eigentlike bedriuwsregels definiearre wurde. It is de kearn fan de applikaasje dy't tige nau oanslút by de werklike bedriuwsprosessen.
• gegevenstagongslaach: soarget foar in mienskiplike ynterface tusken de draaiende applikaasje en de bliuwende backend-opslach.
• databank en bestânsysteem: hjir wurde alle gegevens en statyske aktiva (bestannen, ôfbyldings, ensfh.) opslein.

Hoe grutter de applikaasje wurdt, hoe grutter elke laach wurdt. Dat makket it lestiger om in monolityske arsjitektuer mei te laten groeie, op in bepaald punt wurde dingen gewoan te grut en te yngewikkeld.

Elke kear as do in feroaring yn de applikaasje oanbringst, hat dat ynfloed op de hiele koadebasis. Foar (tige) grutte applikaasjes makket dat it lestiger om de software te ûnderhâlden, want it freget in folslein begryp fan de hiele applikaasje.

Om't de hiele applikaasje fan inoar ôfhinklik is, hawwe problemen yn ien diel faak grutte gefolgen foar it hiele systeem. De kommunikaasje tusken de ferskillende dielen fan it systeem giet yntern, op koadenivo. Dat betsjut dat de ferskillende dielen programmearre wurde moatte yn deselde (of kompatibele) programmeartaal. Dat is in drompel om (yn de takomst) nije technologyen oan te nimmen, want do kinst de programmeartaal fan ien diel fan it systeem net sa maklik feroarje.

Microservices-arsjitektuer

Yn plak fan ien grutte monolityske applikaasje te bouwen kinst dyn applikaasje opsplitse yn lytsere, ûnderling ferbûne tsjinsten. Elke microservice is in lytse applikaasje op himsels, ynklusyf in eigen (mar lytsere + ienfâldigere) arsjitektuer, bedriuwslogika en gegevenslagen.

De ferskillende tsjinsten kommunisearje mei inoar fia API’s dy't ûnôfhinklik fan de brûkte technology definiearre wurde, faak yn in mienskiplike “API-struktuer” lykas REST, JSON, Redis en XML. Dat makket it mooglik dat de kombinaasje fan microservices as “ien systeem” funksjonearret.

Troch de ‘grutte blok’-applikaasje op te brekken yn lytsere tsjinsten, wurdt it makliker om ferskillende dielen fan it systeem te begripen. Dat makket it makliker om it systeem te ûnderhâlden, want elke microservice kin ûnôfhinklik ûntwikkele wurde. It ferleget ek de drompel om nije technologyen oan te nimmen, want do bist frij om de technology te kiezen dy't it bêste past by in bepaalde tsjinst. Ien diel fan it systeem kin programmearre wurde yn in oare taal as de oare dielen. Dat makket it mooglik dat ferskillende teams (mei ferskillende saakkennis) gearwurkje.

De keunst en feardigens om de microservices-arsjitektuer goed te krijen, komt fan it fermogen om in microservice korrekt te definiearjen. Te breed of te fyn kin de arsjitektuer ferneatigje. Do kinst bedriuwsprosessen, hierargy of domeinskieding brûke om elke microservice te definiearjen.

De útdaging fan de microservice-arsjitektuer is dat it it hiele systeem yngewikkelder makket, om't der in ferdield kommunikaasjemeganisme nedich is. De ferskillende API’s dy't mei inoar ferbine, kinne lestich te testen en te debuggen wêze. It wurdt lestiger om feroaringen troch te fieren dy't meardere tsjinsten treffe.

It definiearjen, ûntwerpen en ymplemintearjen fan de ferskate ynterservice-API’s freget in oerienkomst oer de útwiksele gegevens, dat kin lestich te berikken wêze as do fan plan bist útwreide en net-universele gegevensstruktueren te dielen.

It monitoaren en útrollen fan in microservice-arsjitektuer kin yngewikkeld wurde as it tal tsjinsten grutter wurdt. Der is gewoan mear te behearen, wat mear planning en koördinaasje freget foar elke tsjinst.

De krekte arsjitektuer kieze

Myn heit, dy't der net mear is, fertelde my ienris dat do “it measte fertsjinje kinst oan de dingen dy't do net docht”. It bouwen fan komplekse applikaasjes is út syn natuer dreech, it bêste wat do dwaan kinst is besykje dingen ienfâldiger te meitsjen troch gewoan net alles te dwaan. Rjochtsje dy op de dingen dy't echt wichtich binne, doch dy dingen goed.

As dyn applikaasje ienfâldich en lichtgewicht is, is in monolityske arsjitektuer de wei om te gean. Ûntwikkeling, útrol, ûnderhâld, alles is makliker as dingen lyts binne.

As do de kompleksiteit net ûntkomme kinst, dan moatst perfoarst de microservice-arsjitektuer oerweagje. Stel dysels de folgjende fragen:

• Bist do yn steat om in “mienskiplike taal” te definiearjen tusken dyn microservices?
• Binne der dúdlik ûnderskate bedriuwsprosessen?
• Hoe sterk binne dizze bedriuwsprosessen fan inoar ôfhinklik?
• Hoe ferwachtest do dat dyn applikaasje mei de tiid ûntwikkelet, ferwachtest do dat dy groeit of krimpt?
• Hoefolle ferskillende programmeartechnologyen bist do fan plan te brûken? Ferwachtest do dat dat yn de takomst feroaret?
• Wa giet de software bouwe en ûnderhâlde, hawwe sy ûnderfining mei it behearen fan sa’n arsjitektuer?

Konklúzje

Der is gjin “wûnderoplossing” op de fraach hokker softwarearsjitektuer de krekte is. Beide oanpakken hawwe harren foar- en neidielen.

It bêste wat do dwaan kinst is in bewuste - goed oerwagen - beslissing nimme en der folslein foar gean!