Containerized Air Gapped Edge Platform Architecture

Introduction

An emerging use case for containerized platforms has been the ability to deploy applications in what is termed as an air-gapped deployment. This deployment pattern is particularly pronounced around edge computing (more on that later in the blog series) – though there exist significant differences between edge clusters and air-gapped deployments.

Air-gapped applications are those that run isolated from datacenter or internet connectivity.

In verticals such as telco, retail, real estate & healthcare, intelligent applications are deployed around really small or ‘micro’ data centers with a view of performing customer-centric operations at a retail store, oil rig or customer premises. These operations have value only in the interaction time available – for instance, the customer’s attention is captive & round tripping to the main data center introduces the risk of losing the sale/purchase, etc. These include use cases such as real-time promotions/couponing, image/audio recognition, sensor measurement, and real-time fraud detection. The idea is that the application at the point of customer contact has an amount of intelligence built into it. These applications also perform analysis to ensure that data volumes sent to the main application are ’thin’ and curated. A large percentage of these applications introduce another unique requirement – they need to be able air-gapped i.e at times be able to tolerate intermittent lack of connectivity to the data center. This is typically for business and sometimes for security considerations.

Key Architectural Requirements for Airgapped Applications

So, what are some of the key requirements of air-gapped applications from an architectural perspective –

1. Support a truly distributed architecture that can accommodate a mix of business workloads of various kinds running at a location – e.g. web servers, microservices fronted by APIs, functions-as-a-service, NoSQL datastores and data analytics (machine learning & AI)
2. Given the resource-constrained nature of such deployments, the ability to support efficient usage of hardware resources across multiple deployments is key. The platform needs to accommodate running on a mix of CPUs, FPGA accelerators, GPUs, etc.
3. The ability to support multi-tenancy from both an application and a user standpoint both from a resource as well as a security standpoint
4. Support automated lifecycle management of applications and platform – remote installation, platform & app updates, service mesh based traffic shaping for applications based on usage patterns, performance monitoring/logging & troubleshooting, disaster recovery, and failover. Such automation should not depend on constant connectivity to the remote datacenter
5. Support a Dev-SecOps style of development and updating of both application & platform releases. Most times, connectivity is not available and that implies an ability to pull in application updates from a remote or a proxied local Git repository (usually via secure TLS proxy). In extreme cases where the environment is completely offline, there is usually some provision to use USB or CDs albeit in a secure manner

Considering the above requirements, containers and Kubernetes provide the ideal foundation for building these applications. Containers are much more efficient in their usage of resources such as CPU, Memory, and Network – provided by an underlying OS. Kubernetes works as well on a bare metal system (with just an OS and no Virtualization layer) as well as on any underlying hypervisor. Administrators can set up virtual clusters with namespaces that correspond to users with specific resource quotas.

A Reference Architecture for The Open Banking Standard..

The Airgapped Architecture Model –

1. Single or Multiple Masters running nearest to the customer
2. Workers in the Edge Locations running on Baremetal or an IaaS layer (VMware or OpenStack) or a traditional hypervisor (KVM or VMware)
3. Edges do not have a lot of computing power and thus run only one cluster per edge site
4. Typically Gateways installed at the Air gapped Edges that communicate with the equipment when connectivity is restored. Note that Gateways are an optional aspect of the architecture
5. The state of the application is stored at the Edge due to the air-gapped constraints
6. The need to perform independent updates and traffic shaping for Edge Applications

Conclusion

The rate of innovation on the container platforms scene has been nothing short of astounding. Thus, enterprises are looking to standardize on using Kubernetes as the platform to build, deploy and maintain their applications that need to run in a hybrid cloud environment.  Kubernetes is the new Operating System (OS) layer to standardize not just traditional datacenter applications but also hybrid clouds & edge/airgapped implementations. This trend helps derisk enterprises from the diversity of platforms they must support.

The next post will introduce and discuss KlusterKit, a new and exciting open source project that aims to standardize airgapped cloud-native efforts on  k8s while simplifying support for Day-1, Day-2 operations. KlusterKit has been developed & open-sourced at Platform9 by  Arun Sriraman and Daniel Lipovetsky.