MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM Rohit Kelapure Coté MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

Table of Contents

BACKGROUND ...... 2 WHY MICROSERVICES...... 2 PEOPLE & PROCESS...... 3 CHALLENGES WITH MICROSERVICES ...... 4 MIGRATION FROM ESBS TO CLOUD NATIVE PLATFORMS...... 5 PHASE 0 : CO-EXIST ...... 5 PHASE 1 : LIFT AND SHIFT...... 6 PHASE 2 : REFACTOR...... 6 PHASE 3 : REPLACE...... 8 PHASE 4 : TRANSFORM...... 9 TL;DR RECOMMENDATIONS ...... 11

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

Migrating an ESB to Cloud Native Platform

BACKGROUND The rising popularity of microservices as an architecture has led to several questions around the role of the Enterprise Service Bus, or, ESB. Traditionally the role of the ESB was to fulfill the promise of the Service Oriented Architecture (SOA) approach by providing invocation, routing, mediation, messaging, process choreography, service orchestration, , management, agnosticism, support for various message exchange patterns, adapters, transformation, validation, governance, enrichment, support for WS-* standards and abstraction. One can easily see how such software can easily become the central bottleneck for all applications in an enterprise aka ‘The God Object.’

The term ‘central’ can also be used to reference the architectural style, namely everything has to be routed through the ESB. As such, an ESB works on an canonical data representation leading to dumb endpoints and smart pipes. An ESB centric app architecture results in anemic services that are integrated via a smart centralized ESB. In contrast, a microservices approach favors dumb pipes and smart endpoints. There is an inherent conflict between microservices and ESBs.

The microservice architecture pattern is an approach to SOA without the commercialization and perceived baggage of ‘WS-Deathstar’ and an ESB. Many organizations further assert centralization of control by creating a SOA Center of Excellence for Application Integration. Microservice-based applications favor simpler, lightweight protocols such as REST, rather than WS-*. They also very much avoid using ESBs and instead implement ESB-like functionality in the microservices themselves. The Microservice architecture pattern also rejects other parts of SOA, such as the concept of a canonical schema and an unified domain model across bounded contexts.

WHY MICROSERVICES Most enterprise systems over time evolve to Big Balls of Mud. Beyond a certain scale making modifications to this spaghetti code becomes untenable. To avoid this, microservices gives us a structured approach to shear these monoliths and develop and deploy them in an agile fashion. Decomposing a monolith requires patterns like the Strangler, Inverse-Conway, Facade, Adapter, smart routing, feature-flags, zero-downtime-deployment and Proxy. So that organizations can avoid re-inventing the microservices wheel, Pivotal Cloud Foundry natively bakes these concerns into the platform.

pivotal.io MIGRATING AN ESB TO ACLOUD CLOUD NATIVE NATIVE PLATFORM PLATFORM PIVOTAL WHITE PAPER

Integration tools have historically been the domain of the specialists working in the Integration Competency Center. They have required distinct skill sets and domain knowledge – from enterprise application integration, enterprise service buses, services oriented architecture to extract, transformation and load, and enterprise data warehousing and business intelligence. In contrast, the citizen model of integration refers to the process of democratization of integration workflows upending traditional approaches to data and application integration put together by general developers with no specialized domain knowledge driven by the demand for self-service from the business.

The emergence of PaaS and iPaaS platforms are a consequence of the need to speed up software delivery cycles. Features need to be delivered in a time span of weeks instead of years. A good cloud native platform makes this possible by baking into its foundation microservice management capabilities like service discovery, routing, load balancing, application lifecycle management and operational capabilities like canary releases, zero downtime deployment, automation, monitoring and security. Many of the concerns taken care of by the ESB are now usurped by the cloud platform and provided to all the applications transparently at web scale. Moreover these platforms are truly open to extension and can be deployed using next generation tooling like BOSH.

PEOPLE & PROCESS A successful deployment of microservices is contingent on people, process and technology. The development of microservices is done with the agile methodology. The roots of this thinking can be found in the four “laws” of Mel Conway’s seminal 1967 work “How Do Committees Invent”:

Conway’s First Law: A system’s design is a copy of the organization’s communication structure. Conway’s first law tells us team size is important as well as how teams are organized. Communication dictates design. Make the teams as small as necessary to minimize large, sprawling software architectures that mirror multiple large teams. Conway’s Second Law: There is never enough time to do something right, but there is always enough time to do it over. Conway’s second law tells us problem size is important. Make the solution as small as necessary. Conway’s Third Law: There is a homomorphism from the linear graph of a system to the linear graph of its design organization. Conway’s Third law tells us cross- team independence is important. A more modern variant of the same covenant is the ‘two pizza rule’ invented by Jeff Bezos, i.e., teams shouldn’t be larger than what two pizzas can feed. Conway’s Fourth Law: The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems. Conway’s fourth law tells us that time is against large teams therefore it is critical to make release cycles short and small.

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

