From enterprise service bus to microservices

The present and future of data integration in the cloud.

By Timothy McGovern
March 22, 2017
Tatttoo Machines. Tatttoo Machines. (source: Tony Alter on Flickr)

In this episode of the O’Reilly podcast, Jon Bruner sat down with Rahul Kamdar, director of product management and strategy at TIBCO Software. They discussed the shift from the centralized enterprise service bus (ESB) to a distributed data architecture based on microservices, APIs, and cloud-native applications.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Here are some highlights from their conversation:

Cheaper, more scalable, and open to broader interaction

In some ways, [microservices] are derived from the traditional service oriented architecture (SOA) style of services. But really, they represent the niche of that architecture, in terms of the set of practices that you would follow to build the microservices so they are easy to develop, and less expensive to manage, operate, and deploy. Microservices need to be elastic and scalable when taken to concepts such as the cloud.

The second aspect is obviously around APIs—something that is key to companies pretty much all over the world right now—both from a technology standpoint as well as from a business standpoint. APIs extend the concept of microservices to make them available for external consumers in the form of the APIs, which is really defining the services in a standardized format and making them available in a consumable manner for developers and third-party partners alike.

Changing your architecture means changing your culture

For most users and developers who are moving toward this kind of architecture, I think the first thing that is really, really important is that it’s critical to embrace or accept the fact that change is required not only on the technology side, but in many cases, on the organization or the culture side. Not only do you break down your applications from large, what are traditionally called monolithic applications, but, really you break down your teams into more functional groups that are potentially working in a very agile way—an agile scrum way in many cases—so they can reach their end results a lot more quickly, a lot more easily, and at the same time, focus on a very specific common functional set of applications they want to build.

What’s coming down the road?

In the new world, you’re still going to build distributor applications and architecture that supports them, but at the same time, the set of different systems, the set of different data sources and applications that you still need to talk to, is going to remain, and probably get more complex because of hybrid deployments. Some customers who have always been on-premise or in a private datacenter are starting to deploy multiple clouds, or in some cases, something is on a private cloud, something is on a public cloud, and something is on third-party partners. They still want all their systems to be able to talk to each other.

Integration by itself is starting to become even more key, but how it’s being done is definitely changing. ESBs are mostly for the traditional architectures that still remain, but all the new ones are likely to adopt a more distributed integration architecture.

This post is part of a collaboration between O’Reilly and TIBCO. See our statement of editorial independence.

Post topics: Data science