Blog

Service meshes have become a cornerstone in the architecture of modern microservices, providing a dedicated infrastructure layer to manage service-to-service communication. Traditionally, service meshes have relied on sidecar proxies to handle tasks such as load balancing, traffic routing, and security enforcement. However, the emergence of sidecarless service meshes has introduced a new paradigm, promising to simplify operations and reduce overhead.

This blog offers a detailed overview of the pros and cons of sidecarless service meshes, focusing on the security aspects that can make a significant difference. It enables you to navigate the complexities of managing a modern microservices architecture. Whether you choose to stick with the traditional sidecar model, explore the emerging sidecarless approach, or use a mix of both based on the use case, understanding the trade-offs allows you to optimize your microservices communication and achieve greater efficiency and reliability in your deployments.

The Pros and Cons of Sidecarless Service Meshes

A sidecarless service mesh operates by integrating the service mesh layer directly into the underlying infrastructure, such as the kernel, rather than deploying individual sidecar proxies alongside each microservice. This approach leverages shared resources such as DaemonSets or node-level proxies or technologies like eBPF (extended Berkeley Packet Filter) to manage network connectivity and application protocols at the kernel level, handling tasks like traffic management, security enforcement, and observability.

Pros

  • Reduced operational complexity: Sidecarless service meshes, such as Istio’s Ambient Mesh and Cilium’s eBPF-based approach, aim to simplify operations by eliminating the need for sidecar proxies. Instead, they use shared resources like DaemonSets or node-level proxies, reducing the number of components that need to be managed and maintained.
  • Improved performance: By removing resource-intensive sidecar proxies such as Envoy, sidecarless service meshes can reduce the latency and performance overhead associated with routing traffic through additional containers. This can lead to improved network performance and more efficient resource utilization.
  • Lower infrastructure costs: Without the need for individual sidecar proxies, sidecarless service meshes can reduce overall resource consumption, leading to lower infrastructure costs. This is particularly beneficial in large-scale environments with numerous microservices.
  • Simplified upgrades and maintenance: Upgrading and maintaining a sidecarless service mesh can be more straightforward, as there are fewer components to update. This can lead to reduced downtime and fewer disruptions during maintenance windows.

Cons

  • Limited maturity and adoption: Sidecarless service meshes are relatively new and may not be as mature or widely adopted as their sidecar-based counterparts. This can lead to potential stability and reliability issues, as well as a steeper learning curve for teams adopting the technology.
  • Security concerns: Some experts argue that sidecarless service meshes may not provide the same level of security isolation as sidecar-based meshes. Shared proxies can introduce potential vulnerabilities and may not offer the same granularity of security controls.
  • Compatibility issues: Not all existing tools and frameworks may be compatible with sidecarless service meshes. This can create challenges when integrating with existing infrastructure and may require additional effort to adapt or replace tools.
  • Feature limitations: While sidecarless service meshes can handle many of the same tasks as sidecar-based meshes, they may not support all the advanced features and capabilities. For example, some complex traffic management and routing functions may still require sidecar proxies.

The Security Debate

A critical consideration when choosing a service mesh, the debate as to whether a sidecarless service mesh can meet the needs of the evolving threat landscape continues to rage. When it comes to sidecarless service meshes, the primary security risks include:

  • Reduced isolation: Without dedicated sidecars for each service, there is less isolation between services, potentially allowing security issues to spread more easily across the mesh.
  • Shared resources: Sidecarless approaches often use shared resources like DaemonSets or node-level proxies, which may introduce vulnerabilities if compromised, affecting multiple services simultaneously.
  • Larger attack surface: Some argue that sidecarless architectures may present a larger attack surface, especially when using node-level proxies or shared components.
  • Fine-grained policy challenges: Implementing fine-grained security policies can be more difficult without the granular control offered by per-service sidecars.
  • Certificate and mTLS concerns: There are debates about the security of certificate management and mutual TLS (mTLS) implementation in sidecarless architectures, particularly regarding the separation of authentication from data payloads.
  • eBPF security implications: For eBPF-based sidecarless approaches, there are ongoing discussions about potential security risks associated with kernel-level operations.
  • Reduced security boundaries: The lack of clear pod-level boundaries in sidecarless designs may make it harder to contain security breaches.
  • Complexity in security management: Without dedicated proxies per service, managing and auditing security across the mesh may become more complex.
  • Potential for “noisy neighbor” issues: Shared proxy resources might lead to security problems where one compromised service affects others.
  • Evolving security practices: As sidecarless architectures are relatively new, best practices for securing these environments are still developing, potentially leaving gaps in an organization’s security posture.

It’s important to note that while concerns exist, proponents of sidecarless architectures argue that they can be addressed through careful design and implementation. Moreover, some advocates of the sidecarless approach believe that the separation of L4 and L7 processing in sidecarless designs may actually improve security by reducing the attack surface for services that don’t require full L7 processing.

The Middle Road

