Noll
Är det värt ansträngningen att försöka att refaktorera befintliga, och sannolikt monolitisk, applikationer, som microservices, eller är en sådan tid och ansträngning bättre sätt att bygga nya, mer flexibel och smidig-program byggda av löst kopplade microservices?
Foto: Joe McKendrick
Det verkar som företagets IT-team är att ha det på båda sätten, en ny undersökning finner. Undersökningen, som genomfördes av Red Hat bland sina Red Hat JBoss Middleware och Red Hat OpenShift kundbas, anser 69 procent uppgav att de använder microservices för både nya applikationer och för en ny utformning av befintliga. “Dessa data säger oss att microservices erbjuda mervärde till alla användare med deras IT transformation resa-oavsett om de är bara ute efter att uppdatera sin nuvarande tillämpning portfölj eller laddar upp nya initiativ, säger Cesar Saavedra, författare av rapporten.
För en betydande del av den IT-chefer, fördelarna med att använda microservices var insåg relativt snabbt. En tredjedel av gruppen, 33 procent, sa att de började inse fördelarna med att inom två till sex månader i sina implementationer. Dessa fördelar var toppat med en större insikt av agile och DevOps vision, i form av continuous integration och continuous deployment (CL/CD). Förbättrad skalbarhet, snabbare tid till marknad, högre utvecklarnas produktivitet och snabbare felsökning och underhåll var andra fördelar ses som tillämpningar bröts ner i lagom storlek microservices.
Microservices-och i förlängningen, behållare — spelar en stor roll i att re-orientera förhållningssätt till större företag elasticitet, precis som internet i sig självt, och nu blockchain, var utformade i en distribuerad mode för att undvika störningar. Astasia Myers. en riskkapitalist med Redpoint Ventures, för en, ser microservices spela en tole i utvecklandet av “service maskor.” Inte längre placeras ut i en seriell eller punkt-till-punkt mode, microservices och behållare möjliggör service maskorna som “kan hjälpa till att hantera trafiken genom service discovery, routing, lastbalansering, hälso-och kontroll, och observerbarhet, styrbarhet,” Myers påpekar i ett senare inlägg. “Service maskor försök att tämja oregerliga behållare komplexitet. Vi har inte sett en utbredd användning ännu, men vi vet av företag som kör tjänsten maskor i produktion. Dessutom, service maskorna är inte exklusiva för microservices eller Kubernetes miljöer och kan tillämpas på VM och serverlösa miljöer.”
Service maskor och deras microservice och komponenter behållare möjliggör också en relativt ny, hip-klingande sak som kallas för “kaos engineering”, eller, som Myers beskriver det, “disciplin för att experimentera på ett distribuerat system för att bygga förtroende i systemets förmåga att stå emot turbulenta förhållanden.” Med andra ord, avsiktligt kastar apa skiftnycklar i delar av distribuerade system för att se hur saker och ting håller upp. Begreppet kaos teknik förfinades av Netflix, och senare praktiseras av Amazon, Google, Microsoft och Facebook, Myers lägger till. “Kaos tekniska experiment på ett system för att förbättra säkerheten i sin förmåga att klara produktionen frågor”, skriver hon. “Medan bryta system kan vara roligt, det kan inte alltid vara produktiv eller ge användbar information. Kaos engineering förkroppsligar en bredare omfattning, inte bara injicera misslyckanden men också andra symptom som trafik spikar, ovanlig begäran kombinationer, etc. för att upptäcka de problem som finns.”
Naturligtvis, genomföra eller upplösning av program till orkestrerade arrangemang av löst kopplade microservices är inte en övernattning uppgift. Utmaningar att genomföra microservices kräver att arbeta med chefer och slutanvändare i hela företaget för att omfamna det som är delbara och återanvändbara tjänster som erbjuds, Red Hat undersökningen visar. Att övervinna företagskultur och organisatoriska utmaningar är mest uttalad utmaning. Ytterligare, mer tekniska utmaningar omfattar diagnostik och övervakning microservices, tillsammans med att ägna den tid och de resurser som behövs för att deras byggnad, testning och underhåll.
Red Hat undersökningen visar också att IT-chefer är att mildra dessa utmaningar genom att utveckla och genomföra in-house microservices tooling, re-organizing deras DevOps processer, och att arbeta för ett närmare samarbete med leverantörer för att få råd och vägledning. Och kanske så småningom börja injicera lite kaos bara för att se hur det hela fungerar.
(Disclosure: jag har genomfört arbete för Red Hat, som nämns i denna undersökning, som en del av mitt arbete som en oberoende analysföretaget under de senaste 12 månaderna).
Relaterade Ämnen:
Cloud Prioriteringar
Cloud
Big Data Analytics
Innovation
Tech och Arbete
Samarbete
0