Milestone 3 : Part 1
The current implementation of the Radar Data Visualization Applications has some avenues where improvement is possible, for example, inter-service communication, security, service authorization, load balancing and improved monitoring. All of these can be achieved through an integration of a service mesh layer above the existing Kubernetes architecture.
Following are the desired improvements:
- Service Authorization & Authentication - A service mesh can be implemented to enforce inter-service communication restrictions.
- Encryption - Secure communication can be implemented for inter-service communication using encryption through a service mesh.
- Load Balancing - The current architecture uses a round-robin fashion of load balancing, now although this works it is not an optimum way to do it, this can be improved by integration of a service mesh which offers multiple options of doing so like Random, Weighted, Less requests.
- Monitoring - A service mesh to collect and provide various system/network metrics can be implemented.
- Sidecar Proxy - Inter-service communication can be improved by addition of sidecar proxies, which would become solely responsible for the communication of microservices. This can be achieved through the integration of a service mesh.
A service mesh is a configurable, low‑latency infrastructure layer designed to handle a high volume of network‑based interprocess communication among application infrastructure services using application programming interfaces (APIs). A service mesh ensures that communication among containerized and often ephemeral application infrastructure services is fast, reliable, and secure. The mesh provides critical capabilities including service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern.
The service mesh is usually implemented by providing a proxy instance, called a sidecar, for each service instance. Sidecars handle interservice communications, monitoring, and security‑related concerns – indeed, anything that can be abstracted away from the individual services. This way, developers can handle development, support, and maintenance for the application code in the services; operations teams can maintain the service mesh and run the app.
Istio works by having a small network proxy sit alongside each microservice. This so-called “sidecar” intercepts all of the service’s traffic and handles it more intelligently. Istio uses the Envoy proxy as its sidecar. The whole set of sidecars, one per microservice, is called the data plane. The work of the sidecars is coordinated by a small number of central components called the control plane.
