Je op je gemak voelen binnen cloudomgevingen

Het is iets waar je vandaag de dag niet meer omheen kunt, interactie met een Cloud provider. Of dat nu Microsoft Azure, Amazon Web Services (AWS), Google Cloud (GCP) of een andere provider is. We hebben allemaal een voorkeur voor welke we beter vinden, sommige met meer validiteit dan andere.

Onlangs hielden een collega en ik een presentatie over AWS, meer specifiek over waarom het essentieel is voor een Data/Analytics Engineer om zich comfortabel te voelen bij het gebruik van de Cloud Storage en Serverless functies. In dit geval AWS S3 Buckets en AWS Lambda. Na de presentatie daagden we de deelnemers uit om een relatief eenvoudige taak uit te voeren. Haal gegevens op van de Joke API, plaats het ruwe bestand in een S3 Bucket met behulp van AWS Lambda. Laat vervolgens, met een andere Lambda-functie, een trigger afgaan wanneer er iets in die S3-bucket wordt gepUT. Deze tweede Lambda moet het opgehaalde bestand afschuimen en de veilige en onveilige grappen filteren. Daarna plaats je de veilige grappen in een map genaamd"safe" en de onveilige grappen in een andere map genaamd"unsafe" . Relatief eenvoudig, maar het leverde onderweg wel wat uitdagingen op. Zoals een gebeurtenis die verkeerd was ingesteld en uiteindelijk 's nachts exponentieel werd geactiveerd. Dat resulteerde erin dat ik de Free Tier vaarwel zei en moest betalen. Laten we eens kijken hoe je van deze fout kunt leren - en hoe je zelf een verrassingsrekening kunt voorkomen?

Aan de slag in de cloud

Als data/analytics engineer hoef je de cloud gelukkig niet uit je hoofd te kennen en alles zelf op te zetten. Als dat wel zo is, voel ik met je mee. Als dat niet het geval is, kunnen we ons richten op de bronnen die we waarschijnlijk zullen gebruiken. Deze blog zal zich voornamelijk richten op de AWS-stack.
De middelen die we zullen bespreken zijn AWS Lambda, S3, CloudWatch, Secrets Manager, SQS en tot slot een IaC-tool.
In deze blog gaan we ervan uit dat je een andere Data Warehouse oplossing zoals Snowflake en ETL tool gebruikt. Deze blog gaat daarom niet in op de databronnen die AWS te bieden heeft (DynamoDB, RDS, enz.).

Automatisering tussen omgevingen

De cloud is voornamelijk gebaseerd op UI, wat het in sommige gevallen geweldig maakt. Maar als ontwikkelaars willen we graag dat alles dynamisch en automatisch verloopt tussen onze ontwikkel-, staging- en productieomgevingen. Er zijn een paar tools die hierbij kunnen helpen, Terraform is een grote, of AWS hun op CDK. Sinds afgelopen herfst heb ik de kans gekregen om bekendheid en ervaring op te doen met de laatste terwijl ik een van onze klanten hielp.

Als we beginnen met AWS CDK, moeten we er eerst voor zorgen dat het geïnstalleerd is op onze lokale machine. Een goed startpunt is om de gids te volgen die AWS zelf heeft uitgebracht over hoe je je eerste CDK App installeert en maakt. Als je bedrijf al AWS heeft en behoorlijk volwassen is, dan heeft het misschien een lokaal pakket, wat het ontwikkelen nog makkelijker maakt. Zorg ervoor dat je dit van tevoren weet, want het kan je op de lange termijn veel overhead besparen.
Waar AWS CDK in principe voor dient, is het creëren van de bronnen en configuratie die je nodig hebt. Van hieruit stellen we onze Lambda event triggers in, maken we onze S3 Buckets, IAM policies en misschien zelfs wat logging aan. Zorg ervoor dat je je resource-omgeving proof maakt door accountinformatie op te nemen.

Opslaan, opslaan, opslaan

Bron: Wikipedia

