Data Platform Dilemma's: Fabric, Databricks, Snowflake of toch Europees?

Wat je heel vaak ziet, is dat men eerst kijkt naar wat we al hebben. Maar als je even terugkijkt naar het dilemma, dan denk ik dat je eerst goed moet kijken wat je nou eigenlijk daarmee wil. En dat je daar je keuze op zou moeten baseren. Misschien zelfs nog een stapje daarvoor: wat is nou mijn doel met dat dataplatform? Want dat beïnvloedt wat mij betreft ook heel erg de keuze voor het platform zelf. Het ene platform is nou eenmaal sterker in het een, het andere platform is sterker in het ander.

Skiën. Maar niet zo heel goed hoor.

Nog niet.

Nee, we hebben één dag overgeslagen. Toen gaf hij heel veel sneeuw op. Achteraf had het wel gekund. Maar toen zijn we gaan hardlopen.

Jawel, dat telde ook wel mee.

Ja, dat klopt.

Nee, het hele logeerbed ligt vol. Maar ik heb de meeste spullen denk ik wel bij elkaar nu.

Maandag ga ik. Dus dat is nog een paar dagen.

Een paar keer Duolingo openen en dan komt het goed.

Ja, gitaar een beetje.

Oh, goede vraag. Nou, ik ben binnenkort jarig en ik heb een bordspelletje gekregen dat ik graag wilde hebben. Ik moet het nog spelen. Maar dat is een soort pandemic, een coöperatief bordspel.

Ja, daar heb ik weleens van gehoord.

Dan met het Lord of the Rings-thema. Ik ben echt de ultieme nerd, want je moet dus met een groepje samen de ring naar Mount Doom brengen.

Ja, inderdaad.

B.

Ja, ook B.

Nee.

Ah. Toch wel een beetje wishful thinking.

Ja.

Misschien.

Dat is wel een goed dilemma.

Ja, dat is wel een goed dilemma.

Dat ligt aan zoveel factoren. Ik denk idealiter B, maar realistisch A.

Ik wil wel beginnen. Als ik aan een dataplatform denk, dan denk ik aan alles in één platform. Waarbij je dus niet alleen je storage en je compute hebt, maar alles daaromheen wat je nodig hebt om je data engineering en je data-analyse te kunnen doen. Dus niet alleen te kunnen doen, maar ook goed te kunnen doen en goed bij te kunnen houden. Veilig, op een juiste manier. Denk aan je governance, je security, audit, monitoring, logging. Een hele lijst. En dat allemaal in één platform, in één UI. En natuurlijk waar je heel veel data kunt verwerken. Dus het draait niet op één machine, maar het is een cluster van machines. Dus die hele bak met data kan vrij snel gedistribueerd verwerkt worden.

Ik denk wel dat wat Cathy zegt, alles raakt wat een platform zou moeten zijn. Het gaat natuurlijk om data, dat is de kern. En ik denk dat de definitie dan dus is dat je alles kan doen met die data wat nodig is om er waarde uit te halen. Dat dat de definitie van een dataplatform is. En dan raak je dus alle punten die Cathy noemt. Maar ik denk dat dat wel een mooie definitie is: om het op te slaan, te bewerken, governance, et cetera. Dat je daarmee wel redelijk vangt, wat mij betreft.

Ik zou zeggen Databricks, Fabric en Snowflake.

Oké. Ja, Google denk ik nog wel. Google Cloud Platform, ja.

Nee, dat is een cloud provider. Die valt niet onder de definitie volgens mij.

Je kunt dataplatformen hosten op AWS.

Nee.

Nou, dat zou ik wel zeggen inderdaad.

Nee, het Google Cloud Platform heeft tegenwoordig best wel veel functies ingebouwd, waarmee je dus wel governance, databewerking, visualisatie, eigenlijk alles, daarbinnen gekoppeld hebt. Of het heeft een sterke integratie met andere Google-producten die dat doen. Dus ik denk dat je dat wel onder een platform kan scharen.

Ja, ik denk dat hetzelfde een beetje geldt voor AWS ook wel. Er zijn steeds meer toolingetjes die dan samen wel een soort platform zijn of kunnen zijn. Maar als je een beetje de definitie van Cathy volgt, dan niet.

Oké, nou goed, daar komen we later nog wel over te spreken.

Ja, wie wil dat vertellen? Ik weet wel wat het verschil is. Of tenminste, voor mij is het op zich wel een duidelijk verschil. Ik denk dat een deel ook wel een soort buzzwordachtig is.

De lakehouse-architectuur.

Of in ieder geval bedacht door de makers van dit object.

Ja, kijk, ik denk dat je een warehouse kan zien als de klassieke manier waarbij je gestructureerde data dusdanig opslaat dat je er iets mee kan voor reporting. Dat is denk ik een beetje voor mij wat de definitie is, met de nadruk dus op gestructureerde data. En ik denk dat als je naar het lakehouse-idee gaat, dat daar eigenlijk van de laatste jaren bij is gekomen dat je ook ongestructureerde data hebt, of semi-gestructureerd. En dat wil je ook vangen, en daar wil je ook iets mee doen en over rapporteren. En dat is een beetje waar nu de lakehouses op stoelen, zodat je eigenlijk ongestructureerd en gestructureerd in één unit kan verwerken en dat je daar wat mee kan. Een data lake is dan denk ik een beetje de onderliggende term. Dat noemen ze de opslag waar dat allemaal plaatsvindt, waar dat allemaal landt. Want bijvoorbeeld bij Azure heet het ook Azure Data Lake. Zo noemen ze het dus ook gewoon, wat in feite gewoon opslag is.

