By Raj Nair, CEO Avesha
Introduction
The ideal of the “cloud-native” era has always been the ability to get compute any time on-demand as a utility. Compute is a like a utility, but it is also different in that workloads running in a location need to be able to collaborate with workloads running at other locations seamlessly – in other words, application developers take for granted network connectivity. Yet, workloads are locked into clusters because of difficulties in crossing administrative domains (e.g., across clouds or regions or data centers) that requires IT support. Developers really want an easy container-level mechanism that allows connectivity across cluster boundaries and lets developers forget about the network below. This is where an application fabric comes in. It is an application-specific private network abstraction that extends the familiar notion of a cluster, a flat network that enables seamless application communications, to one that transcends all network boundaries and works across the Internet.
An application fabric is a flat network in which there are no gateways or IP address overlaps or translations to worry about. Traffic seamlessly flows from a pod in one cluster to a pod in another far away cluster. The “magic” of a seamless connectivity is created by an overlay that connects the two clusters and is created automatically on-demand. Services in the remote cluster are discoverable just like other local services through a controller pod that “advertises” these remote services locally. Thus, an application fabric truly enables workloads to “roam” to the most ideal location for it.
The rationale for such flexibility in deployment comes from 5 requirements: (1) avoid cloud provider lock-in; (2) support resiliency; (3) handle business situations such as M&A; (4) support low-latency applications; and (5) facilitate migrations. While the first three are obvious, the latter two need a bit of explanation. Low-latency applications may require workloads to run close enough to the client to overcome speed-of-light constraints. Migrations on the other hand can take a while to achieve and need the ability to run workloads partly in the cloud and partly on-prem while continuing to operate the business functions as normal.
Current Cluster Connectivity Issues
The present situation is one where inter-pod connectivity is often done with great effort requiring the involvement of IT personnel to create special cases for each application at each firewall. This not only creates delays for application development but also creates a nightmare for security personnel because it is yet another exception to be justified in a security audit. The real question to ask is why should pods belonging to the same application and same customer must traverse the North-South (N-S) path of all Internet traffic when crossing cluster and cloud boundaries. Clearly, there is a better and more efficient way that will free up the deployment of pods.
Another area of difficulty is the orientation of existing tools such as service meshes or application gateways toward http-centric traffic. The issue is that several workloads use non-http protocols for database or streaming use cases making it difficult to transport over existing N-S paths.
Finally, there is the problem of finding IP addresses that do not overlap – a perennial issue for IT teams stemming from the fact that clusters have private IP addresses that are not coordinated across different administrative domains. Hence, the search for an unused range becomes a quadratically increasing problem as more clusters need to collaborate and gets increasingly challenging as more applications need such connectivity because of IP address space exhaustion.
An application fabric addresses all these problems and offers some other unexpected benefits as explained below.
An Application Fabric for Kubernetes
An application fabric offers a flat network without gateways or translations to allow traffic to seamlessly flow from a pod in one cluster to a pod in another remote cluster without any special effort. Furthermore, all the addressing and routing are local to this network with its own name resolution that works across the network and supports topology-awareness. Such a network is possible by an overlay that connects locations using a network overlay (fabric) – created by a mesh of tunnels or other topologies. Services are discoverable across the fabric using a controller that distributes services among the participating clusters.
Isolation:
A benefit of an application fabric is that it is an island of connectivity and hence multiple instances of application fabrics can co-exist across the same set of clusters and yet use the exact same IP address range. Each fabric defines a closed group of microservices and namespaces belonging to an application and hence supports its own secure workspace in a “super cluster” with its own RBAC (Role-based Access Control) and resource quotas that can be applied at all locations uniformly. In short, an application fabric is a unit of tenancy. Its security is ensured in a uniform manner at all locations. Pods on the application fabric can have mTLS authentication across the fabric. Moreover, any virus or exploit in one application fabric is contained within it and cannot leak over to other fabrics thereby limiting the blast radius. Finally, the application fabric creates a boundary to limit the viewing and monitoring to the status of a specific application but across its entire geographical deployment. This can be valuable in troubleshooting and gauging the overall health of the deployment.
Application fabrics are software-defined entities that may be automated via operators and can be driven via api, GUI or Gitops pipelines to provide on-demand instantaneous connectivity for applications. An application is on-boarded to an application fabric by identifying the specific application fabric via the namespace membership in its yaml file. The rest of the process is completely automatable. A good example of an implementation of an application fabric is the KubeSlice – an open source project at github.com/kubeslice. The reader is encourage to go experiment with the KubeSlice and create and contribute interesting automations for modern application deployments.
Applications:
There are several uses for an application fabric; but the most compelling ones are below.
- Migration – An organization needs to move some of its workloads to the cloud but would like to maintain an on-prem presence during the move. In this process, clearly it would need to have the flexibility of deploying its applications in a multi-location manner. An application fabric easily offers this flexibility.
- Resiliency – An organization wants to be able to insulate itself from cloud region failures and have a multi-location footprint together with a traffic-steering function to achieve uninterrupted operations. Here again, an application fabric offers the ability to have duplicate services across multiple locations with the ability to continuously synchronize data between these locations.
- Multi-cloud – An organization wants to support a multi-cloud footprint arising from a merger or acquisition or simply to be able to use the best cloud features offered by a specific cloud provider. In these cases, an application fabric can greatly simplify bringing together the disparate services spread across different cloud providers using an application fabric.
Conclusion
This paper describes the role of an application fabric in Kubernetes clusters. An application fabric is shown as a secure island of connectivity that can span any set of locations and can be created on-the-fly. It provides the ability to apply uniform policies across multiple clusters easily. Finally, the application fabric is a much-needed step in enabling true application mobility to support various important customer needs of migration, resiliency, and multi-cloud deployment.
##
To hear more about cloud native topics, join the Cloud Native Computing Foundation and the cloud native community at KubeCon + CloudNativeCon North America 2022 in Detroit (and virtual) from October 24-28.
ABOUT THE AUTHOR
Raj Nair, CEO Avesha
Raj Nair is a serial entrepreneur who has founded successful startups in the areas of cloud computing and media delivery. His first startup Arrowpoint Communications, invented L5 network load balancing and was acquired by Cisco Systems for $6B. Later, he co-founded Azuki Systems, a pioneer in Over-the-Top media delivery to phones and tablets and was acquired by Ericsson in 2014. Raj has over 35 patents in a range of communications technologies including content routing, security and load balancing.