The ESB development model of design by committee is at odds with the fundamental tenets of agile and lean development, i.e., smaller decentralized teams and faster release cycles. ESB development requires specialized knowledge and does not support rapid continuous integration and development.

Conway’s Law suggests sweeping, organizational changes are needed to change applications: people must be re-arranged to match the desired architecture. This notion of “large change” is also touched on by the O-Ring Theory of DevOps. This theory states that when production depends on completing a series of tasks, failure or quality reduction of any task reduces the value of the entire product. Another interesting finding is that, the better you are the more value you get from improving your weakness and conversely if you are fairly poor across the board you won’t get as high a ROI on an improvement in one specific area. In order to boost productivity it is critical to pursue excellence across all IT processes, not just locally optimize on discrete technology and process changes.

CHALLENGES WITH MICROSERVICES While there are many, clear benefits to a microservices approach, esp. for organizations that want to increase the agility of their software life-cycle, there are some challenges, primarily due to the youthfulness of microservices when contrasted to the maturity of an ESB approach.

CHOREOGRAPHY BEST PRACTICES ARE STILL EVOLVING When a business system is designed as a suite of microservices that prefer choreography over orchestration it behooves the advocates of the architecture to provide best practices and patterns to implement the abstraction. This is where microservices falls short. The programming frameworks for microservices choreography such as event sourcing and CQRS are woefully behind in terms of maturity and production capability with some notable exceptions like axon or akka-persistence.

LACK OF VISUALIZATION TOOLS An ESB provides a visual mode of development that allows domain modelers and business developers an opportunity to design and validate a business process without getting their hands dirty with code. A cross-bar architecture allows architects to enforce a central point of governance and control over design and implementation. DIY Integration frameworks lack the extensive user and process modeling tools that traditional ESB vendors provide. This is a shortcoming in the DIY Integration ecosystem with Spring Integration.

BUSINESS LOGIC MONITORING Features of the ESB like business activity monitoring and event correlation now have to be implemented in applications or supplied as cross-cutting libraries

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

to applications. Typically an ESB has a whole suite of connector services and adaptors that will need to plugged in for an individual service instead of harvesting from a common core.

ESBS MAY HAVE MORE EXISTING, REUSABLE SERVICES A mature enterprise has a fully developed and very mature suite of ESB services that makes development of features with ESBs easy and fast. The pain of development, training and deployment has been amortized over the years to the point where developing features with the ESB may be equivalent to writing a suite of microservices.

MIGRATION FROM ESBS TO CLOUD NATIVE PLATFORMS If you’ve decided that you’re “stuck” with your current ESB approach, we recommend planning out a migration to microservices approach. There are 5 phases to evolving an ESB infrastructure and accompanying business services to the cloud.

PHASE 0 : CO-EXIST The goal with this step is introduce an alternative approach to the ESB without being overly disruptive with a rip-and-replace approach. This lays the foundation for new application to start following a microservices architecture, and is the first step for applying “the strangler pattern” for existing services.

To do this, deploy the ESB alongside the your chosen PaaS, like Pivotal Cloud Foundry. ESB services are exposed as user provided external services to the PaaS. This allows the enterprise to deploy apps to a platform like Cloud Foundry and keep its existing backend services in an ESB like TIBCO. The advantages here is the ability to move the web tier to the next generation platform without disrupting existing integration flows.

Pivotal Cloud Foundry

Apps Cell Cell Cell Manager Cloud Native Application DevOps Ops Cell Cell Cell Manager

Consume APIs through user-provided services

BW Cluster

BW Studio BW Engine BW Engine BW Engine (design time) TIBCO DevOps BW Admin BW Engine BW Engine BW Engine (run time)

pivotal.io MIGRATING AN ESB TO ACLOUD CLOUD NATIVE NATIVE PLATFORM PLATFORM PIVOTAL WHITE PAPER

PHASE 1 : LIFT AND SHIFT Keeping up a slow and steady pace, this phase preserves the ESB but puts it under the management of the PaaS. You deploy the ESB into the PaaS. Increasingly ESB vendors have moved their offerings to the cloud. SeeTIBCO Business Works Cloud Foundry Edition or mulesoft iPaaS. In fact Gartner defines this as an entirely new category called iPaaS, i.e., a suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud-based processes, services, applications and data within individual or across multiple organizations.

