Making A Right Mesh
Service Mesh + DevOps = ♥️
A service mesh allows for more granular control over microservices communication, enabling more efficient communication between services and increased observability.
This allows for faster and more reliable deployment of new features, which is a key aspect of the DevOps culture. Additionally, a service mesh can provide features such as traffic routing, circuit breaking, and service discovery, which can help organisations to more easily implement continuous integration and continuous delivery (CI/CD) processes.
A service mesh can help organisations to better manage and optimise their microservices infrastructure, which can facilitate the adoption of DevOps practices and culture.
A Service Mesh creates happy paths in Value Streams Maps
A service mesh can help an organisation deliver value to its customers more quickly in a number of ways
Faster deployment. With a service mesh in place, organisations can more easily manage and optimise their microservices infrastructure, allowing for faster and more reliable deployment of new features.
Improved service discovery. A service mesh can provide service discovery capabilities, which can help organisations to more easily locate and communicate with the services that they need in order to deliver new features.
Better observability. A service mesh can provide detailed monitoring and logging capabilities, which can help organisations to quickly identify and resolve issues that might be preventing new features from being delivered to customers.
Resilience. A service mesh can provide features such as traffic routing, circuit breaking and retries, which can help organisations to ensure that their services are highly available and can continue to deliver value to customers even when there are failures or disruptions.
Automation. A service mesh enables automating the deployment, scaling, and management of microservices, thus reducing the time and effort required to deliver new features.
No free lunch
Adopting a service mesh can bring many benefits to an organisation, but there are also some potentially negative consequences to consider:
Increased complexity. Implementing a service mesh can add an additional layer of complexity to an organisation’s microservices infrastructure, which can make it more difficult to troubleshoot and manage.
Resource requirements. A service mesh can consume significant resources, including CPU, memory, and network bandwidth. This can be an issue for organisations with resource constraints or limited infrastructure.
Latency. The additional layer of networking introduced by a service mesh can increase latency, which can negatively impact the performance of an organisation's services.
Vendor lock-in. Some service meshes are built around proprietary technologies, which can make it difficult for organisations to switch between vendors or move away from a service mesh in the future.
Security. A service mesh can introduce new attack surfaces and potential vulnerabilities, which can make it more difficult to secure an organisations microservices infrastructure.
It may also increase the operational and maintenance cost if not implemented and managed properly.
It’s important for organisations to carefully consider these potential negative consequences before deciding to adopt a service mesh, and to be mindful of these issues when planning and implementing a service mesh.
Who really needs it in the end?
What type of organisations (in terms of size or infrastructure) need a service mesh? Who are the early adopters and what would it take for service to become a mainstream technology?
Service meshes are typically used by organisations that have adopted a microservices architecture and are looking to manage and optimise the communication between their many services. These organisations tend to be larger in size and have more complex microservices infrastructure.
Early adopters of service meshes tend to be large technology companies and organisations in the financial and healthcare industries that have a need for high availability, scalability and security of their microservices.
For service meshes to become mainstream technology, a few key factors need to be considered.
Simplicity. As service meshes become more widely adopted, they will need to be made simpler and more user-friendly in order to be accessible to a wider range of organisations.
Standardisation. Service meshes will also need to be standardised in order to make it easier for organisations to switch between vendors and to integrate them with other technologies.
Interoperability. Service meshes should be able to work seamlessly with other infrastructure tools like CI/CD, Istio and Envoy, this will make it easier for organisations to adopt service meshes as a part of their existing infrastructure.
Cost. As service meshes become more widely adopted, the cost of implementing and maintaining them is likely to decrease, making them more accessible to smaller organisations.
Community. A strong and growing open-source community around service meshes can help to drive innovation and improve the reliability and security of the technology, making it more appealing to mainstream organisations.
As service meshes evolve to address these needs, they will become increasingly accessible and appealing to a wide range of organisations across various industries.
An organisation that would never choose to use a service mesh could be an organisation that does not have a microservices architecture. For example, an organisation that has a monolithic architecture and does not have many services to communicate with each other may not see the need for a service mesh.
An organisation that already has a well established and functioning load balancer, reverse proxy and firewall infrastructure may also not choose to use a service mesh.
Another example could be an organisation that has very limited resources or budget, adding another layer of complexity and cost may not be feasible for them.
Additionally, organisations that have a very strict security policy might not choose to use a service mesh, as it can introduce additional attack surfaces and potential vulnerabilities in their infrastructure.
e.g.
Data plane vulnerabilities. Service meshes typically have a data plane component, which is responsible for handling the actual communication between services. These components can be vulnerable to attacks such as denial-of-service (DoS) attacks and other types of traffic manipulation.
Control plane vulnerabilities. Service meshes also typically have a control plane component, which is responsible for managing the configuration of the data plane. These components can be vulnerable to attacks such as unauthorised access and privilege escalation.
Misconfigurations. Service meshes can be complex to set up and configure, and even small misconfigurations can create security vulnerabilities. For example, if a service mesh is configured to allow all traffic, it could be vulnerable to a MitM (man-in-the-middle) attack.
Saying that, having a service mesh in place can provide additional security benefits compared to not having one, for intra-service communication, in a microservices architecture.
A service mesh can provide features such as mutual TLS (Transport Layer Security), which encrypts all communication between services, preventing eavesdropping and tampering. It can also provide network-level access controls, which can help to restrict access to services based on predefined rules. Additionally, service meshes can provide detailed monitoring and logging capabilities, which can help organisations to quickly identify and resolve security issues.
It’s important for organisation's to thoroughly assess the security risks associated with a service mesh before implementing one and to ensure that the service mesh is configured and managed securely. Additionally, it’s recommended to use security best practices and guidelines and to have an incident response plan in place to address any issues that may arise.
It’s ultimately a risk assessment decision an organisation needs to make, taking into account their specific use-case and threat model.
Service meshes are not a one-size-fits-all solution and may not be the best fit for every organisation. The decision to use a service mesh should be based on the specific needs and constraints of an organisation.
Lay of the land
There are several service mesh solutions available in the market, but here are three of the most popular ones and their pros and cons.
Istio is an open-source service mesh that provides features such as traffic management, service discovery, and security. It is widely adopted and has a large and active community.
Pros: Istio is widely adopted and has a large and active community. It provides a lot of features and flexibility, and it’s compatible with most cloud providers and container orchestration platforms.
Cons: Istio can be complex to set up and manage, and its feature set can be overwhelming for some organisations.
Linkerd is an open-source service mesh that focuses on simplicity and ease of use. It provides features such as traffic management, service discovery, and security.
Pros: Linkerd is easy to set up and manage, it has a small footprint, and it’s compatible with most cloud providers and container orchestration platforms.
Cons: Linkerd’s feature set is more limited than that of some other service meshes, and it may not be suitable for organisations with more complex microservices infrastructure.
Consul Connect is a service mesh solution from Hashicorp, it provides features such as traffic management, service discovery, and security. Consul Connect can be used in combination with Consul, which is a service mesh solution for service discovery and configuration management.
Pros: Consul Connect is built on top of Consul, which is a well-established tool for service discovery and configuration management. It has good integration with other Hashicorp tools, and it’s compatible with most cloud providers and container orchestration platforms.
Cons: Consul Connect is a paid product and may not be cost-effective for organisations with limited resources.
New kid on the block
Kuma is a relatively new open-source service mesh developed by Kong, it provides features such as traffic management, service discovery, and security, it also support multiple data-planes.
Kuma is gaining traction in the market and has a growing community and ecosystem, it’s a lightweight and easy to use service mesh that supports multiple data-planes and can be used to manage services across multiple clouds, on-prem and edge environments.
Compared to Istio, Kuma has a simpler architecture and less operational overhead. It also provides a more intuitive and user-friendly configuration, and it’s more lightweight and easier to use than Istio.
Compared to Linkerd, Kuma has a more feature-rich control plane and supports more data-planes and multiple environments like multi-cloud and edge.
Compared to Consul Connect, Kuma offers more flexibility and it’s open-source, it also supports more data-planes and has a growing community and ecosystem.
Magic tech, Voodoo tech
The dominant paradigm service meshes use is the sidecar pattern and envoy proxy for their implementation.
Most service meshes use the sidecar pattern, in which a separate container, called a "sidecar," is deployed alongside each service and is responsible for handling the service's network traffic. Envoy, developed by Lyft, is a popular choice for the sidecar proxy, used by many service meshes such as Istio, Linkerd and Consul Connect.
However, there are alternatives to the sidecar pattern and Envoy proxy for service mesh implementation. We’ll cover those in-depth in a future post.
Decisions Decisions
Evaluating which service mesh is the right one for an organization can be a complex process, but here is a general step-by-step plan that can help
Define your requirements. Start by identifying your organization's specific needs and constraints, such as the number of services, the type of workloads, security and compliance requirements, and the resources available.
Research the options. Research the different service mesh solutions available in the market, such as Istio, Linkerd, Consul Connect and Kong Mesh. Look at their features, compatibility with your existing infrastructure and processes, and the size and activity of their communities.
Create a shortlist. From the research, create a shortlist of service mesh solutions that best meet your requirements and constraints.
Test and evaluate. Set up test environments for each of the service mesh solutions on your shortlist, and evaluate them based on a set of measurable outcomes. These outcomes should include factors such as ease of installation and configuration, resource usage, performance, scalability, and security.
Select a solution. Based on your testing and evaluation, select the service mesh solution that best meets your requirements and constraints.
Implement and monitor. Implement the selected service mesh solution in your production environment, and monitor its performance and usage over time.
Review and improve. Review the service mesh's performance and usage over time, and make any necessary improvements to optimise it for your organisation's needs.
Naturally, crucial to have a clear understanding of your organisation's requirements, constraints and goals to be able to evaluate which service mesh is the best fit for your organisation.
The conquest could happen
Service meshes are a relatively new technology and it's still uncertain whether they will go mainstream in the same way that Kubernetes has for example. It is likely that service meshes will continue to gain popularity and wider adoption in the coming years, as they provide a lot of benefits such as traffic management, service discovery, and security, especially in microservices-based architectures.
There are a few factors that will likely contribute to the mainstream adoption of service meshes:
Increasing adoption of microservices-based architectures: As more organisations adopt microservices-based architectures, the need for service meshes will likely increase.
Maturity of service meshes: As service meshes continue to mature, they will likely become more stable, easier to use, and more feature-rich, which will make them more appealing to organizations.
Cloud-native environment: As more organisations move to cloud-native environments, the need for service meshes will likely increase, as service meshes are well-suited for cloud-native environments.
However, there are also a few factors that could prevent service meshes from going mainstream:
Complexity. Service meshes can be complex to set up and manage, which may deter some organisations from adopting them.
Overlap with other technologies: Service meshes may overlap with other technologies, such as Kubernetes, which could make them less appealing to some organisations.
Security concerns. Organizations may be hesitant to adopt service meshes due to concerns about the additional attack surfaces and potential vulnerabilities they can introduce.
No one knows of course if and when service meshes will go mainstream, but it's likely that service meshes will continue to gain popularity in the coming years as more organisations adopt microservices-based architectures and move to cloud-native environments. However, the complexity of service meshes and the potential overlap with other technologies may slow down the adoption rate. It's also important to keep in mind that the adoption rate and timeline for service meshes may vary depending on the industry and specific use cases
