Azure-technologieën voor het buildproces
In deze les leert u de relatie tussen het innovatieproces en een aantal technologieën in de branche die u kunnen helpen bij het bouwen van nieuwe functionaliteit in toepassingen.
DevOps
Nadat u de buildfase hebt gestart om uw innovatiehypothese te valideren, moeten de vereiste ontwikkelings-, integratie- en implementatiecycli zo gestroomlijnd mogelijk zijn. In deze fase komt DevOps binnen. U kunt DevOps definiëren als 'processen en hulpprogramma's om snel en betrouwbaar softwarefuncties te leveren'. Hier vindt u informatie over deze definitie:
Processen en hulpprogramma's: DevOps en het innovatieproces als geheel zijn gebaseerd op cultuurpatronen die verandering stimuleren. Azure en GitHub bieden uitstekende hulpprogramma's voor DevOps, maar het aanschaffen van een licentie is niet voldoende. Uw processen en organisatiecultuur moeten zich ontwikkelen om verandering en innovatie te omarmen.
Snelle levering van softwarefuncties: DevOps-processen en -hulpprogramma's omarmen het concept van snel mislukken. Het bouwen van MVP's of prototypen om snel te valideren of de functie waarop u werkt in de juiste richting gaat, is de kern van het concept van DevOps.
Betrouwbare levering van softwarefuncties: Organisaties met wijzigingen kunnen vaak snelle wijzigingen aan downtime koppelen. DevOps belooft echter precies het tegenovergestelde: een snelle wijzigingssnelheid en een hoog betrouwbaarheidsniveau. Deze betrouwbaarheid wordt mogelijk gemaakt door het integreren van tests in vroege fasen van de ontwikkelingscyclus, in een proces genaamd 'verschuiving naar links'.
Als de ontwikkeling van een functie in de tijd wordt gezien als een lijn van links naar rechts. Vervolgens voert een verouderd ontwikkelingsproces gebruikersvalidatie en kwaliteitscontrole uit aan het einde van de ontwikkelingscyclus. Aan het 'rechter'-einde van die regel. DevOps adviseert u om zo vroeg mogelijk aan de linkerkant van die tijdlijn te testen en te valideren.
DevOps belichaamt dezelfde kernconcepten van een gezonde innovatiecultuur. Het aannemen van zijn methodologie is essentieel om een flexibele innovatiecyclus te bereiken.
Microservicesarchitecturen
Modulariteit is een bekende techniek om de complexiteit bij het ontwerpen van complexe systemen te verminderen. Als een systeem een complexe interactie is van veel onderdelen die niet uit elkaar kunnen worden gehaald (vaak een 'monolith' genoemd), maken strakke componentafhankelijkheden systeemverbeteringen moeilijk. Elke wijziging moet worden gevalideerd met de rest van het systeem, dus het testproces is complex.
Als het systeem modulair is, kunt u het scheiden in kleinere subsystemen die met elkaar communiceren via goed gedefinieerde interfaces. Het introduceren van wijzigingen in een van deze subsystemen is eenvoudiger, omdat zolang de interface met de andere modules constant blijft, het algehele systeem blijft werken.
Microservicesarchitecturen zijn toepassingspatronen die gebruikmaken van modulariteit. Toepassingen worden onderverdeeld in afzonderlijke, kleine onderdelen die onafhankelijk van elkaar kunnen worden ontwikkeld, mogelijk zelfs met behulp van verschillende programmeertalen. Elk onderdeel of elke microservice kan zelfstandig werken. U kunt deze naar behoefte schalen, u kunt het probleem oplossen als één eenheid. U kunt deze onafhankelijk van de andere microservices wijzigen.
Een vraag die organisaties vaak stellen, is wat te doen als een toepassing monolithisch is. Moet de organisatie de toepassing opnieuw ontwerpen in een microservicesarchitectuur voordat ze innovatie introduceren, of kunnen de processen voor innovatie en herontwerp parallel worden uitgevoerd? Er is geen enkel antwoord op deze vraag. Het hangt af van de complexiteit en de zakelijke relevantie van de toepassing die wordt overwogen.
Tailwind Traders heeft deze vraag onder ogen gezien bij het introduceren van innovatie in het e-commerceplatform. Het bedrijf heeft besloten om een project te starten om de e-commercetoepassing opnieuw te ontwerpen in een microservicesarchitectuur, omdat de bedrijfskritiek van de toepassing deze inspanning rechtvaardigde. Het niet hebben van een modulaire toepassing zou het vermogen van Tailwind Traders ernstig belemmeren om te reageren op veranderende trends in de onlinemarkt.
Tailwind Traders heeft echter besloten om tegelijkertijd enkele van de grote hiaten in het platform aan te pakken. Wachten tot het project voor het opnieuw ontwerpen van de toepassing zou betekenen dat er een aanzienlijk marktaandeel verloren gaat aan de nieuwe start-ups die de e-commercemarkt op dit moment verstoren.
De projecten moeten met elkaar communiceren, geleid door de bedrijfswaarde van innovaties. De inspanningen voor het opnieuw ontwerpen zijn gericht op de meest kritieke toepassingsgebieden, waarbij de noodzaak van aanpassing om de klantervaring te verbeteren het hoogst is.
Containers
De technologie van containerisatie is niet exclusief voor microservicesarchitecturen, maar de concepten werken samen. Containers zijn een manier om toepassingscode en de bijbehorende afhankelijkheden in te kapselen, zodat ze moeiteloos in elk platform kunnen worden geïmplementeerd.
Voor traditionele toepassingsimplementaties moet de organisatie eerst software installeren, zoals de toepassingsruntime, programmeerbibliotheken of externe onderdelen. Deze aanpak resulteert vaak in het probleem 'het werkt op mijn computer': het is moeilijk om dezelfde omgeving te repliceren in ontwikkeling, test, fasering en productie. Kleine verschillen in de manier waarop de toepassingsafhankelijkheden worden geïnstalleerd, kunnen ervoor zorgen dat de toepassing prima werkt tijdens het testen, maar mislukt wanneer deze in productie wordt geïmplementeerd.
Containers wijzigen de regels van het spel. De toepassingsafhankelijkheden worden samen met de toepassingscode in een autonome implementatie-eenheid, de containerinstallatiekopieën genoemd, verpakt. Of de toepassingscontainer nu wordt geïmplementeerd op de laptop van een ontwikkelaar of in een productiecluster met honderden knooppunten, de afhankelijkheidsafhandeling is hetzelfde. De container werkt precies op dezelfde manier, dus het testen van toepassingen is betrouwbaarder en betrouwbaarder.
Containers zijn al heel lang gekomen sinds Docker hun code in 2013 als open source heeft uitgebracht. Containers ondersteunen nu zowel Linux als Windows en verschillende CPU-architecturen. Er zijn veel aanbiedingen in Azure waarmee workloads op basis van containers kunnen worden uitgevoerd. In deze les krijgt u informatie over een aantal hiervan.
Kubernetes en Red Hat OpenShift
Een containerruntime is de technologie waarmee containers op een computer worden gestart, maar er is meer logica vereist in een productieomgeving. Wie meer containers implementeert als er meer prestaties zijn vereist? Wie de containers opnieuw opstarten als ze een probleem hebben? Als er meerdere computers beschikbaar zijn, wie bepaalt welke van hen een bepaalde container moet worden gestart? Deze en andere taken zijn de verantwoordelijkheid van een containerindelingsplatform.
De eerste versie van Kubernetes werd uitgebracht in 2015 en werd binnenkort de feitelijke standaard voor containerindeling. Kubernetes-clusters bestaan uit verschillende werkknooppunten. Elk werkknooppunt heeft een containerruntime, zodat containers kunnen worden uitgevoerd waarop het Kubernetes-besturingsvlak de implementatie van toepassingen in containers plant. Dit besturingsvlak wordt doorgaans uitgevoerd in een set kernknooppunten. Het is verantwoordelijk voor het correct uitvoeren van de toepassing, het omhoog of omlaag schalen van de toepassing en het uitvoeren van vereiste updates.
Een van de belangrijkste redenen voor de populariteit van Kubernetes is de hardware-onafhankelijkheid die containers bieden. Omdat toepassingen op basis van containers betrouwbaar kunnen worden geïmplementeerd in elke containerruntime, kunt u Kubernetes uitvoeren in clouds die gebruikmaken van verschillende hypervisors. De geïmplementeerde toepassingen moeten zich op een vergelijkbare manier gedragen (ervan uitgaande dat de onderliggende hardwarebronnen ook vergelijkbaar zijn). Veel organisaties hebben Kubernetes als een abstractielaag gebruikt waarmee consistente toepassingsimplementatieprocessen zowel on-premises als in openbare clouds mogelijk zijn.
Het uitvoeren van Kubernetes in Azure is eenvoudig. Azure Kubernetes Service is eenvoudig te implementeren en kostenefficiënt, omdat de klant alleen kosten in rekening wordt gebracht voor de kosten van de werkknooppunten. Microsoft draagt de kosten en werking van het besturingsvlak dat de kernonderdelen bevat. Microsoft patches en werkt het besturingssysteem van de werkknooppunten bij, waardoor de operationele complexiteit van het beheren van een Kubernetes-cluster voor het uitvoeren van Linux- en Windows-containers verder wordt verminderd.
OpenShift is een platform voor toepassingsimplementatie op basis van Kubernetes, ontwikkeld en ondersteund door Red Hat. Het bevat veel andere functionaliteiten. Sommige organisaties die ervoor kiezen om hun toepassingen uit te voeren op OpenShift doen dit vanwege deze extra functies en de ondersteuning die Red Hat biedt. Het uitvoeren van OpenShift in Azure is opnieuw eenvoudig. Azure Red Hat OpenShift bestaat uit een OpenShift-cluster waarin Microsoft veel van de aspecten beheert, inclusief de hele levenscyclus van het cluster.
Azure App Service
Azure-app Service is een platform waar organisaties hun webworkloads kunnen uitvoeren zonder dat ze een orchestrator of onderliggend besturingssysteem hoeven te beheren. De enige vereiste is het uploaden van de toepassingscode naar de service via een van de vele beschikbare implementatiemethoden. Azure doet de rest: de toepassing in- en uitschalen, de onderliggende virtuele machines patchen en onderhouden, en nog veel meer, zonder dat hiervoor de leercurve van Kubernetes is vereist.
Azure-app Service ondersteunt workloads op basis van containers, zodat u uw containerinstallatiekopieën kunt uploaden in plaats van de toepassingscode. Het ondersteunt ook Linux- en Windows-workloads en veel verschillende toepassingsruntimes.
Azure-app Service ondersteunt verschillende prijsmodellen, waaronder een serverloze optie met de naam Azure Functions. In Azure Functions wordt alleen toepassingsgebruik in rekening gebracht. Er zijn geen vaste kosten.
Het serverloze model is interessant om te innoveren, omdat u hiermee nieuwe microservices kunt implementeren zonder hoge maandelijkse facturen te maken als de markt ze niet accepteert. Dit model is een ander voorbeeld van de fail-fast strategie, waarbij innovatie niet noodzakelijkerwijs hoge kosten betekent.
Azure-app Service biedt ook functies die ondersteuning bieden voor DevOps-georiënteerde implementaties, zoals web-app-sites. Sites zijn faseringsgebieden waar u nieuwe functies kunt implementeren zonder dat dit van invloed is op de productieomgeving. Sites zijn geweldig vanuit het perspectief van innovatie, omdat u een kleine selectie van uw klanten kunt omleiden naar deze nieuwe versie van de toepassing. Vervolgens kunt u controleren of uw innovatiehypothese juist is. Als u uiteindelijk de nieuwe code naar productie wilt promoveren, kunt u sites 'wisselen' zodat de faseringsomgeving de productieversie wordt.
Samenvatting
In deze les hebt u geleerd hoe technologie innovatie kan ondersteunen:
- DevOps-processen en -hulpprogramma's bieden uw ontwikkel- en operationele teams de superkracht van het snel en betrouwbaar leveren van nieuwe functies.
- U kunt toepassingen opnieuw ontwerpen in microservices om innovatie op hun onderdelen afzonderlijk toe te staan, zonder dat dit van invloed is op de rest.
- Containers maken betrouwbare toepassingsimplementatie mogelijk op meerdere platforms en omgevingen.
- Kubernetes is een cloudagnostisch indelingsplatform voor het uitvoeren van toepassingen in containers.
- Azure-app Service kan webworkloads uitvoeren met minimale beheeroverhead. Het biedt veel functies, zoals serverloze of toepassingssites, om de innovatiecyclus te versnellen.
Tailwind Traders heeft besloten om het herontwerp van de e-commercetoepassing te starten in een microservicesarchitectuur. Het eerste toepassingssubsysteem dat het scheidt van de 'monolith' is de betaalservice, omdat u het hebt geïdentificeerd als een kritiek gebied waar de concurrentie een betere waarde biedt aan klanten.
Na het betalingssubsysteem worden meer toepassingsonderdelen omgezet in onafhankelijke microservices. De microservices kunnen communiceren via REST API's. De toepassingscode voor elke microservice moet in een container worden geplaatst en de ontwikkelings- en operationele organisaties moeten devOps-best practices gebruiken.
Omdat Tailwind Traders niet afhankelijk wil zijn van een specifieke openbare cloud, wordt besloten om interne Kubernetes-expertise te bouwen en de toepassing te implementeren in Azure Kubernetes Service-clusters. Als er nieuwe microservices moeten worden ontwikkeld, heeft het bedrijf ervoor gekozen Om Azure Functions als platform voor MVP-implementatie te overwegen om de ontwikkelingskosten te verlagen.
Waar moet ik naartoe kijken?
Veel van de concepten in deze les worden verder geformuleerd in de artikelen over Cloud Adoption Framework: acceptatie mogelijk maken met digitale uitvindingen en Kubernetes in het Cloud Adoption Framework.