Azure Service Fabric

Azure Service Fabric

Door: Andries van der Meulen – Software Engineer @ Dutchworkz
Bron: SDN Magazine 134 – download

De gedachte om software op te delen in componenten is niet nieuw. Het is de centrale gedachte van veel ontwerp patronen.  Echter zien we verschuiving van een technische splitsing naar een meer bedrijfs-proces-georiënteerde splitsing. De Azure Service Fabric biedt vanuit die gedachten een omgeving aan om dit soort type applicaties te ontwikkelen en te draaien.

Het is een platform waarbinnen je microservices en containers kunt draaien. De voornaamste reden voor gebruik hiervan is schaalbaarheid en betrouwbaarheid.

De Service Fabric is in essentie een soort gecontroleerd uitrol systeem. Een klein onderdeel van de gehele applicatie wordt in een pakket met versienummer gezet. Deze wordt naar een verzameling servers gestuurd (een cluster) waarna het systeem dit pakket distribueert en plaatst binnen de beschikbaar ruimte.

Door dit pakket op verschillende servers (nodes) te laten draaien zijn er een aantal voordelen.

  • Bij drukte of rust kan het aantal instanties van een pakket verhoogd of verlaagd worden. Tevens zorgt het systeem ervoor dat de werkdruk gelijkmatig wordt verdeeld over de verschillende nodes. Hierdoor kan efficiënter gebruik worden gemaakt van de beschikbare hardware.
  • Het parallelle karakter zorgt er tevens voor dat bij uitval van een node of instantie de applicatie beschikbaar blijft.
  • Dit is ook van toepassing tijdens het bijwerken naar een nieuwe of oude versie van een pakket omdat de nodes niet tegelijkertijd worden bijgewerkt.

Het draaien van een Service Fabric is niet gelimiteerd tot alleen Azure. Dit is ook mogelijk op een lokale machine of een andere (online) serveromgeving. Dit kan een overweging zijn indien een organisatie bijvoorbeeld beveiligde data lokaal wilt hebben of dat het diensten gefaseerd naar een cloudomgeving wilt brengen.

Bij Azure is het voordeel dat gebruik kan worden gemaakt van Azure Key Vault (voor het opslaan van certificaten), Azure Diagnostics en Log Analytics (om de gezondheid van de omgeving in de gaten te houden) en is er ondersteuning voor het automatisch kunnen schalen van een cluster.

Microsoft gebruikt zelf de Service Fabric voor een aantal Azure diensten. Bijvoorbeeld SQL Database, Cosmos DB, Cortana, Power BI, Intune, Event Hubs, IoT Hub, Dynamics 365 en Skype for Business.

Cluster

Ieder Service Fabric Cluster bestaat per definitie uit een Availability Set en wordt onderverdeeld in een aantal Fault Domains met daarin Update Domains. Standaard zijn dit 2 Fault Domains met 5 Update Domains.

Een Fault Domain is een serveromgeving welke een gezamenlijke stroom en netwerkvoorziening heeft.

Een Update Domain garandeert dat maar één van deze set per keer wordt bijgewerkt (voor updates en systeemonderhoud).

Elke node is een VM. Deze wordt geplaatst in een Update Domain. Niet elke domein moet een node hebben. Het aantal kan afwijkend zijn per domein. De Availability Set zorgt voor de verdeling van de nodes over de Update Domains.

Op de nodes draaien de pakketten. De Service Fabric zorgt voor de distributie en verdeling hiervoor en kan op basis van CPU en geheugengebruik de pakketten (her)verdelen.

De inrichting van een Cluster binnen Azure kent veel instellingen. De inregeling voor een Service Fabric hangt nauw samen met het type van de microservice of container dat hierop geplaatst gaat worden. Het aantal Fault en Update Domains en de geografische locatie ervan, de grootte en de toegankelijkheid van een node wordt per Availability Set bepaald.

Het doel van deze structuur van de Availability Set is om er voor te zorgen dat er altijd nodes operationeel zijn. Een Availability Set binnen Azure staat los van de Service Fabric. Het wordt ook voor andere toepassingen gebruikt.

Containers