Misschien is je lakehouse een soort storage unit voor de lange termijn. Even om het visueel te maken: zo'n container die je kan huren en waar je oude meubels die je bijna nooit nodig hebt in kan gooien. En dan is je data warehouse misschien wat je in je keukenkastjes hebt staan, waar je makkelijk bij kan.

Ja.

Ja.

Dat kan zeker. Kijk, in feite is de ADLS de opslag van Azure, Azure Data Lake Storage. En daar kun je in feite alles opslaan wat je zou willen. Dat kunnen tabellen zijn die gestructureerd zijn, dat kunnen JSON-bestanden zijn die semi-gestructureerd zijn, dat kunnen foto's of video's zijn die niet gestructureerd zijn. En daar wil je iets mee doen. Met die tabellen kun je dat daadwerkelijk doen. Dus die kun je in een warehouse stoppen, en dan kun je het queryen en er wat analyse mee doen. En hetzelfde geldt eigenlijk voor een lakehouse, maar daar kun je dus ook je foto's en video's in stoppen, waarmee je dus ook met code iets kan doen en kan analyseren. En dat is eigenlijk het hele idee. Dus een warehouse is denk ik vooral gestructureerd, bedoeld om analyse te doen, queries te draaien. Een lakehouse is wat meer all-purpose, dus je kan dat stukje ook nog doen, maar je kan ook ongestructureerd en met andere talen werken. En daaronder ligt het data lake, wat gewoon de opslag is voor alles. Zo zie ik het een beetje.

En ik denk dat de toegevoegde waarde die je daaruit haalt, is dat je het op eenzelfde manier op kunt halen. Dus of het nou gestructureerde of ongestructureerde data is, het is één manier om met die data te communiceren. Dus er gaat een laagje overheen. Delta Lake is een protocol om met die data te kunnen praten. En dat zorgt er dan voor dat je op diezelfde manier met gestructureerde data kunt praten als met die ongestructureerde data.

Het is aan de ene kant een makkelijke keuze, en aan de andere kant ook een ingewikkelde keuze. Wat je heel vaak ziet, is dat men eerst kijkt naar wat we al hebben. Nou, dat kan iets on-premise zijn. Heel vaak in Nederland hebben heel veel bedrijven al Microsoft. En dat beïnvloedt vaak toch al wel de keuze voor een dataplatform. Maar als je even terugkijkt naar het dilemma, dan denk ik dat je eerst goed moet kijken wat je nou eigenlijk daarmee wil. En dat je daar je keuze op zou moeten baseren. Dus eigenlijk de architectuur, of misschien zelfs nog een stapje daarvoor: wat is nou mijn doel met dat dataplatform? Want dat beïnvloedt wat mij betreft ook heel erg de keuze voor het platform zelf. Het ene platform is nou eenmaal sterker in het een, het andere platform is sterker in het ander. Dus als je er heel blanco naar zou kijken, zou je bijvoorbeeld ook misschien minder snel bij Microsoft uitkomen, omdat een ander platform misschien beter bij jouw doel past. Maar omdat je Microsoft hebt, stap je over naar Microsoft bijvoorbeeld. Dus als je heel sec zou kijken naar wat je nodig hebt, ik denk dat dat belangrijk is: welk doel heb ik en welk platform past daarbij?

Ik denk dat je daarnaast ook zou moeten bedenken naar wat voor soort organisatie je toe wilt. Dus hoe ben je als organisatie georganiseerd? Wat voor soort mensen heb je in dienst? Wat voor soort teams heb je, of wil je naartoe groeien?

Ja, dat vind ik ook een hele mooie. Dat is ook belangrijk voor je keuze.

Ik denk dat je je daar ook niet te sterk door moet laten leiden, want vaak zijn bedrijven heel erg gesilood. En dan heb je ook het risico dat je data heel erg gesilood raakt. Dat zien we ook wel veel terug. Dat dan je marketingafdeling werkt met één dataset en je financeafdeling werkt met een andere dataset. En die werken allebei met dezelfde KPI's, maar ze zijn allemaal anders berekend, gebaseerd op andere bronnen. Ja, dan loop je tegen dat soort dingen aan.

Dus ik denk inderdaad dat je én moet kijken naar wat je nu doet, maar vooral ook naar waar je naartoe wilt en wat je wilt doen en hoe je dat dan wilt doen.

Precies, hoe je dat op de meest efficiënte manier kan doen.

De uitkomst kan dan zijn: je werkt nu in silo's, maar dat is misschien helemaal niet zo handig. Of misschien juist wel, want dat vinden wij wel handig.

Nee, voor je data dus meestal niet.

Ja, dat is wel belangrijk. Want welke mensen heb je nou, wat Cathy zegt? Heb je heel veel kennis in huis, of juist niet? Dat beïnvloedt denk ik ook wel de keuze.

Of wil je daarin investeren? Wil je die binnenhouden?

Juist, precies. Willen we een beetje low-codeachtig doorgaan? Of willen we juist hardcore developers hebben? Dat beïnvloedt denk ik ook wel je platformkeuze.

Wat dat betreft zijn er best wel veel opties mogelijk. Als je alles vanaf scratch zelf zou willen bouwen met je eigen data engineers, dan kan dat. Maar als je een volledig end-to-end SaaS-oplossing wil, dan kan dat ook.

Ja.

Dus en je hebt heel veel dingen die ertussenin zitten. Dus wat dat betreft is er gewoon heel veel mogelijk. Wat het ook niet makkelijk maakt om zo'n keuze te maken.

Nou ja, zeker. We zeiden het net al bij het dilemma: binnen drie maanden moet er waarde komen. Dus ik vind dat dat wel altijd het uitgangspunt moet zijn. Staat het dataplatform dan ook binnen drie maanden? Nou ja, ik denk misschien niet elk platform, maar ik denk dat er zeker platformen zijn waar je binnen drie maanden iets van waarde uit kan halen, inclusief het neerzetten.

