Opgelet! Lage drempels voor het toepassen van de Public Cloud
Bij een cloud migratie, en typisch bij de architectuur en design fases van een migratie traject denken we na over het projecteren van de bestaande/gewenste functionaliteiten en kwaliteiten op bij voorkeur cloud-native PaaS diensten in een Public Cloud. De migratie heeft als bron vaak een on-premise bare-metal of gevirtualiseerde server implementatie, of een data-center gebaseerde private cloud variant. We vermijden binnen een migratie traject graag een lift-and-shift aanpak zodat we een oplossing krijgen die zich thuis voelt in de cloud.
Bij het analyseren en het ontrafelen van een bestaande oplossing/omgeving valt steeds weer op de mate van handmatige configuratie en instellingen die nodig zijn (geweest) om de gewenste omgeving over de jaren heen op te bouwen en uit te breiden. Van het configureren van een hosting omgeving en ondersteunende diensten tot aan de uitrol van de applicatie.
Voor bijvoorbeeld een internet-facing website (er vanuit gaande dat deze onderdeel is van een groter webapplicatie landschap) ondergebracht in een data-center omgeving zijn typisch de volgende componenten nodig:
- Server/VM met OS;
- Webserver software (bijvoorbeeld Apache of IIS);
- Internet peering(s);
- Reverse proxy (voor publiceren website naar internet);
- Publieke DNS.
Een enkelvoudige server oplossing heeft v.w.b beschikbaarheid niet de voorkeur, bij horizontaal schalen dient tevens een load-balancer toegepast te worden. Backup (voor disaster recovery), monitoring en alerting dient verder ingeregeld te worden, net als DDOS mitigation. Dat is nog los van de eventuele OTA wensen. Naast het eenmalig inrichten behoort tot de taken het periodiek onderhoud aan servers (bijvoorbeeld patching), configuratie (om ondermeer configuration-drift te voorkomen) en contracten met de verschillende betrokken leveranciers.
PaaS + IaC (en DevOps)
Stel dat we bovenstaande eisen en wensen zouden willen realiseren binnen de Public Cloud, wat zou daar dan voor nodig zijn ?
Onderstaande template, een sectie uit een Microsoft Azure ARM-template, geeft op een decleratieve manier zoals we van Infrastructure-as-Code (IaC) gewend zijn weer wat we moeten beschrijven om de website zoals hierboven geschetst in te regelen.
Door bovenstaande geparameteriseerde template ‘uit te voeren’ wordt binnen Azure de in de template beschreven webapplicatie-PaaS-dienst aangemaakt. Deze dienst bevat, afhankelijk van de gekozen ‘sku’ (of versie) van de dienst in PaaS-vorm de eerder gestelde website eigenschappen.
Door het beschrijven van de gewenste eigenschappen in een template ontstaat de mogelijkheid om:
- de dienst door gebruik van de kracht van parameterisering meerdere malen uit te rollen (voor bijvoorbeeld het voorzien van OTAP omgevingen);
- eventuele ongewenste configuratie aanpassingen ongedaan te maken door middel van het opnieuw toepassen van de template op een bestaande omgeving;
- de mogelijkheid om het uitrollen van de beschreven diensten te automatiseren via bijvoorbeeld de release pipelines van Azure DevOps.
Omdat we gekozen hebben voor een PaaS dienst vallen voor ons de verantwoordelijkheden weg voor een aantal eerder genoemde onderhoudstaken en voorziet onze nieuwe oplossing standaard in een aantal kwaliteiten zoals beschikbaarheid, schaalbaarheid en beveiliging. Er vanuit gaande dat onze web front-end stateless is vervalt de noodzaak voor backup’s voor disaster recovery. De complete infrastructuur definitie is immers beschikbaar als code (in ons voorbeeld als ARM-template), de website functionaliteit rollen we net als de diensten uit middels DevOps release pipelines. En dit voor elke omgeving die we door middel van de template uitrollen !
#include <PublicCloud>
Om van de voordelen van het toepassen van de Public Cloud gebruik te kunnen maken is het natuurlijk niet per se noodzakelijk om een bestaande applicatie omgeving achter ons te laten en volledig te migreren naar de Public Cloud. In de praktijk ligt de drempel voor het in ons voordeel kunnen inzetten van de Public Cloud gelukkig veel lager. De route die we kunnen bewandelen is die van de Hybrid Cloud of zelfs die van het op een veilige manier aanroepen van cloud functionaliteiten vanaf het publieke internet.
Neem onderstaande praktijk voorbeeld;
Een machinefabriek ontwikkelt en levert machines die onderdeel zijn van een productiestraat bij de afnemers. Een machine worden aangestuurd door een applicatie. Deze applicatie wordt lokaal uitgevoerd op een aan de machine gekoppeld workstation en voorziet de operator van informatie over voortgang en kwaliteit van het proces. Op de achtergrond worden tevens gegevens continu opgeslagen m.b.t de prestaties van de machine, eventuele problemen binnen de applicatie software, statistieken rond gebruik (en eventueel verbruik) en gegevens rond de applicatie samenstelling en instellingen (Configuratie Management).
Deze laatste machine gerelateerde categorie van informatie wordt bij periodiek onderhoud of bij eventuele problemen met een machine door een servicemonteur op locatie geanalyseerd.
Om bij problemen klanten sneller van dienst te kunnen zijn en om beter inzicht te krijgen in de prestaties en configuratie van de installed-base van machines heeft de business bedacht dat de machine gerelateerde informatie met hogere frequentie beschikbaar gesteld moet kunnen worden aan de service organisatie. Dit met op afstand inzage in kwaliteit en het ondersteunen van preventief onderhoud in gedachte.
Bij het eerste laagdrempelige ontwerp maken we gebruik van een Azure Storage Account met File storage. Deze is benaderbaar via het internet waarbij authenticatie per machine via tokens verloopt. De machines zetten de machine informatie periodiek in het Storage Account, de service organisatie kan vanaf kantoor het Storage Account benaderen via een SMB-share.
Onderstaande figuur geeft het ontwerp weer.
Om het vinden van de juiste informatie te vergemakkelijken kunnen we ervoor kiezen om in het Storage Account een folder per machine op te nemen, een human-readable formaat vergemakkelijkt het interpreteren van de informatie.
De implementatie van dit ontwerp maakt het mogelijk om in de Public Cloud centraal machine informatie op te slaan en te bewaren, het benaderen van de informatie kan van elke willekeurige locatie.
Bij een tweede ontwerp breiden we het eerste ontwerp uit waarbij we de door de machine geleverde data gaan interpreteren met een FunctionApp.
Deze serverless functionaliteit verwerkt de gegevens op basis van een trigger die aangeeft dat er nieuwe gegevens zijn ontvangen binnen het cloud platform, de gegevens worden opgeslagen binnen een CosmosDB database. Dit is een no-SQL database dienst waarbij meerdere data collecties aangemaakt kunnen worden. Bij het tweede ontwerp kiezen we voor een collectie voor de configuratie informatie van de machines (CM), een collectie voor statistieken rond de prestaties van de machines (stat) en een collectie met informatie m.b.t de werking van de machine applicatie (info). Aan de service organisatie leveren we functionaliteiten via een web applicatie. De functionaliteit bestaat bijvoorbeeld uit rapportage mogelijkheden voor historische inzage in prestaties per machine of bijvoorbeeld informatie over de werking van een bepaalde versie van de machine applicatie.
Bovenstaande voorbeelden schetsen een paar mogelijkheden rond het op een laagdrempelige manier toepassen van Public Cloud diensten. Dit v.w.b de effort die nodig is om functionaliteiten in te regelen als de manier waarop de Public Cloud met standaard (PaaS) diensten bij kan dragen aan het toevoegen van functionaliteiten aan non-Cloud omgevingen.