If you were to make a list of tech buzzwords that are trending today, it would likely include three terms that start with service: Service mesh, Service Fabric and service bus.
These terms all sound similar. And they are all important concepts to understand if you are adopting microservices, API-driven architectures and cloud-native computing in general.
That said, these three terms each mean different things. To unpack those differences and clarify what a service mesh is, what Service Fabric is and what a service bus is, let’s compare and contrast these terms and concepts.
What is a service mesh?
Service mesh is an infrastructure layer that makes service-to-service communication fast, secure and reliable. In the cloud-native model, an application might contain hundreds of services. Each of these services might be powered by thousands of instances, and each instance might be in a steadily changing state. So, communication among these services is generally complex. A dedicated communication layer is imperative to manage and ensure end-to-end reliability. It is implemented as an array of network proxies deployed alongside the application code.
Why service mesh?
In modern cloud-native applications, microservices are combined with containers and an orchestration layer (like Kubernetes). Though the trio combined performs well for scaling and management in cloud environments, there was still some complexity when dealing with hundreds of services. This complexity inspired the need for a dedicated layer to handle service-to-service communication. This dedicated layer is called a service mesh.
How does it work?
The service mesh manages the complexity of reliably delivering requests using an array of powerful techniques. Some of the techniques include latency-aware load balancing, circuit-breaking, eventually consistent service discovery, retry logic, and deadlines. The service mesh is quite analogous to TCP/IP, because the service mesh abstracts the delivery of requests between services the same way that the TCP stack abstracts the delivery of bytes between network endpoints. Like TCP, the service mesh also doesn’t care about the payload or the way it is encoded. But unlike TCP, the service mesh goes beyond “just make it work.” It is committed to providing uniform visibility and control to the application runtime.
What is a service bus?
A service bus, or enterprise service bus (ESB) is a middleware tool that distributes work among the connected components of an application. It is like a message queue that manages data transactions throughout the application. A service bus provides a uniform means of steering work and unifies the different ways in which the application components exchange information. It can be used in distributed computing as well as in component integration.
What does the service bus do?
- It helps the components of the application subscribe to messages based on business policy rules.
- Changing and adding components to an application becomes easier with a service bus as it controls the way that messages move across the application.
- A service bus has full visibility into the application, which makes it easier to enforce security compliance.
- The queues and topics of a service bus help to build reliable applications by better managing the application logic.
What is Service Fabric?
Last but not least is Service Fabric (which we capitalize because it’s the name of a specific service offering in the Azure cloud).
When developing microservices, you have to create a way for the services to communicate with each other. Here, communication is not just about HTTP. Sometimes you will need middleware to coordinate on data consistency. This is where the Azure Service Fabric programming model comes in. It enables you to build these functionalities without using middleware.
What does Service Fabric actually do?
Azure Service Fabric is more than just a networking or communication platform. It provides a programming model where you can actually write the services that you run on Service Fabric, and manage them from the same platform. The programming model is a basic skeleton code within which you can define your business logic. The model was created as Azure’s way to simplify the development of microservices.
The technology enables multiple nodes to be pooled together to deliver services in a scalable manner. All the nodes replicate synchronously and ensure that they have an up-to-date copy of the state of the service. This eliminates the need for shared storage. When a persistent state is needed, an external storage service such as Azure Storage or Azure SQL Database is used.
| Service Bus | Service Mesh | Service Fabric |
|---|---|---|
| A service bus is middleware from the previous service-oriented architecture (SOA) era. An enterprise service bus (ESB) directs messages along a particular route between the application components based on business policies. | A service mesh is an infrastructure layer to handle service-to-service communication in microservices. This enables greater scalability in service-to-service communication. | Service Fabric is a commercial solution from Microsoft Azure which lets you write the services you want to run without having to handle the underlying infrastructure. |
| It gives you visibility into the application and makes code modification somewhat easier than in a monolithic application. | It provides uniform visibility and control into the application runtime, and is the communication model of choice for modern distributed applications. | It helps you build application functionality quickly without using middleware. |
| It can provide load balancing and failover support. Though built for enterprise applications, it has limitations when scaled to very high volumes. | Service mesh imparts some critical capabilities, including service discovery, encryption, load balancing, observability, traceability, authentication, and support for circuit breaker patterns. | Azure Service Fabric is a complete microservice management platform on its own. It lets you create and run services on the Azure cloud, on-premises, or on other cloud platforms. |
Conclusion
In summary, an ESB is a shade better than a monolithic application that doesn’t separate application logic. However, a service mesh is what organizations need as they transition to running cloud-native applications. If you’d like an end-to-end solution and don’t mind an opinionated cloud vendor’s approach, Azure Service Fabric is a good fit.
Like any other component of cloud-based infrastructure, a service mesh is vulnerable to external attacks and internal vulnerabilities, too. But if you are using an end-to-end cybersecurity solution like Twistlock, you don’t have to worry about these vulnerabilities. Twistlock makes sense when talking about Azure Service Fabric, because Microsoft allows customers to run containerized services within Service Fabric, and Twistlock can help you monitor and protect these containerized services. The Twistlock Console (the central dashboard) is deployed as a Replication Controller, and the Twistlock Defenders are deployed within a DaemonSet. Whether you choose a service mesh or Azure Service Fabric (or even both) to run your microservices, Twistlock can protect your containers and applications.