Of misschien niet zo compleet als je het uiteindelijk zou willen, maar wel om iets te hebben waar je mee kunt beginnen.

En dat hoeft ook niet, denk ik. Dat is misschien dan ook de boodschap. Je hoeft niet altijd meteen binnen drie maanden klaar te zijn met alles. Ik denk dat het juist ook mooi is dat je daarna iteratief door kan ontwikkelen en de juiste dingen kan kiezen. Alleen, het is denk ik wel mooi als je focus is: ik ga zo snel mogelijk ook waarde uit zo'n platform halen. Ik heb dat weleens eerder gezegd: het hebben van zo'n platform op zich, dat boeit niet zoveel. Dus ik denk dat die focus wel belangrijk is.

Governance. Zeer belangrijk. En uiteraard kosten.

Het technisch neerzetten van een platform kan op zich best prima gaan, maar je hebt ook heel veel data die erop moet landen. En is die data kwalitatief goed? Zijn daar eigenaren van? Weten die eigenaren wat hun verantwoordelijkheden zijn? Dat zijn denk ik allemaal dingen die je ook mee moet nemen in zo'n proces. En dat zijn vaak juist ook dingen waar het mis op gaat, omdat dat ondergeschikt is eigenlijk.

Nou, een beetje van beide, denk ik. Ik denk namelijk dat de kern van het proces altijd hetzelfde kan zijn. Alleen ik denk dat het ene platform het beter kan faciliteren dan het andere platform. Dus als je daar al sterk in bent als organisatie, heb je daar misschien meer keuze in. Volgens mij komen we daar straks nog wel op. Databricks heeft daar volgens mij best wel mooie tools voor om dat heel goed te faciliteren en te ondersteunen. Dus dan kan het je ook weer helpen om dat proces goed vorm te geven en op te zetten. Dus ik denk dat het van beide kanten wel raakt.

Datamanagement klinkt altijd vervelend. Maar het is superbelangrijk.

Nou, ook dan is governance belangrijk, want de kwaliteit van je data is nog steeds belangrijk. En dat je daar enigszins zicht op hebt, is ook belangrijk. Dus ook al heb je tien man, als die allemaal actief data invoeren en jij wil iets met die data doen, dan heb je daar in feite niks aan. En dat valt wat mij betreft ook allemaal onder governance: zorgen dat de mensen bewust zijn van "hé, ik zit in een proces, we gaan hier later iets mee doen, dus ik moet dit wel goed invullen". Dat is ook al governance. En dat is eigenlijk onafhankelijk van hoe groot je bent. En dan klinkt het heel zwaar, maar dat kan bij wijze van spreken een handleiding zijn: doe het altijd zo.

Ik denk ook dat het helemaal niet moeilijk hoeft te zijn. Helemaal als het een kleine organisatie is, dan kun je heel klein beginnen. Maar het is wel heel makkelijk om het vanaf het begin af aan goed te doen. Je gaat er zo tegenaan lopen als je het niet vanaf het begin gedaan hebt.

Dat is waar. Ik denk eigenlijk inderdaad dat het makkelijker is bij kleinere organisaties. Omdat, hoe groter de organisatie, hoe vaker er al processen in play zijn die ook nog eens botsen met elkaar, waar men naar elkaar gaat kijken. Ik heb dat wel eerder meegemaakt bij opdrachten, dat processen totaal niet op elkaar aansluiten. En dat men dus ook elkaar gaat aankijken: ja, maar dat is niet mijn probleem, want dat komt uit jullie proces. Dus dan is het eigenlijk een groter probleem dan als je met z'n tienen bent en je gewoon kan zeggen "hé, we moeten dit even zo doen, want dan wordt het allemaal beter".

Dat kan in dashboarding bijvoorbeeld zitten. Dus een reden om een dataplatform te hebben kan bijvoorbeeld zijn omdat de business gebruik wil maken van dashboards, omdat ze iets uit hun data willen halen. Dan zou je kunnen beginnen met één klein minimaal dashboardje waarop die bepaalde datastroom alvast in kaart gebracht wordt.

Nou, of misschien nog makkelijker is ad hoc analyses laten doen als je één analist hebt die een beetje SQL kan. En dat je dat mooi in een data warehouse gemodelleerd hebt, zodat die daar makkelijk bij kan. Dan kan je al heel snel waardevolle inzichten halen uit die data, zonder dat je ook nog maar een dashboard hebt staan.

Wat je nu analyseert, wat je misschien in een uurtje gedaan hebt.

Ik zie daar ook nog als bijvangst in, wat misschien niet helemaal netjes is, het faciliteren van bepaalde processen. Daar kan een dataplatform ook in helpen. Omdat processen niet goed zijn ingericht, kan je bijvoorbeeld een soort cheaten door een dataplatform te gebruiken om dat te verbeteren.

Nou bijvoorbeeld, je hebt systeem A en je moet er allemaal data uithalen, en dat moet naar systeem B. Nou, dat moeten mensen nu bijvoorbeeld overtypen, met bepaalde berekeningen en dat soort dingen. Dan kun je eigenlijk heel snel iets toevoegen door te zeggen: oké, we halen het naar het platform, we doen die bewerkingen automatisch en dan zetten we een setje klaar wat gewoon geïmporteerd kan worden. Kijk, daar zou het niet voor bedoeld moeten zijn, want dan zou je moeten zeggen "hé, we moeten onze processen aanpassen". Maar het is wel iets wat stiekem toch alvast even tijdswinst kan opleveren, waarde kan laten zien aan mensen die ermee moeten gaan werken. Dus als je daar met de juiste insteek in gaat, kan dat denk ik ook wel echt een toegevoegde waarde zijn.

