.png){kind=small}
.png){kind=small}
Before start the explanations about Service Mesh infrastructure, let’s understand a little bit about what we have created before, as software architects and developers.
I think it is essential to know why Service Mesh might be useful for you.
We’ll talk a little bit about Software Architecture History. I promise it will be rapid, but it will be worth it.
Let’s analyze the image below
There are different architectures models in the Timeline, including the MVC Pattern which one is present in our architecture today.
SOA and EDA were popularized in 2000 and 2003, respectively; when things started to be distributed.
We started at that time to break things into small pieces of software, for several reasons.
And finally Microservices and Serverless, in 2013 and 2015 respectively, when different approaches about software development were coming.
Conway’s law and Inverse Conway Maneuver sprung up to the scene to explain how to work with Software Architecture in terms of business and Teams.
There is typical behavior if we look at this Timeline, we are trying to divide our software pieces into small and smaller parts, as small as we can.
But, why is it important or related to Service Mesh Infrastructure?
Microservices are distributed systems, and distributed systems means to handle network problems. That is exactly what Service Mesh Infrastructure can help us. Abstracting network issues from developers.
In a nutshell.
Service Mesh can be defined as a dedicated infrastructure to handle a high volume of traffic based in IPC (inter-process communication). In a microservices architecture, is usually called East-West Traffic.
In a few words, service mesh can be considered a “layer” to abstract network for services communications.
These abstractions solve the most part of the network handlings like Load Balancing, Circuit Breakers, Retries, Timeout, Smart Routing which can enable advanced deployment techniques like Canary Releases, Dark Launches, and others.
Then, we can take off these responsibilities from our application code. Also, we can remove these roles from developers, and it is very important because developers should code for the business, not for infrastructure requirements.
Another important characteristic of Service Mesh is Telemetry, some implementations integrate with Jaeger and Prometheus easily.
Famous libraries in the Java ecosystem related to network handlings like Netflix Ribbon, Hystrix and Eureka can be replaced for the Service Mesh implementations like ISTIO.
In general, in the Microservices Architecture, service-to-service communication is quite complex, involving different communications patterns like REST and gRPC over HTTP or AMQP for asynchronous and durable communications.
As we can see, microservices are distributed systems, that is the reason why Service Mesh Infrastructure fits very well.
Let’s look in a simple and pretty standard Microservices Architecture:
Standard Microservices ArchitectureThere are some important things to look here.
North & South Traffic
North-South traffic usually happens between different networks look at the image Network A and Network B. This kind of traffic comes from outside our infrastructure, our clients, and this traffic is not trusted because the external network is out of our control.
We need heavy security here, that’s our Gateway to protect our applications.
Usually, we have an API Platform to manage our external APIs, where API Management techniques and processes can help us with this task.
East & West Traffic
On the other hand, the East-West traffic happens in general on the same network, as we saw before, normally it is called service-to-service communication or IPC.
That is the place where Service Mesh lives.gRPC
is a very interesting framework if you are looking for high through put applications or service-to-service communications.
Conclusions
Service Mesh is an interesting thing you are trying to play with Microservices Architecture, but I strongly recommended you to understand a little deeper before adding Service Mesh in your Architecture Stack.
There is no silver bullet when you think about Software Architecture but we as Software Architect, Developers and other need to understand and propose the right solution considering the company context.
Access the original text here.
