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 reisindustrie een verouderde web-app met behulp van Azure API Management. Het bedrijf host de nieuwe gebruikersinterface als een PaaS-app (Platform as a Service) in Azure. De nieuwe gebruikersinterface is afhankelijk van zowel bestaande als nieuwe HTTP-API's. Deze API's worden geïmplementeerd met effectiever ontworpen interfaces die de prestaties verbeteren, de integratie vereenvoudigen en toekomstige uitbreidbaarheid mogelijk maken.

Architecture

Diagram met de stappen voor het migreren van een web-app met behulp van API Management.

Het diagram toont de stroom tussen on-premises systemen, internet en Azure-services. Aan de linkerkant, binnen een vak met het label on-premises, vertegenwoordigt een wereldbolpictogram bestaande HTTP-services en API's. In hetzelfde vak vertegenwoordigt een browservensterpictogram een bestaande webgebruikersinterface op basis van een browser. Een tweerichtingspijl waarmee deze pictogrammen worden verbonden, geeft de communicatie aan tussen de bestaande browsergebaseerde webinterface en de bestaande HTTP-services en API's. Een gebouwpictogram vertegenwoordigt het on-premises datacenter. Aan de rechterkant, in een vak met het label Azure, vertegenwoordigt een cloudpictogram een API Management-exemplaar. Een tweerichtingspijl die door een vergrendelingspictogram gaat, verbindt dit pictogram en de bestaande on-premises HTTPS-services en API's. Het Azure-vak bevat ook een nieuw API-pictogram en een wereldbolpictogram dat de nieuwe webgebruikersinterface op basis van een browser vertegenwoordigt. Een bidirectionele pijl die via een vergrendelingspictogram gaat, verbindt het API Management-exemplaar en de nieuwe API. Nog een tweerichtingspijl verbindt het API Management-exemplaar en de nieuwe browsergebaseerde webinterface. Tussen het on-premises vak en het Azure-vak vertegenwoordigt een cloudpictogram het internet. Pijlen die door vergrendelingspictogrammen gaan, wijzen van e-commercegebruikerspictogrammen zowel naar de bestaande browsergebaseerde webgebruikersinterface als naar de nieuwe.

Download een Visio-bestand van deze architectuur.

Workflow

De volgende werkstroom komt overeen met het vorige diagram:

  1. De bestaande on-premises web-app blijft de bestaande on-premises webservices rechtstreeks gebruiken.

  2. Aanroepen van de bestaande web-app naar de bestaande HTTP-services blijven ongewijzigd. Deze aanroepen zijn intern voor het bedrijfsnetwerk.

  3. API Management maakt oproepen vanuit Azure naar de bestaande interne services.

  4. De nieuwe API heeft de volgende kenmerken:

  5. De nieuwe browsergebaseerde web-app is afhankelijk van het API Management-exemplaar voor zowel de bestaande HTTP-API als de nieuwe API.

  6. Het e-commercebedrijf voor reizen kan sommige gebruikers doorsturen naar de nieuwe gebruikersinterface voor preview of testen, terwijl de oude gebruikersinterface en bestaande functionaliteit naast elkaar behouden blijven.

Stel het API Management-exemplaar in 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 of API's en nieuwe API's.

In de toekomst kan het projectteam geleidelijk functionaliteit verplaatsen 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 voorkomen.

Components

  • API Management is een beheerplatform en gateway voor API's in alle omgevingen. In deze architectuur fungeert het als een gevel voor de bestaande verouderde API's en de nieuwe API's. De nieuwe client-app verbruikt één consistente interface en het team kan verouderde back-ends incrementeel achter die gevel moderniseren met minimale impact op front-endontwikkeling.

  • App Service is een kant-en-klare PaaS-oplossing voor webhosting die kant-en-klare functies biedt, zoals beveiliging, taakverdeling, automatisch schalen en geautomatiseerd beheer. In deze architectuur biedt App Service flexibele kant-en-klare hosting, zodat het DevOps-team zich kan richten op functielevering.

