Cloud integratie
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? Gaat het meer om de technologie, zoals Kubernetes en 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.
Bij cloud integratie is het niet anders. Even boven het wolkendek vliegen voor een overzicht kan daarom geen cloud, eh… kwaad. In basis kan het drie dingen betekenen:
- Integratie met de cloud
- Integratie in de cloud
- Cloud native integratie
In deze blog bespreken we alle drie types van cloud integratie. Wat houden ze organisatorisch en technisch in?
Integratie met de cloud
We begonnen dit verhaal met het feit dat cloud meer dan één ding kan betekenen. Zowel door de cloud vendors als cloud specialisten wordt weleens alleen gedacht vanuit de cloud waarin ze opereren. Bijvoorbeeld alleen vanuit Azure, maar dit is niet de realiteit van integratie.
Stel een organisatie heeft nog een mainframe draaien, net als een aantal servers en database on premisse. De organisatie is ook bezig zijn applicatielandschap te moderniseren en gebruikt hiervoor Amazon EKS (Elastic Kubernetes Service) en Amazon Fargate (Serverless containers). Daarnaast neemt het 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/cloud blijft, is dit relatief eenvoudig. Echter als 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 heeft, maar des te meer hoe de data bij elkaar kan worden gebracht.
Stel de organisatie heeft inmiddels al aantal moderne services in Amazon draaien. De data is beschikbaar via een API die verplicht encrypt is (HTTPS) en ook verplicht authenticatie gebruikt, bijvoorbeeld via oAuth2 of SAML. Dus waar traditioneel meer aandacht uit ging naar de data en protocollen, gaat hier extra aandacht uit naar security.
Daarnaast zijn on premisse en cloud vaak compleet andere werelden waardoor de dataformaten en protocollen meer 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 premisse.
Een mogelijkheid is op netwerkniveau verschillende zaken in te regelen, denk aan firewalls, trusts, whitelists en VPN Tunnels. Hierbij is integratie dus sterker afhankelijk van werkzaamheden door een netwerkspecialist en de stabiliteit van die oplossingen.
Alternatief voor API’s kan er een broker worden gebruikt. Hetzij via een technologische oplossing (bijvoorbeeld een message broker als Azure Service Bus), hetzij via een value-added network (VAN), een aparte EDI organisatie die dit regelt. Bij een message broker, moeten clients wel het protocol ondersteunen. Bij een VAN zijn natuurlijk kosten verbonden.
Ten slotte kan ook nog een message gateway ingezet worden. In dit geval zet je een stuk tooling op een on premisse service en verbind je die met API’s en brokers in de cloud (ook netwerk technisch staan die open. 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:
Integratie in de cloud
Terwijl integratie met en tussen de cloud dus meer integratie effort oplevert, is integratie in de cloud juist eenvoudiger en zijn er hier meer voordelen te behalen.
We stellen ons weer een organisatie voor. In dit geval gaan we van een start-up uit. De vrijwel 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 component van een microservices omgeving:
Service API: De basis voor een microservice is de API. Het idee rond een microservice is dat niet de hele applicatie wordt ontwikkeld, maar een klein deel rond een zogenaamde business capability. Deze capability wordt geïntegreerd via een vastgedefinieerde REST API (de intelligentie zit in de endpoints). Zo’n microservice leeft meestal in een container die onafhankelijk kan worden uitgerold.
Service Management: Als snel ontstaan er 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 van containers door middel configuratie en management.
De belangrijkste taken van Kubernetes zijn configuatie van containers/pods, het starten en schalen van pods en het managen van containers in een cluster. Daarnaast heeft het ondersteuning voor configuratie van load balancers, port forwarding en firewalls of DNS om toegang te krijgen tot services in een cluster. Tevens zijn er tools voor monitoring, loggen en debuggen van containers. Ten slotte kan er een service catalogus een overzicht bieden van alle services die beschikbaar zijn op het platform. Zie: https://kubernetes.io/docs/tasks/
Service Discovery: Maar als een applicatielandschap en de applicaties zelf zijn opgedeeld in allerlei kleine services die in Kubernetes draaien, hoe vinden ze elkaar dan? Dit is met name een issue, omdat 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 toegewezen door Kubernetes. Het doet dit door een dynamische mapping te maken tussen de naam van een dienst en het IP-adres. De meeste Service Discovery oplossingen kunnen meer dan alleen een systeem naar de juiste adressen verwijzen. Service Discovery tools zoals Consul, 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 nodes mogelijk maken.
Service Mesh: Ten slotte wordt steeds vaker ook nog een service mesh gebruikt. Het is met name deze functionaliteit die het integreren vergemakkelijkt. Bij een service hoeft bepaalde functionaliteit namelijk niet meer in de code van de service gebouwd te worden, maar krijgt elke service een “sidecar”. Dit is een extense die zorgt voor routing, retries, encryptie, authorisatie, certificaten, timeouts etc. Het is dus een specifieke communicatielaag die communicatie tussen services regelt. Zie ook: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
Hoewel de opzet van 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:
En nog twee artikelen over microservices in de praktijk bij Github en Segment:
Cloud native integratie
De laatste categorie is cloud native. De native toevoeging wil niet persé zeggen dat het niet on premisse zou kunnen draaien, maar dat zich vooral thuis voelt in de mist.
Voor cloud native integratie software wordt vaak een open source component als basis genomen, zoals:
- Programmeertalen (Bijv .Net core, Java of Python)
- Frameworks (Bijv Spring integration, Apache Camel of Zato)
- Tools (Bijv Apache Kafka, Kong API Gateway etc).
Deze worden vervolgens beschikbaar gemaakt als service. De hele configuratie, installatie, container management, CI/CD, versiebeheer enzovoorts wordt door de software leverancier voor zijn rekening gehouden. Dit kan bijvoorbeeld door Microsoft (Azure), Amazon (AWS) of Google (Google Cloud) zelf gedaan worden of door een derde partij. Bijvoorbeeld SAP HANA dat als cloud dienst wordt aangeboden.
Dus een microservice is vooral een architectuurconcept met een technische implementatie, maar een cloud dienst (X as service) is meer een product/dienst. Laten we per type nagaan hoe deze als cloud dienst aangeboden worden.
Tools
Ten eerste tools. Dit is vaak software die je ook on premisse kan installeren. Bijvoorbeeld ActiveMQ of Kafka. Als deze, bijvoorbeeld Tool X, als cloud dienst worden aangeboden, heten deze vaak “Mangaged Tool X”.
Soms krijgen ze ook een iets wat gewijzigde naam, zoals AmazonMQ (Managed ActiveMQ op AWS) of Amazon MSK (Amazon Managed Streaming for Apache Kafka). In dit geval verzorgt Amazon de installatie, container management en schaalbaarheid. Het is niet persé dat Amazon actief deelneemt aan 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 kunnen derde partijen deze aanbieden, denk bijvoorbeeld het cloud aanbod 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 het aanpassen van de XML die normaalgesproken op de server staat.
Frameworks als iPaas
Het samenvoegen van verschillende tools en frameworks met een low-code interface, wordt meestal vermarkt als iPaas (integration Platform as a service). Meestal is iPaas de cloud variant van wat voorheen een ESB heette. Een iPaas, zoals bijvoorbeeld Dell Boomi, wordt daarom voor dezelfde soort doeleinden gebruikt, zoals het uitwisselen van data. Als er door een organisate al voornamelijk API’s, Microservices en SaaS applicaties worden gebruikt dan is iPaas een goede oplossing om die via low-code met elkaar te integreren.
Vóór de opkomst van cloud computing kon integratie worden gecategoriseerd als intern of business-to-business (B2B). Interne integratiebehoeften werden vervuld via een on-premises middleware platform en maakten meestal gebruik van een service bus 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 om niet alleen te onderscheiden van traditionele ESB en VAN’s, maar dat op een hoger niveau business processen ontwikkelt kunnen worden door Citizen Integrators.
Cloud functions
Het is ook mogelijk om cloud integraties direct in code te schrijven met behulp van bijvoorbeeld AWS Lambda of Azure Functions. Eigenlijk zijn het kleine stukjes code. In plaats van een microservice die meestal op de developer laptop geschreven wordt en in een container verpakt, wordt deze direct online geschreven en uitgevoerd. De cloud platform regelen 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 cloud functie 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. Één draaiende cloud functie zou lang duren voordat deze 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 deze er meerdere instanties bij. Op een gegeven moment zijn er wel duizend instanties die het bericht oppaken. Zodra de queue leeg is, wordt er automatisch weer teruggeschaald.
Conclusie
Er zijn veel manieren van cloud integratie. In deze blog hebben we een aantal kleuren van de regenboog door de wolken laten zien. Naast open source tooling, is de verwachting dat innovatie van data integratie vooral op cloud computing gaat gebeuren.
More reading
