Multicloud zonder strategie is geen optie

"Elk bedrijf moet een multicloudstrategie hebben, ook als er nog geen plannen zijn om hiermee aan de slag te gaan", vindt Ilja Heitlager, cio van Schuberg Philis. "Het begrip is er en als je je er niet van bewust bent, overkomt het je omdat alles tegenwoordig versaast en vercloudt."

De term 'multicloud' omschrijft niet één type 'cloud', het is een verzamelnaam voor het samenbrengen van verschillende clouddiensten. Dit kan gaan van het specifiek inrichten van verschillende applicaties op enkele van de verschillende clouddiensten die er bestaan, zoals Azure, AWS en Google. Het kan ook gaan om het gecombineerd gebruik of orkestreren van clouddiensten die met behulp van de 'grote drie' samen met saasdiensten in elkaar zijn gezet. Denk daarbij aan bijvoorbeeld een Office 365-omgeving, Salesforce, GitHub en wat al niet meer.

Dat it'ers hierdoor anders werken dan vroeger, staat buiten kijf. "Er is een reden dat de verhouding devs en devops inmiddels ergens rond de een op dertig is geworden. Pin me niet vast op die getallen, maar we gebruiken gewoon steeds meer van dat soort diensten", zegt Ilja.

"Vroeger moest je nog goed nadenken over waar je in investeerde, omdat alles heel veel geld in een keer kostte: de softwarepakketten, je lokale servers en infrastructuur bijvoorbeeld. Nu kun je nieuwe ideeën bedenken en je kunt ze zo uitrollen door even ergens een dienst aan te zetten. Werkt het niet? Dan zet je het weer uit en kost het geen geld meer."

Klant bepaalt

"De verhouding tussen klant en it'er is ook gigantisch veranderd", legt hij verder uit. "De klant, want het gaat hier immers over bedrijfsgerichte it-oplossingen, bepaalt voor ons. Het maakt voor ons niet uit welke cloud we gebruiken; in die zin zijn we cloud-agnostisch. Als je dat laatste overigens vanuit de technische kant bekijkt, zou je cloud-onafhankelijk moeten ontwikkelen, maar daar gaat het in ons geval meestal niet om, tenzij de klant dat wil natuurlijk."Het is fijn om voor één stack te kiezen, want daar kan een it'er heel goed in worden, maar je zit al sneller in een multicloudomgeving dan je denkt.

Dit veranderde landschap betekent heel wat voor de it'er zelf, die moet anders durven werken dan vroeger, net zoals meer flexibel zijn in het gebruik van programmeertalen. "De it'er moet sneller kunnen leren als een klant voor een bepaalde omgeving kiest. De it'er heeft daarin mee te gaan", legt Ilja uit.

Het zijn vaak emotionele argumenten om geen multicloud in te zetten. "Je kunt het vergelijken met fotografie: je hebt Canon-adepten en Nikon-liefhebbers. Dat is in veel gevallen een emotionele keus en niet rationeel. In het geval van it is dat nu AWS, Azure of Google. Denk daarbij even aan Sony dat met systeemcamera's een grote voorsprong wist te behalen en ook een mount voor je oude Canon-lenzen ging leveren, zodat je die nog kon gebruiken en gemakkelijker kunt overstappen. De partij die multicloud voorstelt, is de partij die nog niet binnen is."

Het is fijn om voor één stack te kiezen, want daar kan een it'er heel goed in worden, maar je zit al sneller in een multicloudomgeving dan je denkt. "Als je intern al Microsoft gebruikt, ga je al snel naar Office 365 en Azure, terwijl je ondertussen misschien al onderdelen bij AWS draait. Zonder dat je het doorhebt, zit je al in een multicloud waar je een strategie voor moet hebben", zegt Ilja.

Kies niet voor multicloud

"Als bedrijf moet je bewuster niet voor multicloud kiezen, maar als it'er juist wel. Vroeger was dat andersom, de it'er had zijn favoriete toolbox en daar moest een bedrijf maar in mee. Nu zijn bedrijven veel bewuster en banger voor vendorlock-in, omdat de snelheid van ontwikkelingen en handelen is toegenomen."

Juist daar zit een belangrijk onderdeel van de keuze om wel bewust voor een multicloudstrategie te kiezen, omdat je volgens Ilja anders vanzelf in een vendorlock-in-situatie terechtkomt. Dit komt doordat elk bedrijf een traditie heeft en al die technieken worden allemaal vercloud en versaast. "Let je niet op, dan zit je ineens met een wirwar aan cloud- en saasproviders, en is dat zo lastig aan elkaar geknoopt dat loskoppelen lastig wordt."