We hamsteren tegenwoordig graag gegevens; hoe meer, hoe beter. Omdat opslag de laatste jaren zo goedkoop is geworden, zijn we uit het oog verloren wat we nu eigenlijk opslaan en met de gegevens doen. Ik ga nu niet in op wat we kunnen doen om dit te verbeteren. Ik zal je vertellen hoe we nog meer gegevens kunnen opslaan! En dat is cloud-opslag. Geen stoffige oude rommelige kantoorkelders meer, trage en oude hardware die wordt onderhouden door een willekeurig netsnoer dat aan het plafond hangt. Nee, nu hebben we een eenvoudig schaalbare opslagoplossing in de cloud, S3 voor AWS in dit geval.
S3 is heel eenvoudig op te zetten en ermee te werken, maar biedt onder de motorkap een heleboel krachtige functies. Zoals versiebeheer, intelligente tiering, levenscyclusbeleid en meer. Al die gegevens die we hamsteren en niet gebruiken, maar wel moeten bewaren. We maken gewoon een levenscyclusbeleid dat die gegevens archiveert in de opslagklasse die we willen. Nu hebben we meer budget om de fix van de oneindige lus uit te stellen!

Wat ook geweldig is aan S3, zoals veel andere Cloud Storage-oplossingen, is dat er veel compatibiliteit is met verschillende tools, zoals je Data Warehouse of je ETL-tool. Dit maakt de communicatie en interactie met die gegevens zoveel gemakkelijker.

λ

Lambda is geweldig voor het programmeren van en communiceren met al je bronnen binnen AWS op basis van events. Maar ook voor gewone functies. Het maakt het allemaal centraal, er is geen overhead van het moeten openen van een lijn naar de Cloud Provider, maar directe interactie op een veilige manier met uw bronnen. Het is belangrijk dat je weet hoe je de gebeurtenisinvoer moet lezen en dat je die zo goed mogelijk kunt benutten. Op die manier kunt u dingen dynamischer maken en het aantal hard gecodeerde variabelen in uw code verminderen. Je kunt de kant-en-klare events van AWS gebruiken voor bijvoorbeeld Object creaties op een S3 Bucket. Of je kunt AWS SQS gebruiken. Je kunt de body aanpassen zoals je wilt en er zoveel informatie in opnemen als je wilt. Vaak zijn deze kant-en-klare versies goed genoeg voor de meeste gevallen. Maar het kan gebeuren dat deze niet voldoen; in dat geval kun je andere triggers gebruiken. Zoals EventBridge met aangepaste gebeurtenissen, of direct de Lambda buiten je AWS-omgeving aanroepen als de trigger buiten AWS is. Of zelfs een webhook van Shopify of Atlassian van derden gebruiken.

Shhh

Het kan zijn dat we een API-sleutel of credentials nodig hebben voor een externe toepassing in Lambda. Nu moet je dit zeker niet hard coderen of handmatig toevoegen in de "Omgevingsvariabelen via de UI", maar gebruik maken van AWS Secrets Manager. Je kunt je AWS CDK Stack gebruiken om de naam van het geheim als omgevingsvariabele door te geven aan je Lambda-functie. Dit maakt het dynamisch cross-environment en veiliger.

Logs liegen niet

Logs mag je niet vergeten, ze vertellen het verhaal van hoe goed je programma/applicatie draait. Binnen AWS zouden al je Lambda's, als ze vanaf het begin goed zijn ingesteld, CloudWatch Logs moeten hebben. Deze logs laten ons weten wanneer onze functie in de kern is getriggerd, maar kunnen nog veel meer bieden als we ze op de juiste manier gebruiken. Als beginnende ontwikkelaar leren we om alles wat we doen of creëren af te drukken. We kunnen ditzelfde ritueel toepassen op onze Lambda-functie! Print elke essentiële variabele of uitkomst die je zou willen, maar maak het duidelijk! Als het goed is opgezet voor alle functies, kun je zelfs een Lambda-monitoringfunctie maken voor de logs en een melding maken wanneer er iets essentieels fout gaat, naar je Teams-kanaal of een andere communicatietool door sleutelwoorden te gebruiken.
Natuurlijk is er ook de logbibliotheek beschikbaar, die we opnemen in onze CloudWatch logs. Het wordt aangepast aan wat jouw team gebruikt of wat jouw voorkeur heeft.

Concluderend kan een duik in AWS als Data/Analytics Engineer aanvoelen als een steile leercurve, maar met de juiste tools en kennis is het een ongelooflijk krachtig platform. Of je nu werkt met Lambda, S3 of CloudWatch, de sleutel is om flexibel te blijven, de gebeurtenissen die je triggert te begrijpen en altijd je kosten in de gaten te houden. Fouten gebeuren, maar zolang we ervan leren, zijn het slechts opstapjes om efficiënter en effectiever te worden in de cloud. Dus neem deze lessen, vermijd de valkuilen die ik ben tegengekomen en begin vol vertrouwen aan de opbouw van je cloudinfrastructuur!

Neem contact met me op en laat me weten wat jouw grootste mislukking in AWS Cloud is!

Linkedin