Een container is een volledig geïsoleerde applicatie welke direct op de onderliggende hardware kan worden uitgevoerd. Het is een techniek waarbij het besturingssysteem virtueel wordt aangeboden aan de applicatie in de container. De reden voor het gebruik van containers zijn software standaardisatie en kostenoverwegingen.

De Service Fabric ondersteund het gebruik van containers op basis van zowel Linux als Windows in combinatie met bijvoorbeeld Docker of Windows Server Containers.

Een container bevat alles om zijn applicatie te kunnen draaien. Bijvoorbeeld een Windows container dat een eigen .NET MVC webapplicatie, IIS 10.0 en NET 4.7.2 bevat.

Door een .yaml file wordt een container geconfigureerd. Hierin staan bijvoorbeeld de poorttoewijzingen voor de verbinding van en naar de applicatie. Doordat containers individueel worden geconfigureerd is het mogelijk om meerdere instanties van dezelfde container op een node te draaien.

Azure Service Fabric kan voor containers de uitrol en activatie, verbruik, autorisatie, poorttoewijzing, onderlinge container communicatie, omgeving variabelen, container beveiliging en netwerkmodus beheren en configureren.

Een alternatief voor het gebruik van containers binnen Azure is de Azure Kubernetes Service voor de Azure Container Registry. In vergelijking met de Service Fabric is dit platform eenvoudiger in gebruik. Echter is deze vooralsnog alleen als preview beschikbaar op de Azure omgeving.

Microservices

De Azure Service Fabric is ontstaan door onder andere de ontwikkeling van Azure SQL Database en Azure Cosmos DB. Hiervoor was een andere benadering nodig wat zich resulteerde in de zogenoemde Microservices aanpak.

Microservices kenmerken zich als volgt:

  • Omvat een dienst voor een specifiek klant- of bedrijfsscenario.
  • Ontwikkeld door een klein team.
  • Onafhankelijk qua techniek of platform.
  • Bevat code en eventueel data welke versie-onafhankelijk is en ook zodanig uitgerold en geschaald moeten kunnen worden.
  • Communiceert met andere Microservices op basis van standaard protocollen en duidelijke afspraken.
  • Heeft een unieke naam (URL) waarop deze bereikbaar zijn.
  • Blijft consistent en beschikbaar indien er problemen optreden.
  • Geeft inzicht over zijn huidige staat.

Vergeleken met de meer traditionele aanpak waarbij alle applicatieonderdelen bij elkaar staan zijn er een aantal voor- en nadelen.

De traditionele manier is makkelijker te ontwerpen en heeft snellere communicatie tussen de onderdelen. Nadeel hiervan is dat er een strikte koppeling is tussen de onderdelen en dat ze niet individueel geschaald kunnen worden.
De afhankelijkheid van de andere onderdelen in de applicatie zorgt ook voor een uitdaging voor de uitrol planning.

Het Microservice principe staat dichter bij een specifiek klant- of bedrijfsscenario, waarbij teams eigenaar worden van een bedrijfsproces in plaats van een bepaalde techniek. Onderdelen worden individueel getest, uitgerold en geschaald.
Nadeel is dat er veel meer afzonderlijke entiteiten moeten worden beheerd en onderhouden. Daarbij neemt ook het netwerkverkeer toe en is het lastig om een goed overzicht van het gehele applicatielandschap te krijgen zonder goede hulpmiddelen.

Voor microservices is het nodig om van tevoren goede afspraken te maken over de onderlinge communicatie. Het is aan te raden dat de onderdelen tolerant met de berichten omgaan en dat alleen noodzakelijke informatie wordt gecommuniceerd. Deze aanpak staat tevens bekend als een fijnmazige Service-Oriented Achitecture (SOA). De communicatie gebruikt meestal de publish-subscribe methode met behulp van een service bus (bijvoorbeeld de Azure Event Grid).

Een belangrijk onderdeel voor het ontwikkelen van Microservices is dat deze inzicht geven over de gezondheid en functioneren en dat alle services dit op dezelfde manier doen. Hierdoor wordt het mogelijk om het functioneren van de gehele applicatie inzichtelijk te maken.

Stateless en Statefull

Binnen de Azure Service Fabric wordt onderscheid gemaakt in een aantal typen microservices. Een belangrijk onderscheid hierin is of er gebruik wordt gemaakt van state.