De belangrijkste reden om voor één cloud te kiezen, is om heel snel een dienst uit de grond te stampen. "Netflix koos indertijd heel bewust voor AWS. Het ging ze maar om één ding: streamen en niets anders. Amazon had, zeker toen, de beste papieren wat schaalbaarheid betreft. Vervolgens kon iedereen in een dergelijk team zich richten op ontwikkelen voor die technologie. Als ze in de toekomst ooit een ander platform ernaast willen gebruiken, om bijvoorbeeld minder vendorlock-in te hebben, dan kan dat probleemloos. Het is in die zin al lang geen louter technische keuze meer."

Opdracht voor de it'er

Toch hinkt ook Ilja op twee gedachten over multicloudstrategie. Het komt er volgens hem min of meer op neer dat als je een opdracht hebt voor een bedrijf, je moet proberen zelf niet in een multicloudsituatie terecht te komen voor je opdracht, want dat leidt tot meer complexiteit en afleiding. “De opdracht voor de it’er is nu veel meer jezelf beperken als je voor een bedrijf bezig bent, omdat je tegenwoordig veel meer verantwoordelijkheid hebt."

Voor je het weet, zit je diep in een multicloudomgevingDe bottomline is dat bedrijven digitalisering zo snel mogelijk achter zich moeten laten bij bedrijfsautomatisering, zeker omdat je met elke cloud min of meer alles kunt realiseren en de technische redenen nog maar klein zijn. "Kies er een en ga."

Elk bedrijf is een it-bedrijf

Elk bedrijf is tegenwoordig een it-bedrijf of heeft in ieder geval een digitaal randje, waardoor de it-afdeling nog minder op zichzelf staat en echt onderdeel is van het bedrijf. "It-afdelingen zijn gewend om grondige keuzes te maken over waar je mee in zee gaat, terwijl je als it'er nu veel sneller kunt leveren door op een van de clouds te springen. Hierdoor is de technologiekeuze veel minder relevant geworden", zegt Ilja.

Hij geeft aan dat het fenomeen multicloud sneller zijn intrede doet dan je denkt. “Denk aan het gebruik van GitHub en CircleCI, dat zijn al twee saas-providers. Gecombineerd met Office 365, nog een Salesforce-app en allerhande andere powerapps, nog een datalake bij AWS, wat marketinganalyse en de beste machinelearning bij Google. Voor je het weet, zit je diep in een multicloudomgeving.”

Voordeel multicloud

Beseffen dat multicloud bestaat en dat het ook grote voordelen kan bieden, mits goed ingericht, is de crux, omdat je niet in een keer alles hoeft te vervangen. "Stel, je bedrijf gebruikt honderden apps. Die kun je heel gemakkelijk vervangen en dat hoeft niet allemaal in één keer. Je begint gewoon met eentje, vervangt die door een ander en zo kun je alles afwerken wat je wil vervangen."

Ook wat kosten betreft blijft het overzichtelijk, want je betaalt over het algemeen per tijdseenheid en niet voor het product zelf. Wat dan overblijft, zijn vooral technische zaken, zoals de veiligheid, de latency tussen de apps en dergelijke. "Je moet natuurlijk niet alles bij verschillende diensten draaien. Dat kan knap lastig en complex worden, maar je kunt een deel van het bedrijf elders onderbrengen. Dan is er niets aan de hand."

Om het Cruijffiaans te houden: "Je kunt heel snel schakelen, maar het nadeel is dat je heel snel kunt schakelen."

Schuberg Philis-diner

Op 5 maart 2020 houden we het Schuberg Philis-diner, een meetup waarbij je op het kantoor van Schuberg Philis te Schiphol-Rijk echt een kijkje in de keuken krijgt. Vorig jaar hadden we bijvoorbeeld een workshop Docker & Kubernetes onder begeleiding van Schuberg Philis Engineers. Daarnaast was er een keynote over Security in de cloud. Binnenkort gaan wij aan de slag met het samenstellen van het programma voor het volgende Schuberg Philis-diner. Wil jij hiervan op de hoogte worden gehouden? Vul dan onderstaande poll in. Zodra het definitieve programma bekend is ontvang je één mail van ons.

Bekijk hier het verslag van vorig jaar om een indruk te krijgen.

Wil jij op de hoogte worden gehouden van het Schuberg Philis-diner?

Poll

Ja, houd mij op de hoogte
Nee, ik hoef niet op de hoogte gehouden te worden

De opties zijn uitgeschakeld omdat de deelname gesloten is

Dit artikel is een onderdeel van een artikelenreeks in samenwerking met Schuberg Philis.

