Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
5 min read
Published on 08/12/2020
Last updated on 02/05/2024
Navigating The Service Meshes Map
Share
A “Service Mesh” is an infrastructure layer regulating the interactions and relationships between applications or microservices. Rather than a source of fundamentally new features, it provides a repackaging of functionalities such as request-level load balancing, circuit-breaking, retries, instrumentation, and others. When developing cloud-native or hybrid applications, DevOps increasingly relies on service meshes to abstract application network functions from the code. Born as a facilitator for orchestration in the wake of Kubernetes and other container technology, service meshes are rapidly becoming an indispensable tool for containerization. They enable DevOps teams to focus on building added value services in distributed architectures that are ready to scale with built-in predictability and consistency across platforms. From a security perspective, service meshes are instrumental in enforcing compliance and best practices, alleviating SOC team’s workload and improving resilience while simplifying vulnerability identification and remediation. The ever increasing adoption of public cloud services has created a novel set of complexities stemming from the cloud architectural paradigm. These consist of a collection of interconnected microservices in constant communication and collaboration. The exponentially greater number of endpoints and interactions to monitor, secure, and scale, generated a debugging bottleneck and a new set of security vulnerabilities. Service Meshes emerged as a solution to address these emerging issues.
What Do Service Meshes Do?
When migrating from a monolithic architecture to a hybrid or cloud-native one, DevOps needs to adapt to a methodology capable of incorporating the management of communication between a collection of microservices and safeguard and monitor the drastically increased number of endpoints without compromising on scaling abilities or expanding debugging time or resource requirements. Service meshes are designed to address these issues. From streamlining traffic management by, for example, eliminating the necessity for gateway updates when adding microservices, to reducing complexity by abstracting common infrastructure-related functionalities to a different layer, they provide features that make them near indispensable for cloud-native and hybrid application development. Currently, service meshes most popular capabilities are:Traffic management– Connecting and controlling the traffic flow and API calls between servicesSecurity– Enforcing authentication to secure bi-directional traffic between client and serverAccess Control– Applying and enforcing policies and resource distributionObservability– Inferring the system’s internal states from external outputs
Istio: A full open-source solution founded by IBM, Google and LyftApp Mesh: Exclusive to AWSLinkerd: Initially developed by Twitter for internal use, in 2017 it was made open-source and donated to the CNCFConsul Connect: Open-source with a premium paid serviceSMI(Microsoft Service Mesh Interface): Announced at KubeCon in 2019, it is backed by heavy players such as Linkerd, HashiCorp, Colo.io, and VMWare, it was Kong: An open-source service mesh named Kuma announced in September 2019
Managed or self-managedDeploying Kubernetes clusters with a managed service is easy but comes at the cost of losing control over some of the cluster control pane. Selecting either requires assessing the pros and cons and evaluating the cost in IT management relative to the benefits of added flexibilityFull, partial open-source or proprietaryOpen-source platforms are typically more flexible but might be harder to operate, whereas proprietary ones have more limits and are not free. There is no one size fits all, so the optimal option for a specific project depends on factors such as cost evaluation, necessity for flexibility, availability of IT resources, and moreMulti-cluster expansionLarger projects might require multi-cluster expansion, and smaller ones might need it to scale. When selecting a Service Mesh service, it is always good practice to analyze their multi-cluster expansion capabilitiesLevel of automationAutomation saves time and can also tighten security. Different projects require different types of automation, so checking what automation options are included in a service mesh solution should be part of the selection processLevel of built-in security functionalitiesKubernetes built-in security is lacking, and tightening security implies taking additional measures. Service mesh solutions typically provide some security functionalities that address different prioritiesType and extend of authenticationAuthentication is a critical element of security. A projects’ type, complexity, and scope dictate the authentication features requiredObservabilityCritical to keep a comprehensive view of services health and performance, observability relies on obtaining telemetry data to monitor latency, traffic, errors, and saturation. Choosing between built-in observability, compatibility with external observability solutions or in-house observability configuration are factors dictated by the project’s priorities and should be taken into account when selecting a service mesh solutionInteroperabilityAs the popularity of service mesh grows and new services are emerging, interoperability becomes increasingly critical to enable the interconnection of multiple workloads. Service mesh solutions have various degrees of interoperability that should be factored in when selecting a provider
Subscribe to
the Shift!
Get emerging insights on innovative technology straight to your inbox.
