Downloaded 136 times
Uploaded byBizTalk360
Microservices and the Cloud-Based Future of Integration
The document discusses the future of integration, focusing on microservices and cloud-based solutions, as presented by Charles Young at the BizTalk Summit 2015. It covers various integration topics including enterprise application integration, microservice architecture, and integration platform-as-a-service (iPaaS). The presentation emphasizes the evolution towards simpler, more efficient integration methods and highlights the importance of containerization and hybrid solutions.
More Related Content
Similar to Microservices and the Cloud-Based Future of Integration
Microservices and the Cloud-Based Future of Integration
- 1. tSponsors Charles Young Solidsoft Reply,Principal Consultant Microservices and the Cloud-Based Future of Integration BizTalk Summit 2015 – London ExCeL London | April 13th & 14th
- 2. Charles Young Principal Consultant SolidsoftReply www.solidsoftreply.com geekswithblogs.net/cyoung Specialist Microsoft development consultancy 1993 Microsoft certified application developers 1999 Microsoft managed partner 2000 Microsoft BizTalk integration specialists 2002 Microsoft global advisory council 2010 Windows Azure “cloud first” solutions 2013 Joined Reply Microsoft® Global Partner Network™ PARTNER OF THE YEAR 2006 Winner Application Integration 2008 Finalist Application Integration 2010 Finalist Custom Development 2011 Winner Application Integration 2012 Finalist Government Solutions 2013 Winner Cloud Solutions Today UK “SME” £10M revenue Core team of 60 specialists 100% Microsoft focus ISO 9001 & 27001 compliant UK Government IL3 certified International Society for Pharmaceutical Engineering GAMP5 who we are
- 3. Agenda • Understanding Integration •Integration Trends • Microservices • Microservices & PaaS • Container • Microservice Integration
- 4.
- 5. Integration • Adaptation •Mediation • Transformation • Routing • Orchestration Enterprise Application Integration Data Integration Electronic Data Integration • Extract, Transform and Load • Data Warehousing • Change Data Capture • Federation • Master Data Management • B2B • EDIFACT/X12 • TRADACOMS • HL7 • Partner Management • VANs
- 6. Enterprise Application Integration(EAI) Web Site Email Mobile Devices CMS CRM ERP Channels Line-of-Business Back Office Cloud ServicesTrading Partners Data Services Hub Adaptation Mediation Orchestration
- 7. ESB Service Integration WebSite Email Mobile Devices CMS CRM ERP Distributed Services On-Ramp Services Off-Ramp Services Adaptation Mediation Routing Bus
- 8. ESB Service Integration WebSite Email Mobile Devices CMS CRM ERP Channels Line-of-Business Back Office Cloud ServicesTrading Partners Data Services
- 9. Layered Architecture Web SiteEmail Mobile Devices CMS CRM ERP Data / Integration Business Logic (Application Domain) Presentation Mediation Boundary
- 10. Hexagonal Architecture -Alistair Cockburn Web Site Mobile Devices Email CMS CRM ERP Channels Line-of-Business Back Office Cloud ServicesTrading Partners Data Services Application Domain Ports & Adapters
- 11. The Changing Face ofIntegration
- 12. Standardising the Interface REST over HTTP ServiceClient GET HEAD PUT POST PATCH DELETE OPTIONS HATEOAS Hypermedia URI Resource Metadata(optional) Roy Fielding “Supports software engineering on the scale of decades” SOAP + WDSL ServiceClient Response Service URL SOAP Action SOAP Envelope Payload WSDL Metadata Extensions (WS-*) Wraps messages in standardized, extensible envelope. Provides strongly-typed interfaces
- 13.
- 14.
- 15.
- 16. iPaaS Integration Platform-as-a-Service On-PremisesSystems Hybrid SaaS • Connectors • Mediation • Workflow • Elastic & available • No Capex • Usage-based cost • Browser-based tools iPaaS EAI Server / ESB Fidelity
- 17. Aspirations • Simplicity •Velocity • Evolution • Democratisation • Cost Reduction SIMPLICITY
- 18.
- 19. Microservices in HexagonalArchitecture Web Site Mobile Devices Email CMS CRM ERP Channels Line-of-Business Back Office Cloud ServicesTrading Partners Data Services Application Domain Ports & Adapters Microservices
- 20. Microservice Principles Monolith Monolith Monolith Monolith Presentation Data/ Integration Microservices Avoid centralised governance and management Use lightweight communicationDeploy, host and version independentlyOrganise around business capabilitiesDo one thing and do it wellDecompose monoliths into microservices MicroserviceMicroservice REST No container needed
- 21. Microservices • Emad Benjamin:http://bit.ly/1BmMuet …16 VMs 400 JVMs Load Balancer 6 VMs 12 JVMs
- 22. Port BizTalk Server andMicroservices Ports & Adapters Orchestration Message Box Queues & Subscriptions Mediation Container (e.g., Receive Location) Adapter Pipelines Message AgentBT Transport MessageBox Messages Schemas Pipeline Components Maps Message Endpoint Orchestration Engine Port Port Port Port Message Agent Messages Schemas Pipeline Components Maps
- 23.
- 24. Connector Connector Azure BizTalk Services- MABS Bridge (container) Connector Connector Messages Schemas Maps Mediation Message Endpoint On- Premises Adapter Pipelines
- 25. Ecosystem Connector Azure App Serviceand Microservices Message Endpoint Transformer ValidatorConnector Connector Mediation Logic Hybrid Connection Application Gateway Logic App (Workflow) Business Logic Decoupled Resource Group(container) Connector
- 26. Application Gateway Application Gateway Runtime •Name resolution • Isolated Storage • Shared Config Proxy • API Logging • API access level • Transforming API definition Identity Broker • AAD & social login • Identity brokerage • Secure token store External Inbound Calls Calls between microservices Platform Services • Discovery • Logging • Billing • Automatic Updates • Isolated Storage Authorisation • Application secrets (Twitter, Facebook, etc.) • Azure Active Directory • App and On Behalf Of Access • RBAC rules Metadata • Generate client libraries • Powers Siena and workflow Monitoring • Installed applications • Number of calls to components • Network traffic including endpoints • Detailed performance data • Up time & crashes Proxy • API’s define public/private endpoints Component Author • Crash logs for components Isolated storage Shared config Secure token store
- 27.
- 28. Azure Containers Today MABSAppService Web Apps Mobile Apps API Apps BizTalk Apps Logic Apps PaaS Roles Web Roles Worker Roles
- 29. Windows Server Containers WindowsProcess Windows Process Windows Server Container Windows Process Hyper-V Container Windows Process OS Kernel Docker Engine Docker Client
- 30. Bins & LibsBins& LibsBins & Libs Docker Kernel OS Docker Engine Bins & Libs Bins & Libs Bins & Libs Docker Container Docker Container Docker Container Docker Container Docker Container Docker Container Docker Container Docker Container Docker Container Docker Container Docker Container Docker Hub Public & Private Repos Local Registry Base Image Read Only Writeable Bin & Libs Base Docker Client Tools / API Containership Base
- 31. Docker and DevOps Development Test Production Ship Run Build DockerImage Repos Source Code Repo Build scripts, frameworks and tools Package Management • NuGet • OneGet • Chocolatey
- 32. Docker and PlatformIndependence On-Premises Datacentre Service Provider Cloud Platform Provider Run anywhere
- 33. Evolving PaaS Landscape •Elastic Beanstalk • EC2 Container Service • Lambda • PaaS ‘V2’ • Resource Groups • Docker for WIndows • Gears • Slugs • Dynos Kubernetes Docker SwarmDocker • App Engine • Container Engine• Cloud Foundry • Docker Container Service
- 34.
- 35. Microservice Integration “5^`V z1NphE56V 1`N7j&`V 3t$ j One container to rule them all On-Premises or Service Provider
- 36.
- 37. Microservice Integration Session PresentationApplicationTransport Batch Control Message model Reliable messaging Deduplication Transaction control In-order delivery Message priority Throttling Content streaming and chunking Buffering Connectors Transport protocols Application protocols Message endpoints Metadata and discovery Connections and pooling Timeouts Authentication Push and pull Acknowledgments Fault messages Batch size Metadata harvesting Message exchange patterns: One-Way Two-Way – Half-duplex Two-Way – Full-duplex Certificate management Trust Scheduling Fast Fail Retry Recovery Failed message handling Encoding & decoding Encryption and decryption Enveloping Framing and disassembly Validation Fixing Filtering Enrichment Transformation Caching Auditing Logging Persistence Routing Operation Publishing Subscribing Correlation A Network Stack Application, Service or Data Store Mediation Framework– Composition, Configuration, Deployment, Hosting, Management, Monitoring, Tracking, Disagnostics Ports and Adapters Inherent complexity wont go away
- 38. Mediation microservices Microservice Integration On-Premises or ServiceProvider Platform-level mediation microservices
- 39. Microservice Integration On-Premises or ServiceProvider Fully-decoupled business logic
- 40. Microservice Integration On-Premises or ServiceProvider Platform-level service orchestration
- 41. Microservice Integration On-Premises or ServiceProvider Route by any means • Direct • Data stores • Cache • Queues • Topics & subscriptions • Event hubs
- 42. Microservice Integration On-Premises or ServiceProvider Platform-level Monitoring & tracking
- 43. Microservice Integration On-Premises or ServiceProvider Favour Horizontal Scaling
- 44. Microservice Integration On-Premises or ServiceProvider Technology agnosticism
- 45. Thank You! Charles Young PrincipalConsultant Solidsoft Reply www.solidsoftreply.com geekswithblogs.net/cyoung Specialist Microsoft development consultancy 1993 Microsoft certified application developers 1999 Microsoft managed partner 2000 Microsoft BizTalk integration specialists 2002 Microsoft global advisory council 2010 Windows Azure “cloud first” solutions 2013 Joined Reply Microsoft® Global Partner Network™ PARTNER OF THE YEAR 2006 Winner Application Integration 2008 Finalist Application Integration 2010 Finalist Custom Development 2011 Winner Application Integration 2012 Finalist Government Solutions 2013 Winner Cloud Solutions Today UK “SME” £10M revenue Core team of 60 specialists 100% Microsoft focus ISO 9001 & 27001 compliant UK Government IL3 certified International Society for Pharmaceutical Engineering GAMP5 who we are
Editor's Notes
- #26 After getting some feedback, I have re-worked this slide from the version presented at the BizTalk Summit 2015 conference. The points to note here are really central to the App Service value proposition, but I didn’t really manage to get them across as clearly or fully as I wished. Although, like other iPaaS offerings, Microsoft provide us with a container, this is a container for anything we might wish to use from the rich ecosystem of services (microservices, etc.,) which Microsoft hopes will grow around App Service. This is the very opposite of most iPaaS offerings which are not in a credible position to grow a significant non-proprietary ecosystem. Most iPaaS technologies only allow proprietary components from the single vendor (obviously, these may be able to invoke custom code or external services). Some are attempting to grow an ecosystem around their connector model, but it is unlikely that most will ever be able to achieve the volume and choice that App Service will (probably) achieve. The ecosystem is central here. By (in a future release) hooking it into the Azure Market Place, as well as public and private galleries, Microsoft is opening up models which third party companies can use to create revenue streams. This is ‘AppStore for Microservices’. Another important point is that, although like other iPaaS technologies, App Service provides a workflow engine, this is decoupled entirely from the microservices that it orchestrates. Again, this is a very different model to most other iPaaS offerings which tightly couple their adaptation, mediation and transformation componentry to a workflow or ‘pipeline’. This is why I described most of today’s iPaaS offerings as ‘monolithic’. Microsoft’s iPaaS approach represents a democratised, open, value-generating approach with minimal proprietary lock-in and maximum opportunity and choice. One point I didn’t really articulate fully at the conference is we need still to think very carefully through architecture when exploiting App Servive. This is where hexagonal architecture comes to bear. With the exception of the Application Gateway, nothing else in the App Service model explicitly calls out the separation of ‘ports and adapters’ from business logic. For example, it would be entirely possible for people to create connectors with embedded business logic. This would generally be a very questionable design. The application of Hexagonal architectural thinking to our designs will keep us true!