Microservices zijn standaard Stateless. Dit type onthoud geen data. Bijvoorbeeld een rekenmachine welke twee getallen bij elkaar optelt. Het maken van deze berekening heeft geen andere informatie nodig dan de twee meegegeven getallen.

Indien de rekenmachine een ander getal bij de laatste uitkomst moet optellen zal deze de laatste uitkomst moeten gaan onthouden. Dan wordt het een Statefull microservice.

De Service State refereert aan gebruik van data van schijf of uit het geheugen. De data kan zowel extern als naast de code van de applicatie worden opgeslagen. Extern is bijvoorbeeld een SQL database, Redis Cache, Azure Table service of Azure Queue service. Echter bij Statefull Microservices wordt bedoeld om data naast de code te bewaren. De Service Fabric biedt hiervoor de Reliable Service infrastructuur.

In het traditionele model wordt vaak een enkele databron gebruikt met daarbovenop de verschillende applicatielagen. Vanwege de directe afhankelijkheid van de databron en de datastructuur is het vaak lastig om specifieke applicatieonderdelen bij te werken of te schalen.

Met het microservices model bewaart elke service zijn eigen data. Het schalen wordt hierdoor makkelijker. Echter een nadeel hiervan is dat er aparte services moeten worden gemaakt indien data met elkaar moet worden gecombineerd. Deze maken vervolgens gebruik van de Statefull services.

Daarnaast zal elke Statefull service ook data moeten wegschrijven naar een data warehouse indien offline analyse nodig is.

De Azure Service Fabric heeft de Reliable Services framework waarbinnen oplossingen zijn voor het gebruik van data naast de code. Hierbij wordt gebruik gemaakt van Reliable Collections.

De eigenschappen van de Reliable Collection zijn gericht op het uitlezen en bewaren van data over meerdere systemen. Zo worden datawijzigingen automatisch gerepliceerd over alle systemen en zal de data gegarandeerd bewaard blijven, ook als alle systemen uitvallen.

Service Partitioning

Voor het verbeteren van prestaties en schaalbaarheid van Statefull services wordt er in de Service Fabric gebruik gemaakt van partitioning ofwel een verdelingssysteem. Standaard wordt er gewerkt met 1 partitie (hetgeen gebruikelijk is voor een Stateless service). Echter is het mogelijk om meerdere partities te maken waarin de data wordt verdeeld. De partities repliceren onderling geen data en hoe de data verdeeld moet worden is onderdeel van je applicatie architectuur.

Elke partitie bestaat uit minimaal één Primary met optioneel ActiveSecondary instanties. De data wordt over alle instanties in de partitie gerepliceerd. Allen kunnen deze data lezen, echter alleen de Primary kan hierin schrijven.

Indien de Primary instantie uitvalt zorgt de Service Fabric dat automatisch een ActiveSecondary deze rol overneemt.

Op dit moment ondersteunt de Service Fabric twee vormen om partities te verdelen. Op basis van een getal (Ranged partitioning) en op basis van een naam (Named partitioning). Tevens is het mogelijk om geen partities te gebruiken (Singleton partitioning).

Het is gebruikelijk om een Stateless service vóór de partities te plaatsen welke voor routering naar de juist partitie zorgt (Façade pattern).

Actor

Naast de stateless en statefull microservices is er ook ondersteuning voor Actor Pattern services. Deze aanpak (Virtual Actor Abstraction) is ontstaan uit project “Orleans” en beschrijft een oplossing voor de complexiteit van het gebruik van caching- en datalagen in applicaties (Data Shipping Paradigm).

Het idee achter de Actor Pattern is om het Service-Oriented Architecture karakter van de Service Fabric simpeler te maken en als Object-Oriented Programming aan te kunnen bieden voor ontwikkelaars. Het Orleans programmeer model zorgt voor het aanmaken, in leven houden, aanroepen, distribueren en opruimen van object instanties.

