Inleiding tot cloudtoepassingen
Tip
Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.
Nog een dag, op kantoor, bezig met 'het volgende grote ding'.
Je mobiele telefoon gaat over. Het is je vriendelijke recruiter - degene die dagelijks belt met spannende nieuwe mogelijkheden.
Maar deze keer is het anders: opstarten, vermogen en veel geld.
De vermelding van de cloud, microservices en geavanceerde technologie duwt u over de rand.
Snel vooruit een paar weken en u bent nu een nieuwe werknemer in een ontwerpsessie die een grote e-commercetoepassing ontwerpt. Je gaat concurreren met de toonaangevende e-commercesites.
Hoe gaat u het bouwen?
Als u de richtlijnen van de afgelopen 15 jaar volgt, bouwt u waarschijnlijk het systeem dat wordt weergegeven in afbeelding 1.1.
Afbeelding 1-1. Traditioneel monolithisch ontwerp
U maakt een grote kerntoepassing die al uw domeinlogica bevat. Het bevat modules zoals Identiteit, Catalogus, Bestellen en meer. Ze communiceren rechtstreeks met elkaar binnen één serverproces. De modules delen een grote relationele database. De kern biedt functionaliteit via een HTML-interface en een mobiele app.
Gefeliciteerd U hebt zojuist een monolithische toepassing gemaakt.
Niet alles is slecht. Monolithen bieden enkele duidelijke voordelen. Ze zijn bijvoorbeeld eenvoudig te...
- build
- test
- implementeren
- troubleshoot
- verticaal schalen
Veel succesvolle apps die vandaag bestaan, zijn gemaakt als monolithen. De app is een hit en blijft zich ontwikkelen, iteratie na iteratie en meer functionaliteit toevoegen.
Op een bepaald moment voel je je echter ongemakkelijk. U verliest de controle over de toepassing. Naarmate de tijd aangaat, wordt het gevoel intenser, en uiteindelijk komt u in een toestand die bekend staat als de Fear Cycle:
- De app is zo overweldigend ingewikkeld geworden dat niemand het begrijpt.
- U vreest dat u wijzigingen aanbrengt. Elke wijziging heeft onbedoelde en kostbare bijwerkingen.
- Nieuwe functies/oplossingen worden lastig, tijdrovend en duur om te implementeren.
- Elke release wordt zo klein mogelijk en vereist een volledige implementatie van de hele toepassing.
- Eén onstabiel onderdeel kan het hele systeem crashen.
- Nieuwe technologieën en frameworks zijn geen optie.
- Het is moeilijk om flexibele leveringsmethodologieën te implementeren.
- Architectuurerosie wordt ingesteld naarmate de codebasis verslechtert met nooit-eindigende 'snelle oplossingen'.
- Ten slotte komen de consultants binnen en vertellen u het te herschrijven.
Klinkt dit bekend in de oren?
Veel organisaties hebben deze monolithische angstcyclus aangepakt door gebruik te maken van een cloudeigen benadering voor het bouwen van systemen. In afbeelding 1-2 ziet u hetzelfde systeem dat is gebouwd voor het toepassen van cloudeigen technieken en procedures.
Afbeelding 1-2. Cloudeigen ontwerp
Houd er rekening mee dat de toepassing wordt uitgesplitsd in een set kleine geïsoleerde microservices. Elke service is zelfstandig en bevat zijn eigen code, gegevens en afhankelijkheden. Elke container wordt geïmplementeerd in een softwarecontainer en beheerd door een containerorchestrator. In plaats van een grote relationele database is elke service eigenaar van het gegevensarchief, waarvan het type varieert op basis van de gegevensbehoeften. Let op hoe sommige services afhankelijk zijn van een relationele database, maar andere op NoSQL-databases. Eén service slaat de status op in een gedistribueerde cache. U ziet hoe al het verkeer wordt gerouteerd via een API Gateway-service die verantwoordelijk is voor het routeren van verkeer naar de belangrijkste back-endservices en het afdwingen van veel kruislingse problemen. Het belangrijkste is dat de toepassing volledig profiteert van de schaalbaarheids-, beschikbaarheids- en tolerantiefuncties die zijn gevonden in moderne cloudplatforms.
Cloudeigen computing
Hmm... We hebben zojuist de term Cloud Native gebruikt. Je eerste gedachte zou kunnen zijn: "Wat betekent dat precies?" Een ander industrie buzzword dat door softwareleveranciers is bedacht om meer dingen op de markt te brengen?"
Gelukkig is het veel anders, en hopelijk zal dit boek u helpen overtuigen.
Binnen korte tijd is cloudeigen een belangrijke trend geworden in de software-industrie. Het is een nieuwe manier om grote, complexe systemen te bouwen. De aanpak maakt optimaal gebruik van moderne softwareontwikkelingsprocedures, technologieën en cloudinfrastructuur. Cloudeigen wijzigingen in de manier waarop u systemen ontwerpt, implementeert, implementeert en operationaliseert.
In tegenstelling tot de continue hype die onze branche aanstuurt, is cloudeigen for-real. Overweeg de Cloud Native Computing Foundation (CNCF), een consortium van meer dan 400 grote bedrijven. Het charter is om cloudeigen computing overal in technologie en cloudstacks te maken. Als een van de meest invloedrijke opensource-groepen host het veel van de snelst groeiende opensource-projecten in GitHub. Deze projecten omvatten Kubernetes, Prometheus, Helm, Envoy en gRPC.
De CNCF bevordert een ecosysteem van opensource- en leveranciersneutraliteit. Hierna presenteert dit boek cloudeigen principes, patronen en best practices die technologieneutraal zijn. Tegelijkertijd bespreken we de services en infrastructuur die beschikbaar zijn in de Microsoft Azure-cloud voor het bouwen van cloudeigen systemen.
Wat is cloudeigen? Kom terug, ontspan en laat ons u helpen deze nieuwe wereld te verkennen.
