Azure-tekniker för byggprocessen

  • 10 minuter

I den här lektionen får du lära dig relationen mellan innovationsprocessen och några av teknikerna i branschen som kan hjälpa dig att skapa nya funktioner i program.

DevOps

När du har startat byggfasen för att verifiera din innovationshypotes bör de nödvändiga utvecklings-, integrerings- och distributionscyklerna vara så effektiva som möjligt. I den här fasen kommer DevOps in i den här fasen. Du kan definiera DevOps som "processer och verktyg för att leverera programvarufunktioner snabbt och tillförlitligt". Här följer information om den här definitionen:

  • Processer och verktyg: DevOps och innovationsprocessen som helhet baseras på kulturmönster som uppmuntrar till förändring. Azure och GitHub erbjuder bra verktyg kring DevOps, men det räcker inte att köpa en licens. Dina processer och din organisationskultur måste utvecklas för att ta till sig förändringar och innovation.

  • Snabb leverans av programvarufunktioner: DevOps-processer och -verktyg omfattar konceptet att misslyckas snabbt. Att skapa MVP:er eller prototyper för att snabbt verifiera om funktionen som du arbetar med går i rätt riktning är kärnan i begreppet DevOps.

  • Tillförlitlig leverans av programvarufunktioner: Organisationer med ändringsavvikande associerar ofta snabba ändringar med stilleståndstid. DevOps lovar dock precis motsatsen: en snabb ändringsfrekvens och en hög tillförlitlighetsnivå. Den här tillförlitligheten möjliggörs genom integrering av testning i tidiga skeden av utvecklingscykeln, i en process som kallas "skift till vänster".

    Om utvecklingen av en funktion över tid ses som en linje från vänster till höger. Sedan skulle en äldre utvecklingsprocess utföra användarverifiering och kvalitetskontroll i slutet av utvecklingscykeln. I den högra änden av den raden. DevOps rekommenderar att du testar och validerar så tidigt som möjligt, till vänster om den tidsperioden.

DevOps förkroppsligar samma grundläggande begrepp i en sund innovationskultur. Det är viktigt att använda metoden för att komma till en flexibel innovationscykel.

Arkitekturer för mikrotjänster

Modularitet är en välkänd teknik för att minska komplexiteten i arkitekturen av komplexa system. Om ett system är en komplex interaktion mellan många delar som inte kan tas isär (kallas ofta en "monolit"), gör snäva komponentberoenden systemförbättringar svåra. Varje ändring måste verifieras med resten av systemet, så testprocessen är komplex.

Om systemet är modulärt kan du dela upp det i mindre undersystem som interagerar med varandra via väldefinierade gränssnitt. Det är enklare att införa ändringar i något av dessa undersystem, eftersom det övergripande systemet fortsätter att fungera så länge dess gränssnitt med de andra modulerna förblir konstant.

Mikrotjänstarkitekturer är programmönster som utnyttjar modularitet. Program delas in i separata, små komponenter som kan utvecklas oberoende av varandra, eventuellt även med olika programmeringsspråk. Varje komponent, eller mikrotjänst, kan fungera på egen hand. Du kan skala den efter behov, du kan felsöka den som en enda enhet, du kan ändra den oberoende av de andra mikrotjänsterna.

En fråga som organisationer ofta ställer sig är vad man ska göra om ett program är monolitiskt. Ska organisationen göra om programmet till en mikrotjänstarkitektur innan innovation introduceras, eller kan innovationen och omdesignprocesserna köras parallellt? Det finns inget enskilt svar på den här frågan. Det beror på komplexiteten och affärsrelevansen för det aktuella programmet.

Tailwind Traders ställdes inför den här frågan när de tittade på att introducera innovation i sin e-handelsplattform. Företaget bestämde sig för att starta ett projekt för att omforma e-handelsappen till en arkitektur för mikrotjänster, eftersom programmets affärskritiskhet motiverade detta arbete. Att inte ha ett modulärt program skulle allvarligt försämra Tailwind Traders förmåga att reagera på föränderliga trender på onlinemarknaden.