A mixed deployment, integrating both sidecar and sidecarless modes, can offer a balanced approach that leverages the strengths of both models while mitigating their respective weaknesses. Here are the key benefits and relevant use cases of using a mixed sidecar and sidecarless service mesh deployment:

Benefits

  • Optimized Resource Utilization
    • Sidecarless for lightweight services: Sidecarless deployments can be used for lightweight services that do not require extensive security or observability features. This reduces the overhead associated with running sidecar proxies, leading to more efficient resource utilization.
    • Sidecar for critical services: Critical services that require enhanced security, fine-grained traffic management, and detailed observability can continue to use sidecar proxies. This ensures that these services benefit from the robust security and control features provided by sidecars.
  • Enhanced Security and Compliance
    • Granular security control: By using sidecars for services that handle sensitive data or require strict compliance, organizations can enforce granular security policies, including mutual TLS (mTLS), access control, and encryption.
    • Simplified security for less critical services: For less critical services, sidecarless deployments can provide adequate security without the complexity and overhead of sidecar proxies.
  • Improved Performance and Latency
    • Reduced latency for high-performance services: Sidecarless deployments can reduce the latency introduced by sidecar proxies, making them suitable for high-performance services where low latency is critical.
    • Balanced performance for mixed workloads: By selectively deploying sidecars only where necessary, organizations can achieve a balance between performance and security, optimizing the overall system performance.
  • Operational Flexibility and Simplification
    • Simplified operations for non-critical services: Sidecarless deployments can simplify operations by reducing the number of components that need to be managed and maintained. This is particularly beneficial for non-critical services where operational simplicity is a priority.
    • Flexible deployment strategies: A mixed deployment allows organizations to tailor their service mesh strategy to the specific needs of different services, providing flexibility in how they manage and secure their microservices.
  • Cost Efficiency
    • Lower infrastructure costs: Organizations can lower their infrastructure costs by reducing the number of sidecar proxies (or replacing Envoy with lightweight proxies), particularly in large-scale environments with numerous microservices.
    • Cost-effective security: Sidecar proxies can be reserved for services that truly need them, ensuring that resources are allocated efficiently and cost-effectively.

Use Cases

  • Hybrid cloud environments: In hybrid cloud environments, a mixed deployment can provide the flexibility to optimize resource usage and security across different cloud and on-premises infrastructures. Sidecarless deployments can be used in cloud environments where resource efficiency is critical, while sidecars can be deployed on-premises for services requiring stringent security controls.
  • Microservices with varying security requirements: In microservices architectures where different services have varying security and compliance requirements, a mixed deployment allows for tailored security policies. Critical services handling sensitive data can use sidecar proxies for enhanced security, while less critical services can leverage sidecarless deployments for better performance and lower overhead.
  • Performance-sensitive applications: Applications requiring high performance and low latency can benefit from lightweight sidecars or sidecarless deployments for performance-sensitive components. At the same time, sidecar proxies can be used for components where security and observability are more critical, ensuring a balanced approach.
  • Development and test environments: In development and test environments, sidecarless deployments can simplify the setup and reduce resource consumption, making it easier for developers to iterate quickly. Sidecar proxies can be introduced in staging or production environments where security and observability become more critical.
  • Gradual migration to sidecarless architectures: Organizations looking to gradually migrate to sidecarless architectures can start with a mixed deployment. This allows them to transition some services to sidecarless mode while retaining sidecar proxies for others, providing a smooth migration path and minimizing disruption.

While much depends on the service mesh chosen, a mixed sidecar and sidecarless service mesh deployment may offer a versatile and balanced approach to managing microservices. However, a mixed environment also adds a layer of complexity, requiring additional expertise, which may be prohibitive for some organizations.

The Bottom Line

Both sidecar and sidecarless approaches offer distinct advantages and disadvantages. Sidecar-based service meshes provide fine-grained control, enhanced security, and compatibility with existing tools but may come with increased operational complexity, performance overhead, and resource usage depending on the service mesh and proxy chosen. On the other hand, sidecarless service meshes promise reduced operational complexity, improved performance, and lower infrastructure costs but face challenges related to maturity, security, and compatibility.

The choice between sidecar and sidecarless service meshes ultimately depends on your specific use case, requirements, existing infrastructure, in-house expertise, and timeframe. For organizations with immediate requirements or complex, large-scale microservices environments that require advanced traffic management and security features, sidecar-based service meshes may be the better choice. However, for those looking to simplify operations and reduce overhead, sidecarless service meshes are maturing to the point where they may offer a compelling alternative in the next 12 to 18 months. In the meantime, however, it’s worth taking a look in a controlled environment.

As the technology continues to evolve, it is essential to stay informed about the latest developments and best practices in the service mesh landscape. By carefully evaluating the pros and cons of each approach, you can make an informed decision that aligns with your organization’s goals and needs.

Next Steps

To learn more, take a look at GigaOm’s Service Mesh Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

If you’re not yet a GigaOm subscriber, sign up here.

Source