Death of the ESB: 10 Pitfalls in the transition to Cloud-Native Integration. Rishikesh Palve, 25th Oct 2017 Open Source Summit Europe 2017

Size: px

Start display at page:

Download "Death of the ESB: 10 Pitfalls in the transition to Cloud-Native Integration. Rishikesh Palve, 25th Oct 2017 Open Source Summit Europe 2017"

Ross Freeman
6 years ago
Views:

1 Death of the ESB: 10 Pitfalls in the transition to Cloud-Native Integration Rishikesh Palve, 25th Oct 2017 Open Source Summit Europe

2 What are we going to talk about today? ESBs?? Cloud & Edge Native Pitfalls & Lessons bout Me/Us quick recap on what What has changed? nd Common mistakes and Who are we and how can are ESBs why does it matter? how do we address them we help you or where can you send feedback 2

3 WO What? Microservices Web PIs How? In-Memory, Multicore REST, JSON Why? Mobile, Cloud, PI Economy, IoT SO What? ESB Real-time How? XML, SOP, WS-* Process Modeling Why? E-Commerce BPM EI What? dapters Real-time How? Client-Server Messaging Middleware Why? ERP nalytics ETL What? Batch Jobs Non-realtime How? Mainframe ETL, Databases Why? Data Processing MIS Productivity, gility & Ease of Consumption Evolution of Integration Patterns pplication integration can be described as making independently designed applications work together 3

4 Enterprise Service Bus (ESB) rchitecture for application integration Enables discrete heterogeneous apps & services to communicate with each other and exchange data Central (Messaging + pp) Bus + tech-specific dapters Enterprise Service Bus Leverages SO (Service Oriented rchitecture) Performs a set of common functions, such as Data transformation and manipulation Supports Message Exchange Patterns (MEP) Mediation & Protocol Conversion Service Orchestration 4

Cloud & Edge Native Integration Follows a set of specific patterns IaaS SaaS

modularized Cloud Native build/deploy/manage, automation ready, easy to scale

Legacy Microservices Container Built around business capabilities/reqs Node

independent, granular services Consistently deploy/communicate from anywhere

5 Cloud & Edge Native Integration Follows a set of specific patterns IaaS SaaS W S Integration Microservices Java Modern-infra friendly containers, modularized Cloud Native build/deploy/manage, automation ready, easy to scale up/down based on SLs/rules Clean separation of state, config data On-Prem Legacy Microservices Container Built around business capabilities/reqs Node Microservices Container PI PaaS PI Microservices Container BW PI PI PI Small, independent, granular services Consistently deploy/communicate from anywhere no dependency on server/infra/language NOT JUST RETROFITTING EXISTING TECH! Edge Native 5

6 #1 Reuse SOPful PIs & Server-side conversations as-is Phase III Phase II Phase I Strangler Pattern Compose PIs Old New Old New Old New L O D B L N C E R referencing Martin Fowler s work in 2004 dapters SOP Services Clien t Wrap Proxy 6

7 #2 Key and certificate management are not part of the things that change Introspect and define types of service communication Map out existing process for certificate request, approval, deployment and storing of secrets Group or classify services remember IPs/locations are ephemeral and there are no fixed boundaries any longer Define policies for groups or clusters and ideally automate enforcement as part of CD process Encrypt data in transit and at rest Enforce: Testing + Regular Library Updates 7

#3 1 public-facing PI = 1 pp μgw Bounded Context μs μs Bounded Context B μgw External PIs and PI Management μs μs μs μgw Bounded Context C μs μs μs External or Business PIs are often composed by

8 #3 1 public-facing PI = 1 pp μgw Bounded Context μs μs Bounded Context B μgw External PIs and PI Management μs μs μs μgw Bounded Context C μs μs μs External or Business PIs are often composed by choreography between smaller and finer internal PIs (and their respective app implementations) Each individual microservice/pi has it s own independent lifecycle Final PI lifecycle reflects changes down the chain through versioning and managed publish to external consumers pproach: PI products & pp Platforms VS. PI programs and pp Projects 8

9 #4 LIFT-&-SHIFT Qualities of tall apps Horizontally Scalable Fast startup times Resiliency to servers going and coming at will Pros: Speed, Easier in terms of effort (short-term) Cons: Operational overheads and related risk, costs and potential rework 9

#5 Can put my current tools in a Docker container, sure it will work, right? Can you externalize and manage state? Can you break down the runtime dependencies and run them independently?

10 #5 Can put my current tools in a Docker container, sure it will work, right? Can you externalize and manage state? Can you break down the runtime dependencies and run them independently? Can the config and env variables be defined externally? re you creating bloated containers or these are optimized for your app workloads? Scaling and elasticity can be leveraged without any effort? No hard dependencies on OS or file-system 10

11 #6 all systems I integrate to have to be co-located always Integration Patterns B2B pplication PI Process MFT On-Premises Data spans across users, patterns, deployments and connected endpoints People & Processes PIs pp Developers Data & Systems Cloud Mobile End-Points Personas Integration Specialist Business Users Things On-Premises Cloud Things Deployment Model 11

12 #7 dev = code, qa = test, ops = build and manage Break silos Enforce mandatory automation for entire lifecycle Integration testing not as an after-thought Collective responsibility for each service 12

#8 Bandwidth is always aplenty and resiliency comes from cloud Bandwidth is expensive and unreliable especially on devices and IoT scenarios Build to minimize

13 #8 Bandwidth is always aplenty and resiliency comes from cloud Bandwidth is expensive and unreliable especially on devices and IoT scenarios Build to minimize network/wire chatter Cloud could imply ephemeral servers and containers build for rapid start/recovery Design to account for fragile/legacy back-ends (circuit breakers) 13

14 #9 footprints don t matter as much Cloud Infrastructure On-Premises Infra Herd ofpet Cattle My Cloud Infra Herd of Cattle IoT Edge Infra Swarm of Bees 14

15 #10 Once the tech and tooling is addressed, the problem is resolved ddress Microservice Credit Check Microservice Dev Dev Business Team Development Team OR Biz Ops Biz Ops ddr CC Fulfillment Microservice Biz Dev Ops Fulfill ddr CC Fulfill Operations Team ddr CC Fulfill Culture & Organization 15

16 Leverage the wide spectrum of OS frameworks and best practices available but customize the journey to your use-case and app landscape SaaS W S On-Prem Legacy Microservices Container Integration Microservices B W Jav a P I Enterprise Service Bus IaaS Microservices Container P I PaaS Microservices Container Nod e P I P I P I Central bus arch Distributed apps & endpoints Clou d Nativ e Edge Nativ e 16

17 What we have been doing for 20+ years Deploy anywhere PI Management PIs Events Microservices / Flows Connect to anything 100 s of connectors Build your own Messaging Connectors Systems & Data IoT Devices Cloud PaaS Hybrid On-Prem Edge devices 17

18 Project Flogo Open Source ultra-light edge microservices for - IoT Integration - Edge-based Machine Learning - Conversational Engine for UX - Cloud-native Microservices + Serverless Computing* Inception st GitHub OSS. Release 1st Public Docker Hub Release pp Model support for WI Trigger reuse Support for WI Support for GW Native lambda support* daptive triggers for IoT* Support for GW

19 what can you do next? Stay back and grab a beer? Docker Pull? Go to flogo.io Check out the code github.com/tibcosoftware/flogo 19

20 @rishikeshpalve

Middleware Modernization: lay the foundation to your digital success

Middleware Modernization: lay the foundation to your digital success Agenda 1 Why modernize? 5 Platform services 2 What middleware capabilities would a digital enterprise need? 6 People and processes 3