Konzept für Azure BizTalk Microservices vorgestellt – Vorteile und Nachteile
Kommentare

Azure BizTalk Microservices bezeichnet – kurz gesagt – ein neues Architekturkonzept, das es ermöglichen soll, mithilfe von Microservices zusammengesetzte Anwendungen zu erstellen. Microsoft hat die kürzlich beendete Integrate 2014 genutzt, um sein Konzept dem Fachpublikum näher zu bringen.

Sam Vanhoutte (Technischer Leiter und Produktmanager bei Codit) war vor Ort und hat die präsentierten Informationen in einem ausführlichen Blogpost zusammengefasst – inklusive einer persönlichen Einschätzung, wo die Vorteile, aber auch die Herausforderungen und möglichen Nachteile liegen.

Grundlegendes

Dass die Präsentation auf einem BizTalk-Event stattfand kommt nicht von ungefähr: Das Team von BizTalk Services nutzt die BizTalk-Microservices (sowie Microservices von Partnern) als Grundlage ihrer neuen Cloud-Integrationsfunktionen. Microsoft zufolge soll der Dienst auch über das Windows Azure Pack (WAP) verfügbar sein, wodurch Kunden ihn in der Cloud ihrer Wahl laufen lassen können. Die verschiedenen BizTalk-Microservices sollen – ähnlich wie Azure-Webseiten – in eigenen, skalierbaren Containern laufen. Die Kommunikations-Engine folgt dem leichtgewichtigen HTTP-Ansatz.

Vorteile

Beim Setup und beim Design zusammengesetzter Workflows wird die Azure-Gallery eine wichtige Rolle spielen. Wie genau Microservices auf der Gallery veröffentlicht werden, steht zwar noch nicht fest, Vanhoutte rechnet jedoch fest damit, dass das Partner-Ökosystem in diesem Zusammenhang voll ausgeschöpft werden wird – was der Entwicklung der Plattform insgesamt deutlichen Schwung verpassen dürfte.

Ein großer Nachteil der BizTalk-Services war es laut Vanhoutte bisher, dass jede Instanz zu einer ganzen Reihe großer, dedizierter virtueller Maschinen führte – von einem diskutablen Abrechnungsmodell ganz zu schweigen. Azure Microservices hingegen will kleine, skalierbare Container-Dienste bieten, die sich auch besser mit einer verbrauchsbasierten Abrechnung vertragen.

Zum Stichwort Skalierung merkt Vanhoutte an, dass diese auf eine derart feine Art und Weise möglich sein soll, dass sogar einzelne Integrationsflüsse skaliert werden können (automatisch oder On-Demand).

Im Hinblick auf die Erweiterbarkeit schätzt Vanhoutte, dass sich diese aller Voraussicht nach in benutzerdefinierten Microservices niederschlagen wird: So wird es offenbar möglich sein, eigene Microservices zu schreiben und für die Nutzung in Apps oder Workflows zu veröffentlichen. Ein weiterer Vorteil: Da alle Microservices in ihrer eigenen, isolierten Umgebung laufen, kann fehlerhafter Code auch nur diesen einen Dienst beeinträchtigen – alle anderen bleiben unberührt.

Herausforderungen und mögliche Nachteile

Die erste Herausforderung, die Vanhoutte anspricht, ist die Latenz von Integrationen mit hohem Durchsatz. Im Rahmen des BizTalk-Servers war es möglich, die Performance durch eine Reduzierung der „MessageBox-Calls“ auf ein Minimum zu reduzieren. Beim neuen Dienst besteht das Äquivalent Vanhoutte zufolge augenscheinlich in der Anzahl der „Sprünge“ zwischen den Microservices, was recht ressourcenintensiv wäre und zudem das Konzept des Transaktionsverhaltens zu brechen scheint.

Unklar ist zur Zeit offenbar, wie im Rahmen der Architektur komplexe Messaging-Konzepte wie große Messages, Batching/Debatching oder „lose Kopplung“ gelöst werden sollen, die insbesondere bei der Unternehmensintegration eine wichtige Rolle spielen.

Wie Vanhoutte weiter ausführt, wurde in der Präsentation zudem nicht klar, wie es um die Granularität bestellt ist, d.h. wie feingranular die Microservices gemapped werden sollen. Die gezeigten Beispiele weisen Vanhoutte zufolge jedoch darauf hin, dass jeder Endpoint, jede Transformation und jede Pipline in einem separaten Microsvervice resultiert. Dadurch würde zwar jeder Dienst sehr leicht zu skalieren sein, gleichzeitig wäre eine enorme Komplexität bei der Bereitstellung und der Verwaltung der Microservices die Folge.

Im Hinblick auf Tools und Management schließlich merkt Vanhoutte an, dass der Workflow-Designer zu einhundert Prozent Web-basiert ist und im Azure-Portal gehostet wird, was zahlreiche Vorteile bringen, gleichzeitig jedoch die Fähigkeit zur Entwicklung komplexerer Workflows sowie zur Integration in einem Quellkontroll- bzw. ALM-System einschränken könnte.

Aufmacherbild: indoors of modern computer device with binary code illustrationvon Shutterstock.com / Urheberrecht: Adam Vilimek

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -