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
Download een Visio-bestand van deze architectuur.
Workflow
- De bestaande on-premises webtoepassing blijft rechtstreeks gebruikmaken van de bestaande on-premises webservices.
- Aanroepen van de bestaande web-app naar de bestaande HTTP-services blijven ongewijzigd. Deze aanroepen zijn intern voor het bedrijfsnetwerk.
- Binnenkomende aanroepen worden uitgevoerd van Azure naar de bestaande interne services:
- Het beveiligingsteam staat verkeer van het API Management-exemplaar toe om de bedrijfsfirewall door te geven aan de bestaande on-premises services met behulp van beveiligd transport (HTTPS of SSL).
- Het operations-team staat binnenkomende aanroepen naar de services alleen toe vanuit het API Management-exemplaar. Het voldoet aan deze vereiste door het IP-adres van het API Management-exemplaar toe te voegen aan de acceptatielijst binnen de perimeter van het bedrijfsnetwerk.
- Een nieuwe module wordt geconfigureerd in de on-premises aanvraagpijplijn voor HTTP-services (alleen voor verbindingen die extern afkomstig zijn). De pijplijn valideert een certificaat dat API Management biedt.
- De nieuwe API:
- Wordt alleen weergegeven via het API Management-exemplaar, dat de API-gevel biedt. De nieuwe API wordt niet rechtstreeks geopend.
- Is ontwikkeld en gepubliceerd als een Azure PaaS-web-API-app.
- Is geconfigureerd (via instellingen voor de functie Web Apps van Azure-app Service) om alleen het virtuele IP-adres van API Management te accepteren.
- Wordt gehost in Web Apps met beveiligd transport (HTTPS of SSL) ingeschakeld.
- Heeft autorisatie ingeschakeld, geleverd door Azure-app Service via Microsoft Entra ID en OAuth 2.
- De nieuwe browsergebaseerde webtoepassing is afhankelijk van het Azure API Management-exemplaar voor zowel de bestaande HTTP-API als de nieuwe API.
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
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:
- In een Azure-scenario 'lift and shift' dat is gekoppeld aan een geïmplementeerd virtueel Azure-netwerk, kan de organisatie de back-endservice rechtstreeks adresseren via privé-IP-adressen.
- In het on-premises scenario kan het API Management-exemplaar privé teruggaan naar de interne service via een Azure VPN-gateway en een SITE-naar-site IPSec VPN-verbinding of Azure ExpressRoute. Dit scenario wordt dan een hybride van Azure en on-premises.
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.
Notitie
Zie dit artikel voor algemene informatie over het verbinden van API Management met een virtueel netwerk.
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 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.
Beschikbaarheid en schaalbaarheid
- U kunt Azure API Management uitschalen door een prijscategorie te kiezen en vervolgens eenheden toe te voegen.
- Schalen kan ook automatisch worden uitgevoerd met automatisch schalen.
- Implementatie in meerdere regio's maakt failover-opties mogelijk en kan worden uitgevoerd in de Premium-laag.
- Overweeg om te integreren met Azure-toepassing Insights, waarmee ook metrische gegevens worden weergegeven via Azure Monitor voor bewaking.
Kostenoptimalisatie
Kostenoptimalisatie gaat over het vinden van manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler 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.
Dit scenario implementeren
Maak een Azure API Management-exemplaar in de portal om aan de slag te gaan.
U kunt ook kiezen uit een bestaande Azure Resource Manager-quickstartsjabloon die is afgestemd op uw specifieke use-case.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Ben Gimblett | Senior klanttechnicus
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
Productdocumentatie:
Learn-modules:
- Azure-app Service verkennen
- Een website implementeren in Azure met Azure-app Service
- Uw API's beveiligen in Azure API Management