Det har varit en industri mantra i flera år nu: monoliter är otymplig, oflexibel djur att stoppa allt och alla innovation i dess spår. Men många företag har monoliter i en eller annan form att de har försökt att bryta ner – såsom traditionella ERP-och MRP-system eller storskaliga system transaktionen.
Foto: Joe McKendrick
Tro det eller ej, det finns några bra saker att säga om monoliter. Ellen Körbes, chef för developer relations på Trädgården, för en, påpekade nyligen i en presentation att “det är något som vi hade med monoliter på grund av denna enkelhet magi av programmering var det.” Hon påminner om hur med monoliter, det är lätt att lära sig systemet för första gången. Du har ett stort system, så att du har ett programmeringsspråk, du har en uppsättning av regler, en uppsättning konventioner, och du har en stor en-bygga-kommandot.”
Naturligtvis, Körbes inte se monolitiska system i någon framtid, och erbjuder en öppen källkod plattform för att bryta ner och bygga en microservices arkitektur.
I en separat presentation, Kelly Sutton, teknisk chef på Gusto, diskuteras konsekvenserna av monolith-smashing — särskilt de som är byggda på Ruby on Rails-men hans råd som kan tillämpas på många programmeringsspråk och ramverk som har blivit för stora för att misslyckas.
Till att börja med, problemet med att flytta funktionalitet av en monolit och i microservices är att båda versionerna kommer att behöva underhållas och uppdateras, Sutton påpekar. “Vi har faktiskt skapat ett problem som är värre än vi hade, säger han. “Vi bokstavligen skapats tribal kunskap i vårt system. Nu när vi vill gå ut och hitta en HR-koncept har vi för att gå och fråga någon, ” hej, är att en HR-v2 eller är det i den gamla HR bihang som är bara typ av stickning runt?'”
Problemen växa som ett program eller tjänster skala. Som har fattat beslut om att bryta ut en funktion som en tjänst, såsom HR namn, adresser och personnummer, uppgifter och funktioner kan fortfarande vara delad mellan den nya och gamla program — HR-v1-och HR-v2.
Sutton illustrerar vilka frågor uppstår som monoliter bryts isär:
“Vi räkna upp alla de saker som HR-v1 gör idag. Låt oss säga att det är som 14 saker, och då vi börjar sakta att ansluta den tillbaka till huvudsaken, minutiöst kommer en efter en och flytta dessa 14 beteenden över. Men oftast omkring som halvvägs igenom blir det någon heltidsjobb att bara säga ” okej vad är i HR-v2 och vad som finns i HR-v1.’ Gå lite längre och du är fortfarande få felrapporter mot den gamla HR-system, så nu du säger: “okej, så jag antar att vi åtgärdat felet i den gamla HR-system, men vi måste återskapa det i den nya och sedan fixa det där.'”
Följande är rekommendationer för att bryta isär monoliths utan att komplicera saken ytterligare:
Undvik cirkulära beroenden. Hur gör man för att bryta isär ett monolitiskt system och utveckla en microservices-baserad arkitektur? “Svaret är “plågsamt”, säger Körbes, som konstaterar monolitisk beroenden som bytte från en annan form av beroenden. “Service beroenden är en smärta att hantera. Om jag ändrar min leveransadress service, jag kanske måste uppdatera min order service, och kan jag ändra min order service, jag kanske måste uppdatera min front-end service, eftersom saker och cascade. Jag kan inte bara ändra en sak och förvänta sig att det inte var det.” Skillnaden med monolitisk program är “du har en kompilator, och kompilatorn kan göra beroendegraf för dig.”.
Använd värdet objekt till adress skalning frågor. Som ett exempel, Sutton säger, “vi har en tjänst klass eller objekt som hanterar” vad ska hända när ett företag skriver upp i vår ansökan?’ Vi kommer att skicka ett e-postmeddelande och plussa på lite statistik tränare disk. Här ser ofarlig nog. Små program som kan göra detta. Men vad vi faktiskt har gjort är för evigt tillsammans vårt företag mailer i vår statistik tracker till strukturen av vårt företag-modellen. Detta är förmodligen inte så stor grej, men som vårt program växer, kan det vara mycket, mycket svårt att reda ut. Så istället, vi skal bara de värderingar som vi behöver mindre av de rika aktiv registrera objekt, förvandla dem till värden. kanske ge dem buntar av värden, och sedan skicka dem vidare till vad efterföljande klass eller metod som de behöver för att göra sitt jobb rätt.”
Gå långsamt. Att bryta isär monoliter i distribuerade tjänster kommer att kräva några noggranna överläggningar. “Du har en stor hög av koden och du dela den i 20 bitar och du lägger lite utfyllnad till det och några av dessa bitar är nu ett annat programmeringsspråk, säger Körbes. När du går till microservices, du lägger till saker till det, så det kommer att bli långsammare.” Plus, det är kanske hundratals ytterligare programmering timmar som är inblandade, Sutton säger. “Du måste sitta ner med din produkt lag och säga:” Okej, vi ska göra detta och sedan allt kommer att bli snabbare över tiden men nu är ingenting som kommer att förändras. Vi kommer att refaktorera rätt. Du måste göra ett starkt business case för hur detta kommer att hjälpa dig att snabba upp och hjälpa dig att utveckla säkrare programvara, oavsett hur dålig den aktuella koden är idag.”
Relaterade Ämnen:
DET Prioriteringar
Cloud
Big Data Analytics
Innovation
Tech och Arbete
Samarbete