Some Basics of Service Mesh

What Is a Service Mesh?

Applications may be made more visible, dependable, and secure with the use of a service mesh. Instead of the application layer, these features are offered at the platform layer.

A service mesh is often implemented as a collection of sidecar-shaped network proxies, with application code controlling their operation. The proxies control inter-microservice communication and act as a gateway for adding service mesh functionality. The proxies work together to create a service mesh's data plane, which is managed as a scalable unit from the control plane.

Service meshes have become more and more well-liked as a result of the extensive use of cloud-native apps. A cloud-native application may have thousands of service instances and hundreds of services. These instances are often run under Kubernetes management, are dynamically scheduled on physical nodes, and have an ever-changing state. This greatly complicates service-to-service communication and has a direct impact on how an application behaves during runtime.

?With the help of service mesh technology, it is feasible to control this intricate inter-service communication and guarantee its dependability, security, and overall performance.

Service Mesh Benefits and Drawbacks

Service meshes have certain advantages but also some disadvantages when it comes to controlling communication between services. The following are some benefits of service meshes:

• Both containers and microservices simplify service-to-service communication.
• Since communication failures happen within their infrastructure layer, they are simpler to diagnose.
• Applications can be developed, tested, and deployed more quickly.
• Network services may be efficiently managed when sidecars are used in conjunction with container clusters.
• The security features supported by service meshes include encryption, authentication, and authorization.

Some drawbacks of service mesh are:

• Runtime instances can be raised by using a service mesh.
• There is an additional step involved in communication since the service call must first go via a sidecar proxy.
• Service meshes do not facilitate system or service integration.
• They avoid talking about things like routing type or transformation mapping.

Service Mesh Architecture and Concepts

There is a unique terminology for the functions and components of service meshes:

• A service mesh design often works in conjunction with a container orchestrator like Kubernetes or Nomad.
• Sidecar proxies—to transport traffic between the containers they run with, they operate alongside each pod or instance and interact with one another. Through the orchestration framework, they are controlled.
• Services and instances—Microservices are executed in instances (or pods). Scalable services fault-tolerant replicas of the instances, are often how clients reach the instances.
• Service discovery—Instances must locate accessible instances of the services they must use. A DNS lookup is normally required for this.
• Load balancing—Service meshes can also offer load balancing for the application layer, but orchestration frameworks often provide it for the transport layer (Layer 4) and (Layer 7).
• Encryption—service Meshes can encrypt and decode requests and answers. Reusing existing connections is given priority, which reduces the need to make new ones and boosts efficiency. Usually, sidecar proxies generate the keys and certificates that are used to encrypt traffic via mutual TLS, which is generated by the public key infrastructure.
• Authentication and authorization. Only legitimate requests may be sent to instances thanks to the service mesh's ability to authorize and authenticate requests coming from both inside and outside the app.
• Circuit-breaker pattern—This entails separating harmful situations and, if necessary, reintroducing them gradually.

The component of a service mesh that controls network traffic between instances is called the data plane. The configurations that control the data plane are created and deployed by the control plane. A command-line interface, an API, and a graphical user interface are often included (or may be connected to).

How a Service MeshWorks

Service meshes don't give an application's runtime environment any additional features. Applications need rules to specify how requests are conveyed in any architecture. Because they isolate the logic that controls service-to-service communication to an infrastructure layer, service meshes are distinct from other communication mechanisms (as opposed to individual services).

This is accomplished by integrating a service mesh as a collection of network proxies into an application.

For business-related devices, proxies are frequently used to access websites. Typically, a company's web proxy receives requests for a web page and screens them for security flaws before sending the requests to the host server. Before returning to the user, responses from the page are also forwarded to the proxy for security checks.

Because they operate in addition to microservices rather than as part of them, proxies in a service mesh are also known as sidecars. Within their infrastructure layer, they transfer requests across microservices. The proxies work together to build a mesh-like network.

If you don't have a service mesh, you must program each microservice with the logic that controls interservice communication. This not only wastes a lot of your time since the logic regulating service-to-service communication is concealed inside the services, but it also makes it more challenging to identify communication issues.

Zero-Trust Security and Service Mesh

A major challenge for cloud-native apps is security. A zero-trust strategy is being adopted by many enterprises, which is ideal for a cloud-native environment. The network perimeter is not considered in the zero trust security concept. It needs continual authentication and verification of all communication between application components as well as external communication since it does not trust any entity, even if it is "within" the network.

This is the logic behind all the services in the Clusters before service mesh implementation

This is the logic behind all the services in the Clusters after service mesh implementation

Here are a few ways a service mesh can help implement zero trust security:

• Mutual Transport Layer Security (mTLS) enforcement for all microservices communication
• Managing microservice identity and permission
• enabling central access control administration and implementing the least privilege for each microservice and role (in Kubernetes, this can be done with RBAC)
• facilitating monitoring and observability for microservices to enable the detection and blocking of suspicious access attempts or traffic
• adding access restrictions with a micro-perimeter around each microservice and restricting entry and exit

A service mesh can help mitigate the following types of attacks:

• Service impersonation –To access other services or obtain access to sensitive information, an attacker poses as an authorized service on a private network.
• Packet sniffing – A hacker breaches the private network and eavesdrops on microservices' conversations.
• Unauthorized access – Insiders who are careless or malevolent try to make an illegal request from one service to another.
• Data exfiltration – Data is transferred from a protected resource to an area outside the network by an attacker who is within a secured network.

Some Service Mesh Options for Kubernetes

Here are some of the top service mesh tools you can use to manage communication between microservices in a Kubernetes environment.

• Istio
• Linkerd
• Amazon Web Services (AWS) App Mesh Consul Connect - HashiCorp
• Deepfence Inc Kuma.
• Traefik Mesh.
• Apache ServiceComb.
• Network Service Mesh (NSM)