Het creëren van een eigen Kafka service voor AWS ondanks een berg aan uitdagingen
Als één van LINKIT’s meer ervaren Cloud professionals kijkt Anthony Potappel niet snel op van een uitdaging meer of minder. Maar het opzetten van een eigen Kafka service voor een pilot applicatie op de AWS Cloud, dat was ook voor hem een forse uitdaging. Een kleine maand werkte hij bij een verzekeraar mee aan deze bijzondere en uitdagende opdracht. Voor hen een mooie eerste stap in de richting van het realiseren van de lange termijnplannen van het bedrijf, waarbij het grootste gedeelte van de infrastructuur op de AWS Cloud moet gaan draaien.
Wat is Kafka?
Kafka, officieel Apache Kafka, is een open source streaming platform, ontwikkeld door LinkedIn. Het wordt tegenwoordig op grote schaal gebruikt als een soort van man-in-the-middle bij het verwerken van realtime datafeeds. Gebruikers kunnen zich abonneren op datafeeds en vervolgens gegevens realtime publiceren op meerdere systemen of applicaties. Voorbeelden hiervan zijn het matchen van passagiers en voertuigen bij Uber, of realtime analyses voor onderhoud bij Shell.
Koppelen van applicatie met SaaS-dienst
Het grootste probleem waar Anthony tegenaan liep, was het koppelen van de nieuwe applicatie met met een SaaS-dienst van een derde partij. Daarvoor was een publiek endpoint nodig, waarvoor een Kafka cluster gebruikt werd. Een uitdaging, omdat de Amazon’s Managed Streaming for Apache (MSK) maar via één VPC netwerk of VPN werkt. Dit werd helaas niet door de SAAS-partij ondersteund.
Kokerellen met Kafka in de AWS keuken
Daarentegen biedt AWS wel een zeer uitgebreid bouwpakket, bouwblokken en automatiseringsgereedschappen om zelf een service in elkaar te zetten, op basis van een eigen recept. En dat is waar Anthony mee aan de slag gegaan!
Enorm veel componenten
Het zelf ontwikkelen van een eigen Kafka service is echter geen alledaagse klus. Zo zijn er enorm veel componenten die verwerkt moeten worden. Denk daarbij aan een Elastic Compute Cloud (ECS) met Autoscaling, SSM-Parameter Store, Route53, PrivateCA en Lambda functions. De gecreëerde omgeving wordt vervolgens via een VPN ontsloten naar een tweede AWS-account, met een firewall, Intrusion Detection en Prevention Systems. Pas na al deze acties wordt het endpoint publiekelijk doorgezet. Een flinke lijst aan ondoorzichtige termen dus, waarbij alles moet kloppen.
Voor-en nadelen van een eigen AWS service met Kafka
Het zelf toepassen van al deze componenten op één service bracht zowel voordelen als uitdagingen met zich mee. Zo biedt ECS als voordeel dat er voor Kafka standaard Confluent images gebruikt kunnen worden. Die moeten echter nog wel van een extra security-patch worden voorzien, zodat (automatisch gegenereerde) wachtwoorden via een SSM Parameter Store ingeladen kunnen worden. Om de data veilig van het ene AWS account naar het andere te transporteren is portmapping gebruikt. Helaas voor Anthony is dat een feature die nog niet in de standaard MSK dienst zit van AWS, waardoor deze handmatig moest worden ingesteld.
PrivateCA
Wat dit project voor Anthony vooral speciaal maakte was het PrivateCA component. PrivateCA wordt gebruikt om de uitgifte van (SSL-) sleutels te regelen, zodat Kafka-nodes onderling veilig kunnen communiceren en alleen de applicatie toegang heeft tot het cluster.
Alleen ging het opzetten hiervan niet zonder slag of stoot. PrivateCA is namelijk een van de weinige diensten van AWS die niet volledig kan worden opgebracht via CloudFormation. Het belang van CloudFormation is dat je via één recept kunt uitrollen op 4 omgevingen van de OTAP ontwikkelstraat, waardoor veel tijd en moeite wordt bespaard.
Python Lambda’s
Om dit op te lossen schreef Anthony in Python Lambda’s die (via AWS SDK) de juiste API’s aanroepen, een PrivateKey genereren en vervolgens uploaden naar AWS. Uiteindelijk is de gevraagde omgeving nu 100 procent via CloudFormation geautomatiseerd volgens de AWS Infra-as-code standaard!
Een hele prestatie!
Ondanks de vele hierboven genoemde uitdagingen, slaagde Anthony erin om in minder dan een maand de benodigde configuratie code en bijbehorende documentatie op te leveren. Een hele prestatie! Waar hij ook met recht trots op is. De omgeving wordt nu getest en Anthony springt af en toe bij voor extra support. Na deze fase verwacht hij dat de service zonder problemen zelfstandig kan draaien.
Afronding
Doordat Anthony samen met het team van de klant werkte en de applicatie goed heeft gedocumenteerd, heeft de klant nu de mogelijkheid om zelf verder aan de slag te gaan.
Zo past dit project perfect binnen de LINKIT manier van werken: in een transparante en pragmatische aanpak samenwerken met de klant om zo een business gedreven oplossing te vinden. Met kennisdeling in de hoofdrol!
Sta jij ook voor een AWS uitdaging? En kun je wel wat extra advies gebruiken? Anthony komt graag met veel enthousiasme zijn AWS ervaring met je bespreken. Of lees dit artikel als je wilt weten wat een data engineer voor jouw bedrijf kan doen.
