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.
Bedrijfsleven omarmt multi-cloud als strategie.
echter:
– “probleem wordt groter wanneer er meer cloud-vendoren worden toegevoegd.”
– “Iets meer dan de helft vindt het moeilijk om workloads in verschillende cloudproviders te beheren, vanwege beveiliging, betrouwbaarheid en connectiviteit in het algemeen.”
– “ze zijn zelden hetzelfde”
– “de verschillende beveiligingsdiensten tussen providers (77 procent), het groeiende aantal api’s (75 procent) en de veelvoorkomendheid van op microservices gebaseerde apps (72 procent).”
je zou bijna vragen waarom ze nou multi-cloud omarmen..
maar das vast heel brutaal.
Het probleem kan de auteur prima beschrijven. De oplossing minder :
“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.”
Een “gedistribueerde cloud-aanpak” ??
Een soort van distributed kubeternetes over verschillende cloud-providers heen ??
Nou, als je er eentje over heb wil ik die wel van je lenen.
We kunnen met bananen schieten of met blauwe bonen om doeltreffend te zijn maar als het om de doelmatigheid gaat dan bepaalt het doel het middel. De term cloud is namelijk een abstractie welke eigenlijk alleen maar over het netwerk gaat en nog niet specifiek is over het workload plaatsingsmodel of het service deliverymodel. Oja, laten we ook niet de geografie vergeten omdat we niet alleen landingsrechten hebben aangaande de data maar dus ook de exportbeperkingen zoals we zien met nieuwe ronde sancties. Wat betreft Governance-as-a-Service moeten nu alle kikkers terug in de kruiwagen als we kijken naar aspecten zoals wet- en regelgeving waaraan voldaan moet worden. En aangezien wet- en regelgeving per land kan verschillen kan ik de behoefte aan multicloud van mulitnationale bedrijven begrijpen. En misschien komt dat wel door wetgeving die de cloud uitermate geschikt maakt voor spionage want ik heb liever een Rus in mijn keuken dan een Amerikaan in mijn meterkast;-)
Oudlid weer op zijn eiland waar de de nist definitie van cloud nog niet is aangespoeld.
mbt het vergeten van geografie en landingsrechten heeft iedereen natuurlijk zijn eigen ideeen over locatie, eigenaarschap en geschiedenis
daarop aansluitend past dat als je graag een rus in de keuken hebt, ik je oekraine kan adviseren
Alweer zo’n mooi artikel waarin duidelijk wordt dat afstemming bij zowel on-premises als cloud gebaseerde oplossingen (en hybride combinaties hiervan) vastloopt bij een datagedreven (en daarmee ook procesgedreven) benadering, en juist van de grond komt bij een taalgedreven aanpak.
Want: afstemming ‘=’ stem ‘=’ taal.
https://synoniemen.net/grafisch.php?zoekterm=stem
Die Dino, wat betreft de echo’s uit het verleden kwam hij 17 juni 2021 niet verder dan SWA verwijten dat hij een unix sysadmin uit Jurasic park is. De stem van Jack in het woord stemmingmakerij ontbrak helaas in die discussie hoewel hij (door mij) gemist werd als het om het kaderen van ideeën in definities gaat met het bekende politieke psychologische probleem van loketdenken. Tenslotte kent NIST een Europese tegenhanger zoals ENISA en werken we al enige tijd aan een Europese tegenhanger voor GPS en zijn drukdoende met GAIA-X omdat de digitale monocultuur in Nederland ons afhankelijk maakt van big tech die aan leiband van Washington loopt.
Het is dus maar te hopen dat ik veel gebakken lucht produceer zodat we de Rus in de meterkast niet nodig hebben omdat de windmolens in onze honger naar energie voorzien. Hoorde gisteren aan de bierpomp het gemor over prijzen aan een andere pomp en ben benieuwd wat de Amerikanen in de schakelkast van internet gaan doen, ze deden eerder het licht uit bij Kim Dotcom wat bij Senvja volgens mij voor een verlies zorgde omdat er aanzienlijk wat servers van MegaUpload in Nederland stonden. Beschuldiging van piraterij op industriële schaal is gezien de boekaniers in Amerikaanse tech industrie (Facebook, Google, Amazon en Microsoft) daarmee zoiets als Al Capone voor belastingontduiking veroordelen.
Wat betreft de definities is belastingontduiking namelijk strafbaar maar als je het slim doet en belastingontwijking noemt is er niks aan de hand. Het mooie van taal is dan ook dat je belasting een toegevoegde waarde kunt noemen terwijl het alleen maar prijsopdrijvend werkt zonder enige waarde.
Jack,
Het datagedreven gebeuren in een proces kent in internationale afSTEMming de codering van de regels waardoor de gesproken taal niet meer dan een correponderende regel in een tabel is. Het gaat uiteraard mis als één begrip meerdere vormen van uitleg kent, zo waren 6 Amerikaanse gallons gelijk aan 5 Britse gallons. De beschrijvende data – metadata? – is net als de afgesproken definitie belangrijk als het om de dimensioneringen gaat. Je link geeft dan ook een leuk voorbeeld van een ‘semantisch web’ waar je zonder de juiste context in de gedachtespinsels verstrikt kunt raken als je het verkeerde spoor volgt. Tenslotte klaagt klepelaar in het noorden altijd dat ik het spoor bijster ben als ‘windtalker’ door een wat vrijere interpretatie van de taal heb.
https://www.youtube.com/watch?v=L39XBKcttx4, ja daar issie weer
“internationale afstemming”, zoiets als de vn of het europese parlement hahaha.
oudlid die plotseling het licht ziet mbt het belang van definities, dat je het over hetzelfde heb, altijd handig.
jack daait zijn filosofische speeldoos weer af, maar hoe dat nou meerdere clouds gaat afstemmen..
Afstemming kan worden opgevat als een combinatie van sturing en samenwerking. Samenwerking wordt gedefinieerd als het ontplooien van activiteiten waarbij participanten een gezamenlijk doel nastreven en de sturing heeft betrekking op de invloed die wordt uitgeoefend om dit gezamenlijke streven tot stand te brengen. En wat betreft de gezamelijke definitie van HET DOEL zelf wijs ik op de Europese tegenhanger van een Amerikaans instituut welke op een aantal strategische punten afwijkt van de Europese belangen.
De eerste vraag Dino, over bananen of bonen gaat tenslotte om abstracte waarden die in de filosofie van Zijn & Tijd anders ervaren kan worden als we kijken naar zoiets als ‘Governance-as-a-Service’ waarbij EU-US privacy shield door het Europese Hof onrechtmatig is verklaard omdat het gezamelijke doel niet meer een gedeeld doel is. Ja, ja taal is een lastig dingetje maar al 10 jaar roep ik hetzelfde over de cloud alleen verander ik wel steeds van naam.