Bewerken

Delen via

Een web-app migreren met behulp van Azure API Management

Azure API Management
Azure Monitor
Azure App Service

In dit scenario migreert een e-commercebedrijf in de reisbranche een verouderde webtoepassing met behulp van Azure API Management. De nieuwe gebruikersinterface wordt gehost als een PaaS-toepassing (Platform as a Service) in Azure en is afhankelijk van zowel bestaande als nieuwe HTTP-API's. Deze API's worden geleverd met een beter ontworpen set interfaces, waardoor betere prestaties, eenvoudigere integratie en toekomstige uitbreidbaarheid mogelijk zijn.

Architectuur

Architectuurdiagram

Download een Visio-bestand van deze architectuur.

Workflow

  1. De bestaande on-premises webtoepassing blijft rechtstreeks gebruikmaken van de bestaande on-premises webservices.
  2. Aanroepen van de bestaande web-app naar de bestaande HTTP-services blijven ongewijzigd. Deze aanroepen zijn intern voor het bedrijfsnetwerk.
  3. Binnenkomende aanroepen worden uitgevoerd van Azure naar de bestaande interne services:
  4. De nieuwe API:
  5. De nieuwe browsergebaseerde webtoepassing is afhankelijk van het Azure API Management-exemplaar voor zowel de bestaande HTTP-API als de nieuwe API.
  6. Het e-commercebedrijf voor reizen kan nu sommige gebruikers doorsturen naar de nieuwe gebruikersinterface (voor preview of testen) terwijl de oude gebruikersinterface en bestaande functionaliteit naast elkaar behouden blijven.

Het API Management-exemplaar is geconfigureerd om de verouderde HTTP-services toe te wijzen aan een nieuw API-contract. In deze configuratie is de nieuwe webgebruikersinterface niet op de hoogte van de integratie met een set verouderde services/API's en nieuwe API's.

In de toekomst zal het projectteam geleidelijk functionaliteit overzetten naar de nieuwe API's en de oorspronkelijke services buiten gebruik stellen. Het team verwerkt deze wijzigingen in de API Management-configuratie, waardoor de front-endgebruikersinterface niet wordt beïnvloed en herontwikkeling wordt vermeden.

Onderdelen

  • Azure API Management abstraheert back-end-API's en voegt kruislingse functionaliteit en detectie toe voor ontwikkelaars en toepassingen. In dit scenario wordt de hercompositie van bestaande verouderde back-end-API's en de toevoeging van nieuwe API-functionaliteit mogelijk gemaakt door API Management te gebruiken als een gevel voor de nieuwe clienttoepassing om consistent gebruik te maken van moderne standaarden. Omdat API Management zowel de bestaande als de nieuwe API's vervaagt, kunnen de ontwikkelaars de verouderde back-ends achter de API Management-gevel op een iteratieve manier moderniseren en met minimale tot nul impact op de nieuwe front-endontwikkeling.
  • Azure-app Service is een kant-en-klare PaaS-service (Platform as a Service) voor webhosting die kant-en-klare functies biedt, zoals beveiliging, taakverdeling, automatisch schalen en geautomatiseerd beheer. Azure-app Service is een uitstekende keuze voor de nieuwe API's die voor deze oplossing worden ontwikkeld, omdat het flexibele turn-key hosting biedt, waardoor het DevOps-team zich kan richten op het leveren van functies.

