Van datawarehouse naar datalake

Het integreren van diverse datastromen lijkt een dagelijkse gang van zaken voor veel bedrijven, maar het kanaliseren van die datastromen vereist veel kennis en bovenal: creativiteit. Uiteindelijk wil iedereen naar de public cloud, maar die stap is niet voor elk bedrijf direct haalbaar.

Aan dat soort overgangen en systemen werken Leo Simons [@leosimons] en Eelco de Boer [@meekoh] bij Schuberg Philis. Als mission critical engineers zetten ze allebei hun expertise in om ingewikkelde problemen op te lossen in een keur aan verschillende richtingen. Beiden vertellen Tweakers Partners over hun ervaringen en wat voor interessante gevallen zij tegenkomen in projecten waar ze nu aan werken.

Eelco werkt nu ruim een jaar bij Schuberg Philis en houdt zich bezig met het automatiseren van processen, cookbooks en het up-to-date houden van it-omgevingen. Hij begon zijn carrière als tweedelijnshelpdeskmedewerker bij een grote outsourcingpartij en zit tegenwoordig in het Financial Services-klantenteam van Schuberg Philis. Niemand in het team heeft één specifieke functie zegt Eelco: "Er ontstaan binnen zo'n team vanzelf bepaalde rollen; mensen doen wat ze zelf het prettigst vinden."

Leo had, voordat hij bij Schuberg Philis begon, al jaren als freelancer gewerkt nadat hij van de universiteit kwam. Via internet kwam hij in aanraking met opensourcesoftware en hij leerde zichzelf zo programmeren. Hij werkte onder andere voor de Apache Software Foundation, de BBC, Rijkswaterstaat, video-on-demanddiensten, p2p-applicaties en in de medische informatica. Leo: "Het was een heel spannende stap om over te gaan van het freelance bestaan naar een dienstverband. Achteraf was die spanning nergens voor nodig. Bij freelancen heb je het gevoel van veel vrijheid, maar een deel is illusie. Je zit toch vaak in grotere teams en bent afhankelijk van anderen. Bij Schuberg Philis werken we op basis van overeenstemming. Als je het ergens niet mee eens bent of je wilt iets anders, dan moet je dat maar regelen. Aversie tegen grote organisaties heb ik nog steeds, maar bij Schuberg Philis heb ik daar geen last van."

Zowel Leo als Eelco vindt het leuk om aan grote complexe en kritische system te sleutelen, iets wat je volgens Leo als freelancer niet doet. Eelco komt terug op zijn sollicitatieproces, waarin hij niet kon geloven dat iedereen 'van alles' deed. Dat klopte uiteindelijk wel; je hebt veel vrijheid. Toch zijn er ook mensen die het liefst zestig uur aan één ding werken, maar beiden geven toe dat dit vrij uitzonderlijk is. “Je bent toch onderdeel van een team en je werkt in een bedrijfskritische omgeving. Daar moet je persoonlijkheid wel bij passen”, zegt Eelco.

Forumtopic Schuberg Philis

@meekoh is een forumtopic begonnen over Schuberg Philis. Heb je vragen over dit soort projecten of hoe het is om bij Schuberg Philis te werken, neem dan een kijkje op Ervaring werken bij Schuberg Philis.

“Toch is er zeker ruimte om jezelf op één ding te concentreren. Zo belde vanochtend een collega uit mijn team die zei: ik zet alles uit en ben alleen telefonisch bereikbaar. Dat kan dus wel, maar dat deel je wel met je team”, zegt Leo.

Op dit moment vindt overal een verschuiving plaats van eigen mainframes en datacenters naar de public cloud. Dat is een groot verschil met vroeger legt Eelco uit. "Vroeger had je bijvoorbeeld een datawarehouse waar alle data naartoe werd gestuurd. In de cloud heb je nagenoeg onbeperkte hulpmiddelen tot je beschikking, waarbij het idee van een datalake om de hoek komt kijken. Het maakt ook niet zoveel meer uit hoeveel ruimte iets inneemt. Het voordeel van datalakes is dat je de data opslaat in streams (json/csv). Dit geeft je mogelijkheden om bijna in real time data te verwerken en een goed inzicht te krijgen in hoe de data door de tijd verandert: datalineage. Je probeert zo de etl-handelingen zo laat mogelijk in het proces uit te voeren, in plaats van dat je het vooraan doet, als je de data uit het bronsysteem haalt. Dit maakt het makkelijker om nieuwe bronnen te ontsluiten in een datalake en zo krijgen de mensen van businessintelligence veel meer bronnen om uit te putten."

"Een bekend gebruiksscenario voor datalakes is hulp bij fraudedetectie", zegt Leo. "Zie het zo: iedereen betaalt via z'n smartphone; even geld overmaken is zo gepiept. Als er dan een transactie in het buitenland plaatsvindt, moeten we kunnen detecteren of het om hackers of criminelen gaat of om jouzelf. Zo'n systeem om te checken of iemand de juiste gebruiker is, bouw je boven op een datalake."

Financial Services Team

Het werken met financiële instellingen is uitdagend, omdat een deel van de systemen nog in oude mainframes zit, terwijl de eindgebruiker het gevoel moet hebben dat alles in real time gebeurt. “Een proof-of-concept waar we nu mee bezig zijn, is het automatisch installeren en configureren van banksoftware, met als doel de deploymentcyclus in de ontwikkelstraat te verkorten. We hebben veel geïnvesteerd in automatische softwaretests. We zetten een nieuwe release op 'test' en we controleren bijvoorbeeld of mensen nog geld kunnen opnemen, nog nieuwe klant kunnen worden: noem het maar op. Op dit moment zijn er nog veel handmatige handelingen voordat iets op de testomgeving landt. We willen dat zo'n proces volledig geautomatiseerd is en dat we kunnen testen met 'wegwerpomgevingen'. Public clouddiensten kunnen hierbij helpen, aangezien die zeeën van hulpbronnen hebben die je on demand kunt gebruiken. Zo kun je goedkoop en snel een release testen."