De Service Fabric ondersteund dit programmeer model met het gebruik van Reliable Actors. Deze staat bovenop het Reliable Services framework. Het Reliable Actors model is interessant voor de volgende type applicaties:

  • Grote hoeveelheid kleine gescheiden componenten (>1000) welke hun eigen logica en data bevatten.
  • De componenten werken synchroon en kennen weinig interactie met externe systemen.
  • Aanroep van de componenten moet onafhankelijk zijn van een onvoorspelbare duur van I/O operaties.

Een Actor kan vergeleken worden met een .NET of Java class. Een instantie wordt hiervoor automatisch aangemaakt indien deze wordt aangeroepen en weer opgeruimd na verloop van tijd. De data van de Actor wordt bewaard, ook als de instantie is opgeruimd. Hiervoor wordt gebruik gemaakt van State Persistence uit het Reliable Services framework.

Vanwege het synchrone karakter van een Actor kan deze geen meerdere aanvragen tegelijkertijd afhandelen. Er moeten genoeg instanties bestaan om alle aanvragen tegelijkertijd te verwerken om een potentiele Bottleneck te voorkomen. Tevens is het mogelijk dat er hierdoor een Dead-Lock ontstaat wanneer Actoren elkaar aanroepen en circulaire aanroepketens vormen.

Een Actor is gebaseerd op een Statefull service. De principes van partities zijn ook hierbij van toepassing. Communicatie naar een Actor gebeurt met Reliable Services remoting waarbij direct methodes van de Actor kunnen worden aangeroepen. Via een opgesteld contract (interface) worden deze methodes van een Actor beschikbaar gesteld.

Guest Executable

Als laatste is er ook de mogelijkheid om binnen het Azure Service Fabric gebruik te maken van een Guest Executable. Hierin is het mogelijk om bijvoorbeeld Node.js, Java, or C++ applicaties als een service te draaien. De Service Fabric behandelt Guest Executables als een Stateless service.

Voordelen van deze toepassing zijn bijvoorbeeld om applicatiebeschikbaarheid te garanderen en het centraal kunnen monitoren van de applicatiestatus. Daarnaast wordt het schalen van de applicatie een stuk eenvoudiger.

De volledige applicatie zal met zijn afhankelijkheden in een pakket worden geplaatst. Dit kan handmatig, met Visual Studio, of Yeoman voor Linux. In dit pakket wordt vastgelegd hoe de applicatie gestart moet worden en hoe deze bereikbaar is. Vervolgens wordt dit pakket aan een Service Fabric cluster aangeboden welke deze distribueert over de beschikbare ruimte.

Tot slot

Op het moment dat schaalbaarheid en betrouwbaarheid een belangrijk onderwerp is voor een applicatie, is de Service Fabric een serieuze overweging. Microsoft zet hier groot op in. Veel diensten van Azure zijn al gebaseerd op deze aanpak.

Het idee van data naast de code zal voor een hoop ontwikkelaars nieuw zijn. Het geeft een groot aantal voordelen maar vereist een nieuwe denkwijze in de architectuur. Dit hoeft zich echter niet te beperken tot alleen een nieuwe applicaties. Er zijn meerdere artikelen geschreven over migratietrajecten naar Microservices.

Doordat de Service Fabric containers ondersteund zijn er ook andere mogelijkheden. Volledige applicaties met alle afhankelijkheden kunnen in een container worden geplaatst welke draait op een lokale Service Fabric omgeving. Dit kan bijvoorbeeld een tussenstap zijn naar de Cloud. Applicaties worden voorbereid voordat er kosten worden gemaakt aan een uitgebreide Cloud omgeving.

Het opzetten van een Service Fabric is relatief eenvoudig. Er is ondersteuning voor in Visual Studio (standaard in 2017, los verkrijgbaar voor 2015) en er dient een SDK te worden geïnstalleerd. Hierin zit onder andere een applicatie om lokaal een virtueel cluster te draaien.

 

Referenties

Service Fabric:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

Microservices:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices

Partitions:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-partitioning
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-replica-lifecycle#replica-role
https://blogs.msdn.microsoft.com/mvpawardprogram/2015/10/13/understanding-service-fabric-partitions/

Reliable Services:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-introduction

Reliable Actors:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction

Project Orleans:
https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/

Guest Executable:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-deploy-existing-app

Installatie / SDK:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started

  • SDN Magazine
35
284 views