Alternatives

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

  • Als de organisatie de bestaande eindpunten privé houdt en deze niet openbaar maakt, kan het API Management-exemplaar van de organisatie een koppeling maken naar 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 Application Gateway om openbare toegang toe te staan voor sommige API's, terwijl andere intern blijven. Zie API Management integreren in een intern virtueel netwerk met behulp van 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. In dit scenario kan de organisatie lokaal gebruikmaken 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. Als u zelf-hostende gateways wilt gebruiken, moet u voldoen aan de volgende vereisten:

    • U moet zelf-hostende gateways implementeren met behulp van een bovenliggende resource in Azure, waardoor extra kosten worden toegevoegd.

    • U moet de Premium-laag van API Management gebruiken.

Scenario-details

Een e-commercebedrijf in de reisindustrie wil zijn verouderde, browsergebaseerde softwarestack moderniseren. De bestaande stack is voornamelijk monolithisch, maar sommige HTTP-services op basis van SOAP (Simple Object Access Protocol) bestaan uit een recent project. Het bedrijf beschouwt het creëren van extra inkomstenstromen om geld te verdienen met een deel van zijn interne intellectuele eigendom.

Doelen voor het project zijn onder andere het aanpakken van technische schulden, doorlopende onderhoudsverbeteringen en functieontwikkelingsversnelling met minder regressiefouten. Het project maakt gebruik van een iteratief proces om risico's te voorkomen en voert de volgende stappen parallel uit:

  • Het ontwikkelteam moderniseert de back-end van de app, die bestaat uit relationele databases die worden gehost op VM's.

  • Het interne ontwikkelteam schrijft nieuwe bedrijfsfunctionaliteit en maakt deze beschikbaar via nieuwe HTTP-API's.

  • Een contractontwikkelingsteam bouwt een nieuwe gebruikersinterface op basis van een browser, die door Azure wordt gehost.

Het bedrijf levert in fasen nieuwe app-functies. Deze functies vervangen geleidelijk de bestaande browsergebaseerde client- en servergebruikersinterfacefunctionaliteit die on-premises wordt gehost die de e-commerce-business 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. Om deze doelen te bereiken, besluiten ze hun bestaande SOAP HTTP-services te behouden. Ze zijn ook van plan wijzigingen in de bestaande gebruikersinterface te minimaliseren. Ze kunnen API Management gebruiken om te voldoen aan veel van de vereisten en beperkingen van het project.

Potentiële gebruikscases

In dit scenario wordt uitgelegd hoe u verouderde, browsergebaseerde softwarestacks kunt moderniseren.

U kunt dit scenario gebruiken voor de volgende taken:

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

Considerations

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

Reliability

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.

  • Activeer beschikbaarheidszones wanneer u uw API Management-exemplaar implementeert. De optie voor het implementeren van API Management in beschikbaarheidszones is alleen beschikbaar in de Premium-servicelagen.

  • Gebruik beschikbaarheidszones waarop extra gateway-exemplaren zijn geïmplementeerd in verschillende regio's. Deze combinatie verbetert de beschikbaarheid van de service als één regio offline gaat. Implementatie met meerdere regio's is alleen beschikbaar in de Premium-servicelaag.

  • Integreer met Application Insights, waarmee metrische gegevens worden weergegeven via Azure Monitor voor bewaking. U kunt bijvoorbeeld de metrische capaciteitsgegevens gebruiken om de totale belasting van de API Management-resource te bepalen en of u meer uitschaaleenheden nodig hebt. Resourcecapaciteit en -status bijhouden om de betrouwbaarheid te verbeteren.

  • Zorg ervoor dat downstreamafhankelijkheden, zoals de back-endservices die als host fungeren voor de API's die door API Management worden behandeld, ook tolerant zijn.

Kostenoptimalisatie

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

API Management heeft acht lagen:

  • Verbruik
  • Ontwikkelaar
  • Basic en Basic v2
  • Standard en Standard v2
  • Premium en Premium v2

Zie prijzen voor API Management voor meer informatie 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.

Note

U kunt de developer-laag gebruiken om API Management-functies te evalueren. Gebruik het niet voor productie.

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

Contributors

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

Andere bijdrager:

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

Volgende stappen