Blog

Digitale requirements, het einde van de Enterprise Service Bus?

Auteur Redactie

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 betrekkingop het domein of het functionele bereik van een service. Een ander uitgangspunt is dat een servicezo 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 watde rol van een ESB in een microservices landschap moet zijn.

Microservices en SOA

Microservices wordt ook wel aangeduid als SOA2.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 eenbeperkte set van functies, afgebakend dooreen specifiek domein (bijvoorbeeld ‘billing’ of ‘ordering’). Mede hierdoor wordt een hoge matevan 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 ingezetworden. Communicatie en deployment voldoet daarbij aan industrie standaarden.

Functional microservices

Microservices moeten niet alleen onafhankelijkzijn met betrekking tot ontwikkeling of deployment maar ook onafhankelijk als het gaat omdata management. Dit heeft wederom een directerelatie met het ontwerp van een specifieke serviceen de afbakening van het business domein waareen 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.

Microservices support platform

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 platformfunctionaliteit 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.

Dit artikel delen?

Ben je opzoek naar meer?

Bekijk hier een selectie van onze ebooks.

Digital Business met Microservices

Download nu

Van traditionele organisaties naar digitale winnaars

Download nu

Stappenplan voor digitaal succes

Download nu