As organizations are migrating from monolithic apps to microservices based architectures, often they will utilize the services of multiple cloud providers for various benefits like, ease of deployment, faster application load times, geographical location etc. As a result, managing these applications require skill sets that are relevant to these cloud providers, building complex IPsec tunnels to maintain connectivity, managing IP address allocation to various sites and layering security policies. Also, various personas like DevOps and NetOps tend to use multiple tools to manage these application workloads, thus increasing the overall complexity of managing these distributed applications. 

Of the majority (75%) of organizations deploying apps in multiple clouds, 63% use three or more clouds according to a Propeller Insights survey. Overall, more than half (56%) find it difficult to manage workloads across different cloud providers, citing challenges with security, reliability, and—generally—connectivity. As a result of the mentioned challenges, organizations are looking for a solution to assist with overall cloud governance to one provide optimization for cloud cost, two adhere to security and compliance framework and three just manage inventory of application resources.

Customer scenario

Organization XYZ has a finance application deployed on-prem, the application consisted of four microservices deployed in a K8s cluster . Although, the application was serving well for a small number of customers, it did not provide redundancy or fast response times to its end users. To resolve these underlying issues, the development team decided to distribute the application across various cloud providers with the objective of keeping the backend component on-prem, so the team decided to host Main App in GCP, App2 (Money Transfer app) in AWS, App3 (Refer a Friend) in Azure while hosting the Backend App in the on-prem cluster. Once the application was distributed and deployed in various cloud providers, building the components was a huge uplift and was time consuming requiring different skill sets to manage these cloud providers. The team had to build complex IPsec tunnels, manage the IP address blocks for these sites, setup BGP routing and define security policies relevant to each cloud provider etc. The team was looking for a solution that can abstract the underlying complexities and simplify the management & security across cloud providers, this is where we will be leveraging the F5 XC Services global virtual network and connect all four sites together.

WWT & F5 collaboration to address the customer scenario

F5 leverages WWT's Advanced Technology Center which is housed in St. Louis at their Global Headquarters. WWT has invested $$$ with key strategic partnerships and OEM's including F5. F5 and WWT work very closely on multiple strategic programs, projects, multi-oem integrations, and proof of concepts for customers.

To address this scenario the architecture teams from both the sides collaborated and ran a joint effort to deploy a microservices based application in a distributed cloud framework, each of the four services were deployed in the CE sites and the F5 XC Services platform was used to provide the necessary cloud connectivity and security between these sites. We also leveraged the AI&ML capabilities of the platform for performing API discovery and to gather performance and connectivity metrics.

Multi Cloud POC connectivity diagram

Below are the CE sites that are deployed using the WWT ATC platform resources.

  • A dedicated On-Prem vApp with three node K8s cluster.
  • AWS subscription with EKS cluster and permissions to deploy the F5 CloudMesh Node.
  • Azure subscription with AKS cluster and permissions to deploy the F5 CloudMesh Node.
  • Google subscription with permissions to deploy the F5 CloudMesh Node and utilize the virtual K8s cluster provided by the F5 XC Services via App Stack Cluster

WWT also has a dedicated tenant on the F5 XC Services platform with sufficient privileges to deploy and configure the necessary configuration objects like cloud credentials, origin pools, HTTP load balancers etc. to expose these microservices to the outside world.  We can also work with our customers to have their microservices exposed via F5 XC Services either in a restricted environment or to internet and have users access these services and gather feedback on various metrics.

Application Flow Overview

As mentioned before, the finance app has fours microservices and the team has decided to distribute them to below cloud providers.

  • Main App, this is the front-end application that is interacting with other microservices to gather and display data to end users. Main App will be hosted in GCP cloud via App Stack Cluster using virtual K8s cluster provided by the F5 CloudMesh Node.
  • App2, this is the money transfer component of the application interacting with front-end and backend apps, exposes APIs to transfer money between user accounts. App2, will be hosted in customer's existing EKS cluster and connects to F5 XC Services via AWS VPC Sites.
  • App3, this is refer a friend component of the application, interacts only with the front-end. App3, will be hosted in customer's existing AKS cluster and connects to F5 XC Services via Azure VNET Site.
  • Backend, this is the backend database component of the application interacting with front-end and app2. Backend will be hosted in customer's existing On-Prem environment in a three node K8s cluster deployed on ESX host and connects to F5 XC Services via Site registration process.
Finance app with its API endpoints

Steps to deploy the solution

The collaboration between WWT & F5 focuses on two approaches of deployment targeting specific personas.

  • Deployment via F5 XC Services Console for NetOps persona.
  • Automated deployment by using terraform provider for DevOps persona. You can explore the terraform provider here

So far, you have heard that F5 XC Services simplifies and abstracts the creation of resources needed to provide connectivity between the clouds, it does it via deploying cloud mesh nodes at CE (Customer Edge) sites. You can refer F5 XC Services documentation at F5 Distributed Cloud Site to understand in detail about cloud mesh node, site etc.

As discussed before, we will be deploying cloud mesh nodes at fours providers as below.

  • Creation of AWS VPC Site to discover App2 deployed in EKS cluster
  • Creation of Azure VNET Site to discover App3 deployed in AKS cluster
  • Creation of GCP VPC Site and utilize the Virtual K8s cluster provided by Cloud Mesh Node to deploy and discover Main app.
  • Creation of VMware site(on-prem) to deploy the Backend.

Setting up each of these sites will require configuring various configuration object like cloud credential object, cloud sites, origin pool, HTTP load balancer etc.

You can refer the WWT/F5 MCN POC runbook here to understand the configuration details to deploy via F5 XC Services Console and also by leveraging the terraform automation scripts


As organizations realize the benefits of MCN and build distributed cloud applications, managing these workloads will not be an easy task, through this POC we showcased how F5 XC Services was able to simplify the management & security of a distributed cloud application, it served as a central plane of management to discover services across four Kubernetes clusters that were spread across four cloud providers.

Imagine your DevOps team managing these cloud providers via several native tools, they would need to scale up and have knowledge of all these cloud providers, deploy and manage cloud specific WAF's, Application gateways, Load Balancers etc. and then compare that with F5 XC Services, your DevOps teams can just leverage the F5 XC Services terraform providers and configure all these resources in a consistent fashion, resulting in cost savings, freeing up cycles for your teams to focus on other priority tasks.

Want to explore more on F5 XC Services?

Have a use case that you want to try and explore more on F5 XC Services? please reach out to our team of experts by clicking here. WWT has a dedicated F5 XC Services tenant, our team of experts can work with you and help you with your MCN journey.

You can also explore several simulators provided by clicking here.

What is F5 Distributed Cloud Platform ?

F5 Distributed Cloud Services (F5 XC Services) is a modern SaaS-based platform that consolidates multiple services across monolithic and microservices applications to simplify app management, security, and network connectivity across distributed infrastructure. F5 XC Services can seamlessly work with public cloud providers , private cloud providers (on-prem), and it provides a unified platform that allows creating remote application deployment sites called CE's (Customer Edge) by deploying cloud mesh nodes and securely connecting them via the RE's (Regional Edge) of F5's global network.

F5 Distributed cloud platform overview

F5 Distributed Cloud Global Network

F5 XC's global network is a private dedicated backbone network with point of presence(PoPs) deployed globally, it has multiple transit and peering connections to provide high-performance direct connectivity to public clouds, enterprise private clouds, and edge sites. These PoPs deliver security and connectivity services, a globally distributed control plane, and hosting of high performance and latency-sensitive workloads. The picture below represents the logical topology of the F5 XC Services connecting multiple remote sites.

Site to Site connectivity using F5 cloud global network


Global Infrastructure consist of RE and the individual Nodes are called CE

This global network is securely shared and supports multi-tenancy, customers can manage their respective namespaces depending on the roles assigned, they can also create overlay networks on top of the global network to interconnect resources in remote sites or expose application services to the Internet.