Tailwind Traders tog dock beslutet att ta itu med några av de stora luckor i sin plattform samtidigt. Att vänta på att programomdesignprojektet ska slutföras skulle innebära att man förlorar betydande marknadsandelar till de nya nystartade företag som stör e-handelsmarknaden just nu.

Projekten ska interagera med varandra, som styrs av innovationernas affärsvärde. Omdesignarbetet är att fokusera på de mest kritiska programområdena, där behovet av ändringar för att förbättra kundupplevelsen är som störst.

Containers

Tekniken för containerisering är inte exklusiv för mikrotjänstarkitekturer, men begreppen fungerar tillsammans. Containrar är ett sätt att kapsla in programkod och dess beroenden så att de enkelt kan distribueras på valfri plattform.

Traditionella programdistributioner kräver att organisationen installerar programvara först, till exempel programkörning, programmeringsbibliotek eller externa komponenter. Den här metoden resulterar ofta i problemet "det fungerar på min dator": det är svårt att replikera samma miljö i utveckling, test, mellanlagring och produktion. Små skillnader i hur programberoendena installeras kan göra att programmet fungerar bra när det testas, men misslyckas när det distribueras till produktion.

Containrar ändrar spelreglerna. Programberoendena är packade tillsammans med programkoden i en autonom distributionsenhet som kallas containeravbildningen. Oavsett om programcontainern distribueras på en utvecklares bärbara dator eller i ett produktionskluster med hundratals noder är beroendehanteringen densamma. Containern fungerar på exakt samma sätt, så programtestning är mer tillförlitlig och tillförlitlig.

Containrar har kommit långt sedan Docker släppte sin kod som öppen källkod 2013. Containrar stöder nu både Linux och Windows och olika CPU-arkitekturer. Det finns många erbjudanden i Azure som gör att containerbaserade arbetsbelastningar kan köras. I den här lektionen lär du dig om några av dem.

Kubernetes och Red Hat OpenShift

En containerkörning är den teknik som startar containrar på en dator, men mer logik krävs i en produktionsmiljö. Vem distribuerar fler containrar om det krävs mer prestanda? Vem startar om containrarna om de har problem? Om flera datorer är tillgängliga, vem bestämmer vem av dem en viss container ska startas? Dessa och andra uppgifter ansvarar för en plattform för containerorkestrering.

Den första versionen av Kubernetes släpptes 2015 och blev snart de facto-standarden för containerorkestrering. Kubernetes-kluster består av flera arbetsnoder. Varje arbetsnod har en containerkörning, så att den kan köra containrar där Kubernetes-kontrollplanet schemalägger distributionen av containerbaserade program. Det här kontrollplanet körs vanligtvis i en uppsättning kärnnoder. Det är ansvarigt för att hålla programmet igång korrekt, skala upp eller ned programmet och utföra nödvändiga uppdateringar.

En av de främsta orsakerna till Kubernetes popularitet är maskinvaruberoendet som containrar tillhandahåller. Eftersom containerbaserade program kan distribueras på ett tillförlitligt sätt till valfri containerkörning kan du köra Kubernetes i moln som använder olika hypervisor-program. De distribuerade programmen bör bete sig på ett liknande sätt (förutsatt att de underliggande maskinvaruresurserna också liknar dem). Många organisationer har antagit Kubernetes som ett abstraktionslager som möjliggör konsekventa programdistributionsprocesser både lokalt och i offentliga moln.

Det är enkelt att köra Kubernetes i Azure. Azure Kubernetes Service är enkelt att distribuera och kostnadseffektivt eftersom kunden endast debiteras för kostnaden för arbetsnoderna. Microsoft bär kostnaden och driften av kontrollplanet som innehåller kärnkomponenterna. Microsoft korrigerar och uppdaterar operativsystemet för arbetsnoderna, vilket ytterligare minskar den operativa komplexiteten i att hantera ett Kubernetes-kluster för att köra Linux- och Windows-containrar.

OpenShift är en programdistributionsplattform baserad på Kubernetes, utvecklad och stöds av Red Hat. Den innehåller många andra funktioner. Vissa av de organisationer som väljer att köra sina program på OpenShift gör det på grund av dessa extra funktioner och det stöd som Red Hat tillhandahåller. Det är återigen enkelt att köra OpenShift på Azure. Azure Red Hat OpenShift består av ett OpenShift-kluster där Microsoft hanterar många av sina aspekter, inklusive hela livscykeln för klustret.

