Edge Computing in Java met AWS Greengrass – De Cloud en de Edge gaan hand in hand.
De Cloud bestaat al een tijdje en wordt inmiddels breed gebruikt en is geliefd. Steeds meer bedrijven en applicaties maken de overstap, meestal naar volle tevredenheid. Maar niet alle applicaties lenen zich in gelijke mate voor deze overstap. Het is heel natuurlijk om een CRM-systeem in de Cloud te ontwikkelen en te draaien. Maar als we bijvoorbeeld kijken naar een zelfrijdende auto, dan zien we dat dit wezenlijk anders is. Dan komt Edge Computing kijken.
Door Mark van Kessel, Origineel verschenen in Java Magazine #4 2019 door NLJUG
Globaal gezien kunnen we drie redenen aanwijzen die een hoop applicaties ervan weerhouden in de Cloud te draaien. Alle drie zijn het eigenlijk wetmatigheden waar we niet veel aan kunnen doen.
Natuurwetten, zoals de snelheid van het licht, bepalen hoe snel we data kunnen verplaatsen van A naar B. Helaas neemt deze tijd toe met de afstand. Iedere gamer weet dat het onmogelijk is om een spelletje -waarbij reactietijd belangrijk is- te winnen op een server in Amerika vanuit je zolderkamer in Nederland. De latency is simpelweg te groot. En dan gaan we er nog van uit dat we een stabiele verbinding hebben. Keer op keer blijkt het (te) moeilijk te zijn om een (draadloze) verbinding 100% van de tijd te garanderen, zeker op fysiek afgelegen plekken. Dit heeft consequenties. Je wilt niet dat je zelfrijdende auto botst met een tegenligger, omdat hij een tunnel inrijdt en zijn verbinding met de Cloud tijdelijk verbreekt.
Data versturen kost geld en hoe meer data je moet versturen, hoe meer je moet betalen. Een zelfrijdende auto kan al gauw Terabytes aan data per dag genereren. Afgezien van de vraag of je genoeg bandbreedte hebt om het op te sturen, is de ook vraag of je het kunt en wilt betalen. Vaak heeft de meeste data weinig waarde, maar is intelligentie nodig om te bepalen welke data wel waarde heeft. En dus moet het opgestuurd worden.
Als laatste zijn er ook allerlei regels en regelgeving die de Cloud in de weg zitten. Wetgeving waarbij bepaalde data het land niet uit mag. Maar ook bedrijven die kritische gegevens lokaal willen houden. Vaak is het niet eens zo dat er überhaupt geen data naar de Cloud mag, maar zijn er beperkingen voor een deel hiervan. Er zal dan eerst lokaal data gefilterd moeten worden.
Er zijn dus beperkingen waar we niet omheen kunnen. Door de Cloud alleen als ‘locatie’ te zien, verliezen we andere aspecten uit het oog. Het oude cliché dat de Cloud niets anders is dan iemand anders server aan de andere kant van het internet gaat voorbij aan het feit dat de Cloud meer biedt. Belangrijker is misschien nog wel het Cloud Native paradigma en de gigantische collectie aan Cloud Services die met een enkele druk op de knop tot onze beschikking staan. Duizenden programmeurs zijn elke dag weer bezig deze Services verder uit te breiden, te verbeteren en te beheren. Het is bijna onmogelijk voor één partij deze ontwikkelingen bij te houden, laat staan ze zelf beter te ontwikkelen en te beheren. Dit stelt de Cloud-ontwikkelaar in staat met een ongekende snelheid nieuwe applicaties en ideeën uit te proberen en live te brengen zijn. Dit aspect van de Cloud willen we graag behouden, ook al staan de drie laws direct gebruik in de weg.
Dit is waar Edge Computing om te hoek komt kijken. De Edge bestaat uit de computers, apparaten en servers om ons heen. Het verschil met de Cloud is dat de Edge dichtbij de gebruikers gelokaliseerd is en dus niet ver weg in een datacenter aan de andere kant van het continent.
Voorbeelden van Edge locaties zijn zelfrijdende auto’s, drones, windmolens: +n, maar ook micro datacenters, die on-site bij een bedrijf staan of bij de zendmast van mobiele operators. Deze apparaten en locaties bestonden natuurlijk altijd al, maar in plaats van deze capaciteit als los zand, zonder onderlinge cohesie te gebruiken, gaat het om een groter en connected geheel dat samen, en met de Cloud, interacteert. De droom van Edge Computing is dat miljoenen apparaten samen een gigantisch intelligent netwerk vormen dat zich gedraagt, zoals we nu van de Cloud gewend zijn. De Cloud en de Edge zijn dan ook geen tegengestelde ideeën, maar liggen in elkaars verlengde en versterken elkaar.
Hoewel Amazon lang een Cloud-only filosofie had, met een “take it or leave it”-mentaliteit, heeft deze tech-reus nu ook beseft dat er een hoop use cases zijn waar het klassieke Cloud paradigma knelt. Ze zijn gestart om hun portfolio uit te breiden met Edge georiënteerde services. Wel altijd heel duidelijk met de AWS Cloud als centrale spil en de achterliggende gedachte om zoveel mogelijk naar de Cloud toe te bewegen. Amazon had al langer zijn vizier op de IoT markt, maar heeft zijn Edge portfolio uitgebreid met Services als AWS Outposts, AWS Lambda@Edge, AWS Snowball Edge en AWS (IoT) Greengrass.
AWS Greengrass is simpel gezegd de mogelijkheid om AWS Lambda (de Amazon serverless oplossing) lokaal te kunnen draaien. Het is General Available sinds juni 2017 en behelst alleen software, geen hardware.
De belangrijkste component is Greengrass Core (GGC), een precompiled (Linux) runtime die draait op x86 of ARM en die je lokaal op je eigen hardware kunt installeren.
De GGC is de broker tussen de devices en de Cloud en verantwoordelijk voor zaken als Messaging, Device Shadows, Security, Interactie met de Cloud en Lambda. De minimale systeemeis om GGC te kunnen draaien, is Single Core 1GHz, 128MB Ram. Of dat genoeg is, hangt uiteraard af van hoeveel devices je aan de GGC hangt en hoeveel compute je wilt doen.
De devices en de GGC worden logisch gegroepeerd in een Greengrass Group, met de kanttekening dat elke Group maar één GGC kan hebben. Vaak wordt ervoor gekozen om per locatie één Group te nemen. In het voorbeeld van zelfrijdende auto’s zal waarschijnlijk gekozen worden om één auto als Group te definiëren.
Devices kunnen vrij ‘dom’ zijn en hoeven alleen met GGC te communiceren over het lichtgewicht MQTT protocol. Amazon biedt een IoT Device SDK aan om het gemakkelijk te maken met de GGC te communiceren, maar dit is niet verplicht. Direct MQTT praten kan natuurlijk ook. Dit betekent dat je elk type Device aan GGC kunt hangen. In het geval zo’n device alleen een obscuur proprietary protocol praat, is het mogelijk om een Greengrass Connector ertussen te configureren die het vertaalwerk voor zijn rekening neemt.
De keuze van Amazon voor maximaal één GGC per Group heeft alleen wel consequenties op het gebied van beschikbaarheid en schaalbaarheid. Dus hoewel de Group zonder (permanente) connectie met de Cloud kan functioneren, wil Amazon het ook niet te autonoom maken. Geld verdienen ze uiteindelijk toch voornamelijk in de Cloud.
Greengrass maakt het mogelijk om de cloud-native ontwikkelmanier toe te passen in het IoT domein. Je kunt lokaal, op je eigen hardware, Lambdas draaien en vanuit de Cloud ontwikkelen, deployen, managen en monitoren, zoals we gewend serverless te werken in de Cloud. Aangezien de Lambdas op je eigen hardware draaien, zijn daar geen AWS kosten mee verbonden. Amazon verdient zijn geld per GGC (ongeveer 2 euro per GGC per jaar) en verder door alles wat je met AWS in de Cloud doet. Je blijft betalen voor de kosten om data van/naar de Cloud te brengen en de Cloud diensten die je gebruikt. Een veel voorkomende usecase is om in je AWS Greengrass Lambda data op te slaan in Amazon S3. Daar betaal je dan de standaard $ 3,- kosten voor (netwerk en storage).
Een essentieel verschil met een Lambda die serverless in de Cloud draait en een AWS Greengrass Lambda, is dat de laatste de beschikking heeft over de lokale resources. Deze draait lokaal op je Linux machine en heeft dan toegang tot files en peripherals. Dit maakt het bijvoorbeeld mogelijk om vanuit een Lambda een modem of GPU aan te spreken. Een ander verschil is dat er geen maximumduur zit aan hoelang je Lambda draait. Je kunt hem dan ook permanent als daemon draaien.
Op dit moment ondersteunt AWS Greengrass Lambda de volgende talen: Python, Node.JS, Java, C en C++. Hier gaan we de Java variant nader aan de tand voelen.
Wie bekend is met AWS Lambda zal een hoop herkennen. De meest logische plek om te beginnen, is ook daadwerkelijk met AWS Lambda, want daar kun je functions aanmaken om ze later in Greengrass te gebruiken. Listing 1 laat een simpele handler zien:
public class Handler {
private final static Path PATH = Paths.get("/greengrass/output.txt");
public String handleRequest(Input input, Context context) throws IOException {
context.getLogger().log("Handle request with input: " + input.getInput());
String response = String.format("Hello World - {}", input.getInput());
try {
BufferedWriter writer = Files.newBufferedWriter(PATH);
writer.write(response);
} catch (IOException e) {
context.getLogger().log("Exception: " + e.getMessage());
}
return response;
}
}
Listing 1
Waarbij Input een simpele POJO is die de inkomende JSON representeert:
public class Input {
private String input;
public String getInput() {
return input;
}
public void setInput(String input) {
this.input = input;
}
}
Listing 2
En Context is de AWS Lambda context waar we interessante meta informatie van het request kunnen benaderen, alsmede functionaliteit biedt voor bijvoorbeeld logging.
Als je deze Lambda in de Cloud bij AWS draait, krijg je een exceptie, omdat je geen toegang hebt tot de file /greengrass/output.txt. Maar zoals eerder aangegeven, is één van de voordelen van Greengrass dat je -als je lokaal draait- ook lokale resources kunt benaderen. Nu is het niet zo dat je vanuit je Greengrass Lambda zomaar alle lokale resources kunt benaderen. Elke Lambda draait in zijn eigen beveiligde container en heeft standaard nergens toegang toe. Maar je kunt je Lambda zo configureren dat je bij specifieke resources kunt. Net zoals bij Docker hoeven de paden van de Lambda container en de GGC host niet te matchen, maar kun je aangeven dat /greengrass/output.txt in de Lamdba gemapped wordt op /tmp/output.txt op de GGC host.
Dat we een Lambda hebben, betekent nog niet dat ‘ie draait. Hier is, geheel in lijn met het welbekende serverless function model, een trigger voor nodig. Alle communicatie in Greengrass, dus ook de triggers, gaat door middel van MQTT. De GGC functioneert als Message Broker en beheert de routering via subscriptions. Een subscription is een combinatie van een source, een MQTT-topic en een target. Source en target kunnen zowel devices als Lambdas zijn. Zo kun je dus aangeven dat er een Lambda afgevuurd wordt als er een bericht op een topic van een bepaald device komt.
Veel voorkomende usecases zijn om devices sensor data op een specifiek Topic te sturen en daar vervolgens een Lambda aan hangen die de sensor data filtert, aggregeert, verrijkt en doorstuurt naar de Cloud. Vaak gaat het om behoorlijk veel data, waarvan het niet onmiddellijk duidelijk is of het relevant is -en dus doorgestuurd moet worden of niet- en dus weggegooid kan worden. Hier kan AI uitkomst bieden en Greengrass biedt dan ook mogelijkheden hiervoor. Het krachtige van het Edge Computing model is dat de modellen gewoon in de Cloud, met zijn onbeperkte compute en storage capaciteiten, berekend kunnen worden. Vervolgens kunnen ze gedeployed worden op Edge locaties waar de compute en storage capaciteiten meestal wat minder uitgebreid zijn.
Hoewel Edge Computing vaak in verband wordt gebracht met het einde van Cloud computing, is van een tegenstelling eigenlijk geen sprake. Ze zijn nauw gerelateerd, versterken elkaar en zijn allebei nodig. Je zou zelfs kunnen stellen dat Edge Computing het Cloud Native paradigma nog verder doorvoert. Het strekt de Cloud nog verder uit en maakt de Cloud beschikbaar tot in de haarvaten van onze samenleving.
AWS Greengrass is een toegankelijke en volwassen manier om Edge Computing usecases in het AWS domein op te pakken. Het maakt het mogelijk Cloud concepten toe te passen in een IoT omgeving waar dit voorheen niet vanzelfsprekend was.
Mark van Kessel is software ontwikkelaar en architect bij Luminis Eindhoven met een achtergrond in embedded software die zich tegenwoordig het liefst met Java, Cloud en IoT bezighoudt.