Dit artikel is geen redactioneel artikel, maar een advertorial. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen, daar zullen collega's aanwezig zijn om jouw vragen en/of opmerkingen te bespreken/beantwoorden.

Reacties (42)

[Cergorach]

Nu zijn bedrijven veel bewuster en banger voor vendorlock-in

Bedrijven wisten vroeger niet eens wat het was, nu hebben niet-ITers er wel eens van gehoord en sommigen weten wat het is, maar hebben nog steeds geen idee wat voor invloed en/of risico het heeft op hun bedrijf. Het zijn nog steeds ITers die ergens vraagtekens bijzetten of alarm belletjes laten afgaan.

En wat een hoop mensen vendor lock-in vinden, vind iemand anders gewoon een scripted export/import functie voor... Het is vaak een tool voor verkopers om de concurrentie zwart te maken... Er zitten altijd flinke kosten aan een product migratie, welke gebonden is aan de complexiteit van het product/proces/data.

We hadden het vroeger over vendor lock-in wanneer we de data gewoon niet fatsoenlijk uit een product konden krijgen in een formaat wat iets anders uit kon lezen, dat zie ik tegenwoordig nog maar heel weinig gebeuren in systemen/applicaties.

[Meekoh]

Helemaal mee eens, de grap is dat wij vaak op C(I/F/E)O niveau vaak dit soort angsten horen.
Men is bang dat wanneer ze voor cloud vendor specificieke techniek X kiezen ze daar voor altijd aan vast zitten (je zou het bijna een Oracle syndroom kunnen noemen ). Maar als IT'er zie ik dat niet perse als een zwakte.
Zolang je de data er maar weer op een normaal formaat uit krijgt kun je het elders wel weer importeren.
Ik zeg niet dat het geen geld kost, maar iedere vorm van migratie kost geld ook wanneer je binnen cloud vendor Y blijft en zijn techniek X End of Support nadert.

Het moet je niet tegenhouden. Weest je bewust van het feit dat je voor cloud ABC en bijbehorende technieken kiest en reken dat door als risico. Soms weegt het voordeel (in euros) dat je nu kunt halen uit techniek X gewoon meer op tegen eventuele migratie kosten in de toekomst.

[Reactie gewijzigd door Meekoh op 24 juli 2024 10:43]

[Verwijderd]

Klopt allemaal maar het artikel schetst een beeld alsof cloud diensten sterk uitwisselbaar zijn wat in veel gevallen dus niet zo is.

Als je bijvoorbeeld de Amazon AWS bijbel volgt, dan knip je je applicatie in stukjes en draait die in cloud-native diensten. Dus geen EC2, maar een combinatie van Lamda, SES, Logging, RDS, S3...whatever.

Al die losse componenten in de architectuur zijn AWS specifiek. De lock-in is niet zwak, maar juist 100%. Een dergelijke app naar Azure of Google brengen betekent gewoon compleet opnieuw beginnen.

Daarentegen kan vendor-lockin overrated zijn. Het is in de praktijk lang niet altijd belangrijk om makkelijk te kunnen switchen, dat is alleen zo bij een onstabiele provider.

[DennusB]

Ik snap wat je zegt, maar het klopt natuurlijk niet helemaal : Lambda zijn gewoon functies in programeertaal X (Node, Python, .NET etc), die kan je ook gewoon in een Azure Function opspinnen, mits je niet heel veel cloud functies aanroept vanuit je code, want die moet je inderdaad wel herschrijven.

RDS is gewoon MySQL, SQL Server, Postgres etc, data export en importeren bij een andere cloud en je kan weer door.
SES is een hele simpele mail relay server, als je dat netjes als config aan je applicatie meegeeft lijkt me dat je vrij snel kan wisselen!

[raptorix]

Eens, ik moest vorige toevallig onderzoek doen naar een cloud-exit strategie, niet dat die kans groot is, het is wel verplicht, de meeste componenten zijn prima te migreren, echter hoe meer je PAAS of SAAS gebruikt hoe lastiger het word, en dat is dan ook weer precies het wrange dat de organisatie streeft naar een zo hoog mogelijk gebruik van PAAS/SAAS, wat opzich natuurlijk een prima gedachte is

[Elefant]

Calculeer ook in dat de grrote cloud providers op den duur zo een machtpositie krijgen dat ze stiekem steeds meer lock-ins gaan invoeren, waar de klant pas achter komt als hij wil migreren. In het begin stadium gaat het er om iedereen in de cloud te krijgen, zitten de meeste bedrijven in de cloud dan wordt het zaak om ze te binden.

