Hur möter Microsofts integrationsplattformar den hybrida världen?

Size: px

Start display at page:

Download "Hur möter Microsofts integrationsplattformar den hybrida världen?"

Moris Hood
6 years ago
Views:

3 Hur möter Microsofts integrationsplattformar den hybrida världen?

4 Let s start with a few 101 lessons from 15 years of integration work

Why use an integration platform in the first

general governance of integrations Maintain low

5 Why use an integration platform in the first place? Overview & control Reuse & cost control Architecture flexibility Logging, monitoring, general governance of integrations Maintain low maintenance/ development cost over time Being able to replace system and make changes efficiently

6 To achieve these goals that we need to remember a few patterns, concepts and some basic architecture

System E System F Add when finally System A need changes, updates or is being replaced things will be interesting The integration has built in

dictates how an integration is build, all the way from the source system Leads to details from the source system being built in to whole

replacement of a system becomes complicated System G System H System I System J System K System A System C System B System D New system will

7 System E System F Add when finally System A need changes, updates or is being replaced things will be interesting The integration has built in knowledge about the destination systems format, transport, address and protocol Loose versus hard coupling - problem The destination system dictates how an integration is build, all the way from the source system Leads to details from the source system being built in to whole integration Integration can not be reused forces need for new integrations instead of reuse Creates inflexibility in the architecture replacement of a system becomes complicated System G System H System I System J System K System A System C System B System D New system will need a new integration as the old one is tailored for a specific system. Lots of integration over time. Any change in a system will cause a change to the whole integration

The publisher integration should only have knowledge on how communicate with the source system, the integration platform and how to transform from the source format to a general format Loose versus

New or changed source systems can be replaced.

8 The publisher integration should only have knowledge on how communicate with the source system, the integration platform and how to transform from the source format to a general format Loose versus hard coupling -System solution A New or changed destination system can be added as subscribers to information. Integration only handles requirement directly related to destination system. New or changed source systems can be replaced. Only the integration that handles the requirement from that system needs replacement System C Integration platform The subscriber integration should only have knowledge on how communicate with the destination system, the integration platform, what messages to receive and how to transfer from a general format to a source specific format System B System D New system can be added or changed by just adding or changing the subscribing part of the integration

9 Kunde ByggDoc CoBuilder Logiq EDImeldinger Eksternt: FTP-utveksling Filoverføringer NOBB Ekstern varemaster Clarity Prognose innkjøp Perfion (PIM) Lokal varemaster Microsoft BizTalk Astro WMS (Logistikk) DAX200 ERP-MAXBO Varer, Priser, Tilgjengelighet, Kunder, Ordrer, Distribusjon SuperOffice CRM proffkunder Magento Hybris B2B B2C Azure B2B B2C M3 ERP-Logistikk Varer, Priser, Tilgjengelighet Sentrallager

messages and not receive all messages to all subscribers Needs to have the possibility to

10 Publish subscribe architecture a key pattern Key technical component in creating flexible architecture and a loose coupling Simplifies scaling publishers or subscribers can be scaled independently Often requires the ability to subscribe to meta data on the messages (content based routing) System A The message queue need to be super stabile it cannot fail! It s a major single point of failure. For optimal flexibility an simplicity we need the possibility to filter for only specific messages and not receive all messages to all subscribers Needs to have the possibility to add meta data to messages as that is what we will subscribe to System B System C Needs agents that are responsible for adding the messages to specific publishers queues

11 BizTalk messaging engine, details

Asynchronous versus synchronous the difference Synchronous messaging

As it required immediate response it becomes fragile and require

system Asynchronous messages lets the receiving application handle

sending application leave a message without a direct response and

12 Asynchronous versus synchronous the difference Synchronous messaging has it s place but should be used with care. As it required immediate response it becomes fragile and require lots of error handling, in addition to put stress on the responding system Asynchronous messages lets the receiving application handle the message when it s best suitable Asynchronous messaging lets the sending application leave a message without a direct response and the start working on the next one. Our system endpoint Synchronous messaging? Asynchronous messaging?

13 Asynchronous versus synchronous make the correct choice! Synchronous patterns should only be used when a intermediate response is needed! System A The requirement is really just one way (we don t care about the response) but there is this cool http based API that we can use! Might seem like a good idea at first but will put a lot of stress on the destination system. Failures and resends needs to be implemented directly in the sending system. System B If there isn t a requirement for an intermediate response it s almost always a good idea to try and make the integrations asynchronous or at least semi-asynchronous System A System A Integration component System B System B

14 These have been hard learned lessons

15 So how does this knowledge transfer over to cloud based integrations? Or does it?

16 Look mom! A oneto-one tightly coupled Logic App! System A Logic App Receive action Transform action Send action System B

17 Look mom! A one-to-one tightly coupled System Logic A App! Logic App Receive action Changes to any transformation/logic for any of the integrations will require a redeploy of all integration that are part of the Logic App New or removed systems will require a redeploy of all integration that are part of the Logic App Heavy load on one integration will affect all integrations Logging and monitoring becomes more complicated Decide Transform action Transform action Transform action Send action Send action Send action System B System C System D

18 How can we do things different?