Ja, alleen ik vind eigenlijk dat het dataplatform in die zin niet operationeel in het proces gestopt moet worden. Ik denk dat je dan eigenlijk moet zeggen "hé, applicatie A moet gewoon communiceren met applicatie B". Dat moet niet afhankelijk zijn van het dataplatform. Al zijn er ook wel tegenwoordig steeds meer discussies dat je zegt: nou, we willen sowieso alles op het platform en daarna gaan we het distribueren. Maar goed, dat is een andere discussie.

En dat kan zeker een meerwaarde zijn, alleen waar trek je dan de grens? Dat is heel lastig. Want wat als er nou gewoon events van A naar B moeten die verder geen waarde voor iets hebben, anders dan dat ze heen en weer moeten? Ga je dat dan ook in die driehoek pingpongen? Daar zie ik dan weer geen meerwaarde in. Er ligt ergens een grens, en die grens is dan altijd een beetje vaag, wat mij betreft.

Nou, allereerst laat ik even voorop stellen dat ik zelf niet echt dataplatformen bouw. Ik interacteer ermee als data-analist en data scientist. Maar wat ik zelf heel prettig vind om te gebruiken, en wat ik veel gebruikt heb, is BigQuery. Daarmee kan je toch best wel eenvoudig met SQL ook analyses doen op je data. Eigenlijk makkelijk voor iedereen om te gebruiken, om mee te communiceren. Je kunt het met Python-scripts aanroepen en wegschrijven. Dat vind ik fijn in het gebruik, gebruiksvriendelijk. Verder weet ik dat je ook steeds meer tools hebt die meer gericht zijn op AI en engineering. Dus met Azure heb je bijvoorbeeld Azure ML. En ik geloof dat het bij Google Cloud Platform iets van Vertex AI heet, waar ik je niet op vastpin, want ik heb het niet gebruikt. Dat is ongeveer hetzelfde. Dus er komen wel steeds meer van dat soort functionaliteiten bij. Je hebt uiteraard tools die hele ETL-processen kunnen doen.

In principe kan je alles bij elkaar sprokkelen om te doen wat al die andere platformen er ook in hebben. Daarbij zeg ik wel dat het allemaal Google is. En dat zal ik zo meteen misschien nog wel toelichten. Het is een sterk punt en een zwak punt eigenlijk.

Ik heb ook het idee, maar ik weet niet of jij dat herkent, dat het vooral vanuit de marketing heel sterk is.

Ja, voor marketing en e-commerce kan het handig zijn. Want als je online marketing doet, of je hebt een webshop of whatever, dan log je heel veel events. En die kan je dan, nou ja, je trackt je Google Ads, en die kan je allemaal heel erg gemakkelijk aan elkaar koppelen omdat het allemaal Google-based is. Je hebt je Google Analytics, je hebt je Google Ads, je hebt je Campaign Manager 360, ze hebben zo waanzinnig veel marketingplatformproducten. Het is gewoon letterlijk een vinkje aanzetten en dan staat het in je BigQuery. Je geeft op wat je schema is en weet ik veel wat, en het staat er. Dus dat is een beetje de kracht daarvan. Dat als je al online marketing doet en je zit in die e-commercehoek, het heel snel op te zetten is. Ja, dat is eigenlijk een beetje de kracht van Google Cloud.

Ja, ze hebben Looker Studio, dat is echt een beetje een gebruiksvriendelijke variant, waarmee zelfs mensen met weinig ervaring in het maken van dashboards heel makkelijk drag-and-drop visualisaties kunnen maken, heel snel. Ook dat heeft weer allemaal integratie met allemaal Google-producten. Dus je hoeft niet eens te linken met je warehouse, je kunt direct linken aan Google Ads of Campaign Manager of waar je het vandaan haalt. Daar hebben ze allemaal wel slim op ingespeeld. En daarnaast heb je Looker, en dat is wat ingewikkelder. Daar kun je ook nog een soort semantic-viewmodellaagje overheen bouwen. Wat dan weer nu helemaal hot is, omdat je dat kan gebruiken voor je AI-agents, om context te geven aan je data, waardoor je dus met een prompt kan vragen: maak deze grafiek op basis van sales. En dan weet hij op basis van het semantic-viewmodel: oh oké, maak even een grafiek van sales. En dan heb je bijna geen data-analyse meer nodig eigenlijk.

Echt nodig, nee.

Behalve natuurlijk om al die semantic-viewmodellen mee te bouwen.

Het is lastig op te zetten, maar als het eenmaal staat, dan heeft het wel veel potentie.

Ik denk dat het grote nadeel is dat als je dus andere, niet-Google-bronnen eraan wil verbinden, het complexer wordt. Dan is het niet zomaar een vinkje aanzetten. En het feit dat het allemaal binnen het Google Cloud Platform zit, betekent niet dat het de betere tools zijn. Je hebt bijvoorbeeld bij Snowflake dbt geïntegreerd. En kijk, ze hebben in Google Cloud Platform een soort dbt nagemaakt, maar dat betekent niet dat dat beter is. En zo heb je allemaal dingen: je hebt ze wel, maar is het ook daadwerkelijk het beste? Daar kan je dan je vraagtekens bij zetten.