Juist omdat het gepaard gaat met gigantische infrastructuur waar schaalvoordelen de prijs sterk bepalen zal het inderdaad een zaak van de grote drie worden. Zodra de kaarten geschud zijn, wordt het hun belang om de bedrijven op te sluiten en de prijs te verhogen. Daar varen ze dan alle drie meer wel bij, dan op prijs concurreren.

Het idee volgt dat van een visser. Laat eerst zoveel mogelijk vissen in de fuik zwemmen, sluit dan pas het net.

Als gezond bedrijf met een lange termijnvisie en een streven naar continuiteit (zeldzaam tegenwoordig) zou je liever je een homecloud opzetten dan je over te leveren aan grote leveranciers. Uiteindelijk wordt je uitgebeend.

Ik las pas over de staalproducenten, die werken met marges van rond de 10% en zitten nu met structurele overcapaciteit op de wereldmarkt van 25% . Maar hun echte problemen worden veroorzaakt door hun leveranciers van ijzererts. Dat zijn er nog maar 3. En die eisen in de supply chain 40% van de totale marge op.

Lees ook eens over de 250 organisaties die aan de bel trekken omdat ze uitgebeend worden door bedrijven als Oracle die ze met extra rekeningen bestoken door voordurende voorwaarden van gebruik te beperken. Wie denkt, dat doen die grote jongens niet, die snapt er niets van. Juist die grote jongens doen dat omdat ze daar ongelooflijk veel geld mee kunnen binnenharken. Fatsoen is daar een vies woord. Als grote bedrijven en overheidsorganisaties daar slachtoffer van worden wentelen ze het weer af op de burger en betaalt die weer het gelag van hun stommiteiten.

Uitbesteden is leuk in een vrije markt. Daar is genoeg concurrentie en kan je altijd switchen. Zodra het een oligopolie wordt, gaan bedrijven de marktleider volgen in zijn prijsstijgingen en restricties. Nu is dat nog geen probleem, maar intelligentie betekent toch vooruit kijken? Bedrijven die je willen helpen dingen naar de cloud te brengen zijn er genoeg, maar als het slecht afloopt hoef je daar niet aan te kloppen.

Eigenlijk is Nederland bezig zich als land op te heffen. Je kunt wel roepen dit is de toekomst, maar dat is wel een nare toekomst die je dan omarmt. Dat krijg je als iedereen alleen maar mee wil verdienen zonder verder te kijken.

En hoeveel van die grote cloud providers zijn Europees? Waarom subsidies dumpen in geluidswallen op het platteland, en ondertussen de belangrijkste infrastruktuur totaal verwaarlozen. Je hebt daar zelfs geen druppel subsidie voor nodig, ze hadden alleen maar de markt hoeven beschermen en ze waren hier vanzelf als paddestoelen opgeschoten.

Overigens best goede advertorial. Eerst angstscenario schetsen van cloudfragementatie en dan de opluchting, het hoeft allemaal niet. Gewoon lekker bij je vertrouwde provider, en je kan altijd switchen hoor. Mooie beloftes, maar wel "ohne gewähr". Zag gisteren dat Hans Klok zich in Duitsland had laten begeleiden door professionals en met een schuld van een paar miljoen achterbleef. Heeft 15 jaar moeten zwoegen om die weer weg te werken.

Hoe kun je bereiken dat mensen weer eens verder gaan kijken dan hun neus lang is?

[Reactie gewijzigd door Elefant op 23 juli 2024 12:18]

[raptorix]

Helemaal mee eens, maar ook buiten de cloud ben je niet veilig, je zult altijd in zekere mate kans hebben op vendor lockin, wat betreft databases ontkom je bijna niet aan propriety keuzes, echter organisaties zijn natuurlijk ook niet achterlijk, tegenwoordig is contractueel meestal afgesproken (en zelfs vaak wettelijk) dat software leveranciers aan data portabliteit moeten doen.

Kortom het is een beetje strategisch aftasten, ik heb recentelijk voor 2 grote multinationals gewerkt die wel een strategische samenwerking zijn overgekomen, ik mag hopen dat die contracten wat verder gaan dan standaar SLA's, sterker nog in 1 van de samenwerkingen neemt Microsoft weer "goederen" af van deze partij, hopelijk begrijp je dat ik liever niet spreek over mijn klanten.

[Verwijderd]

Fair enough, ik schudde maar even wat diensten uit mijn mouw maar het is in zijn totaliteit niet triviaal om te switchen. Tel daarbij op scripting (om dingen te auto launchen en configureren) en een super complex authorisatie model welke ook zeer specifiek is voor AWS en het is geen koud kunstje.

Als zijdelings punt: ik vind dat de "guru" in het artikel overdrijft wanneer hij stelt dat een IT-er zomaar even tussen dit alles moeten switchen. Ik ken AWS architecten die alleen maar AWS doen en de grootste moeite hebben om alleen dat al bij te benen.

