Big Data & Amazon Web Services: Vier vragen voor onze Big Data man Ben Hattem

Na jarenlang projecten met ERP systemen te hebben uitgevoerd, werkt Ben nu aan een Big Data Amazon Web Services (AWS) project. Eigenlijk was Ben al langer geïnteresseerd in de mogelijkheden van AWS, maar na dit project is hij echt fan. We stellen Ben vier vragen over zijn ervaringen.

Hoi Ben, om maar direct met de deur in huis te vallen; Waarom AWS? Wat vind je zo gaaf aan AWS?

Eind jaren 90 ben ik begonnen als technisch SAP-consultant (TC’er heette dat toen). TC’ers hadden destijds heel veel te maken met fysieke hardware. Installaties werden vaak vanaf de console in de serverruimte gedaan, omdat je een hele set CD’s achter elkaar aan de machine moest ‘voeren’.

Fast forward naar nu. Tegenwoordig zie je als technisch SAP Consultant nog zelden fysieke servers. CD’s zijn vervangen door Dvd’s die op hun beurt weer vervangen zijn door directe downloads. De SAP-applicatie draait vaak op een gevirtualiseerde server die niet eens een CD speler meer heeft. De volgende stap is dat je niet langer in servers gaat denken, maar in termen van services. Vanuit een business perspectief zijn servers niet interessant, uiteindelijk gaat het om de service die ze verlenen en niet om het apparaat. Leuk dat een server 4000 SAPS kan leveren, maar wat kan ik er dan mee? Hoeveel orders kan ik per uur verwerken met 4000 SAPS? En wat als de zaken goed gaan en ik meer orders wil verwerken dan mijn server aan kan?

Je kunt ook anders naar automatisering kijken. Je kunt de IT-behoefte van een bedrijf opdelen in services en die services als zelfstandige blokjes draaien. Voor elk blokje kun je dan de beste in zijn soort selecteren. Blokjes zijn geen fysieke machines meer, maar software die ‘ergens’ draait en je betaalt alleen als je het blokje gebruikt. Als je dan ook nog de mogelijkheid toevoegt om met behulp van software de afzonderlijke blokjes te configureren, krijg je wat tegenwoordig wel Infrastructure as a Service (IaaS) heet en dan kom je bijvoorbeeld uit bij Amazon Web Services (AWS).

AWS geeft de mogelijkheid om infrastructuur te programmeren. Ik vind dit mateloos fascinerend: met een paar regels Python code kan ik een template naar AWS sturen die een compleet landschap voor mij installeert. Dat kan heel klein zijn, als een statische website, maar ook een volledig redundant SAP-landschap dat in meerdere locaties high-available is. Vroeger werd je beperkt door het aantal fysieke servers wat je hebt, tegenwoordig word je alleen beperkt door je eigen verbeelding (en je budget). De uitdaging is om het zo te ontwerpen dat je zo efficiënt en goedkoop mogelijk de functionaliteit realiseert die nodig is.

AWS biedt natuurlijk een heleboel mogelijkheden, maar in dit geval gaan we het hebben over Big Data. Hoe bevalt Big Data met AWS?

Als het gaat over Big Data dan houd ik me bezig met de technologie die Big Data mogelijk maakt. Er zijn veel definities van Big Data, maar de terugkerende kenmerken zijn dat het om grote hoeveelheden ongestructureerde data gaat. Snelheid is vaak ook een factor: data komt snel binnen en moet snel weer benaderbaar zijn.

Er is een wereld van verschil tussen SAP- en Big Data technologie. SAP is van oorsprong een degelijk pakket met een duidelijke database structuur. Je zou kunnen zeggen dat bij SAP de structuur van tevoren al vastligt en dat je daar de data/bedrijfsprocessen zo goed mogelijk in laat passen. Bij Big Data is het eerder andersom: zoek de structuur in een gigantische berg data. Dit lijkt deels op Analytics, maar Analytics gaat uit van kleinere hoeveelheden data met een van tevoren bepaalde structuur.