Cases

In dit artikel bespreken we een van de complexe it-vraagstukken waar Schuberg Philis dagelijks mee te maken heeft. Maar er zijn er natuurlijk nog veel meer. Op deze pagina hebben we alle informatie omtrent Schuberg Philis voor je verzameld.

"Zo'n patroon bij een bank implementeren is een uitdaging", zegt Leo. "Dat zit vooral in legacy en enterprisesoftware."

Eelco: "Veel software waar je mee werkt, is niet geschikt voor de paas/saas-diensten in de public cloud. Die systemen komen uit de trage, inflexibele wereld van vroeger. Vier releases per jaar bij een bank zijn al veel, maar je merkt dat er een enorm verschil zit tussen nieuwe en oude spelers."

"Nederland was er vrij vroeg bij met elektronisch bankieren en alles zit wel aardig in elkaar, maar wel met oude mainframes", vervolgt Leo. "Die kun je leuk aan elkaar knopen, maar die verwachten dan nog wel dat er een batch wordt gedraaid, terwijl de public cloud dat allemaal in real time aankan. Dat is het leuke van handig integreren, dat je die oude systemen zo kunt koppelen dat je toch iedere week een nieuwe app kunt uitbrengen."

Schuberg Philis brengt veel van zijn klanten via de eigen mission critical cloud naar de public cloud met behoud van de infrastructuur. Was dat eerste voor sommigen al een uitdaging, dan geldt dat zeker voor het tweede. Leo zegt dat het een andere manier van denken is, omdat je vertrouwen moet hebben in systemen van hyperscalers als AWS, Microsoft en Google. Als voorbeeld geeft hij een ddos-aanval bij banken: de public cloud heeft zoveel resources dat je dat goed kunt opvangen.

Mobilityprovider

Een omgeving waar beduidend minder legacy-systemen rondslingeren, is de leasewereld. Leo werkt voor een grote leasemaatschappij, die zich in hoog tempo aan het omvormen is tot innovatieve mobiliteitsprovider. Het team ontwikkelt een compleet nieuw digitaal platform dat deze klant klaarstoomt voor de toekomst. Bij het project waaraan Leo en zijn team werken, is geen angst om over te stappen naar de public cloud. Het is juist de vraag welke saas-partners voor dit project praktisch zijn en hoe die aan elkaar te koppelen, maar ook hoe die later eventueel kunnen worden vervangen zonder dat dit problemen oplevert. “Bij dit project heb ik te maken met nul virtual machines, in tegenstelling tot Eelco, die af en toe nog Windows-patches moet bijhouden. Ik heb andere problemen, zoals: hoe stevig is serverless software nou?" zegt Leo.

Hij is met zijn team onder andere een mobilityteam binnen Schuberg Philis aan het opzetten en is daar nu zes maanden mee bezig. Voor de leasemaatschappij werkt Schuberg Philis samen met in totaal vijf partners. In dit team is Leo nu scrummaster. "Het is wel een uitdaging om samen te werken met top-downteams, maar iedereen wil veranderen en af van de traditionele kokers. De digitale transformatie zorgt er ook voor dat de verkokerde teams gaan samenwerken."

Creatief

"Het is super interessant met welke technieken we bezig zijn, zowel hoe je ze toepast als waarom. De keuze achter de keuze, zoals met de public cloud en het sneller laten draaien van developmentomgevingen. Die keuze is aan het team en komt niet van een andere afdeling of innovatieclub. We bedenken zelf waar we behoefte aan hebben, overleggen dat met onze klanten en gaan het gebruiken. Van ons wordt verwacht dat we ook weten wat het volgende stukje techniek is dat interessant voor ze wordt. Voor zover we daar centrale hulp bij hebben, is dat faciliterend. Het centrale Labs-team van Schuberg Philis helpt met het opzetten van experimenten, proof-of-conceptprojecten en MVP’s. Het doet dat niet rechtstreeks voor de klant, maar helpt het klantenteam om te zorgen dat de projecten gaan draaien. Ik ben ervan overtuigd dat dit de beste manier is om dat te doen. We zitten in een bedrijf vol met creatieve techneuten en die zitten allemaal vol met ideeën", besluit Leo.

Persoonlijke workshop

Schuberg Philis is expert op het gebied van complexe it-projecten. Kamp jij of kampt jouw organisatie met een it-uitdaging, stuur dan een e-mail naar [e-mail]. Wie weet maak jij kans op een persoonlijke workshop van een van de Schuberg Philis-experts bij jou op kantoor.

Schuberg Philis meetup-diner

Dit artikel is onderdeel van een artikelenreeks in samenwerking met Schuberg Philis. Binnenkort houden we het Schuberg Philis meetup-diner, waarbij je op kantoor echt een kijkje in de keuken kan krijgen. Ben je nieuwsgierig geworden en wil je een uitnodiging ontvangen voor dit evenement, vul dan onderstaande poll in.

Wil jij een uitnodiging voor het Schuberg Philis-meet-updiner?

Poll

Ja, stuur mij een uitnodiging voor het toekomstige Schuberg Philis-meet-updiner!
Nee, ik ben niet geïnteresseerd.

De opties zijn uitgeschakeld omdat de deelname gesloten is

Reacties (37)

[dude88]

Vanuit de inleiding:
"Uiteindelijk wil iedereen naar de public cloud, maar die stap is niet voor elk bedrijf direct haalbaar."

Waarom wil iedereen naar de public cloud?
Private en hybrid cloud kunnen ook prima opties zijn.

Naar mijn idee wordt de public cloud teveel gehypt. De public cloud is met name een goed verdienmodel voor de bedrijven erachter.
Elk bedrijf zal zijn eigen keuzes moeten maken afhankelijk wat het beste bij je past. Soms kan je het zelfs per applicatie overwegen wat je wil, het ene intern, het andere via bijvoorbeeld SaaS.

[Meekoh]