Alternatieven

  • Als de organisatie van plan is om de infrastructuur volledig naar Azure te verplaatsen, inclusief de virtuele machines (VM's) die de verouderde toepassingen hosten, is API Management nog steeds een uitstekende optie omdat deze kan fungeren als een gevel voor elk adresseerbaar HTTP-eindpunt.

  • Als de organisatie had besloten om de bestaande eindpunten privé te houden en deze niet openbaar te maken, kan het API Management-exemplaar van de organisatie worden gekoppeld aan een virtueel Azure-netwerk:

  • De organisatie kan het API Management-exemplaar privé houden door het in de interne modus te implementeren. De organisatie kan vervolgens implementatie gebruiken met Azure-toepassing Gateway om openbare toegang in te schakelen voor sommige API's, terwijl andere intern blijven. Zie API Management integreren in een intern virtueel netwerk met Application Gateway voor meer informatie.

  • De organisatie kan besluiten om de API's on-premises te hosten. Een van de redenen voor deze wijziging kan zijn dat de organisatie geen downstreamdatabaseafhankelijkheden kan verplaatsen die binnen het bereik van dit project naar de cloud vallen. Als dat het geval is, kan de organisatie nog steeds lokaal profiteren van API Management met behulp van een zelf-hostende gateway.

    De zelf-hostende gateway is een containerimplementatie van de API Management-gateway die verbinding maakt met Azure op een uitgaande socket. De eerste vereiste is dat zelf-hostende gateways niet kunnen worden geïmplementeerd zonder een bovenliggende resource in Azure, waarvoor extra kosten in rekening worden gebracht. Ten tweede is de Premium-laag van API Management vereist.

Scenariodetails

Een e-commercebedrijf in de reisindustrie is het moderniseren van de verouderde softwarestack op basis van browsers. Hoewel de bestaande stack voornamelijk monolithisch is, bestaan sommige OP SOAP-gebaseerde HTTP-services (Simple Object Access Protocol) uit een recent project. Het bedrijf overweegt het creëren van extra inkomstenstromen om geld te verdienen met een deel van het interne intellectuele eigendom dat het heeft ontwikkeld.

Doelstellingen voor het project zijn onder andere het aanpakken van technische schulden, het verbeteren van doorlopend onderhoud en het versnellen van de ontwikkeling van functies met minder regressiefouten. Het project gebruikt een iteratief proces om risico's te voorkomen, waarbij enkele stappen parallel worden uitgevoerd:

  • Het ontwikkelteam zal de back-end van de toepassing moderniseren, die bestaat uit relationele databases die worden gehost op VM's.
  • Het interne ontwikkelteam schrijft nieuwe bedrijfsfunctionaliteit die beschikbaar wordt gesteld via nieuwe HTTP-API's.
  • Een contractontwikkelingsteam bouwt een nieuwe gebruikersinterface op basis van een browser, die wordt gehost in Azure.

Nieuwe toepassingsfuncties worden in fasen geleverd. Deze functies vervangen geleidelijk de bestaande functionaliteit van de client-/servergebruikersinterface van de browser (gehost on-premises) die nu het e-commercebedrijf van het bedrijf mogelijk maakt.

Leden van het managementteam willen niet onnodig moderniseren. Ze willen ook de controle over het bereik en de kosten behouden. Hiervoor hebben ze besloten om hun bestaande SOAP HTTP-services te behouden. Ze zijn ook van plan wijzigingen in de bestaande gebruikersinterface te minimaliseren. Ze kunnen Azure API Management gebruiken om veel van de vereisten en beperkingen van het project aan te pakken.

Potentiële gebruikscases

In dit scenario worden verouderde softwarestacks op basis van browsers gemoderniseerd.

U kunt dit scenario gebruiken om het volgende te doen:

  • Bekijk hoe uw bedrijf kan profiteren van het gebruik van het Azure-ecosysteem.
  • Plan voor het migreren van services naar Azure.
  • Meer informatie over hoe een overstap naar Azure van invloed is op bestaande API's.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die de kwaliteit van een workload helpen verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

  • Overweeg om uw Azure API Management-exemplaar te implementeren waarvoor beschikbaarheidszones zijn ingeschakeld. De optie voor het implementeren van API Management in beschikbaarheidszones is alleen beschikbaar in de Premium-servicelaag.
  • Beschikbaarheidszones kunnen worden gebruikt in combinatie met extra gateway-exemplaren die zijn geïmplementeerd in verschillende regio's. Dit verbetert de beschikbaarheid van de service als één regio offline gaat. Implementatie in meerdere regio's is ook alleen beschikbaar in de Premium-servicelaag.
  • Overweeg om te integreren met Azure-toepassing Insights, waarmee ook metrische gegevens worden weergegeven via Azure Monitor voor bewaking. De metrische capaciteitsgegevens kunnen bijvoorbeeld worden gebruikt om de totale belasting van de API Management-resource te bepalen en of extra uitschaaleenheden vereist zijn. Het bijhouden van de resourcecapaciteit en -status verbetert de betrouwbaarheid.
  • Zorg ervoor dat downstreamafhankelijkheden, bijvoorbeeld de back-endservices die als host fungeren voor de API's, ook tolerant zijn voor API Management.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.

API Management wordt aangeboden in vier lagen: Developer, Basic, Standard en Premium. Zie de prijsrichtlijnen voor Azure API Management voor gedetailleerde richtlijnen over de verschillen in deze lagen.

U kunt API Management schalen door eenheden toe te voegen en te verwijderen. De capaciteit van elke eenheid is afhankelijk van de bijbehorende laag.

Notitie

U kunt de developer-laag gebruiken voor evaluatie van de API Management-functies. Gebruik het niet voor productie.

Als u de verwachte kosten wilt bekijken en wilt aanpassen aan uw implementatiebehoeften, kunt u het aantal schaaleenheden en App Service-exemplaren wijzigen in de Azure-prijscalculator.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Productdocumentatie:

Learn-modules: