A service mesh dictates how separate parts of a microservices application share data with each other, a service mesh is a dedicated infrastructure layer for enabling service-to-service comms between different microservices.
There is actually not a unified definition for the term microservices. A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:
- Different services that communicate over a network using standard protocols like HTTP
- They are centred around the capabilities of the business
- There is no tie to a specific types of databases, programming languages or hardware
- They are message-enabled and generally small in size
If you think of each part of an app, referred to as a ‘service’ relies on other app services to give end-users what they need. For example, if a client of an internet-based retail website wants to purchase something, they need to whether if the item is in stock or not.
The service that talks with the businesses stock database has to talk with the product’s webpage, which in turn has to talk with the website’s shopping cart. To aid future sales, the online store may also build a component or ‘service’ that presents users with recommendations of other products they may purchase.
This recommendations service needs to talk to the database of products to facilitate creation of these recommendations, potentially using the same database calls as the initial call to the product page required.
Most modern applications are created this way, lots of services and calls, each performing an independent, isolated function. This can lead to greater hardware loads and requirements as these services work independently, duplicating effort.
Enter the service mesh
A service mesh optimizes these calls by controlling the requests between these isolated services and optimizing them along the way. This doesn’t sound revolutionary – apps already have ways in which different parts communicate, but a service mesh dictates how these micro services communicate – by removing the service-to-service communication and
Modern applications are often broken down in this way, as a network of services each performing a specific business function. In order to execute its function, one service might need to request data from several other services. But what if some services get overloaded with requests, like the retailer’s inventory database? This is where a service mesh comes in—it routes requests from one service to the next, optimizing how all the moving parts work together.
A service mesh doesn’t introduce new functionality to an app’s runtime environment—apps in any architecture have always needed rules to specify how requests get from point A to point B. What’s different about a service mesh is that it takes the logic governing service-to-service communication out of the individual services and moves an infrastructure layer.
So – why now?
Modern businesses are evolving, as is their requirement to scale, be flexible and be agile. Faster, more readily deployable applications are required due as dictated by technology-centric business models.
The old-fashioned methods of creating Monolithic – large, difficult to change and created in a single platform (sometimes called spaghetti) applications are disappearing due to the modern requirement of faster changes in an agile, cloud-first environment.
A monolithic application may potentially by easier to build, but microservices architecture is far superior in creating applications that evolve and handle many functions in a single app.
This is the year of modern practices – cloud-first business strategies and dynamic, fast moving business models. Covid has taught us that business plans can and may have to change rapidly to accommodate for totally unforeseen circumstances and microservices are designed with change in mind.