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.
Here’s what you’ll learn in this guide:
What Is an ESB?
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.
What are Microservices?
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.
Comparing Microservices and Monolithic Applications
Monolithic Applications: ESB vs. Microservices
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.
Microservices
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.
Defining Characteristics of Microservices
In this paragraph we’ll define the characteristics of a microservices application:
- Exists as a network of connected, modular components that perform separate functions or “services” within the application.
- Each function or service meets a specific business need.
- Each microservice operates independently, so it’s easy to add, update, delete or switch out services without affecting the rest of the application.
- The connected microservices that make up an application can be written in different programming languages.
- Microservices are deployable on cloud servers and data centers, making it easy to quickly integrate new cloud-based microservices into an application.
- When deployed on a scalable cloud platform, the latest cloud-based SaaS services are immediately available to your enterprise.
- Adding new microservices (or application functionality) does not affect the operation of other functions, so upgrades are simpler and easier to perform.
How Microservices Architecture Works
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.”
The Best Path to Take
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.
Building a Microservices Application with iPaaS
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:
- Connect with data sources and instantly extract secure, customizable REST APIs without writing a single line of code.
- Quickly integrate the DreamFactory runtime environment with web-scale apps.
- Declare data source endpoints that are invoked at runtime.
- Update database endpoints without altering any code.
- Define specific business logic for data sources.
- Embed basic validation and error handling into DreamFactory without altering the application logic.
- Launch DreamFactory as multiple containers deployed on Swarm, Kubernetes, or Apache Mesos.
- Integrate your DreamFactory containers with your microservices on Docker.
- Quickly add/remove functionality by integrating different cloud-based SaaS microservices to your app infrastructure.
Microservices in Action: Real-World Examples
With the rise of microservices, enterprises now have four paths to establish an IT infrastructure:
- A single monolithic application: A single monolithic application for all business systems (highly inefficient).
- Multiple monolithic applications: An array of monolithic applications connected through an ESB – the traditional method (the prevailing model).
- Hybrid ESB/microservices: A mix of monolithic applications and cloud-based microservices connected via ESB and iPaaS (where enterprises are currently headed).
- Full microservices: A complete microservices architecture where each business function runs as a compartmentalized, yet integrated service (the future).
Let’s look at three real-world examples of the last two microservices-based infrastructure paths into action:
1. Netflix
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.
2. SoundCloud
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.
3. Uber
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.”
Monolith-First or Microservices-First?
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.”
The Microservices Advantage
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:
Highly scalable: ESB vs. Microservices
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.
Platform and language flexibility
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.
Improved reliability
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.
Data security and compliance
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.
Independent teams can develop each microservice
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.
Contained complexity
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.
Smaller, and focused development teams:
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.
Faster time to market
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.
Greater business agility
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.
Future-proofing benefits
If a new technology or security threats appear, the microservices architecture allows you to quickly update the specific service affected.
Support for the DevOps philosophy
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.
Are Microservices Right for You?
“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:
- Growth hurdles: You’re facing growth hurdles because of bloated, monolithic applications that aren’t flexible or scalable enough to fulfill your changing business requirements.
- Scaling challenges: You need the scaling flexibility of a cloud-based ecosystem that can handle real-time data integrations and massive data volume.
- Building IoT networks: You’re building an IoT network with thousands or millions of IoT endpoints and the massive horizontal scaling requirements and large-volume data demands require cloud-based solutions.
- Advanced BI: You want to tap into more advanced ML and AI business intelligence that requires the powerful computation abilities of a cloud-based server.
- More focused app development: You’re building an application or software-as-a-service solution that provides a variety of services, but you want to focus your time on building one unique microservice. You can complete the application by adding the prebuilt microservices that support it.
- Save money and time: You want to increase business agility, and save money and time when updating your IT infrastructure.
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.
DreamFactory: Automated, No-Code, API Generation for Your Microservices Architecture
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.
Related Articles:
What Are Containerized Microservices, Designing Web-Scale Workloads with Microservices, MicroservicesDesigning Web-Scale Workloads with Microservices, Microservices Webinar Recap