From the Enterprise Service Bus to Microservices
Dealing with legacy is one of the most common areas of conversation we have around “cloud native” and Pivotal Cloud Foundry. I wrote up a basic framing for how to think of legacy applications last year as part of my cloud-native journey series, and in reviewing talks for the upcoming SpringOne Platform conference I’ve noticed that it’ll be one of the topics at that event this August.
Pivotal architect Rohit Kelapure has been working on this topic a lot and has written a white paper on migrating from Enterprise Service Bus (ESB)-based legacy architectures. After working with him on the paper a tad, I had a few questions whose answers I thought would be helpful to share for all those folks who ask about this topic.
Coté: Technology choices often start with the best of intentions. Few people want to make a “bad” system. What’s driven so many organizations to choose ESBs?
Rohit: ESBs are a response to enterprise needs around service integration, audit, transformation, business impact traceability, composability, data transformation and a central point for governance. The promise of SOA was to be fulfilled by an ESB. Unfortunately, ESBs ultimately got supplanted by enterprise vendors that created all-you-can-eat expensive to deploy and operate monolithic software appliances that developers hated. ESBs have proven to be the wrong manifestation of the useful Enterprise Integration Patterns patterns laid down by Gregory Hohpe and Bobby Woolf.
Coté: In microservices, there’s always lots of talk about using Conway’s Law — “a system’s design is a copy of the organization’s communication structure” — to your advantage. If your software ends up mimicking your organization structure (and, thus, the “communication structure”), why not organize teams to match your desired design? Thus, if you had a “catalog” and “customer” microservice, you’d have teams for each of those. First, have you seen that this actually happens? Second, how are you seeing organizations transition — do they just overnight rearrange people, or is it more gradual?
Rohit: Organizations transitions in a variety of ways most doing in a gradual fashion. Only if there is a top level C-suite buy-in will an inverse Conway maneuver work. A lot of companies especially middle management say the right things; however when it comes to doing, they fall back to their older more traditional ways of silos and ticket based processes. There needs to be a genuine disruptor to the enterprise which causes and justifies the change to organization hierarchy. The more dire the disruption the faster the transformation.
The people and process part of the transition to microservices-based share-nothing architectures is the most difficult. Often an external change agent needs to be injected to enable the change and act as a catalyst to the transformation. One way a change like this is affected is via an island deployment i.e. the creation of a Center Of Excellence that does not have any of the baggage of the parent and can create its own distinct culture for the full stack of technology.
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 — Rohit Kelapure
Coté: In your paper, you say that ESBs are better at “choreography” than microservices: “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.” First, what do you mean by “choreography,” can you give an example? Second, why does a microservices approach fall short (i.e., what is it lacking?)
Rohit: The difference is best explained by Steve Johns: “orchestrations are ‘fixed’ in that there is a described set of steps and decisions. ‘Choreographies,’ should be, more goal oriented and be about the coordination of resources towards that goal.”
When microservices are choreographed they collaborate together to achieve a particular business capability. The interaction model of the services needs to be clearly defined and understood. All the failure models and the consistency models need to be implemented correctly to ensure that transactionality and consistency of data are maintained. When there is no central controller the services need to collaborate together. The model of interaction between services moves from a command-control style to an iterative collaborative model. Without proper rules and idioms of engagement, a collaborative style of interaction will fail.
Coté: When should someone stay with an ESB? Or, should they always migrate from it?
Rohit: This is a business decision. It is a cost-benefit analysis of whether the code and business logic locked in the ESB is strategic and open for modification and extension. On the other hand, if the ESB logic and code has been stabilized and there is no strategic advantage gained by separating them then there is no need to migrate. In my experience, if your code needs to be more flexible and have the ability to change quickly — you want to be “more agile” — a microservices approach will have better results than a traditional ESB.
Coté: You describe five phases of migrating from an ESB approach to a microservices approach. It seems like the first three phases are largely about changing the underlying ESB implementation, but keeping the same behavior in the code. Thus, there will be little tangible benefits until you get to the later phases where you’re replacing code and then replacing the ESB altogether. Is this right, or are there benefits you’ll start seeing right away as you migrate?
Rohit: You will start seeing the operational benefits in the beginning of faster deployment and better resiliency. As more of the ESB logic gets migrated you start getting the advantages of microservices where developers ramp up faster, develop and deliver code rapidly and service logic can fit in one head. So the operation benefits give way to a more exponential benefits afforded by the simplicity provided by microservices.
Coté: At one point, you type “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.” To me, this reads as if you have less moving parts, you have less variability in your system. You want to reduce variability so that you can move fast and be more agile (with less to worry about, you have, well, less to worry about that can slow you down). How can organizations make sure that in their switchover to microservices they keep as few moving parts as possible and thus achieve that goal?
Rohit: Codify these principles of one language, one runtime and one CI/CD process as code. Provide code repositories and attached pipelines that bake in these idioms from the start i.e. make doing the right thing the default. If developers want to deviate from the default they take on the burden of operationalizing the services and developing them according to the right idioms and guidelines laid down by the group.
If you’re looking to increase your architecture’s agility with microservices, be sure to check out Rohit’s full paper. Also, you’ll get the chance to hear from and talk with him and many other people who are working through this kind of transformation at the SpringOne Platform conference this August 1st to 2nd. Hopefully, we’ll see you there!