19 Azure Service Bus an its two modes Complete pub/system in Azure packed with features. Topic/subscriptions offers content based routing capabilities Message Sender Logic App A Service Bus Namespace Filter: InvoiceType = A Subscription A Message Receiver Logic App D Logic App B BizTalk Server Topic Subscription B Filter: InvoiceType = A or InvoiceType = B BizTalk Server

20 So how can we use all this together?

21 Azure Cloud based/external System A Cloud based/external System B The application specific Logic Apps are responsible for system specific communication and can handle a number of protocols and transports. Also responsible for transforming between system specific format an shared formats. System specific Publisher System specific Subscriber System specific Publisher Publish/subscribe - Azure Service Bus System specific Subscriber Subscribers are only subscribe to specific messages using a Service Bus Subscription. Publishers only publish messages to the Service Bus with the right properties set. BizTalk acts very similar to the Logic Apps Publisher and Subscribers and either publishes or subscribes to messages on the Bus On premise based System C System specific Publisher On-premise data gateway On premise based System D System specific Subscriber Depending on previous investments, strategy etc. Logic Apps might also be used for communicating with on-premise applications On premise

22 Kunde ByggDoc CoBuilder Logiq EDImeldinger Eksternt: FTP-utveksling Filoverføringer NOBB Ekstern varemaster Clarity Prognose innkjøp Perfion (PIM) Lokal varemaster Microsoft BizTalk Astro WMS (Logistikk) DAX200 ERP-MAXBO Varer, Priser, Tilgjengelighet, Kunder, Ordrer, Distribusjon SuperOffice CRM proffkunder Magento Hybris B2B B2C Azure B2B B2C M3 ERP-Logistikk Varer, Priser, Tilgjengelighet Sentrallager

23 Kunde ByggDoc CoBuilder Logiq EDImeldinger Eksternt: FTP-utveksling Filoverføringer NOBB Ekstern varemaster Clarity Prognose innkjøp Perfion (PIM) Lokal varemaster Microsoft Azure Service Bus Astro WMS (Logistikk) DAX200 ERP-MAXBO Varer, Priser, Tilgjengelighet, Kunder, Ordrer, Distribusjon SuperOffice CRM proffkunder Magento Hybris B2B B2C Azure B2B B2C M3 ERP-Logistikk Varer, Priser, Tilgjengelighet Sentrallager

Azure Event Grid will finally enable event bases architectures!

specific Subscriber Event Grid should make it possible for subscribers to be

hopefully get us away from all polling need today System specific Publisher

24 Azure Event Grid will finally enable event bases architectures! System specific Publisher System A Publish/subscribe Azure Service Bus System specific Subscriber Event Grid should make it possible for subscribers to be woken up (using a webhook) when there s a message on the queue for them and will hopefully get us away from all polling need today System specific Publisher System specific Subscriber Will today constantly check for messages by scheduled polling. Expensive System B

25 But what about synchronous integrations?

Overview and control and general governance is just as important for this type of integration Reuse can rarely be achieved

26 Shouldn t the same rules and goals apply for a http based synchronous integrations? Cloud Clients These also need to be monitored and logged! Overview and control and general governance is just as important for this type of integration Reuse can rarely be achieved without the concept of composite services exposed data service are usually to granular and will force implementation details in to the client. Again, creating tight coupling HTTP HTTP HTTP On-premise based systems and data stores On premise

27 Been here before? What s the difference between a message in a file and in a http payload?

28 API Management will solve some problems like overview, control & governance Cloud Authentication, security, policies, logging and monitoring Azure API Management Clients Central API Management gives overview, control and general governance Also offers the possibility of abstracting away complexity in underlying implementation improves reuse HTTP HTTP HTTP On-premise based systems and data stores On premise

29 Reuse! Not possible when having tight coupling

30 Micro/composite services architecture Clients Virtual Services Azure API Management HTTP This over simplified! Cloud based systems and data stores HTTP Micro Service/Composite service Logic App/Function/Api App - Cache/performance - Synchronous requirement, asynchronous behavior in back end system - Client system callbacks and push to client patterns - Full stack logging and monitoring On premise data gateway On-premise based systems and data stores On-premise based systems and data stores On premise

Conclusion All shortcuts will cost money over time!

money and time in the long run An efficient architecture

good architecture, planning and governance No problem

perfectly designed technical platform When possible - Always

Synchronous integrations should have the same requirements

31 Conclusion All shortcuts will cost money over time! One-to-on, tightly coupled integrations will always cost money and time in the long run An efficient architecture requires much more that good technical platform Requires good architecture, planning and governance No problem building one-to-one, tightly coupled integrations on a perfectly designed technical platform When possible - Always choose a pizza delivery over a swat team at your door! Synchronous integrations should have the same requirements as an asynchronous integrations Resuable, stabile maintainable synchronous are however hard to achieve

Sentinet for Windows Azure VERSION 2.2

Sentinet for Windows Azure VERSION 2.2 Sentinet for Windows Azure 1 Contents Introduction... 2 Customer Benefits... 2 Deployment Topologies... 3 Isolated Deployment Model... 3 Collocated Deployment Model...