 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
One of the critical gaps in Kubernetes is the clean separation of concerns between developers and operators. As a passionate cloud native evangelist, I love Kubernetes. But, the lack of a developer-oriented application platform for Kubernetes has been my pet peeve for a long time.
Last week, when I saw the release of VMware Tanzu Application Platform (TAP) 1.0, I was genuinely excited. It took a few hours to deploy TAP on an existing Kubernetes cluster-based on Google Kubernetes Engine. Once I was able to access the UI and the platform, I dug into the details by exploring the documentation and trying the developer workflow.
VMware TAP is highly influenced by the company’s lineage of building application platforms, frameworks, and tools based on Cloud Foundry and Spring Boot. Developers familiar with Spring Initializr will instantly relate to the bootstrapping workflow provided by Tanzu Application Accelerators. As a Cloud Foundry developer, I appreciated the workflow of binding pre-provisioned stateful resources such as RabbitMQ and PostgreSQL with TAP applications.
VMware built TAP for enterprise developers assembling/building internal and external applications based on microservices. I use the term assembling because modern applications are increasingly becoming composable and a collection of various open source components.
There are three broad user personas for TAP — platform operator (PlatformOps), application developer(AppDev), and developer security operator (DevSecOps).
The platform operator is responsible for installing and configuring TAP on top of a Kubernetes cluster. They focus on overlaying the platform that integrates with existing building blocks of Kubernetes, such as the Container Networking Interface (CNI) and the Container Storage Interface (CSI).
The ultimate goal of the platform operations team is to expose AppDev and DevSecOps platforms that abstract Kubernetes primitives while exposing the essential functionality needed to build and operate modern applications. She can also publish best practices and organization-specific conventions as policies that will be adhered to by the developers and operators.
An application developer building on TAP doesn’t need to know or deal with behind-the-scenes stuff of the cloud native stack such as image builders, scanners, image registries, RBAC, ingress, and others. He focuses on writing code, debugging it, and iterating over the process to improvise it.
Developers can use a combination of CLI and a code editor or an IDE plugin that automates the process through seamless integration with TAP. VMware calls this workflow of developing, debugging, and iterating as an inner loop. They get a personal environment that closely resembles the production environment.
The developer security operator takes the code built by the developer to the production environment. He has complete visibility and control over the supply chain responsible for building the images, performing automated and manual/functional testing, scanning and signing the images, storing them in a secure registry, and deploying and running the application. This is referred to as an outer loop that occurs outside of core development and debugging.
TAP provides an out-of-the-box (OOTB) workflow for DevSecOps based on the best-of-the-breed open source projects. But the enterprise team can easily customize the workflow by swapping the OOTB components and even altering the steps and process. For example, the OOTB workflow can be altered to generate Helm charts and store them in a chart repo as versioned artifacts before deploying the apps.
VMware Tanzu Application Platform is a double-sided sticker. One side of the platform is stuck to Kubernetes, while the other is meant for modern applications. Enterprises can adopt a consistent developer environment and workflow as long as the deployment target runs TAP.
TAP can be configured on mainstream managed Kubernetes offerings, including those by Amazon Web Services, Microsoft Azure, and the Google Cloud Platform. Developers can even install it on Minikube based on Hyperkit for macOS. The tanzu CLI is pointed to the cluster running TAP to implement the workflow.
The best thing about TAP is that it treats Kubernetes as the lowest common denominator building the platform abstractions on top of it. This is fundamentally different from the approach that Red Hat has taken for building OpenShift. Comparing Red Hat OpenShift with VMware Tanzu Application Platform deserves a separate article that I am going to publish in the near future.
The other thing to note is that TAP is not Cloud Foundry. The official and commercial implementation of Cloud Foundry is available as Tanzu Application Service (TAS), which is the latest reincarnation of Pivotal Application Service (PAS). The key difference between TAP and TAS is the target environment.
The former is designed for Kubernetes clusters, while the latter is meant to run virtual machines. Though TAS can also be deployed on Kubernetes, VMware is positioning it as the PaaS layer for VMs. Some of the open source projects such as Cloud Native Build Packs (CNAB) and kpack may be common to both the implementations, but there is a subtle difference in the user personas and use cases between TAP and TAS.
On a different note, VMware has some work to do in simplifying the Tanzu brand which has multiple overlapping offerings. From a branding perspective, Tanzu is turning out to be another vRealize that’s an umbrella brand for various products.
TAP implements everything that happens between committing the code to running it in production within the context of Kubernetes. From CI/CD pipelines to monitoring and scaling, the production deployment takes place on Kubernetes. This brings transparency, flexibility, and modularity to the platform.
If you are curious about how platforms are built on Kubernetes, you should study two implementations — Tanzu Application Platform and Kubeflow. Both are excellent examples of how Kubernetes can be the meta platform for niche, purpose-built abstractions.
In one of the upcoming articles, we will explore how TAP transforms a plain vanilla Kubernetes cluster into a developer-oriented application platform. In the following article, I will walk you through the steps of installing TAP on a GKE cluster and building/running your first cloud native application on it. Stay tuned!