[MadEgg]

Als het goed is ontwerp je je slimme stukjes code als een platform-agnostische library. De rest zijn stukjes lijm die je library aan de cloud native diensten plakt. Die lijm moet je opnieuw ontwikkelen of op zijn minst aanpassen, de daadwerkelijk slimme stukjes code niet.

Maar goed, vanzelfsprekend is de cloud providers er veel aan gelegen om zo veel mogelijk de lock-in te creëren. Als goede ontwikkelaar doe je een beetje extra moeite om dat zoveel mogelijk tegen te gaan.

[Ed Vertijsment]

Ik gebruik bewust liever niets anders dan een (aantal) "domme doos/dozen" van provider X, of Y, of Z. De rest gewoon in configuratie management (in mijn geval Ansible) en deployen maar. In dat geval kun je gewoon zelf de werking afdwingen en binnen ongeveer 30 seconden van leverancier veranderen, wel zo fijn.

[Cergorach]

Sure, maar dat is niet efficiënt in veel gevallen, niet in snelheid, in kosten en vaak ook niet qua schaalbaarheid. En wellicht ben je niet afhankelijk van de leverancier qua server hardware of VM platform, maar je zit nog steeds aan je OS, je Ansible, etc. 'vast'. Effectief verplaats je je afhankelijkheden naar je eigen tooling en qua tooling veranderen kan een vrij complex geintje wezen wat redelijk wat tijd kan kosten en een enorme impact op je bestaande klanten kan hebben (indien je opeens over moet).

@Ed Vertijsment Het is precies wat @Meekoh aangeeft, je verplaatst het issue imho.

[Reactie gewijzigd door Cergorach op 24 juli 2024 10:43]

[Ed Vertijsment]

Ik mis hier een beetje het punt. Ja je verplaatst de afhankelijkheden naar eigen beheer. Maar dat is volgens mij niet moeilijker dan elke keer de specificaties van vendor X bekijken om te zien of hoe dat werkt.

Mja, vast aan het OS, sure. Maar zolang het maar SSH snapt zie je relatief safe, en bovendien beperkt niets je om off the shelf playbooks te gebruiken en deze te deployen. Scheelt je weer beheer.

Ik zeg niet dat het geen kostenplaatje heeft, in mijn ervaring is het vaak wel een lager kostenplaatje dan de cloud die vooral op papier goedkoper lijkt, maar niet in de realiteit. Zelf heb ik nog aan een groot project gewerkt dat juist van de cloud is teruggegaan naar enkele sterke VPS omdat dat gewoon gigantisch veel geld scheelde (en voor de meeste project de schaalbaarheid van cloud 0 toegevoegde waard heeft, ook de miljoenenpubliek websites, en ja daar werk ik mee).

Laten we zeggen dat het een niet per se duurder of goedkoper hoeft te zijn, gebruik vooral je wat je het fijnst vindt. Echter zijn al die SaaS platformpjes wel een recept voor vendor lock ins.

[Meekoh]

Ik denk dat het punt wat @Cergorach probeert te maken is, dat in sommige gevallen een vendor lockin een aanvaardbaar en ingecalculeerd risico is. (correct me if I am wrong)

Tooling lockin is bijna net zo "gevaarlijk", je wilt niet weten hoeveel code en werk er in onze Chef cookbooks (Dat Ansible alternatief) zit.
Weggaan van Chef is echt een Huge challenge, de cookbooks (71 stuks) die wij ook open sourced hebben zijn slechts een fractie van wat er aan cookbooks in gebruik is binnen het bedrijf(honderden). Ook dat is niet zomaar omgezet naar Ansible of Puppet en is ook absoluut geen laag kostenplaatje.

Maargoed toegegeven een VPS kan ook prima, gewoon een "extra cloud"

[goarilla]

Waarom wil je migreren weg van chef ?

[Meekoh]

Ik zeg nergens dat ik weg wil van chef Het was bedoeld als voorbeeld van tooling die toch wel heel erg verweven is in je landschap.

Wij zijn zelf grootverbruikers van Chef, een aantal van onze community cookbooks zijn bijv. door Chef overgenomen en zijn tegenwoordig standaard onderdeel van Chef zelf.

[Vagary]

De belangen bij zowel Cx/managers en IT'ers lopen flink uiteen, onder IT'ers benoem ik zowel developers, architecten en operationele engineers.
Managers willen vaak intern kosten besparen terwijl de IT'ers juist meer budget willen hebben om zichzelf of de bestaande IT omgeving verder te ontwikkelen.

