Det er blevet en industri mantra i mange år nu: bautasten er tungt, ufleksibel og dyr at standse enhver og alle innovation i dens spor. Men mange virksomheder har bautasten i en eller anden form, at de har forsøgt at bryde ned – sådan som traditionelle ERP-og MRP-systemer eller store transaktion systemer.
Foto: Joe McKendrick
Tro det eller ej, der er nogle gode ting at sige om bautasten. Ellen Körbes, leder af udvikler relationer til Have, til en, der er påpeget i en nylig præsentation, at “der er noget, som vi havde med bautasten på grund af denne enkelhed magien i programmering var der.” Hun minder om, hvordan du med bautasten, det er nemt at lære systemet for første gang. Du har et stort system, så du har et programmeringssprog, du har en sæt af regler, et sæt af konventioner, og du har en stor én-build-kommando.”
Selvfølgelig, Körbes ikke se monolitiske systemer i nogen fremtid, og byder på en open source platform til at nedbryde og genopbygge en microservices arkitektur.
I en særskilt præsentation, Kelly Sutton, engineering manager ved Gusto, diskuteret konsekvenserne af monolith-smashing — især dem, der er bygget på Ruby on Rails — men hans råd kan anvendes til mange programmeringssprog og frameworks, som har vokset sig for store til at krakke.
For startere, er problemet med at flytte funktionalitet ud af en monolit, og i microservices er, at begge versioner bliver nødt til at blive vedligeholdt og opdateret, Sutton påpeger. “Vi har faktisk skabt et problem, der er værre, end vi havde,” forklarer han. “Vi bogstaveligt talt skabt tribal viden i vores system. Nu, når vi ønsker at gå ud og finde en HR-koncept, vi har til at gå spørge nogen, ” hey, er, at en HR-v2 eller er der i den gamle HR-vedhæng, der er bare lidt for at holde sig omkring?'”
Problemerne vokse som programmer eller tjenester skala. Som det er besluttet at bryde ud af en funktion som en service, såsom HR navne, adresser og cpr-numre, data og funktioner kan stadig være delt mellem de nye og de gamle programmer — HR-v1-og HR-v2.
Sutton illustrerer, hvilke spørgsmål der opstår som bautasten er brudt ud:
“Vi opremse alle de ting, som HR v1 gør i dag. Lad os sige, det er ligesom 14 ting, og så kan vi langsomt begynde at forbinde det tilbage til hovedprogrammet, omhyggeligt kommer en efter en, og flytte disse 14 adfærd over. Men som regel omkring, som om det halvvejs igennem, bliver det en person på fuld tid job bare for at sige, ” okay, hvad der er i HR-v2, og hvad der er i HR-v1.’ Gå en lille smule længere, og du stadig får fejlrapporter mod den gamle HR-system, så nu er du siger, ” okay, så jeg tror, at vi har rettet fejlen i den gamle HR-system, men vi er nødt til at genskabe det på ny og derefter ordne det der.'”
Følgende er anbefalinger til at bryde fra hinanden bautasten uden at komplicere sagen yderligere:
Undgå cirkulære afhængigheder. Hvordan kan man bryde ud af et monolitisk system og udvikle en microservices-baseret arkitektur? “Svaret er “pinligt”, ” siger Körbes, der bemærker, monolitisk afhængigheder er ved at blive omlagt fra en anden form for afhængighed. “Service afhængigheder er en smerte at styre. Hvis jeg ændre min forsendelse service, jeg måske nødt til at opdatere min ordrer service, og hvis jeg ændre mine ordrer service, jeg måske nødt til at opdatere min front-end service, fordi tingene cascade. Jeg kan ikke bare ændre på en ting, og forventer, at det ikke er til at være der.” Forskellen med monolitisk programmer er “du har en compiler, og compileren kunne gøre afhængighed grafen for dig.”.
Brugen af værdi genstande til at løse opskalering. Som et eksempel, Sutton siger, “vi har en service klasse eller et objekt, der håndterer ‘, hvad der skal ske, når en virksomhed skilte op i vores program?’ Vi skal nok sende en e-mail og tilvækst nogle statistikker træner tæller. Det ser uskyldigt nok. Små applikationer, der kan gøre dette. Men hvad vi har faktisk gjort, er for evigt koblet vores virksomhed mailer i vores statistik tracker til strukturen af vores forretningsmodel. Dette er sandsynligvis ikke det store af en deal, men da vores ansøgning vokser, kan det være meget, meget svært at rede ud. Så i stedet for at vi skræl bare de værdier, som vi har brug for ud af de rige aktive optage objekter, omdanne dem til værdier. måske giver de bundter af værdier, og så bare give dem sammen til, hvad den efterfølgende klasse eller metode, som de har brug for at gøre deres job, højre.”
Bevæge sig langsomt. At bryde fra hinanden bautasten i distribuerede tjenester kommer til at kræve nogle grundige overvejelser. “Du har en stor bunke af koden, og du dele det op i 20 forskellige bidder, og du lægger nogle polstring til det, og nogle af disse stykker er nu et andet programmeringssprog,” siger Körbes. Når du går til microservices, du tilføjer ting til det, så det kommer til at være langsommere.” Plus, der er måske hundredvis af ekstra programmering af timer, der er involveret, siger Sutton. “Du er nødt til at sidde ned med din produkt teams og siger,” Okay, vi skal nok gøre det, og så tingene kommer til at få hurtigere over tid, men for nu intet kommer til at ændre sig. Vi kommer til at refactor højre. Du er nødt til at gøre en stærk business case for, hvordan dette kommer til at hjælpe dig med at fremskynde og hjælpe dig med at udvikle sikrere software, uanset hvor dårlig den aktuelle kode er i dag.”
Relaterede Emner:
DET Prioriteter
Cloud
Big Data Analytics
Innovation
Tech og Arbejde
Samarbejde