Cloud Native Computing Foundation ServiceMeshCon North America 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Leveraging Service Mesh For Enterprise Multi-Cloud Strategy- Jun Wei & Victor Martinez, Equinix

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Leveraging Service Mesh For Enterprise Multi-Cloud Strategy- Jun Wei & Victor Martinez, Equinix

Multi-cloud strategy is becoming the new norm when it comes to cloud adoption for enterprises, especially for global companies cross multiple geographic regions. Many factors can contribute to the motivation behind multi-cloud strategy, including best of the class solutions from multiple cloud providers, reliability and flexibility, and optimal performance-cost benefits. All major cloud providers are offering coherent solutions to enable hybrid and multi-cloud strategies. Among all solutions, Service Mesh is an effective technology to deliver the benefits of multi-cloud strategy to enterprises. We will examine a few multi-cloud use cases and architecture considerations and how to leverage service mesh for typical enterprise multi-cloud strategies, including failover, best of class, and flexible scale-in-and-out application deployment patterns. In particular, we will explore private connections among multiple cloud providers to ensure enterprises the ultimate security and privacy for their data while enabling multi-cloud strategies.

A

My name is joon wei, I'm senior principal solution architect at equinex.

B

Hello: everybody. My name is viktor martinez, senior solution, architect at equinix.

A

We're here to present leverage service mesh for enterprise, multi-cloud strategy.

A

In this talk, we will cover multi-cloud strategy for enterprises and examine a few use cases.

A

We will look into application deployment regarding requirements, key consideration and options in more details. Then we will discuss what roles service mesh can play for multi-cloud strategy, followed by a quick demo and some future considerations.

A

As the cloud adoption penetrating deeper into enterprise I.t domains, more and more enterprises start to realize the inevitable trends of multi-cloud.

A

Multiple factors can contribute to the motivation towards multi-cloud strategy.

A

Each cloud provider has its unique offerings that are the best of the class being able to leverage best of the class solution from multiple cloud providers will allow enterprise to benefit without being locked in with one provider.

A

Backup and disaster recovery always require a secondary region or location. In some cases that may not be always available from one cloud provider. This is why another cloud providers can be a viable option, either in primary, secondary or active active manner.

A

It is flexible under quick to set up backup or disaster recovery in a cloud than looking for other alternatives.

A

In other cases, multiple cloud providers can offer optimal performance cost benefit if planned it carefully.

A

Let's examine the requirement associated with the application deployment in a multi-cloud environment. Take the example of best of the class use case when deploying a services across multiple clouds. Several factors will need to be taken into the considerations.

A

For example, when a database services is deployed in a different cloud away from other services, for example, web front services, the latency introduced by multi-cloud deployment should not adversely affect the overall application performance.

A

In addition, security over the connection between clouds needs to be in place to make sure the data transferring back and forth will be in alignment with all security and compliance mandates.

A

Key questions we need to ask ourselves is latency bandwidth adequate for my deployment in multiple clouds.

A

Would my data be safe when traversing between clouds? Is there any sla associate with the connection between clouds.

A

For the connection between clouds, there are many options to choose from public internet with proper vpn. Tunnels can be an option for testing and validation when ready for production deployment. Private connection deserve serious considerations.

A

Next, we will examine those use cases in more details. First, let's look at scenario for best of the class use case.

A

Here is example of application book info, if decided to deploy some services in another cloud we like to make sure the latency introduced by such deployment won't affect overall performance to ensure that the latency and the bandwidth between two clouds needs to be within certain ranges.

A

To achieve that, we probably want to have two cloud deployments adjacent to each other.

A

On the right, we show a cloud infrastructure map for north america at ashform. There are multiple cloud providers within close proximity to each other, such as aws, google cloud and azure to name a few. This gives us a viable option for dimension deployment into multiple clouds at ashform.

A

In many cases, large amount of data are flowing between two clouds or security, and the compliance mandates are required. Proper security measured needs to be in place for the connection between two clouds.

A

The private connection will probably be the first choice for such requirements.

A

Many cloud providers offer private connection options. For example, awx direct connect, azure express routes, google cloud interconnect to connect a deployment from two clouds. Privately, you can simply connect two clouds through a joint cloud, on-ramp location in short, multi-cloud access and the private connections are the key components to the success of the best of class use cases.

A

Another use example is backup and the disaster recovery use cases leveraging. Another cloud for backup and disaster recovery can be an excellent choice in some cases.

A

Take example of the deployment in aws region asia-pacific sydney, as shown on the right. There is only one aws region in that area. If you are looking for backup most likely, you will use aws asia-pacific singapore.

A

However, if data sovereignty is mandated, you will have to look for an alternative within country boundaries.

A

Luckily, you will have you will find that many other cloud providers within close proximity, most of them share the common cloud on-ramp location at sydney in the case of backup and disaster recovery in a different cloud whenever the synchronization between two deployments are is required. Private connection would be necessary.

A

In that case, you can always use the private connection to access both cloud provider from a joint cloud, on-ramp location, again. Multi-Cloud access and the private connection are the key components to the success of backup and disaster recovery. Use cases.

A