The Pivotal Cloud Foundry edition of TIBCO allows individual TIBCO business processes to be natively scaled and managed by Pivotal Cloud Foundry. From a Pivotal Cloud Foundry perspective the TIBCO business process is treated as a new language with its own buildpack. This is a reasonable middle ground between ESBs and microservices. There are two issues with a cloud enabled ESB like TIBCO. First, the ESB needs to leverage native messaging capabilities (like FTL) that are not available natively in the PaaS. Second, the ESB needs to leverage the managed data backing services natively available on the platform.

Pivotal Cloud Foundry

Apps Cell Cell Cell Manager Cloud Native Application DevOps Ops Cell Cell Cell Manager

TIBCO BW Studio Cell Cell Cell DevOps Container Edition

PHASE 2 : REFACTOR This phase starts to scrape away at the ESB, refactoring services to be microservices oriented. The goal is to make sure that the ESB layer is kept as thin as possible. At this point there are many opportunities to migrate from using the ESB to using the Spring Integration and Spring Cloud frameworks in Pivotal Cloud Foundry to achieve basic transformation, mediation, and routing.

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

There are several common refactorings in this phase:

• Consumer Services Expose APIs with formats/protocols desired by consumers.

• Consumer services transform formats provide sync/async, protocols and composite workflows.

• Provider Services integrate with legacy IT systems, implement required workflow and consume whatever protocol/format is exposed by legacy systems.

• Refactor services incrementally per bounded context, prioritizing the ones that are new or under active development. Standardize consumer APIs over REST/ JSON and reduce the cross-bar architecture complexity by not entertaining a variety of consumer preferences.

• Extend bounded contexts to include legacy app dependencies.

For high performance data intensive workloads the cost of serialization/ deserialization of messages from the enterprise bus may be too high. Consider a binary serialization mechanism like Google protocol buffers or Kyro for internal messaging, APIs, caching, etc across services.

For a graphical UI, leverage Spring Flo for design and visualization of streaming and batch data pipelines. Flo allows you to create real-time streaming and batch pipelines either with the textual shell or the drag and drop interface.

Front-End Applications

Business Services Pivotal Cloud Foundry RESTful APIs Consumer Services Enterprise Service Bus Provider Services

IT Systems and Applications

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

Front-End Applications

Business Services Bounded Content Bounded Content

RESTful APIs Consumer Services Enterprise Service Bus Provider Services

IT Systems and Applications

PHASE 3 : REPLACE This phrase replaces actual code and services in the ESB with newer frameworks, getting closer to the goal of transforming from a centralized ESB to a decentralized microservices approach. As with phrase 2, behavior is largely preserved, but how that behavior is implemented is changed. Spring Integration and its cloud successor Spring Cloud Stream provide successively higher layers of abstraction making it possible to write ESB flows and functions using cloud native architectural constructs leveraging annotations and interfaces to specify business function. Spring Cloud Stream is a combination of Spring Cloud, Spring Boot and Spring Integration where integration modules are Spring Boot apps. The plumbing of putting together channel adapters and flows over message brokers like Kafka and RabbitMQ is done intelligently by the platform. Spring-cloud-dataflow can also orchestrate jobs so batch-processing and stream-processing are all manageable in a consistent way on a unified platform. Spring cloud “tasks” can handlespring- batch jobs as well as simple one-off runnable tasks. This approach does not rely on IDE tools to design the services and an additional step to deploy. Development of integration services is the same as development of any other business logic which eliminates the traditional impedance mismatch associated with ESBs and allows for a faster iteration of feature code. The citizen integration framework like Spring Integration provides developers a familiar Java developer’s way to compose and operate on services.

One language (Java), one runtime (Tomcat) and one CI/CD process on a structured platform results in the holy grail of reduced time to value and increased efficiency.

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

Both and Spring Integration have a vast number of components, modules and adapters to legacy systems that can aid in this transformation and integrate with existing enterprise services. REST APIs from zConnect should be leveraged natively on the mainframe where possible replacing the man-in-middle legacy adapter layer if possible. z/OS Connect enables z/OS systems such as CICS and IMS to provide RESTful APIs and accepts transactional JSON payloads via the WebSphere Liberty app server.

Organizations often consider using Apache Camel at this point. However, unlike Spring Cloud Stream Apache Camel does not provide higher level microservice abstractions for designing flows other than a DSL. Apache Camel is in the same category as Spring Integration in terms of being a lightweight framework alternative to ESBs. Apache Camel like Spring Integration is a low level toolbox of components that can be used to implement EAI patterns.

Orchestrate Composable Data Microservices

HOST

Cloud Foundry Lattice YARN X

Spring Cloud Data Flow

