Het bedrijfsleven omarmt multi-cloud als strategie. Maar zodra organisaties die strategie uitrollen, wachten hen uitdagingen die veelal samenvallen met een gebrek aan effectieve oplossingen die het gat tussen meerdere clouds overbruggen.
Een van die uitdagingen is een veilige wederkerige koppeling van workloads die bij meerdere providers worden gehost. Dit probleem wordt groter wanneer er meer cloud-vendoren worden toegevoegd.
Uit onderzoek van Propeller Insights blijkt dat twee derde van de organisaties die apps implementeren in meerdere clouds, dat in drie of meer clouds doen. Iets meer dan de helft vindt het moeilijk om workloads in verschillende cloudproviders te beheren, vanwege beveiliging, betrouwbaarheid en connectiviteit in het algemeen.
Dit probleem is deels toe te schrijven aan concurrerende operationele modellen. Elke afzonderlijke cloud biedt diensten en api’s die uniek zijn voor de afzonderlijke cloud-aanbieder, en vereisen vaak dat klanten zich houden aan verschillende vaardigheden, beleidslijnen en benaderingen. Elke cloud biedt een software-gedefinieerde netwerkervaring, maar ze zijn zelden hetzelfde. Hierdoor lopen configuraties uiteen, met gevolg voor de de beveiliging en prestaties.
De introductie van cloud-native, op microservices gebaseerde applicaties, versterkt dit effect. Het aantal cross-communicatie-instanties neemt immers aanzienlijk toe. Uit genoemd onderzoek blijkt dat beveiligingsproblemen in multi-cloud-omgevingen worden verergerd door de verschillende beveiligingsdiensten tussen providers (77 procent), het groeiende aantal api’s (75 procent) en de veelvoorkomendheid van op microservices gebaseerde apps (72 procent). Dit alles zorgt voor een behoefte – en vraag – aan een nieuwe benadering van multi-cloud networking.
Multi-cloud networking
Om de levering van applicaties te vereenvoudigen, moeten twee benaderingen van multi-cloud networking samenkomen. Ten eerste moeten we softwaregedefinieerde internetworking van onderaf aanvliegen. Het creëren van een overlay die de verschillen tussen netwerkomgevingen abstraheert en de uitdagingen van het gebruik van meerdere cloud-omgevingen samen aanzienlijk vereenvoudigt. De vaste fysieke infrastructuur wordt gebruikt als een onderlaag met een standaard cross-cloud control plane die dynamische virtuele netwerken erbovenop mogelijk maakt.
Ten tweede moeten we eenvoudige containernetwerken uitbreiden tot een geavanceerde distributie van bovenaf. Terwijl de industrie is begonnen met het standaardiseren van container workloads als de de facto applicatie-eenheid, moet de relatief ongenuanceerde networking eronder worden uitgebreid naar andere omgevingen. Dit markeert de uiteindelijke opkomst van een gedistribueerde cloud om te helpen bij het beheren van applicatieverkeer tussen omgevingen.
Deze aanpak heeft al geleid tot de creatie van twee abstractielagen in applicatiearchitecturen: Kubernetes om het beheer van netwerkworkloads te vergemakkelijken en SDN om internetworking te vereenvoudigen. Maar de manier waarop deze twee benaderingen momenteel convergeren, veroorzaakt nog steeds aanzienlijke uitdagingen, zoals de manier waarop deze technologieën organisaties dwingen toch een bepaalde configuraties aan te nemen om een gestandaardiseerde internetworking-aanpak te verkrijgen wanneer er meerdere clouds bij betrokken zijn. De aanpak van de ene cloudprovider – zelfs voor uiterst eenvoudige netwerktaken zoals VLAN-beheer – verschilt duidelijk van de aanpak van een andere. En beide kunnen volledig vreemd zijn aan de aanpak van de onderneming voor de eigen private cloud-inspanningen. De manier waarop netwerken in verschillende cloud-omgevingen worden geleverd en beheerd, leidt vaak tot de noodzaak om een team van experts in de verschillen tussen de respectieve omgevingen in dienst te houden, alleen al om gelijke tred te houden met de netwerkstandaardisatie.
De mix
Door meer dan een cloudprovider aan de mix toe te voegen, wordt de intensiteit van het probleem vergroot. Het is duidelijk dat er betere manieren zijn om dit probleem aan te pakken door Kubernetes en SDN dichter bij elkaar te brengen, verschillen in de omgeving op te lossen en de noodzaak om een netwerkexpert te zijn om dit allemaal voor elkaar te krijgen, weg te nemen. Deze gedistribueerde cloud-aanpak lijkt de ‘best of all worlds’.
Wanneer zakelijke beslissingen en applicatiebehoeften worden afgewogen voorafgaand aan het selecteren van het ‘beste netwerk/cloud’ voor een dienst, ontstaan de problemen. Deze beslissing omvat een verscheidenheid aan factoren, zoals kosten, de mogelijkheid om op te starten, de snelheid van de implementatie of de noodzaak om in een bepaalde regio te zitten, of elke andere factor die de klant als cruciaal beschouwt voor het succes van een applicatie. Zelden worden netwerkfactoren of interoperabiliteit met andere clouds in overweging genomen bij de initiële zakelijke beslissing. Helaas leidt dit tot nieuwe uitdagingen naarmate de applicatie vordert in de verwachte levensduur en andere bedrijfsonderdelen andere beslissingen nemen over cloud-gebruik.
Een mix van leveranciers en omgevingen is niet verkeerd, maar het is aan te raden te streven naar het creëren van gemeenschappelijkheid tussen al deze leveranciers met build-to-scale-oplossingen die overeenkomen met de netwerkvaardigheden, applicatiebehoeften en zakelijke wensen. Zo’n gedistribueerde cloud-aanpak wordt ondersteund door drie belangrijke overtuigingen. Het begrip dat het netwerk een model moet ondersteunen van ‘overal en altijd’, zonder verlies van kwaliteit of klantervaring. De overtuiging dat elke internetworking-cloud eenvoudig, volledig en consistent moet zijn, ongeacht de onderliggende cloud die klanten zouden kunnen kiezen. En dat klanten meerwaarde moeten kunnen halen uit eenvoudige, api-gestuurde eenheid tussen besturings- en beheerplatforms.
Het doel is een gedistribueerde cloud te leveren die de concepten van cross-cloud-elasticiteit met zich meebrengt zonder enorme kostenstijgingen, tijdsbeperkingen bij provisioning of omgevingsvariabelen. Hiertoe moeten meer adaptieve applicaties worden ontwikkeld, en moeten klanten geholpen worden bij het voltooien van deze transities, zodat ze workloads eenvoudig kunnen verplaatsen naar de efficiënte en effectieve locaties, regio’s of kostenmodellen. Zonder voor elke omgeving een staf van netwerkwizards in dienst te hebben.