Er wordt nog teveel met de oogkleppen op besloten, men denkt nog teveel aan het eigen technische project in tegenstelling hoe je meerdere projecten tegelijk beter kan servicen op basis van bijvoorbeeld een geautomatiseerde multi IAAS oplossing. De 1 doet wat in Azure, de ander is wat aan het proberen in AWS en zo werken ze in silo's terwijl de bedoeling was de IT omgeving te optimaliseren. We zijn gewoon weer terug in UX en MCSE werelden.

Dat kan te maken hebben met het onvermogen om te willen veranderen of juist onvoldoende visie op een strategie en de uitwerking daarvan, misschien is het een combinatie. Ik zie toch vaak dat het geen vervolg krijgt doordat een manager te kennen geeft ingefluisterd te zijn door zijn medewerkers dat er geen toegevoegde waarde te behalen valt. De manager moet het support krijgen van zijn achterban anders loopt zijn project sowieso gevaar, immers de manager kan niet voldoende inschatten of het echt gaat helpen.

Ik kan zo 10 top bedrijven noemen die geen idee hebben over hun uitgave patroon op cloud gebied en of dat gerechtvaardigd is ten opzichte van de uitkomst en duur van een cloud project, een project dat ofwel transformeert naar een cloud omgeving, waarbij developers omgevingen testen en/of onderzoek doet naar een multi cloud omgeving of al bezig is aan een multicloud oplossing.

Ik denk dat de belanghebbenden in een bedrijf intern daadwerkelijk samen doelen moeten definieren wat een mogelijke strategie kan opleveren. Als ik langskom, als IT dienstverlener, voordat dat gebeurd is het vaak gissen naar wat een bedrijf nu eigenlijk wil.

[kruigerb]

Uberhaupt cloud zonder strategie is geen optie......

[Meekoh]

en toch gebeurd het

[Cergorach]

Cloud kan prima zonder een 'strategie' zoals je dat noemt. Het is een tool uit de toolbox en je gaat niet voor elke tool een strategie bedenken. Cloud kan zo simpel zijn als: we hebben functie x nodig, wat zijn de kosten/baten voor optie a/b/c? Niet ieder bedrijf heeft daar een IT strategie voor nodig, deze gebruiken IT als een tool om de daadwerkelijke 'productiestraat' te laten draaien. Niet alles heeft een custommade en complexe IT applicatieketen nodig... Ik zou zelfs willen zeggen, dat je dat zoveel mogelijk wil vermijden.

[rkeet]

*click* on
*click* off

[NicoJuicy]

Het is fijn om voor één stack te kiezen, want daar kan een it'er heel goed in worden, maar je zit al sneller in een multicloudomgeving dan je denkt.

Blijkbaar de hype van microservices gemist

Enneuh, multicloud = Azure Arc vreemd genoeg klik

[Reactie gewijzigd door NicoJuicy op 24 juli 2024 10:43]

[Meekoh]

niet bepaald, meerdere klanten van ons gaan al de microservice kant op inclusief wijzelf. Alleen ook de hele Microservice hype heeft zo zijn haken en ogen.