Zeker. Als we het hebben over die definitie van een dataplatform, dan probeert Fabric eigenlijk alles te vangen in dat platform. Dus waar sommige tools wat meer specialistisch zijn, zoals bijvoorbeeld Snowflake, dat niet zozeer gebaseerd is op echt het binnenhalen van data, probeert Fabric dat allemaal te vangen. Dus je hebt eigenlijk een set aan tools die je in de brede zin kan gebruiken om je data te managen, op te slaan, te bewerken, binnen te halen, te governen. En dat is eigenlijk wat Fabric is. Dan heb je tools zoals Fabric Data Pipelines voor orchestratie en ook om data te kopiëren. Dataflows is een tool die een hele mooie UI heeft, drag and drop, waar je heel snel dingen mee kan ophalen, transformeren, neerzetten. Maar ook gewoon Spark-notebookjes kun je draaien. We hadden het over warehouses en lakehouses. Nou, daar heeft Fabric allebei een versie van gemaakt. Dus zo probeert Fabric eigenlijk, denk ik, een soort mooie SaaS-oplossing te zijn, alles in één, voor de data-analist en data engineer.

Jazeker, dat is precies hetzelfde. Dat is een voordeel en een nadeel. Al proberen ze wel zoveel mogelijk ook echt externe bronnen toe te voegen. Dus je kan denk ik wel makkelijker dan met Google nog externe bronnen koppelen. Maar het is wel allemaal Microsoft, dus het werkt in feite het beste met allemaal andere Microsoft-spullen. En ze hebben natuurlijk OneLake, wat een mooi onderdeel is, waarin je het hele opslagstuk abstraheert van de eindgebruiker. Dus in feite is het heel makkelijk: ik doe iets, dat staat ergens in de cloud, maar ik hoef dat allemaal niet te managen en bij te houden. De rechten onderling, dat wordt allemaal voor je weggehouden.

Ja, daar hadden we het net al kort over. Ik denk ook wel een hele mooie tool. Ik denk ook wel wat sterker bijvoorbeeld in AI. Ik denk dat de kern echt de data warehousing is, zoals we het net beschreven. Daar zijn ze supergoed in, heel snel. Er zit ook een usage-based pricingmodel onder, dus je betaalt echt alleen maar voor je gebruik. Ik denk dat je heel snel out of the box kan starten. Dus waar andere tools toch nog wat meer configuratie nodig hebben, is Snowflake iets wat je bij wijze van spreken, volgens mij verkopen ze het ook zo, uit de doos haalt en ermee aan de gang kan. Dus ik denk dat dat ook wel een heel mooi voordeel is. Alleen, na wat ik eerder zei, het heeft dus bijvoorbeeld niet alle functionaliteiten om data naar Snowflake toe te halen. Dus daar zul je sneller zien dat er externe tools zoals Fivetran of dat soort tools voor gebruikt worden.

Ja, precies. En dat kan een prima keuze zijn.

Ik vind het wel fijn dat ze een beetje platform- en toolagnostisch zijn, toch?

Ja, dat zijn ze helemaal. Je kan het op elk van de grote drie draaien. Je kan het op Azure, AWS en Google draaien.

Ja, dat maakt verder niet uit wat je gebruikt. Het loopt maar gewoon via hun platform uiteindelijk.

Ze hebben ook de storage en de compute gescheiden, dus je kan daarin heel snel ook opschalen.

Ja, dat heeft Google Cloud overigens ook.

Ja, dan gaan ze er dus vanuit dat je je data ergens al hebt staan, in een opslag ergens in AWS of in Azure, op die manier.

Ja, die kan eigenlijk al die andere dingen die jullie net benoemd hebben.

Maar beter.

Dat wil ik niet zeggen, want ze kunnen het allemaal goed. Ik denk dat, als je het vergelijkt met bijvoorbeeld Fabric, het dus ook zo'n alles-in-één-platform is. Ze proberen zoveel mogelijk bij elkaar te zetten, goed geïntegreerd, zodat je daar zelf niet meer naar om hoeft te kijken. Dus uiteindelijk denk ik dat het qua features en qua tooling allemaal op hetzelfde neerkomt: je kunt je data binnenhalen, je kunt het verwerken en je kunt het beschikbaar stellen. Maar ik denk dat hetgene waarin ze verschillen, meer zit in hoe je het gebruikt. Dus hoe gebruiksvriendelijk is het? Wat voor persoon werkt daarmee? In Fabric kun je bijvoorbeeld vrij makkelijk dingetjes aan elkaar klikken, is die leercurve misschien wat kleiner, waardoor je dus ook sneller een datateam neer kunt zetten. Terwijl in Databricks dat wat complexer kan zijn, en ook het opzetten van zo'n platform kan wat complexer zijn, omdat je heel flexibel bent. Dus dat is aan de ene kant een voordeel, dat je heel flexibel bent in Databricks. Je kunt eigenlijk alles wat je kunt bedenken instellen. Denk aan je compute, je storage. Je kunt nog bepalen waar je je storage neerzet. Dus stel je hebt ergens anders iets staan, dan kun je daar ook naartoe linken. Allemaal heel flexibel, maar dat zorgt er dus wel voor dat je best wel veel moet configureren. Dus dat kan een nadeel en een voordeel zijn. En dat is denk ik het grote verschil. Dus Databricks focust meer op de data engineering, dus meer de engineer. Terwijl Fabric en de andere platformen denk ik meer focussen op de analyticskant, dus meer het gebruik van de data.

Ja, dat denk ik ook. Dus ik denk bijvoorbeeld: Fabric is meer all-round en Databricks is in die zin meer gespecialiseerd. En precies wat jij zegt, dat kan een vloek en een zegen zijn. In Fabric kun je bijvoorbeeld niet heel erg instellen hoe je je clusters precies wil en wat je er allemaal mee wil doen. En als je hele zware machine learning wil gaan doen, dan denk ik ook niet dat Fabric het allerbeste platform is, en dat Databricks dan weer veel fijner is.

Maar aan de andere kant kan dat in Fabric dus ook een voordeel zijn. Want misschien wil je wel helemaal niet dat je mensen daar rekening mee hoeven te houden.