De meeste van onze klanten zijn op zijn minst aan het kijken naar de public cloud en wat die voor hun te bieden heeft.
Er is ook zeker minstens 1 persoon die binnen ieder groot bedrijf liever diensten afneemt dan dingen aanschaft, de CFO. En die heeft daar hele goede redenen voor.

Een van de redenen dat veel financiele instellingen klant bij ons zijn, is omdat ze graag van onze eigen Mission Critical cloud omgeving gebruik willen maken. De echte public cloud vinden ze wellicht nog een stap te ver. Dus Ja Private en Hybrid kunnen prima, je moet het per use case bekijken.

In het geval van een datalake is het bijna een no-brainer om zoiets in de public clouds af te nemen, zelf al die hardware/capaciteit aanschaffen is vele vele vele malen duurder.
Een andere klant had bijvoorbeeld veel behoefte aan compute power, op zich ging dat prima op onze eigen cloud. Echter uiteindelijk hebben we gekozen het op AWS Spot instances te laten draaien, de berekeningen waren minstens 2x sneller klaar en qua kosten waren de spot instances ongeveer 1/3 van wat het in onze eigen cloud omgeving zou kosten.

Toch ben ik van mening dat steeds meer richting de public cloud providers zal gaan. Kijk maar naar O365, dat groeit als een malle en ik zie steeds meer bedrijven hun eigen Exchange omgeving opdoeken (inclusief wijzelf).

[Sandor_Clegane]

Totdat de "race to the bottom", zoals die op dit moment gaande is, afgelopen is en de prijzen weer gaan stijgen. Waar ga je dan heen met al je data? Egress kosten zijn echt hoog.

Plus je hebt vendor lockin zoals nooit tevoren, gebruik je de Cloud api's van MS of Amazon? Zit je vast aan die cloud omgeving.

Ik zou me als bedrijf echt nooit zo ophangen aan een leverancier.

[Meekoh]

Interresante discussie
Die uitdaging heb je nu ook al als je niet van een cloud provider gebruik maakt. Daar ben je ook aardig opgesloten (alhoewel MS wel goed bezig is met alle linux support e.d.). Zit je niet nu ook al vast aan een Vsphere api? of een Openstack api? Azure Stack api? etc. etc.

Ook al zijn wellicht de egress kosten relatief hoog, dan nog weegt dat nauwelijks op tegen de kostenbesparing die je daarvoor al wellicht hebt gerealiseerd.

Waar een vraag naar is, komt vaak ook een oplossing voor. Er zijn al enige jaren andere partijen die compatibiliteit tussen de API's regelen (Terraform, Cisco Cloud center a.k.a. cliqr and so on). Wij gebruiken dezelfde Terraform plans om op onze eigen cloud iets uit te rollen en op AWS/Azure. Dat is echt geen rocket science.

Ik kan uit ervaring spreken dat migreren tussen cloud providers (zolang je je automations maar op orde hebt) een stuk minder spannend is dan het lijkt. En je dus echt niet zo "opgehangen" bent aan een leverancier als je denkt.

edit:
Sterker nog, met de hele containerization movement die aan de gang is maakt het helemaal geen bal meer uit of je container nou onprem/Azure/AWS/Google cloud draait. Ze bieden allemaal een vorm van containers aan en met bijv. de Kubernetes (k8s) services is het op al die clouds nagenoeg hetzelfde.

[Reactie gewijzigd door Meekoh op 24 juli 2024 04:56]

[Sandor_Clegane]

Als je alles tot een VM/container beperkt heb je een punt, die kun je redelijk simpel migreren, maar als je dingen als machine learning of zoiets als AWS Lambda of Azure functions in je applicaties opneemt dan heb je je applicatie beperkt tot die bepaalde cloud omgeving. En dat is nu juist waar die mooie scalability vandaan komt en wat een groot voordeel van de cloud moet zijn.

En als je weer zoiets gebruikt dat je van cloud naar cloud kunt migreren dan kun je alleen gebruik maken van laagste algemene deler die elke provider aanbiedt, dan doe je eigenlijk niets meer dan ijzer de deur uit doen. Wat een valide reden kan zijn, begrijp me niet verkeerd.

Maar een datalake opbouwen zoals hierboven beschreven op VM'tjes lijkt me een beetje als een vierkant in een rond gat proberen te drukken.

[Meekoh]

AWS Lamda en Azure Functions zijn niet perse API's. Binnen de "worker", draait namelijk gewoon Python/Node.JS/C#/Java/etc. die je zelf geschreven hebt. Die code zelf kun je zowel op cloud A als cloud B gebruiken. Het gaat er net om hoe je alles opzet/designed. Het toverwoord hierbij is "loosly coupled" (mooi voor de bullshit bingo lijst).
Laten we even bij Lambda blijven als voorbeeld, ik zou mijn function zo simpel mogelijk maken. Wil je hem aanroepen dan zet ik er een API-gateway voor bijvoorbeeld. Op die manier is het aanroepen gewoon standaard REST verkeer. Je hoeft niet je hele applicatie compleet te herschrijven als je naar Azure Functions zou gaan. Je krijgt hooguit je parameters iets anders aangeleverd e.d., maar de kern logica blijft hetzelfde. Dat is nu juist het mooie aan serverless.

Mooi leesvoer: klik

Je hoeft niet perse voor alleen Cloud A of alleen Cloud B te kiezen. Ik weet vanuit mijn vorige werkgever dat een zekere grote frisdrank fabrikant juist voor AWS EN Azure gaan, bijv. om risico te spreiden of lockin te voorkomen.

Wat betreft het datalake, dat is inderdaad niet op VM'tjes gebouwd. Er is van te voren nagedacht over hoe we de data weer makkelijk weg kunnen krijgen. In principe is alle data die het lake in gaat standaard json, deze beland zowel in S3 als in een Redshift cluster. Waarom ook op S3? Twee redenen:
1. Exit strategie, ik kan die json files zo in een andere database van Provider Y knallen.
2. ik kan mijn hele redshift database opnieuw opbouwen (wellicht met andere tabel structuur), maar de data heb ik nog in S3. Die kan dus gewoon weer opnieuw ingelezen worden.

