Bewerken

Delen via


Oplossingen voor meerdere clouds met het Serverless Framework

Azure Functions

In dit artikel wordt beschreven hoe het CSE-team (Commercial Software Engineering) van Microsoft partner is van een wereldwijde retailer om een serverloze oplossing met hoge beschikbaarheid te implementeren op zowel Azure- als Amazon Web Services (AWS)-cloudplatforms, met behulp van het Serverless Framework.

Architectuur

Diagram met de serverloze architectuur met meerdere clouds.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

  • De gebruikers-app kan afkomstig zijn van elke bron die zich kan aanmelden bij de cloud. In deze implementatie meldt de gebruiker zich aan bij een gateway-app die taakverdeling aanvraagt 50-50 tussen de Azure- en AWS-clouds.
  • Elk antwoord wordt ook gerouteerd via de API Manager-gateway, die het vervolgens naar de aanvrager-app verzendt.

Onderdelen

Het serverloze framework

Deze oplossing maakt gebruik van het Serverless Framework, beschikbaar via Serverless, Inc. De gratis versie van het Serverless Framework bevat een CLI, meer invoegtoepassingen en beperkte bewakingsservices. De Pro-editie biedt operationele mogelijkheden in clouds, zoals verbeterde bewaking en waarschuwingen. Het framework ondersteunt Node.js- en Python-talen, en zowel AWS- als Azure-cloudhosts.

Als u Azure wilt gebruiken met serverloze framework, hebt u het volgende nodig:

  • Node.js, om microservices te verpakken
  • Azure Functions, om functionaliteit te bieden die vergelijkbaar is met andere cloudplatforms
  • Het serverloze framework ter ondersteuning van implementatie en bewaking van meerdere clouds
  • De serverloze multicloudbibliotheek om genormaliseerde runtime-API's te bieden voor ontwikkelaars
  • De serverloze Azure Functions-invoegtoepassing ter ondersteuning van implementatie met meerdere clouds. Deze invoegtoepassing was aanvankelijk niet pariteit met de vergelijkbare AWS Lambda-invoegtoepassing en werd uitgebreid voor dit project.

In de volgende afbeelding ziet u de verwerkingspijplijn. De middlewarelagen vertegenwoordigen eventuele tussenliggende functionaliteit die nodig is voordat de handler wordt bereikt.

Diagram met een pijplijn voor verwerking met meerdere clouds.

Cloudagnostische API's

De serverloze implementatie op elk platform ondersteunt afzonderlijke functies als microservices, één voor elk functioneel VM-knooppunt en voert de verwerking zo nodig uit. Elke AWS Lambda-functie heeft een bijbehorende Azure Functions-functie. De serverloze multicloudbibliotheek bouwt analoge microservices van beide clouds in een cloudagnostische genormaliseerde REST API die client-apps kunnen gebruiken om te interfacen met beide platforms. Omdat de abstracte API-laag code biedt om de bijbehorende microservices voor elk platform aan te pakken, hebben transacties geen vertaling nodig. Met de cloudagnostische interface kunnen gebruikers-apps communiceren met de cloud zonder te weten of te zorgen welk cloudplatform ze openen.

In het volgende diagram ziet u dit concept:

Diagram met een cloudagnostische API.

CI/CD met GitOps

Een primaire taak van het Serverless Framework is om alle problemen met de infrastructuur van het implementeren van een app in de cloud weg te werken. Door gebruik te maken van een op manifest gebaseerde benadering kan het Serverless Framework alle implementatieproblemen verwerken, zodat implementatie zo nodig kan worden geautomatiseerd om GitOps te ondersteunen.

Hoewel in dit eerste project handmatige implementaties zijn gebruikt, is het realistisch om serverloze builds, tests en implementaties in of in clouds op basis van manifestgestuurde servers te implementeren. Dit proces kan een GitOps-werkstroom voor ontwikkelaars gebruiken: bouwen vanuit Git, met behulp van kwaliteitspoorten voor testen en evalueren, en serverloze oplossingen naar beide cloudproviders pushen. Het uitvoeren van alle implementaties met behulp van het Serverless Framework vanaf het begin van het project is de meest efficiënte manier om door te gaan.

API-manager

Api Manager kan een bestaande of aangepaste toepassing zijn. Apigee™ API Manager in deze implementatie heeft alleen als router gehandeld om een load balance van 50-50 transacties te bieden aan de twee cloudplatforms en is te weinig gebruikt voor de mogelijkheden ervan.