Ja, of heb je de mensen niet. En dan is het fijn als alles voor je gemanaged wordt.

Ik denk het wel, ja.

Zou ik ook zeggen, ja.

Google Cloud kan ook best wel ingewikkeld worden om op te zetten.

Omdat je dus te maken hebt met al die verschillende tools die je wel of niet gebruikt.

Ja, er is heel veel documentatie over, maar wat ik heb gelezen is dat de support ook niet heel goed is. Dus het is soms lastig, zeker als je tegen dingen aanloopt, om het recht te breien.

Ja, ik denk ook wel, ik zit een beetje tussen Fabric en Snowflake te denken: wat is dan makkelijker? Ik denk dat het uiteindelijk natuurlijk ligt aan wat je doet. Maar ik denk dat Snowflake nog net iets makkelijker is om mee te beginnen dan Fabric, omdat Fabric net wat meer instellingen vraagt en toch weer groter is, dus daardoor ook weer indrukwekkender. Dan moet je ook weer keuzes maken. Dus dat maakt het net weer wat ingewikkelder, maar het is toch nog wel vrij toegankelijk. Vooral als je al in de Microsoft-wereld zit. Dan ken je de UI, je kent de knoppen, Power BI kent iedereen natuurlijk, onderdeel van Fabric. Dus ik denk dat het daar weer veel wint.

En ook aan de gebruikersgroepen en zo, die kun je in Fabric gewoon één op één overnemen en gelijk gebruiken. Dus dat maakt het een stuk makkelijker.

Engineering.

De flexibiliteit. Dus aan de ene kant de flexibiliteit van het gebruik van het platform, maar ook de flexibiliteit in hoe je je code schrijft.

Ja, het kan ook zijn dat je het onnodig complex maakt.

Ja, dat kan zeker.

Misschien heb je het wel helemaal niet nodig.

Precies.

Ja, ik denk hun warehousing en wat je daarmee kan doen, dat is echt denk ik het allersterkste van Snowflake. Dat dat gewoon out of the box meteen draait, supersnel is, heel snel dingen op en af kan schalen. Als je een hele zware query hebt, gooi je hem omhoog, draait die query, zet je hem weer naar beneden. En je hebt wat je nodig hebt. Dus die flexibiliteit en het gebruiksgemak en de snelheid.

Nou, en zonder opstarttijd.

En zonder opstarttijd. Want dat is misschien een klein beetje een technisch ding, maar je hebt natuurlijk altijd die compute, al die resources nodig. Snowflake managet dat allemaal voor jou. Dus, wat verkopen ze, binnen één of drie seconden heb je dat beschikbaar en kun je gaan. Dat is natuurlijk superhandig als je bezig bent.

Andere platformen bieden dat ook wel aan. Dan bieden ze het aan als serverless compute, maar daar betaal je dan weer extra voor.

Of het is niet zo snel. Maar goed. Maar dat vind ik wel echt mooi van Snowflake, ja.

Ja, dus wat je met e-commerce vaak hebt, is een stream aan eventlogdata uit je website. En dat zijn echt bakken en bakken. Laat staan als je meerdere websites hebt met heel veel gebruikers, die allemaal interacteren met je website, elk klikje, whatever, alles wordt gelogd. En dat gaat supersnel en dat moet allemaal worden opgeslagen. Daar is Google Cloud echt heel goed in. Het schaalt ook automatisch op, dus als er meer mensen naar je website komen, dan wordt het nog steeds opgeslagen. Het enige is dat als je dus zelf de event tracking niet goed neerzet, dan wordt er ook heel veel troep opgeslagen. Het kan heel snel te veel worden, en met ook veel artifacts in je data die je dan later weer moet zien op te schonen.

Fabric? Ik zou zeggen de veelzijdigheid van Fabric. Dat is wel echt een sterk punt. Ze noemen het soms ook wel een Zwitsers zakmes, dat geloof ik wel. Je kan eigenlijk alles wat je nodig hebt wel doen. Of het echt altijd het beste is, is natuurlijk het tweede, maar in feite zit alles wat je nodig hebt om iets met data te doen er wel op enige manier in. Ik denk dat dat een heel sterk punt is, dat je gewoon alles in één kan doen.

Niet alleen machine learning-modellen, maar ook die complexe data engineering-taken.

Ja, en het analyseren van die webdata. Daar zijn natuurlijk ook oplossingen voor bedacht: hoe visualiseer je dat? Heb je een makkelijk templatedashboard of whatever om dat allemaal in te zetten?

Ja, ik denk dashboarding, en in die zin de algemene zin van iets doen met je data. Dus geen AI, geen machine learning, maar gewoon: ik heb data, ik laad het in, ik moet er wat mee doen, ik bouw een rapportje, ik draai een klein modelletje. Die veelzijdigheid, daar is Fabric wel echt goed in. Generalistisch is Fabric heel goed. Heb je specialistische doelen, dan kan je misschien beter naar andere platformen kijken.

Dat is een hele goede vraag. Ik heb ook gezien dat dingen naast elkaar bestaan. En ik denk: als je daar een goede business case voor kan maken, dat dat ook prima kan. Alleen denk ik dat het daar ook weleens aan ontbreekt. Dus wat je dan krijgt, is dat het ene team in Fabric gaat werken, het andere team meer van Databricks houdt en het andere team meer van Snowflake. En we gaan het allemaal doen, maar allemaal niet op een manier waarop het perfect is ingeregeld. Dus dan betaal je eigenlijk juist heel veel voor allerlei dingen die je niet nodig hebt. Maar goed, als je zegt "ik heb iets met machine learning en dat wil ik graag in Databricks doen", dan kan je daar een goede business case voor maken en de rest bijvoorbeeld in Fabric houden. Al zou ik daar wel iets terughoudend in zijn, denk ik.