Ik was zelf heel lang erg sceptisch over de public clouds en lock in, maar ervaring heeft geleerd dat dit echt meevalt als je er maar van te voren rekening mee houd!

edit: gezien je posts in PRG begrijp je denk ik wel wat ik bedoel. De vraag is of de lockin bij Lambda/Functions erg is, of dat je ernaar kunt plannen.

Edit2: eigenlijk zou je eens met @Verwijderd moeten babbelen die is meer dev, Ik ben meer ops die ook wat dev doet of kom langs bij het diner

[Reactie gewijzigd door Meekoh op 24 juli 2024 04:56]

[Sandor_Clegane]

Voor een deel kan ik met je mee, voor een deel ook niet.

Maar dat is zo lang als dat het breed is.

Voor je lake voorbeeld: Ervan uitgaande dat de provider waar je het dan neerzet goedkoper/beter is. Plus dat je dan je hele stack opnieuw kan gaan testen. Natuurlijk is daar wel een mouw aan te passen, net zoals met huidige applicaties je een DAO laag bouwt, maar in de praktijk blijkt het toch allemaal wat weerbarstiger. DB A performed beter dan DB B, etc. etc. Om zomaar dan even je applicatie om te batterijen naar een andere provider lijkt me geen sinecure.

Dit gaat ook wel op voor Lambda en Functions denk ik, natuurlijk is er een hoop overlap, maar zoals met alles in de IT, the devil is in the details.

En als je een paar terra aan JSON ( kleine files gok ik) in S3 hebt staan wat je eruit wilt halen, dan is dat best een dure en tijdrovende aangelegenheid. Dit kun je natuurlijk allemaal syncen, maar de complexiteit die je dan inbouwt, weegt dat dan op tegen flexibiliteit en wat bespaar je dan?

[Meekoh]

Idem hier.

In dit geval met een Redshift DB, dan zit je aardig opgesloten. Echter in het geval van een datalake is de onderliggende techniek ondergeschikt aan de data zelf. Zolang je de ruwe data maar hebt in een formaat kun je dat wel weer in een andere database krijgen. Hoe alle omringende databases/apps hun data dat lake in krijgen is inderdaad wel een dingetje. Echter hierbij hebben wij geprobeerd een relatief simpele abstractie laag te bouwen, mochten we moeten switchen dan is het een kwestie van de api calls vervangen.

True het is geen sinecure en er zal ongetwijfeld genoeg tijd in gaan zitten. Maar dat zou ook zjin wanneer je on-prem van software wisselt naar Hadoop/kafka etc.

Heb even in de AWS calculator gegooid wat het zou kosten om 100 TB aan data te transferen naar elders, ik heb daarbij aangenomen dat standard s3 storage gebruikt wordt en een json file gemiddeld 100KB is, dat komt neer op +- 10K. Echter in dat geval zou ik eerder gebruik maken van Amazon's Snowball service waarbij ze de data encrypted aanleveren op disk per koerier, kosten 3K. Dat is een fractie van wat de hardware zou kosten voor een datalake als ik het zelf moest bouwen. Die 3K om data de cloud weer uit te krijgen zijn peanuts vergeleken met andere kosten waar we mee te maken hebben.

Maargoed, ik zou zeggen geef je op voor het Diner, babbelen we dan verder

[Sandor_Clegane]

Maar het punt is nu juist dat je on prem niet zo snel wisselt van stack. Het gaat er juist om dat je je provider beu bent en naar een andere cloud wilt uitwijken. Omdat hij, ik noem maar wat, geen garanties kan geven omtrent GDPR of de prijzen de pan uit rijzen, of noem een honderd andere redenen waarom je misschien van provider wilt wisselen. Als je dan de API en infra van de cloudprovider gebruikt zoals Redshift, dan moet je hier dus een flinke hoop tijd in steken wil je dit kunnen migreren. Je kunt niet even wat VMs afnemen op Azure en daar S3 op installeren, ik noem maar wat. ( Ja, ik weet dat de meeste van deze objectstores het S3 dialect wel ondersteunen, CEPH en Gluster doen dat ook, het gaat om het voorbeeld.)

Misschien doe ik dat wel.

[Reactie gewijzigd door Sandor_Clegane op 24 juli 2024 04:56]

[Meekoh]

Als ik het zo over de jaren bekijk, dan wisselt ook on-prem zo om de 3 tot 5 jaar op zijn minst van hardware. Meestal is dat niet alleen een hardware refresh, maar ook tegelijk een software refresh/upgrade (nieuw OS/software/etc.). Wellicht zelfs naar een ander product dat betere features heeft... Dus ik zou zeggen on-prem is dat wel degelijk het geval.

Kijk ook bijvoorbeeld eens naar de contracten die bedrijven aangaan met outsourcing clubs. Die zijn vaak ook voor 3 tot 5 jaar tegenwoordig en meestal als daar geswitcht wordt dan switch je in principe ook van "provider", kost ook een klap geld maar gebeurd wel!

Je bent welkom in ieder geval

[Sandor_Clegane]

Je bent het wel met me eens denk ik dat het verhuizen van een VM waar Hadoop op staat van partij A naar B een stuk simpeler is dan het omzetten van APIs in een applicatie? En het upgraden van versie A naar versie B van dezelfde applicatie is ( door de bank genomen ) ook gemakkelijker.

Maar ik denk dat we wel op een lijn zitten.

Yay!

[Cergorach]

Naar mijn idee wordt de public cloud teveel gehypt. De public cloud is met name een goed verdienmodel voor de bedrijven erachter.

Ja en nee. Voor veel organisaties zijn de algehele kosten lager in de public cloud. Echter zijn er problemen aan beide kanten van het issue, de verkopende partij prijst het de wolken in, de daar werkende ITers/partijen boren het de grond in. De waarheid zit ergens in het midden.

