8. Cloud Integratie
Door de mist van de cloud
Alle recepten van The Bakery Group staan veilig in de cloud. Maar wat betekent dit? Cloud is een wat vage term. Is het tegenwoordig niet synoniem aan cloud providers, zoals AWS of Azure? Maar er is toch ook zoiets als de private cloud? Of gaat het meer om de technologie, zoals Kubernetes en Docker containers? Maar die kan ik toch ook lokaal draaien? Gaat het dan om de hosting? Maar van wat? VM’s, Containers, Lambda’s of SaaS-applicaties?
Kortom: als je door de mist van de cloud heen kijkt, zie je een regenboogpalet aan kleuren die in elkaar overvloeien.
Cloud integratie
Bij integratie in de cloud is het niet anders. Even boven het wolkendek vliegen voor een overzicht kan daarom geen kwaad. In de basis kan cloud integratie drie dingen betekenen:
1. integratie met de cloud
2. integratie in de cloud
3. cloud native integratie
In dit hoofdstuk bespreken we alle drie types van cloud integratie. Wat houden ze organisatorisch en technisch in?
1. Integratie met de cloud
Zowel door cloud vendors als door cloud-specialisten wordt weleens alleen gedacht vanuit de cloud waarin ze opereren. Bijvoorbeeld alleen vanuit Azure of AWS.
Dit is niet de realiteit van integratie. Stel: The Bakery Group heeft nog een mainframe draaien, net als een aantal servers en een database on premise. De organisatie is ook bezig haar applicatielandschap te moderniseren en gebruikt hiervoor Amazon EKS (Elastic Kubernetes Service). Daarnaast neemt zij nog een aantal SaaS-diensten af die worden gehost in Azure.
De verschillende applicaties en services hebben data van elkaar nodig. Wanneer je binnen een specifiek domein blijft, is dit relatief eenvoudig. Met domein wordt hier een cloud provider of on premisse bedoeld. Als je tussen domeinen data gaat uitwisselen, zul je over het internet moeten gaan.
Dit levert voor integratie een aantal uitdagingen op die niet veel met het uitwisselen van gegevens te maken hebben, maar des te meer met hoe je de domeinen bij elkaar kunt brengen. Denk aan alle netwerk- en beveiligingslagen die tussen een cloud- applicatie en een on premise-applicatie zitten.
Netwerken, security en protocollen
The Bakery Group heeft inmiddels al een aantal moderne services in Amazon AWS draaien. De data is beschikbaar via een API die verplicht versleuteld is (HTTPS) en ook verplicht authenticatie gebruikt, bijvoorbeeld via oAuth2. Dus waar traditioneel meer aandacht uitging naar de data en protocollen, gaat bij cloud- integratie extra aandacht uit naar beveiliging.
Daarnaast zijn on premise en cloud vaak compleet andere werelden waardoor de dataformaten en protocollen vaak sterk van elkaar verschillen. Ook ben je meer afhankelijk van elkaars netwerken. Er moet dus rekening gehouden worden met security, netwerk (failures) en verschillende protocollen. Integratie met de cloud en tussen verschillende clouds kost daarom aanzienlijk meer tijd dan integratie tussen twee applicaties on premise.
Een mogelijkheid is op netwerkniveau verschillende zaken in te regelen, denk aan firewalls, network trusts, whitelists en VPN Tunnels. Hierbij is integratie dus sterk afhankelijk van werkzaamheden door een netwerkspecialist en de stabiliteit van die oplossingen.
Als alternatief voor het werken met API’s kan een broker worden ingezet. Hetzij via een technologische oplossing (bijvoorbeeld een message broker, zoals Azure Service Bus), of via een value-added network (VAN), een aparte EDI-organisatie die dit regelt. Bij een message broker moeten clients wel het gebruikte protocol ondersteunen. Aan een VAN zijn natuurlijk weer extra kosten verbonden.
Tenslotte kan ook nog een message gateway ingezet worden. In dit geval zet je een stuk tooling op een on premise server en verbind je die met API’s of een broker in de cloud. De message gateway is een brug tussen de verschillende protocollen en netwerken. Een voorbeeld van een message gateway is Assimbly.
Samengevat brengt integratie tussen on premisse en de cloud en tussen cloud providers de nodige uitdagingen met zich mee, waarvoor veel verschillende oplossingen mogelijk zijn.
Meer lezen:
2. Integratie in de cloud
Terwijl integratie met en tussen cloud providers dus meer integratie-inspanning kost, is integratie in de cloud juist eenvoudiger en zijn er hier meer voordelen te behalen.
We stellen ons even een andere organisatie voor. In dit geval gaan we van de startup Chattie uit. Een bedrijf dat chatbots met kunstmatige intelligentie ontwikkelt. Vrijwel de volledige IT van deze organisatie draait met een microservices architectuur in de Google Cloud. Wat maakt nu dat integratie naadloos gaat? Hieronder de belangrijkste technische componenten van een microservices omgeving:
Service API: de basis voor een microservice is de API. Het idee rond een microservice is dat niet de gehele applicatie wordt ontwikkeld, maar een klein deel rond een zogenaamde business capability. Deze capability wordt geïntegreerd via een vast gedefinieerde REST API (de intelligentie zit in de endpoints). Zo’n microservice leeft meestal in een container die onafhankelijk kan worden uitgerold.
Service Management: al snel ontstaan er bij de start-up veel microservice containers, die alle gemanaged dienen te worden. De standaard om dit te doen is Kubernetes. Dit oorspronkelijk bij Google ontwikkelde platform zorgt voor de orchestratie door middel van configuratie en management van containers.
De belangrijkste taken van Kubernetes zijn het configureren van pods (met één of meerdere containers), het starten en schalen van pods en het managen van pods in een cluster. Kubernetes heeft het ondersteuning voor configuratie van load balancers, port forwarding en firewalls of DNS om toegang te krijgen tot services in een cluster. Bovendien zijn er tools voor monitoring, logging en het debuggen van containers. Tenslotte kan een service catalogus een overzicht bieden van alle services die beschikbaar zijn op het platform. Zie:
https://kubernetes.io/docs/tasks/
Service Discovery: als een applicatielandschap en de applicaties zelf zijn opgedeeld in allerlei kleine services, hoe vinden ze elkaar dan? Dit is met name een issue doordat containers dynamisch worden geladen en opgeschaald. De oplossing is service discovery.
Get Raymond Meester’s stories in your inbox
Join Medium for free to get updates from this writer.
Service discovery vormt een brug tussen de naam van een service en het IP-adres dat is toegewezen door Kubernetes. De meeste Service Discovery-oplossingen kunnen overigens meer dan alleen een systeem naar de juiste adressen verwijzen. Service Discovery tools zoals Consul en ETCD bieden ook een ‘health check’. Als de service niet healthy is of niet reageert, zal de service discovery het adres niet langer teruggeven en zo fail-over naar een van de andere service nodes doen.
Service Mesh: tenslotte wordt steeds vaker ook nog een service mesh ingezet. Het is met name deze functionaliteit die het integreren vergemakkelijkt. Bij een service mesh hoeft bepaalde functionaliteit namelijk niet meer in de code van de service gebouwd te worden, maar krijgt elke service een “sidecar”. Dit is een extensie die zorgt voor routing, retries, encryptie, autorisatie, certificaten, time-outs etc. Het is dus een specifieke communicatie laag die communicatie tussen services regelt. Zie ook: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
Hoewel de opzet van een microservices-omgeving in Kubernetes relatief complex is, biedt het dus een sterke integratie. Een uitgebreid artikel door Bilgin Ibryam en Steef-Jan Wiggers over de ontwikkeling van gedistribueerde systemen in de cloud is te lezen op InfoQ:
Op InfoQ staan ook nog twee artikelen over microservices in de praktijk bij Github en Segment:
Cloud native integratie
De laatste categorie is cloud native integratie. De native toevoeging wil niet per se zeggen dat het niet on premise zou kunnen draaien, maar dat zich vooral thuis voelt in de mist.
Voor cloud native integratiesoftware wordt vaak een open source component als basis genomen, zoals:
- Tools (Bijv. Apache Kafka, Kong API Gateway etc.).
- Frameworks (Bijv. Spring integration, Apache Camel of Zato)
- Programmeertalen (Bijv. .Net core, Java of Python)
Deze worden vervolgens beschikbaar gemaakt als cloud service. De hele configuratie, installatie, container management, CI/CD, versiebeheer enzovoort wordt door de softwareleverancier voor zijn rekening genomen. Dit kan bijvoorbeeld door Microsoft (Azure), Amazon (AWS) of Google (Google Cloud) gedaan worden of door een derde partij. Denk aan Dell Boomi dat als cloud-dienst wordt aangeboden.
Dus een microservice is vooral een architectuurconcept met een technische implementatie, maar een clouddienst (X as a Service) is daarentegen een product/dienst. Laten we per technologietype nagaan hoe deze als clouddienst aangeboden wordt.
Tools
Ten eerste tools. Dit is vaak software die je ook on premise kunt installeren. Een voorbeeld is Apache Kafka. Als deze als clouddienst worden aangeboden, heten deze vaak “Managed Tool X”. In ons voorbeeld “Managed Kafka”.
Soms krijgen ze ook een ietwat gewijzigde naam, zoals AmazonMQ (oftewel Managed ActiveMQ op AWS) of Amazon MSK (oftewel Amazon Managed Streaming for Apache Kafka). In dit geval verzorgt Amazon de installatie, containermanagement en schaalbaarheid. Het betekent overigens niet dat Amazon per se actief deelneemt aan de ontwikkeling van het open source- project.
In sommige gevallen worden deze tools in-house ontwikkeld, zoals Azure Service Bus door Microsoft of Amazon SQS door Amazon. Ook derde partijen kunnen deze aanbieden, denk bijvoorbeeld aan het cloudaanbod van Mule, Tibco of Red Hat.
Meestal zijn deze tools niet echt low-code, maar worden er wel verschillende manieren om te configureren aangeboden. Bij AmazonMQ is dit bijvoorbeeld het aanpassen van de XML die normaal gesproken op de server staat.
Frameworks als iPaaS
Het samenvoegen van verschillende tools en frameworks met een low-code interface wordt meestal op markt gebracht als iPaaS, integration Platform as a Service. Meestal is iPaaS de cloudvariant van wat eerder een ESB heette. Een iPaaS, zoals bijvoorbeeld Dovetail | Integration made easy, wordt daarom voor dezelfde soort doeleinden gebruikt, zoals het uitwisselen van data. Als er door een organisatie al voornamelijk API’s, Microservices en SaaS-applicaties worden gebruikt, dan is iPaaS een goede oplossing om die via low-code met elkaar te laten integreren.
Vóór de opkomst van cloud computing kon integratie worden gecategoriseerd als interne integratie of business-to-business (B2B) integratie. Interne integratiebehoeften werden vervuld via een on-premise middleware platform en maakten meestal gebruik van een service bus (ESB) om de uitwisseling van gegevens tussen systemen te beheren. B2B-integratie gebeurde via EDI-gateways of een value-added network (VAN).
De komst van SaaS-applicaties creëerde een nieuw soort vraag waaraan werd voldaan via cloud-gebaseerde integratie. Sinds hun opkomst hebben veel van deze diensten ook de mogelijkheid ontwikkeld om legacy of on-premise applicaties te integreren, alsmede als EDI-gateways te fungeren.
Low-code is vaak een kerncomponent van zulke cloud integratie platforms, ook om zich te onderscheiden van traditionele ESB en VAN’s. De gebruikers van deze platforms worden Citizen Integrators genoemd, omdat zich minder met code en meer met business processen bezig houden.
Cloud Functions
Het is ook mogelijk om cloudintegraties direct in code te schrijven met behulp van bijvoorbeeld AWS Lambda of Azure Functions. Eigenlijk zijn het kleine stukjes code die uitgevoerd worden in de cloud. In plaats van een microservice die meestal op de laptop geschreven wordt en in een container verpakt, wordt deze direct online geschreven en uitgevoerd. Het cloudplatform regelt die hele infrastructuur vervolgens op de achtergrond.
Stel: er moet data gefilterd worden. In dit geval kan een service dat op een queue zetten. Laten we van een queue op Amazon SQS uitgaan. Een cloudfunctie geschreven in Python haalt de berichten op uit de queue en geeft deze gefilterd weer terug.
Het voordeel is natuurlijk dat het serverless is (er zijn geen zorgen te maken over onderliggende infrastructuur), maar ook de schaalbaarheid is belangrijk. Hier een voorbeeld hoe dit ongeveer in zijn werk gaat:
Naast de cloud-functie die berichten filtert, loopt er een check die kijkt of de queue leeg is. Stel: er staan een paar miljoen berichten op de queue. Het zou lang duren voordat één draaiende cloud-functie alle berichten gefilterd heeft. AWS kan daarom het aantal instanties automatisch opschalen. Het kijkt elke 5 seconden of de queue leeg is, zo niet dan zet het er meerdere instanties bij. Op een gegeven moment zijn er wel duizend instanties die het bericht oppakken. Zodra de queue leeg is, wordt er automatisch weer teruggeschaald.
Conclusie
Er zijn veel manieren van cloud integratie. In dit hoofdstuk hebben we een aantal kleuren van de regenboog door de wolken laten zien. Naast in open source software, is de verwachting dat innovatie van data-integratie vooral op cloud computing gaat plaatsvinden. In het laatste deel zullen we een aantal van deze trends verder volgen.
