What is Multi-Cloud Application Network?

And Why Do You Need One?

The Origin of the Multi-Cloud Application Network (MCAN)

Software application structure has shifted from ‘monolithic’, where the functions of the application communicate in RAM, to ‘Micro-Services’ or Service Oriented Architecture (SOA), where the functions communicate over a network.  So, by definition, all modern applications require a network, and you could generically refer to that network as an ‘application network’.  

In practice, we don’t often use that term, especially when we run an application in a single cluster or cloud instance. Instead, we just simply call the network a LAN, VPC or Subnet, etc.  However, when you run your application across multiple clusters or clouds, you almost always use a shared Wide Area Network (WAN), like the internet.  

This is where the concept of ‘multi-cloud application network’ is born.  

When your application pieces need to communicate across clouds and/or clusters, you have many new concerns that you did not have with a single cluster application.  For example, you now need to:

• Discover/Control which application pieces (containers and services) are in which cloud

• Set up a gateway in each cloud

• Tell all the clouds how to reach each other

• Resolve cloud domain and service names in remote clouds

• Globally load balance services (for cloud, cluster, and service protection)

• Authenticate network access to only your approved application pieces

• Distribute keys and encrypt all communication

​

And every time your application changes, you need to update all of the above.  Quite a lot to do!

A Kubernetes Application Operations Platform with a “Multi-Cloud Application Network” (MCAN) feature does all this and more.  

​

A Multi-Cloud Application Network is a network that is aware of all your application pieces, in all your clouds (clusters), and can securely connect and balance all of the application communication.  This concept was pioneered by skupper.io and it is sometimes called a Virtual Application Network (VAN).

​

An Overlay Network for your application

A Multi-Cloud Application Network  uses a peer-to-peer overlay network, meaning a network of virtual links between services running in the underlying physical networks.  If you are not familiar with the term ‘overlay’, the most common example of an overlay network is a VPN, which similarly allows an employee to securely access the corporate network, regardless of what network the employee’s device is attached to.  

​

An overlay network has the benefit that it can be set up and modified without affecting the underlying networks.  In a multi-cloud scenario, this is powerful, as you might have a different type of network in each of your clouds.  Modifying and integrating these ‘underlay’ networks directly would require that you be an expert on each cloud’s network configuration and APIs, and can integrate and automate it to your app's liking.  

​

This is challenging, and sometimes not possible.  

​

For example, how can you be sure that the underlay networks are properly modified when your app changes?  What if a change you make in the underlay network has unintended consequences for the application?  What if you have duplication subnet or IP addresses in two underlying networks?  How do you resolve the conflict?  

The benefit of an overlay network, like a Multi-Cloud Application Network, is that you don’t have to understand, communicate with, integrate or automate the underlying networks.  Instead, a Multi-Cloud Application Network accesses each of the underlay networks like any simple client would, and then establishes its own overlay network, where it has full control over the multi-cloud communications.  

​

This means you can easily operate a Multi-Cloud Application Network across all sorts of clouds, whether private clouds with Cisco networks, or multiple cloud instances from the same provider, or even multiple cloud providers like AWS, GCP, Azure, without designing to the APIs or learning their network tools.

​

A Network for DevOps self-service (not NetOps or SecOps)

Another important aspect of a Multi-Cloud Application Network, is that it is created, configured, and maintained by application operators, not network operators.  This is important.  Application operators don’t want to operate a traditional IP network, where they manage IP addresses, Routers, Firewalls, VPNs, etc.  

​

They also don’t want to be dependent upon a network operator for their app communication needs. Their applications are too dynamic to worry about such concerns. Instead, they want to ‘self-service’ application connectivity, decoupled from the IP details.  

Kubernetes is dominating application infrastructure for just this reason.  Kubernetes abstracts away the IP details, allowing application teams to focus on the application, instead of the IP hosts in the network.  However, Kubernetes can only do this for a single Kubernetes domain (cluster).  When an app spans multiple Kubernetes clusters, someone needs to deal with all the IP, router, and security details between clusters.  

If that someone is a network operator, the thing they build is just a TCP/IP network, and it doesn’t know anything about application services.  When the application needs change, which is often several times a day, the network operator needs to update the network to stay in sync with the application.  

A Multi-Cloud Application Network is different, because it is controlled by the application team, allowing them to focus on the application instead of the underlying networks.  A Multi-Cloud Application Network helps preserve the agility of microservices and Kubernetes across multiple clusters.

Why use a Multi-Cloud Application Network (MCAN)?

In summary, a Multi-Cloud Application Network is an application-aware overlay network for application operators to easily connect their application services across clouds and clusters.  

The main reasons why you would use a KAOPS's Multi-Cloud Application Network are to: 

• Operate an application across multiple K8s clouds/clusters

• Connect different types of clouds (private, public, hybrid, edge)

• Secure your application communication (AuthN/Z, mTLS)

• Protect your cloud/cluster from failures with global load balancing

• Dynamically update your application connectivity without modifying your network(s)

• Avoid detailed cloud network configuration and integrations

• Monitor your application services and health across clouds