This blog post was co-written by John Carden, Drew Malone, and Derek Tracy.
Kubernetes has become the de-facto platform for containerized applications. But it’s a fractured environment and each Kubernetes distribution has their own nuances. Further, much of today’s cloud native software design assumes a healthy Internet connection, which is not always available. What’s missing is a standardized way to deliver applications on top of any Kubernetes, without an Internet connection (also known as air-gapped deployments).
Air-gapped deployments are common scenarios with the United States Department of Defense and other high security environments that also include the tactical edge—a smaller compute footprint made to run mission applications on limited hardware, often with little-to-zero outside network connections.
Put together, there is a gap on how to reliably deploy Kubernetes applications into disconnected tactical edge sites. What we need is a single answer to questions like:
- How do I build my container image?
- How do I deploy my app?
- What are my security controls and how am I addressing them?
- How do I make all of the above work in air-gapped deployments?
Creating a workflow with a single answer to questions like these offers two key benefits. One, it lowers the operational friction typically involved with deploying code to a location other than one’s laptop and two, it drastically improves our speed (thus, updates are pushed to the mission in days, not weeks/months/years). Getting the answer for one of these questions means standardizing a few things. Let’s look at a real-world example of this.
When you’re an emergency medical technician (EMT) and you’re in a moving ambulance providing care for a victim, where are the bandages? Where are the scissors? Do you know where the alcohol pads are? Yes, you do. They’re in the exact same location in this ambulance as they are for every other ambulance in the fleet. Why is that? It’s because ambulances are stocked in an identical manner in every ambulance. That way, there is only ever one answer to the question, “Where are the bandages?”
In short, they standardize everything.
We can do the same thing with our Kubernetes clusters. To continue the ambulance example, if our Kubernetes clusters are the ambulance, then the platform we build in our Kubernetes cluster is the way we stock it.
Contents of a Boxer Multi-Role Armored Vehicle (MRAV) of the Royal Netherlands Army. (Source: imgur)
Tanzu Application Platform simplifies Kubernetes
Consider the usual development model, where we develop/integrate/deploy all in the same environment.
But what about when we send our code away from HQ? Deploying means a lot of things with a lot of artifacts. What are your artifacts? Container images? Kubernetes manifests? What else? And how do you carry an artifact from HQ out to your tactical edge site when there’s no Internet connection?
VMware Tanzu Application Platform automatically builds the container image for you and also creates the Kubernetes manifest files for you. It then packages all these artifacts into a single object—a workload, consisting of the container images plus the Kubernetes manifest files that describe how to deploy your app. All the dependencies are bundled into this workload, removing the need for an Internet connection when we deploy.
We can take this workload, deliver it to our disconnected tactical edge site (via a satellite link, thumb drive, or whatever means we have), and deploy it to our tactical edge site in the exact same way we do at HQ.
Let’s think through what happens when we don’t have this level of standardization.
Suppose we have just our Kubernetes cluster. How do we build our container images? Well, we can use the tried-and-true Dockerfile route, but now we’re on the hook to maintain 1) the Docker base image, and 2) the Dockerfile itself. Every cycle we spend curating our Dockerfile workflow is a cycle not spent on new features and bug fixes.
Okay, so we can build our container image with Dockerfiles. What about deployment? As a reminder, the required skillset for the question, “How do I deploy my app?” is so complex that there’s an entire certification for it. So in addition to curating Dockerfiles, we’re also responsible for curating the Kubernetes manifest files. This is guaranteed to introduce variability, which is the opposite of standardization, which means mission updates become very complicated, very quickly. This results in delays to new mission releases making it where they belong—in production.
Tanzu Application Platform simplifies these decisions and standardizes the workflow, which is how it allows you to run your application anywhere. And because of the workload packaging, air-gapped deployments work just as intended, meaning you get updates to mission software in days instead of weeks or months.
Tanzu Application Platform’s air-gap support ensures that components, upgrades, and patches are made available to the system and that they operate consistently and correctly in the controlled environment—in addition to keeping the organization’s data more secure at all times.
Build once, deploy anywhere
Let’s talk about choice; specifically, the choice of which Kubernetes to run on. You can’t always guarantee that your favorite Kubernetes distribution is going to be available at your tactical edge site. In fact, there are Kubernetes distributions made specifically for small, tactical edge locations. In that world, let’s take advantage of our large Kubernetes installation at HQ, where we have the horsepower to conduct our full scans, tests, and packaging. Then at our tactical edge sites, let’s use only what’s necessary to run our (already tested, scanned, and built) application.
Tanzu Application Platform is a modular platform, meaning you only deploy what you need, where you need it. At HQ, you can run your Full profile, which includes everything in the platform. You have all your developer utilities, all your scans, packaging, and customizations. When it’s time to deploy your application around the world, simply install the Run profile, which is a pared down instance of Tanzu Application Platform that only runs applications on your tactical edge site. This can be called the Just Enough Platform. By using only what you need, you can make the most out of the limited hardware in your tactical edge site. And because it runs on any Kubernetes, it doesn't matter what distribution is in your tactical edge site.
A defense for standardization
Standards may sound boring, but they’re critical to having a reliable path to production. By standardizing our application platform, we simplify the challenges of running in a heterogenous world filled with a variety of Kubernetes clusters. By packaging workloads in the same way, we know they can be reliably deployed into a disconnected tactical edge site. We can have a single answer to many of the questions developers face and we can make the most out of our air-gapped, tactical edge locations by running a Just Enough Platform to run our applications the same way, on any Kubernetes cluster.
Learn more
Want to learn more about Tanzu Application Platform? Visit the site for updates and resources, and be sure to check out our latest content on the Tanzu Application Platform Tech Zone page.