Ja, dat is misschien ook goed om te noemen inderdaad. Fabric is echt verbonden aan Microsoft en die kun je alleen op Azure draaien. En Databricks kun je op eigenlijk alle drie de grote draaien.

Net als Snowflake.

Nee.

Ja, voor mij is dat een beetje een gewetensvraag, want eigenlijk zou je moeten zeggen dat het wat mij betreft altijd relevant is. En het gaat natuurlijk ook om je data, maar eigenlijk zelfs los van je data zou je daar zelf ook een mening over moeten vormen. Ook al heb ik alleen maar data die, bij wijze van spreken, iedereen gewoon naar buiten kan zien, en die dus helemaal niet relevant is. Maar dan nog is de diepere laag natuurlijk: wil ik dat dan? Kan ik dat dan wel op een Amerikaans platform zetten? Want dat maakt niet uit. Maar onze persoonsgegevens moeten ergens in Europa staan, en daar mag Amerika bijvoorbeeld, of China, niet bij komen.

Nou, je hebt de Cloud Act, die eigenlijk zegt dat je Europese gegevens beschermd zijn. Maar eigenlijk geldt dat alleen voor Europese bedrijven. En dat betekent dat als jij bij een Amerikaans bedrijf je data opslaat, ook al kies je misschien Europese servers, dat in principe de Amerikaanse overheid bij jouw gegevens mag kijken. Dus om die reden, en al helemaal met de huidige geopolitieke situatie, maar dit speelt natuurlijk al veel langer dan dat, roepen experts dat we meer onafhankelijk moeten zijn van Amerika en andere landen. Het is gewoon heel lastig, omdat ieder bedrijf zijn data bij een Europees bedrijf zou moeten stallen, maar er zijn zo weinig alternatieven.

Ik denk, tenminste, dat het iets genuanceerder ligt dan dat. Die Cloud Act stelt inderdaad dat het zou kunnen dat de Amerikaanse overheid je data op zou mogen vragen als ze daar een hele goede reden voor hebben. Dan is natuurlijk de vervolgvraag: wat zien zij als een goede reden? Vinden wij dat ook een goede reden? Maar dat betekent niet dat de hele Amerikaanse overheid de hele tijd in alle Europese data zit rond te snuffelen. Dus de vraag of het gebeurt, dat weten we niet. Het gaat voornamelijk om welk risico je wil lopen. En jij begon je vraag met of je je data in Europa zou moeten stallen. Dat is ook niet het enige stukje, denk ik. Het feit dat je data in Europa staat, is sowieso een goed idee als je in Europa bent. Want het is heel inefficiënt als je je data ergens op een heel ver circuit de wereld over stuurt. Het moet iedere keer de hele wereld heen en terug. Dus dat is sowieso al een goede reden om het wel in Europa op te slaan. Dan heb je het over het kiezen van een bepaalde regio, en dat kan bij alle cloud providers. Maar daarnaast hebben we de laatste tijd inderdaad veel in het nieuws gezien over soevereiniteit. En dat gaat meer over waar je data leeft. Dus dat gaat er deels over waar je data staat, maar ook operationeel, juridisch, technisch. En daar zitten heel veel gradaties in. Het is niet: ik wil van vandaag op morgen kunnen overstappen op een soeverein Europees dataplatform. Er zit nog zoveel meer tussen. Als je naar de hele groten kijkt, die zetten daar zelf ook stappen in. En je kunt dat dan weer opdelen in twee soorten, denk ik. Waarbij de een, dat is dan Amazon, een hele losse cloud in Europa zet, die staat ergens in Duitsland. Dat is een heel los, afgesplitst bedrijfsstukje, wel nog steeds van Amazon, maar dan is het dus wel iets moeilijker gemaakt om eventueel bij die data te kunnen. Dus wat zij bijvoorbeeld doen: het is sowieso los van het grote bedrijf, er werken alleen Europese medewerkers, dus die scheiding is gewoon heel groot. Dus zo'n eigen cloud zie je als een heel los, nieuw AWS-platform met zijn eigen controlplane. En daarnaast kun je dan bij bijvoorbeeld Microsoft en Google, die stellen gewoon wat meer regels op, of wat meer controles. Die gebruiken hetzelfde platform, eenzelfde Azure, eenzelfde Google, met gewoon wat meer beloftes erbij. En daar kun je dan ook voor kiezen. Maar dat is wel echt iets heel anders. En ze noemen het trouwens allebei... wat was het? Amazon heeft de AWS European Sovereign Cloud. En Microsoft heeft dan de Microsoft Sovereign Cloud. Maar het is wel goed om er rekening mee te houden wat dat dan precies is. Want het blijft het geval dat het nog steeds Amerikaanse bedrijven zijn, dus het valt nog steeds onder de Cloud Act. Dus of jouw data nou in Europa staat of niet, dat risico blijft. Het risico is alleen iets minder geworden, omdat ze niet direct bij je data kunnen.

Ik zou zeggen: de enige reden om er niet over na te denken is als je misschien een opensourceproduct hebt waarbij iedereen toch al zicht heeft op je data, dan maakt het niet zoveel uit. Maar voor bijna alle overige bedrijven geldt dat je er wel even naar zou moeten kijken, denk ik.