In de meeste gevallen zijn de totaal kosten lager of heeft men een veel betere oplossing met ondersteuning. Met de standaard prijzen geld dat voor de meeste kleine organisaties, de grote organisaties kunnen betere prijzen bedingen en dan is het afhankelijk van hoeveel lager die prijzen zijn. Voor verschillende oplossingen zijn er natuurlijk verschillende sweetspots.

Het meest voorkomende is natuurlijk een vervanging voor Exchange of zelfs de Pop3 boxen bij de hosting partij. Daar zijn oplossingen zoals Google G Suite en Microsoft Office 365 natuurlijk uitstekend voor geschikt, niet alleen voor dagelijks gebruik (zowel gebruiker als beheerder), maar zeker ook voor wanneer het (echt) misgaat. Natuurlijk gaat elke beheerder die z'n brood verdient met Exchange op locatie daar fel tegenin gaan, maar aan de andere kant zie je ook IT consultants voor cloud producten de meest rare sprongen en constructies maken om toch een klant in hun cloud aanbod te krijgen of dat nu handig is of niet.

Afgelopen jaar toevallig een klant tegengekomen waar het absoluut niet handig was om naar de cloud te gaan ivm. de fysieke locatie van de klant en de mogelijkheden van internet en aansluitingen. Dan moet je gewoon zeggen, hoe graag ze ook eigenlijk naar de cloud willen, dat is niet verstandig. Verder wil men bij rekensommetjes nog wel eens vergeten zaken mee te nemen (aan beide kanten van het sommetje)...

[Reactie gewijzigd door Cergorach op 24 juli 2024 04:56]

[poehee]