AWS is een cloud provider die diverse services levert die in Big Data scenario’s gebruikt worden. Hierbij staat het niet bij voorbaat vast welke onderdelen in welke volgorde gebruikt worden. Er zijn wel bepaalde patronen die je vaak terug ziet komen, maar dan toch steeds weer anders geïmplementeerd worden. Een patroon is bijvoorbeeld Extract – Transfer – Load (ETL): haal de data ergens vandaan (extract), converteer naar een bruikbaar formaat (transfer) en laad in een bestemming die geschikt is voor het uiteindelijke doel (load). De uiteindelijke architectuur wordt sterk bepaald door wat nodig is: soms is het een goed idee om een Kinesis stream via een Lambda functie naar een Redshift cluster te laten uploaden, een andere keer gebruik je Docker containers op een ECS-cluster om een URL uit te lezen en de gegevens via een EMR (Hadoop) cluster naar een Hive tabel in een S3 bucket te schrijven.

Het interessante aan Big Data in combinatie met AWS is dat je steeds puzzeltjes oplost: wat past in dit specifieke geval? AWS levert een doos Lego (services) en jij mag je bouwwerk zelf in elkaar zetten. Het is de sport om alles zo goedkoop en robuust mogelijk te doen.

Je bent helemaal gewend aan ERP, wat was het moeilijkst in dit project?

Het project waar ik op dit moment bij betrokken ben is een migratie van een bestaand Hadoop cluster naar de AWS cloud. De initiële gedachte was om een zogenaamde lift-and-shift uit te voeren: bouw een bestaande omgeving zoveel mogelijk na, maar dan met AWS services.

Toen ik begon was de lift-and-shift al uitgevoerd. De basis was aanwezig, maar niet stabiel genoeg. Wat het mede lastig maakte is dat het oorspronkelijke Hadoop cluster door een vast team in de loop der jaren is opgebouwd. Documentatie was een ondergeschoven kindje: iedereen wist wat er speelde en hoe de datastromen liepen. Nu, in de nieuwe situatie, is een groot deel van het oude team (met de kennis in hun hoofd) niet meer beschikbaar. We moeten vaak aan de hand van de configuratie uitpuzzelen hoe het werkt.

Wij zijn nu bezig om enerzijds de omgeving verder te stabiliseren en waar nodig architectuur aanpassingen te maken. Dat is vaak lastig, omdat het niet meevalt om van een rijdende auto de wielen te vervangen. Daaraan gekoppeld brengen we in kaart waar de kosten worden gemaakt en hoe we deze kunnen minimaliseren.

Je vraagt wat het moeilijkste was… In tegenstelling tot SAP is er in AWS Big Data land veel minder een vaste structuur: je moet meer zelf bouwen. Weliswaar is er documentatie beschikbaar, maar uiteindelijk moet je zelf een architectuur realiseren. Dat maakt het interessant en boeiend, ik ben dol op technologie en het aanbrengen van structuur, maar tegelijk ook lastig.

Wat zouden jouw tips zijn?

Gebruik maken van AWS en IaaS is wezenlijk anders dan je eigen servers in een eigen datacenter draaien. Dit moet je niet onderschatten. In de cloud werk je volgens andere principes dan in een eigen datacenter. Bijvoorbeeld: sizing van een nieuwe SAP omgeving is belangrijk wanneer je een eigen machine gaat kopen. Waarom? Eenvoudig: de machine moet zwaar genoeg zijn om de load aan te kunnen, maar een te zware server kost onnodig veel. Hier gaat een hoop tijd en moeite in zitten. In een cloud omgeving is sizing veel minder belangrijk. Is je machine te licht? Start gewoon een zwaardere. Interessant is dat het ook andersom werkt: is je machine te zwaar en staat hij niets te doen? Neem gewoon een lichtere en dus een goedkopere.

Belangrijk is wel om steeds kritisch te kijken naar wat je op welke manier gebruikt. Cloud technologie kan je helpen om Total Cost of Ownership te verlagen, maar er zijn geen garanties. In de cloud betaal je voor gebruik en niet voor eigendom, je moet dan ook meer en beter monitoren waar je de kosten maakt. Je moest steeds blijven nadenken of het goedkoper kan. Vaak betekent dit ook dat je van tevoren niet precies weet hoe je uiteindelijke architectuur er uit gaat zien.

Een interessante trend binnen AWS is het gebruik van zogenaamde serverless technologie. Hierbij gebruik je geen servers meer, maar neem je automatisch op- en afschalende services af. Naar de services zelf heb je geen omkijken, AWS beheert deze en dat zit bij de prijs inbegrepen. Op die manier kun je bijvoorbeeld een website bouwen die letterlijk centen kost als niemand hem gebruikt, maar automatisch opschaalt tot duizenden gebruikers indien nodig. Of zoals men bij AWS ook wel zegt: “no server is easier to manage than no server”.