We are the Trusted Partner for America's
#2 largest private company
When it comes to meeting service level objectives like latency and uptime, the ability to manage traffic between services is critical. This is because it allows the operations team to implement operational patterns like circuit breaking or backpressure to compensate for poorly behaving services.
Service meshes can provide this type of traffic control. Because their primary function is to manage service-to-service communication, they can provide such features rather easily. However, because they are designed to effectively connect a source call to its optimal destination service instance, these traffic control features are destination oriented.
In other words, service meshes are well suited to balance individual calls across a number of destination instances, but rather unsuitable to control traffic from a number of sources to an individual destination or to control traffic across an entire service landscape, for that matter.
To some extent, monolithic applications are protected by their single address space. Once a monolith has been broken up into microservices, however, the network becomes a substantial attack surface. More services mean more network traffic, which, for hackers, means more opportunities to attack the flow of information. This is the reason why service meshes, provide the ability (and infrastructure) to secure network calls. The security-related benefits of service mesh revolve around three core areas:
Istio, for example, provides developers with a certificate authority to manage keys and certificates. With Istio, you can generate certificates for each service and to transparently manage their distribution, rotation, and revocation. With these capabilities, services can authenticate each other and implement proper access controls.
Decomposing an application into a number of microservices doesn’t automatically turn it into a network of independent services. The application still acts as the single, stand-alone application it was before it has merely become distributed.
Its microservices typically share the same code repository and are part of a single architectural blueprint. They are less like services shared across multiple applications than components of their parent application.