[quote]
Vanuit de inleiding:
"Uiteindelijk wil iedereen naar de public cloud, maar die stap is niet voor elk bedrijf direct haalbaar."
[/quote

Dit is een perfect voorbeeld van een eenvoudige drogreden ("Beroep op autoriteit" - en dan "Appelleren aan het algemene geloof").

Verder, men gaat naar de cloud zonder de vraag te stellen welk probleem ze hiermee oplossen of zonder op zijn minst niet ook de nadelen te laten meewegen.

[MadEgg]

Dit is een perfect voorbeeld van een eenvoudige drogreden ("Beroep op autoriteit" - en dan "Appelleren aan het algemene geloof").

Verder, men gaat naar de cloud zonder de vraag te stellen welk probleem ze hiermee oplossen of zonder op zijn minst niet ook de nadelen te laten meewegen.

Exact. Ik werk ook in deze branche en ik ben al een paar klanten tegengekomen die komen met een verzoek als: "Wij willen naar de cloud, verzinnen jullie maar wat we ermee moeten gaan doen"

"The cloud" kan leuk zijn om dynamisch te schalen, maar de kosten zijn ook wel weer dermate hoog dat het evengoed snel goedkoper is om je eigen infrastructuur te beheren. Ik zou altijd uitgaan van een eigen serverpark voor in ieder geval de minimale load en waarschijnlijk zelfs de gemiddelde load, en dan uitwijken naar IaaS/PaaS om pieken op te vangen. Alles erin draaien is veel duurder. Je bespaart wel iets op ICT-beheer, maar ook je applicaties in de cloud moeten beheerd worden dus het is niet alsof je van alle kosten verlost bent.

[Meekoh]

True, niet alles wordt goedkoper in de cloud. Maargoed de volledig redundante infra die er nu ligt is ook niet goedkoop

Wat wel interresant is om te vermelden, ik zat laatst in een bespreking voor het mogelijk overnemen van het IT landschap van een potentiele klant. Waar jij zegt: "Wij willen naar de cloud, verzinnen jullie maar wat we ermee moeten gaan doen". Dat is precies bij die klant gebeurd in het verleden (andere outsourcing toko), met alle gevolgen van dien. Daar is dus voor ons de uitdaging om dat weer recht te zetten.

Edit: Bedenk ook dat het niet alleen maar gaat om VM's in een public cloud draaien. In het geval van de mobility provider uit het artikel, wordt er bijna volledig gebruik gemaakt van Azure Functions bijv. dat scheelt wel degelijk in de kosten, je bent toch HA/redundant en kunt upscalen wanneer je maar wilt zonder dat je meteen een vermogen kwijt bent aan een server park dat de halve dag uit zijn neus staat te vreten.

[Reactie gewijzigd door Meekoh op 24 juli 2024 04:56]

[MadEgg]

True, niet alles wordt goedkoper in de cloud. Maargoed de volledig redundante infra die er nu ligt is ook niet goedkoop

Zeker niet. Maar je kunt wel een VPS huren in een lokaal datacentrum met SLA en redundantie. Dat is alsnog goedkoper dan eenzelfde machine in de cloud huren. Als je de machine dus 24/7 gebruikt kun je het beter lokaal regelen. En met één server is dat nog niet zo interessant maar als je sowieso al een flinke load te verwerken hebt gaan de verschillen wel stapelen.

Wat wel interresant is om te vermelden, ik zat laatst in een bespreking voor het mogelijk overnemen van het IT landschap van een potentiele klant. Waar jij zegt: "Wij willen naar de cloud, verzinnen jullie maar wat we ermee moeten gaan doen". Dat is precies bij die klant gebeurd in het verleden (andere outsourcing toko), met alle gevolgen van dien. Daar is dus voor ons de uitdaging om dat weer recht te zetten.

En zo houden we elkaar aan het werk

Overigens probeer ik op zo'n moment de klant wel in te laten zien dat een dergelijke doelstelling niet echt constructief is en ze na te laten denken over welke processen het kostbaarst en het meest dynamisch zijn om te kijken waar de cloud echt meerwaarde kan bieden. Roekeloos diensten in de cloud mieteren omdat dat hip is ga ik mijn handen niet vuil aan maken.

[Meekoh]

Zeker niet. Maar je kunt wel een VPS huren in een lokaal datacentrum met SLA en redundantie. Dat is alsnog goedkoper dan eenzelfde machine in de cloud huren. Als je de machine dus 24/7 gebruikt kun je het beter lokaal regelen. En met één server is dat nog niet zo interessant maar als je sowieso al een flinke load te verwerken hebt gaan de verschillen wel stapelen.

In ons geval zou het dan niet VPS huren zijn, maar een VM in onze eigen cloud in ons eigen datacenter(s). Dat is ook zeker een optie, maar ik hou je niet tegen om een VPS af te nemen ergens, als dat beter past bij het totaal plaatje voor jou business case dan kan dat ook zeker een valide keuze zijn.

En zo houden we elkaar aan het werk

Dus jij was dat

Overigens probeer ik op zo'n moment de klant wel in te laten zien dat een dergelijke doelstelling niet echt constructief is en ze na te laten denken over welke processen het kostbaarst en het meest dynamisch zijn om te kijken waar de cloud echt meerwaarde kan bieden. Roekeloos diensten in de cloud mieteren omdat dat hip is ga ik mijn handen niet vuil aan maken.

Dan zijn we het daar in ieder geval over eens

[Noxious]

In ons geval zou het dan niet VPS huren zijn, maar een VM [...]

Is dat niet exact wat een VPS is?

[Aetje]

Dit. Om naar "de cloud" te kunnen migreren moet je applicatie:
- Geen geheime data bevatten. Je beheert de hardware immers niet meer. Dit is een no-go voor bijvoorbeeld militaire contracten. En ik heb een donkerbruin vermoeden dat met die GDPR dit nu voor alle databeestjes met privacygevoelige data ook geldt.
- Geschikt zijn/gemaakt worden. Vooral legacy applicaties waar steeds meer performance van verwacht wordt lopen tegen een bottleneck aan die simpelweg niet met cloudbased opgelost wordt.
- Voordeel hebben van "De Cloud". Kwa UI latency zul je er geen winst mee boeken.

Ook moet je netwerk aangepast worden - firewall instellingen voor een intranet applicatie die op het internet gehost wordt maar alleen vanaf het LAN toegankelijk is maar waarbij users met een VPN verbinding vanaf het internet via het bedrijfsnetwerk bij moeten komen... wil nog wel eens een puzzeltje zijn. Ook zul je om single-point-of-failure te voorkomen, je internet verbinding dubbel moeten nemen. Immers, zonder internet pijp is je public cloud onbereikbaar, dus zodra je critical infrastructure in de cloud belegd wordt je internet verbinding een onderdeel van critical infrastructure, en moet je die dubbel uit gaan voeren.

Al met al zie ik wel voordelen in "the cloud", met name voor incidentele maar zware taken (compileren binaries van hele grote projecten, 3d renderen, etc... ook zware databases waar server/client latency niet direct een issue is) maar om nu elke app in "the cloud" te gooien? Een nuchtere kosten/baten analyse lijkt mee eerst verstandig.

[Meekoh]

Dit. Om naar "de cloud" te kunnen migreren moet je applicatie:
- Geen geheime data bevatten. Je beheert de hardware immers niet meer. Dit is een no-go voor bijvoorbeeld militaire contracten. En ik heb een donkerbruin vermoeden dat met die GDPR dit nu voor alle databeestjes met privacygevoelige data ook geldt.

Klopt, dat is ook zeker niet altijd mogelijk. Die klanten hebben wij ook. Alleen GDPR gooit daar minder roet in het eten dan je denk. Als jij zorgt dat je data ten alle tijden zowel in rest als in transit encrypted is naar een public cloud provider dan is dat qua GDPR geen issue. GDPR is ook meer bedoeld om de consument meer rechten te geven over hun eigen data. Een financiele instelling mag tegenwoordig ook gebruik maken van de AWS en Azure (Google weet ik niet), dit is goedgekeurd door de DNB zolang er een clausule in het contract staat die de DNB ten alle tijde het recht geeft om toegang te krijgen tot de datacenters waar de data van die financiele instelling in staat.

- Geschikt zijn/gemaakt worden. Vooral legacy applicaties waar steeds meer performance van verwacht wordt lopen tegen een bottleneck aan die simpelweg niet met cloudbased opgelost wordt.
- Voordeel hebben van "De Cloud". Kwa UI latency zul je er geen winst mee boeken.

True, legacy gaat definitely niet beter preseten als je het in de cloud plempt

Ook moet je netwerk aangepast worden - firewall instellingen voor een intranet applicatie die op het internet gehost wordt maar alleen vanaf het LAN toegankelijk is maar waarbij users met een VPN verbinding vanaf het internet via het bedrijfsnetwerk bij moeten komen... wil nog wel eens een puzzeltje zijn. Ook zul je om single-point-of-failure te voorkomen, je internet verbinding dubbel moeten nemen. Immers, zonder internet pijp is je public cloud onbereikbaar, dus zodra je critical infrastructure in de cloud belegd wordt je internet verbinding een onderdeel van critical infrastructure, en moet je die dubbel uit gaan voeren.

Dat is inderdaad een gevolg van de keuze voor een public cloud. Het wordt niet altijd zomaar "magic met dancing unicorns all over the place" door applicaties daarheen te verhuizen. Nieuwe SPOF's moet je ook zeker voorkomen, dus ja die dubbele internet pijp ligt hier zeker!

[Meekoh]

Verder, men gaat naar de cloud zonder de vraag te stellen welk probleem ze hiermee oplossen of zonder op zijn minst niet ook de nadelen te laten meewegen.

Doen we natuurlijk wel, maar komt wellicht niet helemaal goed naar voren in de beperkte ruimte die we in een artikel hebben
Dat iets niet in het artikel naar voren komt wil niet zeggen dat het niet gebeurd...

[Verwijderd]

Waarom wil iedereen naar de public cloud?

Precies het eerste wat ik ook dacht. Genoeg iig om de rest niet meer te lezen maar te scannen.

Private en hybrid cloud kunnen ook prima opties zijn.

Of... geen cloud? Genoeg toepassingen, zelfs hele bedrijven, die helemaal niet van de "applicaties" aanelkaar hoeven hangen en met een apparaat om al dan niet electronischische briefjes te produceren eigenlijk al een heel eind komen... of zelfs klaar zijn. Back-up-oplossing erbij en je bent er. Hoezo SLAs en proberen grote bedrijven zich er aan te laten houden?

De public cloud is met name een goed verdienmodel voor de bedrijven erachter.

Dit bedrijf verkoopt dan wel geen cloud, maar wel cloud-diensten. Hun verdienmodel bestaat uit het overnemen van je hele kritische bedrijfs-IT. Of "iedereen" daarheen wil durf ik te betwijfelen, ik zou het iig niet willen. Maargoed, ik hou dan ook graag de dingen waar ik echt afhankelijk van ben zoveel mogelijk in eigen hand. Je bedrijf zien verdampen omdat een toeleverancier de verkeerde manager aanstelt die vervolgens oliedomme en voor mij desastreuze fouten maakt is niet helemaal mijn cup of tea, zulke fouten maak ik toch echt liever zelf.

Goed, redenen waarom ik het niet wil kan ik wel verzinnen. Waarom iemand, dat wetende, zijn bedrijf dan toch zo afhankelijk wil maken, is mischien wel interessant om eens te horen. Hoe maak je die afweging dat je dan toch op een "laten we met dit bedrijf in zee gaan" uitkomt?

[Meekoh]

Of... geen cloud? Genoeg toepassingen, zelfs hele bedrijven, die helemaal niet van de "applicaties" aanelkaar hoeven hangen en met een apparaat om al dan niet electronischische briefjes te produceren eigenlijk al een heel eind komen... of zelfs klaar zijn. Back-up-oplossing erbij en je bent er. Hoezo SLAs en proberen grote bedrijven zich er aan te laten houden?

Tuurlijk why not, punt is wij richten ons op bedrijfs kritische of zelfs samenlevings kritische applicaties.
Onze klanten verwachten dat systemen ALTIJD beschikbaar zijn, 100%. Alles aan de infra is minstens dubbel uitgevoerd over meerdere datacenters/regions.
En om dit zo kosten efficient mogelijk te bereiken maken we gebruik van onze eigen cloud omgeving (Cloudstack) als de Public cloud providers. In the end is onze eigen cloud ook gewoon wat hardware met een backup oplissing erbij

Dit bedrijf verkoopt dan wel geen cloud, maar wel cloud-diensten. Hun verdienmodel bestaat uit het overnemen van je hele kritische bedrijfs-IT. Of "iedereen" daarheen wil durf ik te betwijfelen, ik zou het iig niet willen. Maargoed, ik hou dan ook graag de dingen waar ik echt afhankelijk van ben zoveel mogelijk in eigen hand. Je bedrijf zien verdampen omdat een toeleverancier de verkeerde manager aanstelt die vervolgens oliedomme en voor mij desastreuze fouten maakt is niet helemaal mijn cup of tea, zulke fouten maak ik toch echt liever zelf.

Goed, redenen waarom ik het niet wil kan ik wel verzinnen. Waarom iemand, dat wetende, zijn bedrijf dan toch zo afhankelijk wil maken, is mischien wel interessant om eens te horen. Hoe maak je die afweging dat je dan toch op een "laten we met dit bedrijf in zee gaan" uitkomt?

Klopt, niet iedereen zou onze klant kunnen zijn. Er zijn genoeg grote bedrijven die juist voor ons kiezen en ons wel verrtouwen boven hun huidige outsourcing toko, of interne IT afdeling.
Zo'n beetje iedere financiele instelling bijv.in Nederland is linksom of rechtsom klant bij ons, dat is niet zozeer omdat ze perse moeten outsourcen of het niet zelf willen doen, maar omdat ze ons vertrouwen.
Oh enneh, managers hebben we niet, kun je die alvast wegstrepen

[Wixed]

De public cloud biedt tal van voordelen die private cloud niet bieden. Zaken zoals scalability, low/no maintenance cost en high availability zijn voorbeelden van aspecten die grote cloud providers zoals Microsoft en Amazon veel beter kunnen dan de meeste bedrijven. Bovendien wordt hybrid-cloud minstens even hard "gehyped". Hybrid-cloud is een mooie trade-off (best of both worlds).

[mlsomers]

Waarom zou een consument ooit naar de public cloud willen?

Neem bijvoorbeeld Toon, die dingen geven ze gratis weg, maar om je eigen data te bekijken moet je elke maand een bedrag neertellen om die statistiekjes online te mogen bekijken... En dat terwijl ik hier een Synology heb draaien die dat soort data ook wel zou kunnen opslaan, maar nee, dat kan toontje niet hoor... Ik wacht nog op een commerciële OpenTherm thermostaatje die dat wel kan.

Ook voor bedrijven zijn er beren op de weg. Het grote probleem met public cloud is dat een klein foutje grote kosten met zich mee kan brengen. Als je bijvoorbeeld een bugje hebt zitten in een webservice waardoor deze in een loop blijft hangen en de processors naar de 100% toe jaagt, met automatisch schalen aan, dan kan dat ineens klauwen vol met geld kosten voordat je het door hebt! Op je privé machine blijft die schade dan beperkt tot even niet beschikbaar zijn.

Nu even op een zijspoor... Ik denk dat als we alle processorkracht in onze gadgets (intelligent-edge zoals Microsoft het noemt) zouden kunnen bundelen zodat het als één grote gedistributeerde virtuele computer zou functioneren, daar zou ik wel naar toe willen! Maar dan wel open en private houden... Dat is veel meer een "cloud" dan wat men tegenwoordig de "cloud" noemt. Zware datacenters waar clusters computers zwaar geconcentreerd op één kluitje staan lijken in mijn ogen totaal niet op een cloud, eerder op een ijsberg of zo, want het nieuwste wat daar draait is over een aantal jaar sterk verouderd en moet wegsmelten. In de "edge" heeft dat een veel natuurlijker verloop, tablets, telefoons, NAS, bewakingscamera's enzovoorts worden gaandeweg vervangen door betere als dat nodig is, en al die apparaten hebben nog wat loze rekenkracht over...

[Meekoh]

Hoe kom je er bij dat dit artikel over gewone consumenten gaat?

Dat terzijde, ja ik weet wat toon doet met jou data en ook waar het opgeslagen is, daarom heb ik het ook niet.

En voor bedrijven, ja daar zijn veel mooie voorbeelden van foutjes te vinden. Maar daar heb je meer dan genoeg tools beschikbaar om dat soort situaties te voorkomen. Als je zo'n klassieke fout maakt als unlimited autoscaling op een slechte app, dan vraag je er ook een beetje om. Alle cloud providers bieden je tools om dat soort dingen te voorkomen. Je auto heeft ook niet voor niets een rem, maar als je die niet gebruikt...

Over je zijspoor, interresant idee, moeten ze wel wat verzinnen op de battery drain van al die gadgets
Maar in principe gebeurt het al! Kijk maar eens naar al die IoT bot netwerken

[Reactie gewijzigd door Meekoh op 24 juli 2024 04:56]

[mlsomers]

Je noemt het met recht een klassieke fout, maar die is niet beperkt tot "slechte apps". Met de best geteste 100% code-coverage app die door externe certificatie is gekomen kan het je nog gebeuren! Dan maar hopen dat je operators en systeembeheerders niet slapen als ze die sms-jes ontvangen.

Over mijn zijspoor, daar is wel wat governance voor te verzinnen. Vaak hangen gadgets langer aan de oplader dan dat ze moeten opladen, en dan kunnen ze wel 100% bijdragen (zolang ze niet te warm worden).

Het gebeurt inderdaad al op applicatieniveu, zoals seti@home, mersenne GIMPS. Het "Ethereum Virtual Machine" komt nog het dichtst bij wat ik in gedachten heb, maar de blockchain is niet echt nodig voor veel applicaties. Docker swarm is ook een interessante ontwikkeling. Ik heb alleen nog geen general-purpose OS gezien die autonoom taken kan distribueren over machines van uiteenlopende kaliber.

Nog zo'n zijspoor idee is Outernet, een peer-to-peer wifi netwerk in dichtbevolkte gebieden, waarin IP adressen en DNS in een blockchain zijn vastgelegd in plaats van organisaties als ICANN, en internet providers. Als ik Wifi aan zet zie ik een hele lijst van routers, van buren van alle kanten, en ik denk dat je in de steden wel een flink bereik zou kunnen krijgen. Dit zou vooral handig zijn voor tracking, en communicatie met de kids (chat), zonder daar een G4 abonnement voor nodig is. Of IOT toepassingen waar LORA te traag is. Een gebruiker moet natuurlijk wel voorrang krijgen op zijn eigen hardware, en misschien een maximale bandbreedte instellen voor de community. Ook dit is geen nieuw idee, de Pirate-Box heeft dit al gedeeltelijk voor elkaar, alleen is dit anoniem zonder addresseringsmogelijkheden.

Tja, veel zijsporen, misschien ben ik wel spoorloos

[dabronsg]

Ik vind het nog steeds apart dat dit soort advertenties wordt geschreven alsof het een diepte interview is...

[Honbrifcl]

Voordat je begint te lezen weet je al dat het een .adv is. Met dit in het achterhoofd, vind ik het artikel toch wel enigszins interessant om te zien waar bedrijven en mensen zo mee bezig zijn en hoe data tegenwoordig zo een belangrijk product is dat het de kernactiviteit van een bedrijf vormt, een paar decennia geleden ondenkbaar. De advertentiewaarde raakt mij verder niet aangezien ik op de arbeidsmarkt niet meer actief ben...

[dabronsg]

De inhoud van het artikel is ook wel interessant, (alhoewel ik het heel erg eens ben met dude88 en poehee) maar de manier van schrijven is bijna een belediging van het intellect van de lezers. Beetje op het niveau van "Heb je schimmel in je badkamer, nou dan heb je een probleem..."

Het product kan nog zo goed zijn, maar als ik zo wordt aangesproken haak ik af.

[Reactie gewijzigd door dabronsg op 24 juli 2024 04:56]

[Hans1990]

De cynische kant van mij zegt dan ook tweakers "100% onafhankelijk" is - op de advertentie artikelen na dan...

[Reactie gewijzigd door Hans1990 op 24 juli 2024 04:56]

[Loekino]

Het is inderdaad een beetje maf. Maar wij van wc-eend vinden toch dat iedereen een wc blokje van wc-eend moet hebben. Wist je dat iedereen dit ook wilt? Dit uit diepte interviews en nog diepere Research Points door Geraldine de Intelligence Direct Man Lady Expert is op de afdeling Very English Name. Geraldine komt uit een simpele wereld maar werkt nu bij de Automated Sequence Wrapper afdeling als verpakker Wrapping Engineer of Science.

[Reactie gewijzigd door Loekino op 24 juli 2024 04:56]

[Bekers]

Krijg je dit soort advertenties ook niet te zien als je een abo hebt?

[Verwijderd]

Helaas...

[Ginz]

Ze staan inderdaad wel in je tracker, maar niet op de frontpage. Die filteren we er voor abonnees tussenuit.

[MadEgg]

Ik ben hier terecht gekomen via de reacties in de tracker maar op de homepage verschijnt deze advertorial voor mij als abonnee niet.

[Jantimon]

Het is ook een advertorial en niet een simpele advertentie zoals een banner dat wel is. Bij een advertorial zit wat meer diepte - wat blijkbaar voor sommige mensen toch misleidend overkomt. Je ziet .adv al staan voor je het artikel aanklikt en er boven staat advertorial. Lees het dan ook zodanig (of niet).