Api Manager moet het volgende kunnen doen:

  • Indien nodig binnen of buiten een cloudplatform worden geïmplementeerd
  • Berichten routeren naar en van beide cloudplatforms
  • Aanvragen voor logboekverkeer om asynchroon berichtverkeer te coördineren
  • Aanvragen en antwoorden doorsturen met behulp van de algemene REST API van en naar de gebruikerstoepassing
  • De status van beide serverloze frameworkimplementaties in de cloud bewaken om de mogelijkheid om aanvragen te ontvangen te valideren
  • Geautomatiseerde status- en beschikbaarheidscontroles uitvoeren op elk cloudplatform, ter ondersteuning van routering en hoge beschikbaarheid

Alternatieven

  • Andere talen, zoals Python, kunnen de oplossing implementeren, zolang ze worden ondersteund door de serverloze implementaties van de cloudplatforms, AWS Lambda en Azure Functions in dit geval. Dit project heeft Node.js gebruikt om de microservices te verpakken, omdat de klant vertrouwd was met Node.js, en zowel AWS- als Azure-platforms ondersteunen het.

  • De oplossing kan elk cloudplatform gebruiken dat het Serverless Framework ondersteunt, niet alleen Azure en AWS. Momenteel rapporteert serverloze framework compatibiliteit met acht verschillende cloudproviders. Het enige nadeel is ervoor te zorgen dat de elementen die ondersteuning bieden voor de architectuur met meerdere clouds of het equivalent ervan, beschikbaar zijn op de doelcloudplatforms.

  • De API Manager in deze initiële implementatie heeft alleen als router gereageerd om een load balance van 50-50 transacties te bieden aan de twee cloudplatforms. Api Manager kan andere bedrijfslogica voor specifieke scenario's bevatten.

Scenariodetails

In serverloze computing wijst de cloudprovider dynamisch microservicesresources toe om code uit te voeren en worden alleen kosten in rekening gebracht voor de gebruikte resources. Serverloze computing abstraheert app-code van infrastructuurimplementatie, code-implementatie en operationele aspecten, zoals planning en onderhoud.

Net als bij andere services heeft elke cloudprovider een eigen serverloze implementatie en is het moeilijk voor klanten om een andere provider te gebruiken zonder aanzienlijke operationele impact en kosten. Potentiële klanten kunnen deze situatie zien als verzwakking van hun onderhandelingspositie en flexibiliteit. Vergrendeling van leveranciers is een van de grootste obstakels voor cloudimplementatie voor ondernemingen.

Het opensource Serverless Framework is een universele cloudinterface voor het ontwikkelen en implementeren van serverloze computingoplossingen tussen cloudproviders. Opensourcen en algemene API's voor serverloze functies helpen providers, klanten en partners cross-cloudoplossingen te bouwen voor de beste services. Het Serverloze Framework vermindert de belemmeringen voor cloudimplementatie door de problemen met vergrendeling van leveranciers en redundantie tussen cloudproviders aan te pakken. Klanten kunnen hun oplossingen optimaliseren op basis van kosten, flexibiliteit en andere overwegingen.

CSE en het Azure-productteam hebben de serverloze CLI gezamenlijk herschreven ter ondersteuning van nieuwe Azure Functions-functies, zoals Premium Functions, API Management en KeyVault. De serverloze CLI biedt nu een standaardinterface voor GitOps-implementatie voor zowel Azure als AWS. Het team heeft ook de serverloze multicloudbibliotheek ontwikkeld, die een genormaliseerde runtime-API biedt voor het implementeren van serverloze apps in zowel AWS als Azure.

Dit ontwerp biedt hoge beschikbaarheid met actief-actieve failover tussen meerdere cloudplatforms, in tegenstelling tot actief-passieve failover. Als de service van één cloudprovider beschadigd raakt of niet beschikbaar is, kan deze oplossing aanvragen omleiden naar een ander cloudplatform.