Azure Arc is interresant (paar collega's lopen nu rond op Ignite, dus ben benieuwd naar wat ze hierover hebben opgestoken), maar MS is daar geen vreemde in. Je kunt in andere MS producten ook al AWS managen (Azure Stack, SCVMM, Azure DataFactory etc.).
Het past helemaal in het straatje dat Microsoft alles en iedereen wil ondersteunen.

[Reactie gewijzigd door Meekoh op 24 juli 2024 10:43]

[Tha Render_2]

Zo goed als elk bedrijf zit in een multicloud scenario. Heb je een lokale server of workload draaien en zitten je mailboxen in Office 365? Dat is multicloud. Je eigen on-premise IT-infrastructuur is verbonden met het internet dus bezie dat als je eigen private cloud, in combinatie met dan O365 wat public cloud is. Dus ja, multicloud is the way to go, maar het is belangrijker om aan workload placement te doen, wat is de beste locatie per workload? Private cloud, public cloud of partner cloud?

[Seth_Chaos]

De cloud is toch wel de mooiste marketing term van deze eeuw. Hoe krijg je bedrijven zo ver dat ze een dienst afnemen waar ze vrijwel geen zicht en of controle over hebben.

[DennusB]

Wat mij betreft kan je zicht en/of controle deels oplossen in de cloud, zeker in een multi-cloud solution. Wat voor zicht of controle mis je?

[Cergorach]

Hoe krijg je bedrijven zo ver dat ze een dienst afnemen waar ze vrijwel geen zicht en of controle over hebben.

Doordat de meeste bedrijven helemaal geen zicht en/of controle daarover willen hebben. Ze willen iets invoeren en ze willen dat er iets uitkomt zoals zij dat willen, ze willen dat dit zo goedkoop mogelijk gebeurd (TCO), zo weinig mogelijk downtime als ze werken en er het liefst zo weinig mogelijk aan hun kop over worden gezeurd. Beveiliging en hoe dat in de toekomst blijft werken is vaak maar bijzaak. IT is voor het gros van de bedrijven geen corebusiness en zo hoort dat ook.

Want laten we eerlijk wezen 'bedrijven' hebben ook geen toegang tot lokale systemen omdat de IT beheerders alle admin accounts beheren. Over het algemeen heeft een directeur geen admin account, zeker niet zonder tussenkomst van een IT beheerder. En ik heb genoeg ongein meegemaakt waarbij IT beheerders dergelijke data ontoegankelijk maakten voor het eigen personeel, raar maar waar. Zelfs meegemaakt dat we door een muur heen moesten omdat het toegangssysteem stuk was om in de serverruimte te komen...

Controle over IT systemen is een illusie waar men vanaf moet.

Ik vind dit een hele goede weergave van de werkelijkheid:
https://xkcd.com/2224/

[Meekoh]

Zo nieuw is het niet, hetzelfde geld bijv. voor nagenoeg alle nutsbedrijven.
Je neemt een dienst af elektriciteit bijv., maar je hebt geen zicht in het productie proces.

[Seth_Chaos]

Ja, maar daar breng je niet al je data onder. Als klant heb je geen vat op de beveiliging. Je weet nooit hoe veilig je data werkelijk is, en kunt daar dan ook geen garanties op geven. Je legt als organisatie een hele hoop vertrouwen bij zo'n bedrijf.

[Meekoh]

Nogmaals, dat kan geheel wenselijk zijn vanuit een bedrijfsperspectief.
Ga je dan als bedrijf een eigen datacenter opzetten, zelf je security regelen zowel fysiek als digitaal, brandveiligheid etc.? Alles onder controle houden? Dat worden een hoop datacentertjes dan

Immers als je je servers bij een hoster plaatst ben je ook niet 100% zeker wie er bij je data kan. Je hebt dan net zo min vat op de beveiliging als bij een van de grote publieke clouds. Bij een fysieke server kan een autoriteit bijv. net zo goed de data ophalen. Kijk maar eens naar hoe de Politie de Hansa Marketplace heeft overgenomen. Ze hebben zonder dat de eigenaar dit wist disks geswapped in de server (Met toestemming van de hosting toko en rechter natuurlijk).

Bovendien heb je bij de grote cloud providers wel degelijk zelf een groot aandeel in de beveiliging.

Hetzelfde vertrouwen leg je bij de stroomleverancier, geen stroom is vaak geen productie en dus geen inkomsten.

[Seth_Chaos]

Dat is allemaal niet nodig. Er zit fysiek geen verschil tussen hosted servers en een cloud omgeving. Het berust op dezelfde hardware. Alleen bij de één neem je je verantwoording over de omgeving en je eigen data, en bij de ander geef je het allemaal uit handen, en hoop je maar dat dat achter gesloten deuren goed geregeld is.

[Meekoh]

Bij een Azure/AWS ben je net zo verantwoordelijk voor je data als bij een True hosting of iets dergelijks.
Op server niveau is het vergelijkbaar, maar dat is niet echt wat ik bedoel.

Klanten van ons willen een audit doen op zowel ons datacenter als op hun data in de Azure datacenters bijv. Als je het wilt heb je gewoon het recht om achter die gesloten deuren te kijken. Dat is heel belangrijk auditability en compliancy. Je benaderd dit van een te technische kant. Het maakt niet uit waar het draait, audit's moeten in ons vakgebied (en met name bij de klanten waar ik mee werk) altijd gebeuren. Niks hopen -> Facts & Evidence

Bovendien ben je in een public cloud nog steeds verantwoordelijk voor je data. Jij moet zorgen dat je data encrypted is zowel at rest als in transit, dat de keys daarvan veilig zijn opgeslagen etc. Dat backups offsite worden geplaatst en ga zo maar door.

[Rolfie]

Maar kan je het als klant zelf beter, sneller, goedkoper en veiliger dan een cloud leverancier?

Als ik bijvoorbeeld kijk naar de MFA mogelijkheden biedt, daar kan ik zelf niets voor neerzetten.
Storage noodzakelijk, ik klik de T's zo bij klaar in een paar minuten.
Security inrichten? Hoe regel ik zelf mijn continuïteit bij een uitval? Hoe regel ik de fysieke toegang goed?

Ik heb wel zelf de controle hierover, als ik het zelf neer zet. Maar dat wil niet zeggen dat ik het zelf beter neer kan zetten.

[colinthart]

Versaast. Vercloudt. Multicloud. Pfft.

[Verwijderd]

Geweldig dit soort artikelen. In het engels zou dit al nietszeggende consultancy bullshit zijn maar verbasterd naar half Nederlands moet het vooral als komedie beschouwd worden.

[jeffer]

Het begint al met 'Elk bedrijf moet een multicloudstrategie hebben'.
Hoe serieus moet je dan de rest van het advertentie nemen...

Edit: Ik heb artikel maar even gewijzigd naar advertentie.

[Reactie gewijzigd door jeffer op 24 juli 2024 10:43]

[Meekoh]

Nou als je de rest van het artikel leest, best wel serieus.
Ik had ooit zo'n tshirt waarop stond: "There is no cloud, it is just someone else's computer"
Dat geld niet alleen voor de de Google/Microsoft/Amazon's van de wereld, maar alles wat ja als saas of paas dienst afneemt is in principe ook een cloud dienst.
Beetje MKB'er zit al zo in SalesForce, Exact Online, O365, Gsuite, Github, Azure Devops, Slack e.d. dat zijn toch echt meerdere cloud diensten en als je daar geen visie/plan overhebt...tsja your loss.

edit naar aanleiding van je edit:
Er staat toch ook duidelijk helemaal bovenaan "Advertorial"

[Reactie gewijzigd door Meekoh op 24 juli 2024 10:43]

[Cergorach]

Waarom zou een 'beetje MKBer' zowel O365 als Gsuite hebben, wat moeten zij met Github, Azure Devops of Slack? Ik ben het met je eens dat een 'beetje MKBer' op meerdere cloudplatformen/providers zit. Maar dat beetje MKB bedrijf is bezig met hun product, niet met de IT er achter.

Daarnaast gebeurd dat niet allemaal tegelijkertijd. Er worden met der tijd keuzes gemaakt en die worden (hopelijk) tegen de vorige keuzes aangehouden en men krijgt daar (hopelijk) een beetje degelijk advies over. Een klant denkt we hebben email via Office 365, dus de mail uit ons CRM daarmee versturen, iets waar Exchange Online niet voor geschikt is. De beslissingen ga je niet allemaal 'frontloaden', die ga je behandelen wanneer je er tegenaan loopt, want dat 'frontloaden' zou ten eerste veel te veel geld kosten dat nooit terug wordt verdient en ten tweede, tegen de tijd dat het naar voren komt is de beslissing alweer vaak achterhaalt. Dat heb je met een dergelijke snelle ontwikkeling en helemaal bij clouddiensten waar 'rolling updates' normaal zijn.

De essentiële beslissing is al veel eerder gemaakt, zijn we een IT bedrijf of zijn we een X bedrijf wat Y maakt? Als puntje bij paaltje komt, zijn de een hele hoop bedrijven dat laatste...

[Meekoh]

Miereneuken is ook een kunst he
Ik schud daar gewoon wat random SaaS diensten uit mijn mouw, je hoeft ze natuurlijk niet allemaal tegelijk te gebruiken, laat staan als MKB'er duh
Ging om het idee...

Ze zijn inderdaad bezig met hun product, hun "ding". Het feit dat ze al dat soort diensten gebruiken zegt genoeg over hun strategie van het "outsourcen" van IT diensten. Wat opzich ook al een vorm van "multicloud" strategie is. Wij focussen op ons core product en alles wat we daaromheen nodig hebben nemen we zo veel mogelijk als dienst af.

Mijn punt was ook niet zozeer de MKB'er an sich. Het punt dat ik probeerde te maken is dat alleen al dat soort bedrijven flink wat saas diensten afnemen. Dit geld in net zo grote mate voor groot/enterprise. Wellicht onbewust gebruiken ze dus al aardig wat "cloud" diensten. Alleen daar is shadow-IT in sommige gevallen ook een dingetje geworden, die SaaS diensten maken het allemaal ook zo simpel

[Reactie gewijzigd door Meekoh op 24 juli 2024 10:43]

[Rolfie]

Een klant denkt we hebben email via Office 365, dus de mail uit ons CRM daarmee versturen, iets waar Exchange Online niet voor geschikt is.

Exchange Online kan dit gewoon hoor. Het CRM systeem is dan het probleem en niet Exchange Online.

[Verwijderd]

Slack bij het MKB...beetje wereldvreemd?

[Meekoh]

Niet perse, ken genoeg MKB bedrijven/startups die slack gebruiken, maar dat is een beetje offtopic