Istio (istio.io) is a service mesh solution designed to solve networking challenges with managing containers. Istio uses a policy-based management framework to provide network connectivity to containers using a service mesh.
Applications build using a microservice architecture composed of multiple containers; each container provides a specific service or function required by the application. One or more containers can provide a single service.
The above diagram depicts how a 3-tier application may look if provided by containers. If you’re familiar with topology diagrams, it doesn’t look much different from a typical 3 tier application with components behind a load balancers VIP.
Conceptually a service isn’t much difference between a VIP and containers are pool members. The terminology does not transfer to containers exactly, and there are some differences, but it’s not a bad starting point for learning.
Providing secure and reliable network connectivity for containers is an ongoing challenge. An application can be distributed across many individual containers, some of which may only exist for seconds.
A service must be aware of all containers which provide the required functionality, and the discovery process must be dynamic and fast. This is where a service mesh can be very helpful.
Key capabilities
Istio provides several critical capabilities for improving container networking, the list below is just a sample of them.
• Traffic Management: Istio uses Envoy and Pilot to provide policy-based management of container traffic. Policies provide dynamic application of policies to containers at runtime.
• Service discovery: When a container instance needs to talk to another instance, the service mesh can use service discovery to find a healthy destination instance.
• Security: Security features such as encryption and TLS encryption can be utilized to increase the security of container networking.
• Load balancing: Provides traffic load balancing for containers running the relevant service. This can be integrated with service discovery to perform health checks, preventing traffic from being sent to unhealthy containers.
• Telemetry: Istio provides granular telemetry data to administrators and application developers. Performance information can be used to provide performance data of individual transactions and the services.
• Reduction in code complexity: Using a service mesh decouples application network functions from the applications source code allowing developers to focus on the application itself.
Support for service meshes
A service mesh is made up of different components to providing different planes of operation. The architecture is designed to provide independent layers of management and operation, which isolates functionality and fault domains.
• Sidecar proxy: A sidecar proxy is a container which is attached to another container intercepting incoming and outgoing traffic. The container orchestration framework manages these.
• Control plane: The control plane provides management and orchestration functionality for a service mesh solution. The orchestration process of attaching a sidecar proxy to a newly created container occurs at the control plane layer.
• Data plane: The data plane is where the network traffic moves. Ingress and egress traffic traverse the data plane to get to or from a container.
Istio uses integrations with the container management system (such as Kubernetes) to obtain data about the containers for functionality such as health checks.
There are many areas which a service mesh makes sense and can solve container networking challenges. But like all solutions, it’s not a one size fits all. When assessing Istio as an option for your container networking needs, it’s important to review the capabilities and limitations equally.
Sidecar proxies are containers that are attached to another container. For each running container, there is an additional container to be managed. The orchestrator handles management of a sidecar proxy, however, is still an additional object to be tracked and monitored.
The use of a sidecar proxy is yet another step in the traffic path. The sidecar proxy processes the traffic before forwarding it, and this can cause increased latency for network traffic.
“Latency cost/overhead is approximately 10 millisecond for service-to-service (2 proxies involved, mixer telemetry and checks) as of 0.7.1, we expect to bring this down to a low single digit ms.” - https://istio.io/docs/concepts/performance-and-scalability/
Maintaining a production container solution is a complex task that requires ensuring the multiple systems are communicating correctly. The number of independent projects which form a container solution is not insignificant and introducing a service mesh is adding yet another tool into the mix.
Service mesh technologies solve real challenges with managing a container solution. Currently, it seems that larger container deployments can get significant benefits, where a smaller deployment might not see that value due to added complexity.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