Dit project voldoet aan de volgende technische doelstellingen:

  • Maak een oplossing voor meerdere bedrijfstakn.
  • Gebruik de serverloze bibliotheek met meerdere clouds ter ondersteuning van een cloudagnostische API die communiceert met microservices waar ze ook worden geïmplementeerd.
  • Ondersteuning voor een GitOps CI/CD-proceswerkstroom voor ontwikkeling, testen en implementatie op alle ondersteunde cloudplatforms.
  • Gebruik op API gebaseerde toegang via een geverifieerde cloudgateway en taakverdeling tussen cloudplatforms met behulp van de gateway als router.

Andere mogelijke voordelen van het gebruik van het serverloze framework zijn:

  • Preventie of vermindering van vergrendeling van leveranciers
  • 40-60+% codereductie tijdens de ontwikkeling met behulp van de serverloze bibliotheek zonder multicloud
  • Ontwikkeling van best-of-breed oplossingen die de services van verschillende cloudproviders combineren
  • Verwijdering van de meeste platform- en infrastructuurcomplexiteit en onderhoudsvereisten
  • Eenvoudiger gegevens delen, prestaties en kostenvergelijkingen en de mogelijkheid om te profiteren van speciale aanbiedingen
  • Actieve hoge beschikbaarheid

Potentiële gebruikscases

  • Schrijf toepassingen aan de clientzijde voor meerdere platforms met behulp van een cloudagnostische API uit de serverloze multicloudbibliotheek.
  • Implementeer een verzameling functionele microservices in een serverloos framework op meerdere cloudplatforms.
  • Gebruik een cloudagnostische app op cloudplatforms zonder dat u weet welk platform het host.

Overwegingen

  • In dit artikel worden geen beveiligingsoplossingen beschreven, hoewel de eerste implementatie deze bevat. Er zijn veel mogelijke beveiligingsoplossingen, een aantal platformafhankelijke oplossingen en dit framework moet geschikt zijn voor een redelijke oplossing. Gebruikersverificatie is de minimale beveiliging die wordt aangenomen.

  • Omdat het moeilijk is om de verschillen tussen AWS en serverloze functionaliteitsaanbiedingen van Azure te formuleren, moeten vroege inspanningen zich richten op het toewijzen van de functies die beschikbaar zijn op elk cloudplatform en het identificeren van de benodigde transformatievereisten. U kunt een platformagnostische API ontwikkelen op basis van deze informatie.

  • Het gebruik van een opensource-oplossing kan risico's veroorzaken, vanwege langetermijnonderhoud en ondersteuningsproblemen met opensource-software.

  • In het gratis serverloze framework is bewaking voornamelijk beperkt tot het beheerdashboard. Bewaking is beschikbaar in de betaalde enterprise-aanbieding. Op dit moment bevat de serverloze invoegtoepassing van Azure Functions geen voorzieningen voor waarneembaarheid of bewaking en moet deze functionaliteit worden gewijzigd om deze mogelijkheden te implementeren.

  • Deze oplossing kan metrische gegevens gebruiken om prestaties en kosten tussen cloudplatforms te vergelijken, zodat klanten het gebruik naadloos kunnen optimaliseren op cloudplatforms.

Dit scenario implementeren

Een traditionele blauw-groene implementatie ontwikkelt en implementeert een app in twee afzonderlijke, maar identieke omgevingen, blauw en groen, waardoor de beschikbaarheid wordt verhoogd en het risico wordt verminderd. De blauwe omgeving is meestal de productieomgeving die normaal gesproken live verkeer verwerkt en de groene omgeving is een failover-implementatie indien nodig. Normaal gesproken implementeert de CI/CD-pijplijn automatisch zowel blauwe als groene omgevingen binnen hetzelfde cloudplatform. Deze configuratie wordt beschouwd als een actief-passieve configuratie.

In de multicloudoplossing wordt blauwgroene implementatie geïmplementeerd in beide cloudplatforms. In het serverloze geval worden twee dubbele sets microservices geïmplementeerd voor elk cloudplatform, één als de productieomgeving en de andere als de failover-omgeving. Deze actief-passieve installatie binnen elk cloudplatform vermindert het risico dat dit platform uitvalt, de beschikbaarheid verhoogt en multicloud actief-actief hoge beschikbaarheid mogelijk maakt.

Diagram met een actief-actief blauw-groene implementatie.

Een secundair voordeel van blauwgroene implementatie is de mogelijkheid om de failover-implementatie op elk cloudplatform te gebruiken als testomgeving voor microservices-updates, voordat deze worden vrijgegeven aan de productie-implementatie.

Volgende stappen