Hantera risker under applikationsmodernisering

Published on 28 Aug 2020

Företag som vill utnyttja plattform-som-en-tjänst (PaaS) som Pivotal Cloud Foundry och Red Hat Open shift, börjar vanligtvis med två applikationsmiljöer:

Nya initiativ (greenfield) som kan byggas från grunden med hjälp av molnbaserade bästa praxis

  • Befintliga applikationsmiljöer (brownfield) som de skulle vilja modernisera för molnets smidighet, skalbarhet och prestandafördelar
  • Många av de befintliga arbetsbelastningarna (brownfield) är viktiga applikationer för verksamheten, genererar betydande intäkter och är känsliga för störningar. Även om det skulle vara idealiskt att helt omarbeta dessa applikationer med hjälp av molnbaserade principer, är det i allmänhet inte praktiskt eller kostnadseffektivt att göra det.

Denna genomgång ger praktiska råd och bästa praxis om var och hur man kommer igång med omstruktureringen av en monolitisk applikation. I kombination hjälper detta IT-team att påskynda moderniseringsprocessen och minskar risken för att påverka kundhändelser och affärsprocesser längs vägen.

Var ska man börja?

Identifiera kandidater och komponenter för refactoring

Innan vi börjar, låt oss sätta scenen med ett par antaganden:

Du börjar med en välstrukturerad monolit:

Innan du startar processen med att omstrukturera element i din monolit måste du göra en del arbete för att säkerställa att den är välstrukturerad. Om du inte är säker på om du börjar med en välstrukturerad Monolith, läs mer genom att ta en titt på den här videon "Modular Monoliths" av Simon Brown (@simonbrown), en industrikonsult inom mjukvaruarkitektur.

Du använder DevOps praxis och verktyg:

För att få ut det mesta av cloud-native måste du följa DevOps bästa praxis och använda automationsverktyg för kontinuerlig integration (CI)/kontinuerlig leverans (CD). För mer information om detta, ta en titt på e-boken "Lessons Learned While Writing The DevOps Handbook" av författare: Gene Kim, Mark Tomlinson, Andi Grabner.

Vad är en monolit och hur refaktoriserar jag den?

Vi tenderar att tänka på monoliter som något dåligt i dagens nya värld av distribuerade, löst kopplade applikationsarkitekturer. Om du har en välstrukturerad monolit är de enda dåliga delarna med den att det är en enda kodbas och för att skala den måste du skala hela saken. I själva verket, "Ur ett mjukvaruperspektiv är en monolit en kombination av affärsförmågor eller avgränsade sammanhang, alla inblandade i en kärnkontext. Processen att omvandla en app till en mikrotjänstbaserad arkitektur innebär separation av var och en av dessa avgränsade sammanhang i sina egna sammanhang.”

Se även : 3 fördelar med Citrix ADC med flexibel licensiering

Ladda ner för att läsa hela vitboken om hantering av risker under applikationsmodernisering

Icon
THANK YOU

You will receive an email with a download link. To access the link, please check your inbox or spam folder