Digitale requirements, het einde van de Enterprise Service Bus?

Geschreven door Alex van Koutrik op 1 oktober 2017

Cloud, Docker, Microservices en Continuous Delivery, de buzzwords in de wereld van software ontwikkeling anno 2016, 2017 en 2018. Tegelijkertijd zien we dat bestaande software leveranciers hun ‘middleware’ en integratie oplossingen als een ‘Enterprise Service Bus’ nog nadrukkelijk promoten. Is er nog leven voor de ESB in een digitaal, microservices landschap?

Microservices, docker en het einde van ESB?

Om te beginnen wil ik begrippen als Docker en Microservices toelichten voor we verder gaan naar het nut en de noodzaak van een Enterprise Service Bus of integratie platform in een Microservices landschap.

Microservices is geen technologie, maar een software architectuurstijl die mede gebaseerd is op Domain Driven Design (DDD) principes.

Daarbij heeft de term ‘micro’ vooral betrekking op het domein of het functionele bereik van een service. Een ander uitgangspunt is dat een service zo autonoom mogelijk is.

Een veel gehoorde mening is dat Microservices een Enterprise Service Bus overbodig hebben gemaakt, omdat microservices zijn gebaseerd op het principe van ‘smart endpoints’ en ‘dump pipes’.

 


Docker

Docker is een technologie oplossing, gebaseerd op een concept van virtuele containers. Het gebruik van uniforme containers zorgt ervoor dat deployment en distributie van software (applicaties, services) snel, eenvoudig en gecontroleerd kan worden uitgevoerd op elke omgeving. De meeste mensen zijn het er over eens dat Docker de toekomst van softwareontwikkeling blijvend zal veranderen.


 

Geen zware integratie platformen met (overbodige) functionaliteit en intelligentie, maar lichtgewicht oplossingen voor de ondersteuning van a-synchrone messaging.

Door verder in te zoomen op een microservices architectuurstijl en te kijken naar relevante kenmerken en verschillen ten opzichte van een Service Oriented Architecture (SOA), wordt duidelijk wat de rol van een ESB in een microservices landschap moet zijn.

Microservices en SOA

Microservices wordt ook wel aangeduid als SOA 2.0 of SOA zoals dit oorspronkelijk bedoeld was. In een microservices architectuur kunnen services onafhankelijk ontwikkeld, gedeployed en op- en afgeschaald worden. Een service heeft een beperkte set van functies, afgebakend door een specifiek domein (bijvoorbeeld ‘billing’ of ‘ordering’). Mede hierdoor wordt een hoge mate van autonomie bereikt.

Een belangrijk verschil met SOA is, dat in het geval van microservices, meerdere technologieën naast elkaar gebruikt kunnen worden. Oftewel voor een specifieke microservice kan indien gewenst of noodzakelijk een andere technologie ingezet worden. Communicatie en deployment voldoet daarbij aan industrie standaarden.

Microservices moeten niet alleen onafhankelijk zijn met betrekking tot ontwikkeling of deployment maar ook onafhankelijk als het gaat om data management. Dit heeft wederom een directe relatie met het ontwerp van een specifieke service en de afbakening van het business domein waar een service betrekking op heeft. Verder kan een microservice voor intern gebruik zijn of hij kan beschikbaar gesteld worden aan derden.

Als we gaan kijken naar het speelveld van middleware en integratie voor bovenstaande architectuurstijlen wordt duidelijk waar deze aan moeten voldoen in een microservices tijdperk.

Integratie in het microservices tijdperk

De behoefte aan integratie met de opkomst van cloud, Internet of Things, mobile en Big Data alleen maar groter geworden. Denk aan software van bijvoorbeeld Booking.com die met behulp van API’s aan derde partijen beschikbaar worden gesteld. Of de opkomst van Data Lakes (Hadoop, Elastic) die vragen om de integratie met ERP systemen, Twitter feeds en andere Social Media bronnen als Facebook. Data van mobiele telefoons die geïntegreerd wordt in software applicaties, portals om location based services te kunnen bieden.

Daar zien we ook een aantal belangrijke verschillen met het tijdperk van de Service Oriented Architecture, waar de behoefte aan integratie vooral werd gevoed door End to End Business processen die over verschillende systemen of applicaties lopen.

Denk aan eCommerce omgevingen met order to cash processen die vragen om de integratie van onderliggende applicaties (ERP, DWH, CRM). Daarbij wordt het meer en meer belangrijk om realtime te kunnen beschikken over data die gerelateerd is aan een event dat zich afspeelt. Ook dit heeft gevolgen voor de eisen die worden gesteld aan een integratie oplossing.

Requirements van nieuwe middleware

Als we het voorgaande proberen te vertalen naar requirements die we stellen aan de nieuwe generatie middleware integratie oplossingen of ESB’s dan levert dat onderstaande op:

  • Een flexibele oplossing, die schaalbaar en gedistribueerd is en die verder gaat dan een API management oplossing;
  • Ondersteuning van lightweight integratie in de vorm van a-synchrone messaging, zeker met de opkomst van Internet of Things;
  • Service delivery platform functionaliteit in plaats van integratie platform functionaliteit;
  • Specifieke functionaliteit voor service discovery, deployment, auto scaling en monitoring.

Het is interessant om vast te stellen wat bestaande integratie platformen en ESB’s hierin kunnen betekenen of hoe deze zich ontwikkelen. Maar ook is het de moeite waard om te kijken naar de mogelijkheden en beperkingen van API management oplossingen die zich in het speelveld van API’s en microservices architecturen manifesteren.

Meer weten over Reactive systems, microservices en wat het voor jouw eindgebruikers oplevert? Lees ook de interessante whitepaper “Van traditionele organisatie naar digitale winnaar”. Hierin wordt er praktisch dieper op dit onderwerp ingegaan.

Hoe wordt jouw organisatie een winnaar in het digitale tijdperk?

lees nu de gratis whitepaper