Azure App Service

Azure App Service är en plattform där organisationer kan köra sina webbaserade arbetsbelastningar utan att behöva hantera någon orkestrerare eller underliggande operativsystem. Det enda kravet är att ladda upp programkoden till tjänsten via en av många tillgängliga distributionsmetoder. Azure gör resten: skala programmet in och ut, korrigera och underhålla de underliggande virtuella datorerna och mycket mer, utan att kräva kubernetes inlärningskurva.

Azure App Service stöder containerbaserade arbetsbelastningar, så du kan ladda upp containeravbildningen i stället för programkoden. Den stöder även Linux- och Windows-arbetsbelastningar och många olika programkörningar.

Azure App Service stöder olika prismodeller, inklusive ett serverlöst alternativ som kallas Azure Functions. I Azure Functions debiteras endast programanvändning. Det finns inga fasta kostnader.

Den serverlösa modellen är intressant för innovation, eftersom den gör att du kan distribuera nya mikrotjänster utan att medföra höga månatliga fakturor om marknaden inte accepterar dem. Den här modellen är ett annat exempel på den felsnabba strategin, där innovation inte nödvändigtvis innebär höga utgifter.

Azure App Service erbjuder även funktioner som stöder DevOps-orienterade distributioner, till exempel webbappplatser. Platser är mellanlagringsområden där du kan distribuera nya funktioner utan att påverka produktionsmiljön. Slots är bra ur ett innovationsperspektiv, eftersom du kan omdirigera ett litet urval av dina kunder till den här nya versionen av programmet. Sedan kan du kontrollera om innovationshypotesen är korrekt. Om du så småningom vill höja upp den nya koden till produktion kan du "byta" fack så att mellanlagringsmiljön blir produktionsversionen.

Sammanfattning

I den här lektionen har du lärt dig hur teknik kan stödja innovation:

  • DevOps-processer och -verktyg ger dina utvecklings- och driftteam superkraften att leverera nya funktioner snabbt och tillförlitligt.
  • Du kan bygga om program till mikrotjänster för att tillåta innovation på deras komponenter individuellt, utan att påverka resten.
  • Containrar möjliggör tillförlitlig programdistribution på flera plattformar och miljöer.
  • Kubernetes är en molnagnostisk orkestreringsplattform för att köra containerbaserade program.
  • Azure App Service kan köra webbaserade arbetsbelastningar med minsta möjliga hanteringskostnader. Det erbjuder många funktioner, till exempel serverlösa eller programplatser, för att påskynda innovationscykeln.

Tailwind Traders har beslutat att börja omdesigna sin e-handelsapp till en arkitektur för mikrotjänster. Det första programundersystemet som det separerar från "monoliten" är betaltjänsten, eftersom du har identifierat det som ett kritiskt område där tävlingen erbjuder bättre värde för kunderna.

Efter betalningsundersystemet konverteras fler programkomponenter till oberoende mikrotjänster. Mikrotjänsterna kan kommunicera via REST-API:er. Programkoden för varje mikrotjänst ska containeriseras, och utvecklings- och driftsorganisationerna ska använda Metodtips för DevOps.

Eftersom Tailwind Traders inte vill vara beroende av något specifikt offentligt moln, har det beslutat att skapa Kubernetes-expertis internt och distribuera programmet i Azure Kubernetes Service-kluster. Om nya mikrotjänster behöver utvecklas har företaget valt att betrakta Azure Functions som en plattform för MVP-distribution för att minska utvecklingskostnaderna.

Var du ska titta härnäst

Många av begreppen i den här lektionen beskrivs ytterligare i cloud adoption framework-artiklarna Empower adoption with digital invention and Kubernetes in the Cloud Adoption Framework .Many of the concepts in this unit are further articulated in the Cloud Adoption Framework articles Empower adoption with digital invention and Kubernetes in the Cloud Adoption Framework.Many of the concepts in this unit are further articulated in the Cloud Adoption Framework articles Empower adoption with digital invention and Kubernetes in the Cloud Adoption Framework.