One of the main problems migrating to the cloud, and where businesses spend a lot of time, is in network modifications such as IP changes and DNS and firewall rule updates. Combined with business processes, such as opening tickets to other departments, filling in forms, waiting for approval, and of course, avoiding human errors, the cloud adoption process can be a time-consuming and expensive endeavor.
A multi-platform mesh service layer, along with a software-defined interconnection service such as Equinix Fabric™, will solve most of the network challenges that you may encounter during your cloud migration journey. This solution allows your developers to fully focus on tasks such as migrating virtual machines to containers or replacing a database with a cloud storage service.
Equinix Fabric™ Data Sheet
Equinix Fabric directly, securely and dynamically connects distributed infrastructure and digital ecosystems on Platform Equinix®. Establish data center-to-data center network connections on demand between any two Equinix Fabric locations within a metro or globally via software-defined interconnection.Read More
Understanding a service mesh
A service mesh provides a dedicated infrastructure layer that enables and manages connectivity between services or microservices. By having a service abstraction layer, we get several benefits including, but not limited to:
- service discovery
- secure connections between distributed platforms
- observability into communications
- traffic management for improved deployments
- centralized failover policies
The service mesh usually works with a service discovery agent to detect when a service comes up or when it stops working. It is usually implemented by providing a proxy instance for each service instance. These proxies are called “sidecars” since they run alongside each service. Sidecars handle service-to-service communications tasks such as authorizations, authentications, monitoring or anything that can be abstracted away from the service itself. See diagram below.
Service Mesh Service-to-Service Communications
Istio, Linkerd and Consul Connect are just some of the many interesting service mesh options available on the market. We recommend looking at a comparison table[i] of the best service mesh options to understand which one best suit your architecture. Most of these solutions are Service Mesh Interface (SMI)[ii] compliant. This means that they meet a series of standard specifications that cover the main capabilities of service mesh, such as policies, metrics and traffic management, and therefore facilitate their integration with different services or platforms.
Service management in the hybrid multicloud world
When moving to a hybrid multicloud infrastructure, you need a centralized way to control where each service is and how they communicate with each other if they are on different platforms. In addition, it is possible that you’ll end up having the same service distributed in different places — both on-premises and in multiple clouds — and will need a way to balance the traffic between them.
To better understand how it all works, let’s take the example of migrating from virtual machines (VMs) to Kubernetes[iii]. The service mesh not only covers the management space between on-premises data center and cloud environments, but also between the VMs and other platforms, such as containers.
The high-level diagram below shows where the service mesh would fit in our hybrid architecture on Platform Equinix®.
In this example, some of the VMs are being migrated from an Equinix International Business Exchange™ (IBX®) data center to Google Kubernetes Engine (GKE) in Google Cloud. In this example, the following components are being used:
- Equinix Fabric – To quickly establish a private, direct connectivity between the on-premises and GKE/Google Cloud platforms, which provides all the security of a private link and allows you to easily scale network bandwidth up and down, depending on the workload or where you are in your migration journey.
- Consul Connect, which is made up of agents, gateways and proxies:
- Agents – The core process of Consul, agents track what tasks are running in the cluster and where they are located.
- Mesh Gateways – Provide communication between service meshes that can reside in different clouds or runtime environments.
- Proxies – Enable unmodified applications to use the service mesh. The configuration is basically the same in both platforms. The main difference is that VMs have a one-to-one relationship with the underlying envoy proxy[iv] (in this case) and on the Kubernetes side, the proxy will be launched as a sidecar process. So, for every pod, there will be an envoy proxy with that particular service.
The multiple technical benefits of a service mesh architecture
With a service mesh architecture in place, there are many capabilities that you can benefit from:
- Multi-Platform Service Discovery: It does not matter where your service is or if the platform it runs on are VMs, containers or bare metal, such as Equinix Metal™.
- Enhanced Security: In addition to Equinix Fabric, which allows you to bypass the public internet and reduces security threats and the attack surface, a service mesh will establish a zero-trust networking model by enforcing mutually authenticated transport layer security (TLS) connections between services authorized by identity-based policies.
- Traffic Management: With a service mesh you can configure services that can communicate with each other or set up weighted load balancing that will allow you to improve your release process with blue-green deployments, A/B tests or canary testing.
Deploying hybrid multicloud using a service mesh architecture
With a service mesh architecture, your hybrid multicloud environment can include one or more cloud providers, several data centers, or coexisting VMs and containers. Wherever you need to handle distributed workloads, interconnected service mesh architectures and Equinix Fabric will deliver them across the global Equinix platform.
For more information, watch our webinar on executing an interconnected cloud strategy.