Omarkitektur för nonstop innovation

Många företag bygger sina egna mjukvarutjänster med monolitiska arkitekturer.

Denna strategi har fördelar: att designa och distribuera monolitiska system är i allmänhet okomplicerat initialt. När applikationer blir allt mer sofistikerade kan det bli svårt att upprätthålla utvecklarnas produktivitet och driftsättningshastighet, vilket resulterar i system som är dyra, tidskrävande och farliga att distribuera. Det här dokumentet visar hur du omarbetar dina appar till ett molnbaserat paradigm som gör att du kan påskynda leveransen av nya funktioner även när dina team expanderar, samtidigt som du ökar mjukvarukvaliteten och uppnår högre nivåer av tillförlitlighet och tillgänglighet.

När tjänsterna och de team som ansvarar för dem expanderar tenderar de att bli svårare att anpassa och hantera, samt mer komplicerade. Det blir svårare att testa och distribuera, lägga till nya funktioner och upprätthålla stabilitet och tillgänglighet.

Det är möjligt för företag av alla storlekar och inom alla discipliner att uppnå höga nivåer av mjukvaruleveransgenomströmning, tjänstestabilitet och tjänsttillgänglighet, enligt forskning utförd av Google DORA-teamet. Högpresterande team kan distribuera flera gånger per dag, leverera ändringar i produktionen på mindre än en dag, återställa tjänsten på mindre än en timme och uppnå felfrekvenser mellan 0 och 15 %.

Dessutom kan bra prestationer förbättra utvecklarnas produktivitet, mätt som antalet distributioner per utvecklare och dag, även när de utökar sina team.

Vad är en inbyggd molnarkitektur?

Att bygga, testa och distribuera monolitiska applikationer måste utföras som en enda enhet. Ofta ändras eller konfigureras operativsystemet, mellanprogramvaran och språkstacken för en applikation. Skript och procedurer för applikationsutveckling, testning och distribution är ofta unika för varje applikation. Detta är enkelt och effektivt för greenfield-applikationer, men när dessa system expanderar blir det svårare att modifiera, testa, distribuera och köra dem.

När systemen expanderar ökar dessutom antalet och komplexiteten hos de team som är ansvariga för att utveckla, testa, distribuera och driva tjänsten. Det är populärt men felaktigt att dela upp team efter funktion, vilket resulterar i överlämningar mellan team som ökar ledtider och batchstorlekar och resulterar i avsevärd omarbetning. Forskning utförd av DORA visar att högpresterande team är dubbelt så benägna att bygga och distribuera programvara som ett enda tvärfunktionellt team.

Bland symptomen på detta tillstånd är:

• Långa, ofta trasiga byggprocesser
• Sällsynta integrations- och testcykler
• Ökad ansträngning krävs för att stödja bygg- och testprocesserna
• Minskad utvecklarproduktivitet
• Smärtsamma implementeringsprocesser som måste utföras utanför kontorstid, vilket kräver schemalagda driftstopp
• Betydande ansträngning för att hantera konfigurationen av test- och produktionsmiljöer

Övergång till molnbaserad

Många företag har implementerat en "lyft-och-skift"-metod för att migrera sina tjänster till molnet.

I denna metod är inga små systemändringar nödvändiga, och molnet hanteras i huvudsak som ett konventionellt datacenter, även om ett som erbjuder mycket överlägsna API:er, tjänster och administrationsverktyg än konventionella datacenter.

Men bara lyft och skift erbjuder ingen av fördelarna med den molnbaserade modellen som diskuterats ovan.

På grund av priset och svårigheten att överföra sina applikationer till en molnbaserad arkitektur, vilket inkluderar att tänka om allt från applikationsdesign till produktionsverksamhet och hela mjukvaruleveranslivscykeln, stannar många företag i lyft-och-skift-fasen. Denna oro är berättigad: flera stora företag har misslyckade fleråriga "big bang"-initiativ för omplattformar.

Svaret är att anta ett progressivt, iterativt och evolutionärt tillvägagångssätt för att omarbeta dina system till molnbaserade, så att team kan lära sig att arbeta framgångsrikt i detta nya paradigm samtidigt som de fortsätter att producera ny funktionalitet: detta är en "flytta-och -förbättra" strategi.

Tillämpningen av strypfikon är ett framträdande motiv i evolutionär arkitektur. Istället för att bygga om system från grunden, utveckla nya funktioner på ett modernt, molnbaserat sätt, men låt dem kommunicera med det gamla monolitiska programmet för befintlig funktionalitet. Byt nuvarande funktionalitet gradvis över tiden, allt efter behov för den konceptuella integriteten hos de nya tjänsterna.

Ladda ner Google Clouds whitepaper för att lära dig mer om Re-architecting för nonstop innovation endast på Whitepapers Online.