PHASE 4 : TRANSFORM After phase 2 and 3 you are leveraging a lot of Integration patterns, that is, Enterprise Application Integration (EAI) constructs. Any ESB, albeit even light weight cloud native ones, inevitably result in context bleeding and a proliferation of interchange contexts resulting from sharing a canonical data model. Entities and aggregates are outside their bounded context, or, even worse, replicated in other parts of the system in a more generic representation. This adds an extra layer of complexity and often results in less than agile conditions.

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

Phase 4 does away with these EAI patterns replacing their use a pure event driven messaging architecture. This is a decomposition of the ESB integration services based on purpose alignment model to higher order vertically sliced domain based service. The intent is to make each service independent and self-contained. That is, each service becomes a smart endpoint. The service fulfills a contract for a bounded context and is complete in all respects.

In this phase, process orchestration is replaced by choreography. To facilitate this switch-over, the Spring Cloud framework provides an umbrella of Netflix OSS tools that should be used when writing distributed systems. The services implemented with the help of Spring Cloud and the platform are responsible for providing all the qualities of service provided earlier by the ESB.

At this point, the goal is to move all services to a fabric of independently operating, coarsely grained microservices that are choreographed to achieve business function. A user journey now becomes a series of async interactions. In this choreography-driven approach the central controller service is replaced by the asynchronous flow of events over a message bus. These events are picked up by interested services and appropriate actions are taken which may be message enrichment, transformation, etc.

Since business process flows are now transformed to event and activity flows, business activity monitoring becomes critical. Following the pattern of creating smart end-points, compensation of failed transactions and exception actions should be incorporated into business logic. Additional work is needed to ensure that you can monitor and track that the right things have happened.

The decomposition of a monolith to microservices is done by breaking the system into a shared kernel and identifying candidate bounded contexts using techniques like event storming and model-storming. Then, use an Anti-Corruption Layer to ring-fence clearly distinguishable bounded contexts from their neighbors to allow for extraction. Start with the core domain, and then move to other parts of the system according to business value. Transform the monolith using approaches such as Strangler, asset-capture, event-interception and reference-data. One common cycles is to move through the progression of include Shared Kernel -> Customer-Supplier -> Open Host Services -> Published Language. References (ian-cooper, implementing-ddd).

pivotal.io MIGRATING AN ESB TO A CLOUD NATIVE PLATFORM PIVOTAL WHITE PAPER

TL;DR RECOMMENDATIONS Obviously, migrating from an enterprise-wide, centralized approach like using an ESB is a lengthy, complex process with many moving parts. However, understanding the general before and after state, along with prioritizing your projects based on business value, should provide a straight-forward path to making your applications more agile.

We end by summarizing three, key, recommendations for migrating from ESBs to microservices: 1. Where a comprehensive suite of ESB services already exist, follow a phased approach to migrating ESB composite and provider services. Business logic should reside in the actual applications, rather than inside the ESB in the form of complex routing and transformation rules, for example Only fundamental ESB functions like legacy adapters and pure transformation and mediation should be handled by the ESB. Phase 1 is short term, Phase 2 & 3 is medium term and Phase 4 should be the target for longer term transformation. 2. Where existing ESB services do not already exist, start greenfield net new development with a pure microservices based approach, that is, jump to Phase 4. This will accelerate development to target state and generate a collateral of slimmed down domain based replaceable and reusable cloud native services. Support for horizontal concerns will be provided by Cloud Foundry. Integration concerns will be handled by implementing the app with Spring technologies (Spring Cloud Stream, Spring Cloud Data Flow, Spring Batch, Spring Reactor, and so on) and forward looking design patterns like CQRS, event sourcing and accumulate-only data stores. 3. Create sample business process, and app code repositories as well as an internal knowledge base around technologies like Spring Integration, Spring Data, Spring Cloud and Spring Batch. As developers start writing apps on cloud native platforms they need to be equipped in understanding the tradeoffs in writing distributed systems at scale otherwise the result will be distributed balls of mud.

Pivotal’s Cloud Native platform drives software innovation for many of the world’s most admired brands. With millions of developers in communities around the world, Pivotal technology touches billions of users every day. After shaping the software development culture of Silicon Valley’s most valuable companies for over a decade, today Pivotal leads a global technology movement transforming how the world builds software.

Pivotal, Pivotal Cloud Foundry, and Cloud Foundry are trademarks and/or registered trademarks of Pivotal Software, Inc. in the United States and/or other Countries. All other trademarks used herein are the property of their respective owners. © Copyright 2016 Pivotal Software, Inc. All rights reserved. Published in the USA. PVTL-WP-6/16 pivotal.io