Next, let's look at how service mesh can help to implement those use cases in a multi-cloud environment. Multiple clusters are formed to manage traffic between services through service mesh by defining destination rules and virtual services. The ingress of each clusters will be able to route traffic. Accordingly, in the case of multi-cloud multiple clusters in a multi-cloud environment, the ingress will be able to route traffic to services that are not local to its cluster.

A

Proper network configuration needs to be in place to route traffic between clusters through connection across multiple clouds. We will show some example in the demo.

A

Can the service mesh know where to deploy services into other clusters in a second cloud? It depends with a cluster previously deployed in the second cloud. The surface mesh will be able to generate detailed telemetries, but in many other cases this is actually a day, zero planning decision.

A

For example, we will have to look at the cloud infrastructure map like the one showing on the right to first figure out, where are the locations with multi-cloud access or mca?

A

Major cloud providers are almost everywhere these days, but not all cloud providers are available at a given location or a specific feature. You design may not be available everywhere carefully. Choosing the right, multi-cloud access location may not be a trivial tasks and requires external measures once that is determined, proper ingress policies can then be injected into service mesh for multi-cloud traffic management.

A

Again. Multi-Cloud access and private connections are the keys to the success of multi-cloud strategy. Here for backup and disaster recovery, a duplicate deployment can be within the same provider if a new region is available or to a different provider. If second region is not available here, multiple multi-cluster, ingress or mci will be helpful through mci.

A

Proper backup strategy can be implemented, whether it's primary secondary or active, active.

A

In the case of serving global user, multiple copy of the same deployment can be deployed in each of the region closer to users through the global load, balancing feature of mci, the intel region deployment can be with the same provider or a mix of a different provider, as shown on the map to the right.

A

The proper backup policy can be defined for both intro region and interregion scenarios.

A

Similarly, as stated before, whenever synchronization is needed, private connection may be necessary once again. Multi-Cloud access and private connections are the key to the success of multi-cloud strategy.

A

Next, we will share a few experiments how service mesh help with application deployed in multiple cloud environments.

A

We will demonstrate that best of the class deployment across two clouds can be achieved. In this case, we have already chosen ashvan as the multi-cloud access location and have built a private connection between two clouds.

A

Service mesh are used to route traffic across two clouds deployment.

B

So basically, our goal in this demo is for you to see how we can connect two managed clusters from different cloud providers using a private connection instead of the internet.

B

The first scenario is the deployment of an application on a single kubernetes cluster. The application is book info included within the istio samples, where there is a micro service that has different versions. Product page is calling to review service balancing the requests.

B

If we evolve this solution to a multi-cluster to extend our deployment, we must connect both kubernetes in some way. As shown in this diagram, there is the option of connecting via the internet, using issue gateways and public, addressing our proposal chooses a more secure solution and ensures better and more stable performance than the internet.

B

In our ideal scenario, we connect both private clusters through private connectivity. We achieve this by using equinix as an interconnection provider that allows us to perform cloud-to-cloud routing pairing without leaving their own premises.

B

Equinix offers as a service to deploy a virtual, router and virtual circuits to the clouds in a flexible and on-demand model, and now, let's take a look at our gke and aks clusters in a scenario based on the later model. Of course, the nodes are not exposed to the internet and the configuration is in a private mode. Initially, the booking application is deployed entirely on the gke cluster.

B

If we analyze the graph in kiyali, we can see that there is a traffic balancing to the reviews, microservice and that all of them are in the google cloud.

B

Let's remove now the deployment of version number three that is on gke.

B

As you can see, the retro stars no longer appear now. Let's wait a few seconds to see that this version is no longer available for the review service in the kayali graph.

B

Time now to deploy this same service in our azure manage cluster.

B

If we wait a few seconds, we will see that we are able to display again this version number three, but from aks.

B

As you can see, we have enabled the connection between both clouds using our private connectivity and extending the deployment of the application.

B

To demonstrate that we're using this private connectivity using equinix as the link and express road with cloud interconnect, we are going to disable one end of the multi-cloud connection.

B

Let's select the villain attachment of our interconnect connection here, you can see that automatic private addressing is always used. So, let's disable it now. We just block the routing of data traffic between the two clouds.

B

Let's go back to the book info application.

B

To see how version 3 reviews are no longer displayed now, the microservices that are in the google cloud are not able to reach azure cluster. We broke the private connectivity between aks and gke.

B

If we take a look at the kle console, we will see how little by little the service is degradated for that version. Having demonstrated this, let's re-enable the vlan attachment of the google site.

B

Now, after a few seconds, our application in a multi-cloud mode should be stable again.

A

For future consideration, we are exploring ways of automating the process for enterprise multi-cloud strategies, including multi-cluster, ingress and global load, balancing over multiple clouds and automating multi-cloud access planning with service mesh traffic management.

A

To summarize, let's recap: the key takeaways multi-cloud has become the new norm when enterprises consider their cloud adoption strategy.

A

Multi-Cloud access and private connections are crucial to the success of multi-cloud strategy.

A

Service mesh is one of the key enablers for multi-cloud strategy.

A

At the end of the day, how to automate the process to enable multi-cloud strategies are among the most important challenges faced by enterprises. Service mesh is definitely a right technology. Let's make it work with that. We conclude our presentation.