by Jeremy H
• January 28, 2020
We’re delving into ESB vs. Microservices. The Enterprise Service Bus (ESB) has reigned for more than a decade as the preferred method for connecting monolithic business applications. However, with digital transformation and cloud-services rising to the forefront – forethinking enterprises are racing to achieve greater agility. They’re doing this by (1) breaking up monolithic applications into “microservices” and (2) loosely connecting them to establish a “pluggable,” service-based infrastructure.
While ESBs continue to play a vital role in connecting monolithic business applications and supporting enterprise IT infrastructures, but the microservices movement is fundamentally changing the way enterprises manage their tech resources.
However, the term “microservices” is often mischaracterized so we’ll explain ESB vs. microservices in simple terms that anyone can understand.
To fully understand ESB vs. microservices, it’s important to look at both technologies separately. We’ll start with a brief explanation of ESB (enterprise service bus) technology.
ESBs establish data connections between monolithic applications. They provide users with a host of pre-built software adapters. ESBs also offer a secure and “pluggable” app integration hub that establishes a communication pathway between essential enterprise business systems. In this way, ESBs eliminate the need for custom-code, point-to-point integrations in many cases – which speeds up system upgrades, facilitates adding/removing applications, and boosts overall business agility and growth capabilities.
*For a deeper exploration ESB technology, read our in-depth guide to ESB here.
Key takeaway: The most important thing to remember about ESBs for this guide is that they focus on connecting the monolithic applications that serve an enterprise – and each of these applications performs a variety of services.
Did you know you can generate a full-featured, documented, and secure REST API in minutes using DreamFactory? Sign up for our free 14 day hosted trial to learn how! Our guided tour will show you how to create an API using an example MySQL database provided to you as part of the trial!
Access Your No-Code APIs Now
The microservices architecture is an approach to building applications that focuses on breaking down monolithic applications into independent, but loosely-connected “microservices.” These microservices work together as a “pluggable” structure you can use to form an enterprise IT infrastructure.
James Lewis and Martin Fowler gave the seminal definition of microservices in their authoritative piece, “Microservices”:
“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
Key takeaway: Whereas ESB technology builds an IT infrastructure by connecting applications (that perform multiple interdependent services), the microservices architecture connects a “hive” of “pluggable,” autonomously-running services.
In monolithic applications, an ESB connects all the features and functionality of each application run interdependently within a single instance. The monolith houses all of the code for each of the functions and services it performs.
Monoliths start small, but as requirements grow, development teams bolt new functions on top of each. This happens until the monolith becomes interdependent, complex and difficult to untangle. This interdependence is problematic when making upgrades or changes. The code from different development teams working on different areas of the application invariably conflicts and collides. Ultimately, this happens until it’s impossible to manage application improvements.
Eventually, it’s necessary to recode the entire application from scratch. Doing this is costly and could detract from other business priorities. Alternatively, you can dismantle the monolith into its component parts, and create a microservices architecture.
A microservices architecture is different because the application exists as a network of small, autonomously running services. These microservices communicate with each other to create the larger application – usually by sending HTTP requests to their respective APIs.
In this way, the microservices application is a honeycomb of “pluggable” services. They allow you to quickly develop, add, or remove features without affecting the larger whole.
Key takeaway: The microservices application architecture breaks down the traditional, monolithic application into its component parts because doing this allows them to run securely, and independently from each other. This provides a more agile framework for enterprise IT infrastructures because you can quickly, and inexpensively make adjustments to your suite of services in response to changing business requirements.
In this paragraph we’ll define the characteristics of a microservices application:
For a succinct description of how microservices architecture works, we’ll refer to this guide from the DreamFactory team, “Designing Web-Scale Workloads with Microservices”:
“Microservices are not just code modules or libraries – they contain everything from the operating system, platform, framework, runtime and dependencies, packaged as one unit of execution. Each microservice is an independent, autonomous process with no dependency on other microservices. It doesn’t even know or acknowledge the existence of other microservices. Microservices communicate with each other through language and platform-agnostic application programming interfaces (APIs). These APIs are typically exposed as REST endpoints, WebHooks, or can be invoked via lightweight messaging protocols such as RabbitMQ. They are loosely coupled with each other to avoid synchronous and blocking-calls whenever possible.”
A common architectural design pattern for a microservices architecture is to implement HTTP/REST with JSON. Microservices API connections are secure and reliable, but they are kept as “loose” as possible to facilitate the “pluggability” of services. Loose connections also prevent one service failure from negatively affecting the whole application.
As for running and managing a microservices architecture, containerized environments and container orchestration are an excellent fit. By running each microservice in a separate container that houses the minimum-required executables and libraries for the service, each microservice is contained within a distinct, isolated environment. Integration with other microservices occurs by answering calls through a kernel or container orchestration tool.
Docker is a popular solution for containerized environment and container orchestration. Kubernetes is also growing in popularity for container orchestration.
Key takeways: The secret to integrating a microservices architecture lies in APIs exposed as REST/HTTP endpoints alongside JSON. Containerized environments and container orchestration also play an important role in running, managing, and integrating individual microservices.
iPaaS (integration platform as a service) tools that provide RESTful services for creating mobile, web, and IoT applications – such the DreamFactory iPaaS – facilitate the building of a microservices environment because they automate the labor required to establish data connections between separate microservices.
DreamFactory offers server-side scripting and API-driven administration features that help developers rapidly establish secure, reliable connections between the individual services that comprise their microservices architecture. From a technical perspective, the DreamFactory iPaaS allows microservices developers to:
With the rise of microservices, enterprises now have four paths to establish an IT infrastructure:
Let’s look at three real-world examples of the last two microservices-based infrastructure paths into action:
Netflix began adopting the microservices model in 2009 after scaling challenges led to frequent service outages. They were breaking down their monolithic application structure before the term microservices had even been coined, and their transformation began.
Netflix began by moving its non-customer facing movie encoding system to the Amazon AWS cloud, and over the two years, the platform moved all of its customer-facing web services to AWS. By 2012 the transition was complete, and Netflix consisted of hundreds of interconnected, cloud-based microservices. Netflix’s willingness to embrace the microservices movement is one of the most important contributors to the platform’s extraordinary growth.
SoundCloud initially developed its platform as a monolithic Ruby on Rails application nicknamed “the Mothership.” The Mothership allowed hundreds of thousands of musicians to collaborate and share their music. However, SoundCloud faced scaling challenges that it couldn’t resolve with band-aid patches.
Instead of dismantling the Mothership completely, SoundCloud simply stopped adding features. They started using separate microservices to add the new functionality they required. Gradually, SoundCloud started removing different functions from the monolith, replacing them with microservices. This has allowed SoundCloud to grow more freely with production-ready features and shorter feedback cycles.
Like SoundCloud and Netflix, Uber started as a monolithic application. As Uber experienced rapid growth, it experienced some struggles. They struggled to add new features, resolve bugs, and overcome technical debt in a single software depository (storage location for software packages). Moreover, developers required in-depth knowledge and experience with existing systems just to make a single change.
Drawing inspiration from Netflix and other rapid-growth companies, Uber decided to divide its monolithic application into multiple codebases to create a microservices architecture. Uber chose the microservices approach with the goals of “promoting clear ownership, offering better organizational scalability, and providing more resilience and fault tolerance through [its] commitment to microservices.”
In all the examples above, developers began with a monolithic application that they later divide into microservices after facing scaling challenges. Interestingly, this “monolith-first” approach tends to result in greater success in comparisson to a “microservices-first” approach, according to microservices thought-leader Martin Fowler:
“As I hear stories about teams using a microservices architecture, I’ve noticed a common pattern. (1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up. (2) Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. This pattern has led many of my colleagues to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.”
Whether you’re using a strictly microservice architecture or an ESB/microservice hybrid, we’ll walk through how incorporating microservices into your operational strategy brings great benefits. Here’s what you can gain:
Since each feature or service of a microservice architecture is self-contained and autonomous, it’s easy to scale the individual components up or down in response to changing requirements.
As long as you have a way to connect and integrate the microservices together (usually with an iPaaS), you can program them in different languages, use disparate technology, and run them on different platforms. This makes development easier because (1) your team has the freedom to develop new microservices with their existing skillsets; and (2) you can choose whatever implementation technology best fits the performance requirements of the microservice.
Since each microservice can run independently, there is less chance that the failure of one service will result in the failure of the entire ecosystem. Even when one microservice synchronously invokes another. Using features like circuit breaker will stop the failure of one service from cascading throughout the application. This prevents resource exhaustion while the calling service waits for the failed service to respond – thus bolstering the resilience of the entire ecosystem.
Because microservices run in isolation from each other, sensitive information – like health data, financial data, business records, and other confidential information – is easier for developers to contain and protect from hacks and inadvertent exposure. Since developers maintain full control over access to the data in each microservice, achieving HIPAA and GDPR compliance is a faster and less expensive proposition.
You can break up the development of a microservices architecture across independently working teams – or outsource the development of specific services. You won’t have to wait for each team to finish before seeing the results of each microservice in action.
A microservice architecture frees developers to only worry about the complexity of the individual service they are building. This compartmentalization facilitates the perfection of each component and it also makes it easier to break down the management of large application projects into smaller, more manageable jobs.
The microservices each team is building dictates the team’s originization. Teams tend to be dramatically smaller, easier to manage, and can focus more on the processes they’re building.
Microservices support a CI/CD/CD (continuous integration/continuous delivery/continuous deployment) development cycle. Microservices have less dependency on each other. This means you can ship software and services faster before finishing your complete vision for the product. This allows you to update the software with new features over time, as the development of different microservices completes.
With microservices, enterprises can experiment with new features – and quickly delete them if they don’t work . They can do this without posing a threat to the larger application ecosystem, and without incurring substantial business risks. This furthermore translates into greater business agility because enterprises can test new tech and services without investing a tremendous amount of time, labor, and money.
If a new technology or security threats appear, the microservices architecture allows you to quickly update the specific service affected.
The microservices development philosophy supports quick and fluid responses to the needs of users. The speed at which developers can deploy highly focused upgrades supports the modern DevOps philosophy of greater communication and collaboration among users, operational engineers, and software developers.
“If it ain’t broke, don’t fix it,” is a maxim that certainly applies here. Therefore, If your enterprise is running smoothly with an ESB and a suite of connected monolithic applications – there’s no reason to embrace the microservices revolution (yet).
On the other hand, here are some indicators that you’re ready for microservices:
In conclusion, If you’re ready to embrace microservices movement, consider using an iPaaS (integration platform as a service) platform. You’ll be able to incorporate new microservices into your IT infrastructure while leaving your monolithic applications intact. From there, embark on the gradual process of isolating application functions into flexible, agile, and scalable cloud-based microservices.
Whether you’re trying to maximize the efficiency and agility of your enterprise IT infrastructure or building a new SaaS platform – the DreamFactory iPaaS offers a point-and-click, no-code interface that simplifies the process of building a microservices application architecture. Try DreamFactory for free and start building APIs for microservices immediately.
What Are Containerized Microservices, Designing Web-Scale Workloads with Microservices, MicroservicesDesigning Web-Scale Workloads with Microservices, Microservices Webinar Recap
Join the DreamFactory newsletter list.