Orchestratie in een multi-cloud architectuur

Wanneer we het hebben over 'multi-cloud', betreft het in eerste instantie vaak de connectiviteit tussen het 'on-premise' datacenter en één of meerdere public clouds. Echter, multi-cloud omvat veel meer dan de hierboven genoemde verbindingen.

Een multi-cloud omgeving bevat ook orchestratie, end-to-end monitoring en zeker ook security. Het doel is namelijk het aanbieden van een infrastructuur die applicaties beschikbaar maakt op een zo eenvoudig mogelijke en veilige manier.

Onzichtbare infrastructuur

Een multi-cloud infrastructuur is geen doel op zich, net zoals een netwerk nooit een doel op zich is.  Beide fungeren als een platform om andere diensten beschikbaar te maken. In die context gaat het er bij een multi-cloud dan ook om, op een kostenefficiënte manier workloads beschikbaar te maken waar deze nodig zijn. De flexibiliteit die de multi-cloud biedt mag niet ten koste gaan van de gebruikerservaring. Als dat wel zo is, schiet deze zijn doel voorbij.

Een infrastructuur is in het meest ultieme geval onzichtbaar, waarbij het voor gebruikers niet uit mag maken of de workload in AWS, Azure of on-premise draait. Het is vergelijkbaar met het opendraaien van een kraan. Draai de kraan open en er stroomt water uit. Waar het water vandaan komt en hoe de waterpompen werken, is niet relevant voor de gebruiker van dat water. Die heeft dorst of wil afwassen. Zo moeten gebruikers van een applicatie zich niet druk hoeven maken over de verschillen in de onderliggende infrastructuur, zoals het draaien op verschillende cloud-platformen. Ze moeten zich enkel bezighouden met de applicatie zelf, en nog beter, wat ze uit die desbetreffende applicatie willen halen.

Dynamische policies zijn een vorm van automatisering, die it-beheerders kunnen helpen om de gebruikers van applicaties binnen een multi-cloudomgeving te faciliteren in hun behoeften. 

Overlay networking

Helaas is de praktijk weerbarstig. Het end-to-end toepassen van dynamische policies is lastig, zeker bij traditionele underlay netwerkarchitecturen. Die zijn vaak statisch en sterk gesegmenteerd. Elke verandering ergens in het ‘path’ is daardoor lastig, zeker als dit netwerkoverschrijdend is. De underlay netwerkarchitectuur is complex, vraagt veel resources om te beheren en het is lastig om wijzigingen door te voeren.

Dit is één van de belangrijkste redenen waarom overlay networking zo snel populair geworden is. Daar waar de underlay statisch is en wellicht niet kan voldoen aan wat de applicatie nodig heeft, biedt overlay networking flexibiliteit, dynamische paden én de mogelijkheden om snel veranderingen door te kunnen voeren. Helaas heeft het toevoegen van een extra laag in de vorm van een overlay netwerk ook gezorgd voor een toename van de complexiteit, terwijl de toevoeging het beschikbaar maken van de applicaties zou moeten vergemakkelijken. Kortom, overlay networking is een krachtige tool, maar vraagt vooral van de beheerders een extra inspanning wanneer ze deze laag apart moeten gaan beheren. 

De grootste uitdaging is dus hoe de complexiteit eruit gehaald kan worden. Ik geloof er heilig in dat het niet uit moet maken waar en op welke manier u welke resources beheert. Virtuele of fysieke servers, underlay of overlay networking, merchant of custom silicon, public of private cloud of fysieke of virtuele routers of firewalls, moeten allemaal vanuit een ´single pane of glass´ te managen zijn.

Door een universele orchestratielaag over alle lagen van het netwerk en de applicatie resources heen te leggen, wordt het mogelijk om fysieke en virtuele resources als één geheel aan te sturen en policies end-to-end te implementeren.

Het gebruik van een consistente en uniforme manier van programmeren en aanspreken van de netwerkresources is hier essentieel en in mijn ogen de enige manier om de infrastructuur onzichtbaar te maken. Als de underlay en overlay apart beheerd worden, dwingt dat de persoon die ertussen zit, om op te treden als ‘unifier’. Een positie die in deze context vraagt om problemen. En wat is dan het voordeel voor bijvoorbeeld een enterprise?

Ik denk dat we in dit geval veel kunnen leren van DevOps. Een van de basisprincipes van DevOps is dat de staging- en de productieomgeving identiek zijn binnen het continue integratie-model. Wanneer dit niet het geval is, ben je genoodzaakt om een tweede ronde van uitrollen en valideren te doorlopen voordat je de wijziging definitief door kunt voeren. Hetzelfde model geldt voor policies. Als de underlay en overlay gescheiden zijn en geen ‘centraal brein’ hebben, valt er een gat tussen deze twee werelden. Dit gat moet vervolgens opgevuld worden door beheerders, die moeten bepalen of een change acceptabel is of niet.

Om een multi-cloud te laten functioneren als een dynamische, onzichtbare infrastructuur met een overkoepelende en alles integrerende orchestratielaag, moeten de menselijke en foutgevoelige interpretatie tussen alle lagen en onderdelen er uitgehaald worden. Alleen dan komt een multi-cloudomgeving tot zijn recht.