Nee, dan valt het dus nog steeds onder die Cloud Act. Het zijn nog steeds Amerikaanse bedrijven. Dus er is op dit moment eigenlijk geen direct alternatief voor de drie, vier grote waar we het net over gehad hebben, maar dan van een Europese cloud provider. Je kunt dat wel nabouwen natuurlijk. En ook dat gaat dan weer in allemaal stapjes, waarbij je bij ieder stukje van dat platform zelf zou moeten bedenken: ga ik dit van iemand afnemen, dus van een cloud provider, of ga ik het zelf doen? En als je cloud ziet als allemaal hele kleine bouwblokjes, kun je voor al die bouwblokjes afzonderlijk kiezen of je dat zelf gaat doen of afneemt. Als je het zelf doet, heb je het in eigen beheer, maar dat betekent dus ook dat je het zelf moet regelen. Terwijl als je het afneemt, dan kun je er ook van uitgaan dat het op een bepaalde manier veilig gehouden wordt.

Nee, op dit moment in ieder geval niet.

Dus dat is een cloud-aanbieder die allemaal van die kleine clouds, of klein, het kan klein tot groot zijn, cloudblokjes aanbiedt die je af kunt nemen. En daar kun je dan dus zelf weer voor kiezen welke blokjes je wel en niet afneemt en hoe je die aan elkaar koppelt. Maar dat is dus al wat meer werk dan dat je zegt "ik wil een Fabric of ik wil een Databricks", waar al die blokjes, waarschijnlijk dezelfde blokjes, al voor je aan elkaar gekoppeld zijn.

Amerikaanse bedrijven hebben natuurlijk jarenlang een soort monopolie gehad en heel veel tijd om te ontwikkelen, eigenlijk weinig concurrentie van Europese bedrijven. En ik denk dat daar nu wel een switch in gaat komen.

Zeker. Ik denk dat die noodzaak ook gewoon nog niet gevoeld is.

Dat kan beide. Je kunt er bijvoorbeeld voor kiezen om een managed database af te nemen, dan heb je iets om je data op te slaan. Maar je kunt er ook voor kiezen om een VM af te nemen en dan ga je daar zelf je database op hosten. Dus ook daar zijn dan weer gradaties in, in hoeveel je zelf wil doen en hoeveel je af wilt nemen.

Virtual machine.

Dat is een hele goede vraag. Het kan veiliger, maar alleen als je het echt goed doet. Dus je moet dan ook zelf overal aan denken. Je moet alles helemaal goed dichtgezet hebben. Dus een heel klein foutje kan hele grote gevolgen hebben.

Ja, dat zijn juist ook meerwaarden van bijvoorbeeld een Fabric. Daar zit iets in wat managed private endpoints heet. Dat is een concept dat jouw Fabric koppelt aan een andere cloud resource, en dat dat volledig afgeschermd van het publieke internet bij Microsoft gebeurt. Nou, dat zijn gewoon mooie services. Het zit in de naam: managed, het wordt allemaal voor je gemanaged. Dat zijn allemaal dingen die je anders zelf moet gaan bedenken: hoe ga ik dat dan op een veilige manier doen? En als je heel veel losse stukjes hebt die je allemaal op een bepaalde manier aan elkaar moet knopen, kan het zijn dat je daarmee dus weer meer risico creëert dan dat je dat bij zo'n Fabric zou doen en in één zo'n platform zou stoppen. Het hoeft niet, ik bedoel, wat Cathy zegt. Maar we hebben ook weleens dingen gezien waarvan je denkt: ja, als we het zo in elkaar draaien, dan is het allemaal niet zo handig.

Ja, dan heb je wel een klein legertje, heel specialistische mensen nodig. En van de cloud af is dat nog een optie. Dat kan ook, maar dan heb je hetzelfde probleem. Dan komt het deels op hetzelfde neer, plus je bent dan zelf ook nog eens verantwoordelijk voor het bijhouden van al die machines. Dus je koopt machines in, die komen gewoon met de post binnen, je pakt ze uit, en dan moet je nog eens beginnen met ze neerzetten, in een stopcontact stoppen, aan elkaar prikken, en dan maar zorgen dat ze samen in een cluster kunnen draaien, een OS erop installeren, precies dat soort dingen. Maar je moet er ook rekening mee houden dat er inderdaad brand kan uitbreken, dus je wilt het het liefst op twee of drie extra plekken neerzetten. Je moet aan koeling denken, je wilt je belangrijke machines niet te warm, niet te koud. Ja, zomaar door. En dit geldt dus voor al die stukjes, al die stapjes die er tussenin zitten.

Het lijkt toch altijd weer complexer. Ik denk dat de instelling moet zijn: het kan wel. Het kan wel.

Het ligt er alleen aan welke risico's je zelf wilt nemen. Dus wat je wilt, hoe groot je data is.

Ja, ook.

Ja, precies.

Ik denk niet Fabric.

Het ligt eraan wat je met AI wil doen.

Misschien een Snowflake voor de makkelijke instap, Databricks voor de iets complexere dingen.

En ik denk dat Fabric zelf ook wel zou kunnen passen hoor, maar het ligt echt aan de use case.

Dat is altijd zo.

Ja, nou, denk vooral eerst zelf even goed na over wat je wel en niet wilt. En laat je ook vooral niet gek maken door al die verschillende tools die er zijn.

Ik zou zeggen: kijk ook naar wat er open source beschikbaar is. Er wordt heel veel ontwikkeld, en echt niet allemaal door de drie grootste datatechnologiebedrijven van de wereld. Heel veel mensen doen het ook open source, en vaak is dat zelfs nog beter.

Ja, oké. Ik heb deze keer een hele praktische bedacht: ga het gewoon proberen, want alle grote platformen hebben gratis trials. Daar kun je je heel makkelijk voor aanmelden. Fabric heeft dat, Snowflake heeft dat, Databricks heeft dat ook, toch, Cathy? Probeer het gewoon. Doe alle drie, pak een use case en kijk gewoon hoe het werkt. Doe dat in het begin, dan denk ik dat het heel erg helpt bij de keuze.