The Challenges of Kubernetes
In today’s world, the technology industry is heavily invested in migrating to modern application platforms that utilize container technologies such as Kubernetes.
While the move to containers and a microservices architecture has huge benefits, there are many challenges when trying to implement a Kubernetes deployment that makes the transition very complex:
1. Steep learning curve
2. Lack of standardization
3. Many moving parts
4. Hard to configure and manage at scale
5. Undefined path to production
6. No concept of an application
Let’s try to understand these challenges a bit more.
Steep Learning Curve
Kubernetes is a very robust system that exposes huge flexibility and a very wide API surface, allowing for nearly anything to be possible.
While this offers great capabilities, it can be very overwhelming and very difficult to fully grasp all of the capabilities in the system.
Not only is Kubernetes itself a complex system, but it is also just the starting point. To productionize it, knowledge of a whole set of complementary tools – like logging, monitoring, networking, storage, and more – is also required.
Lack of Standardization
Due to the complexity and the wide API surface Kubernetes offers, developers and platform operators will inevitably deploy applications in many ways based on what they know and very often based on examples they have found on the internet.
While having such a vibrant community like that of the Kubernetes ecosystem is an amazing asset, everyone implements things a bit differently, and the lack of standardization makes debugging issues and understanding topologies of your specific environment very difficult while also complicating auditability, which is a key issue for many sectors.
Many Moving Parts
Kubernetes has a distributed architecture and is a pluggable system. In a typical Kubernetes deployment, beyond the various components of the Kubernetes cluster itself, you will typically need 10-20 additional tools to really productionize the environment. This includes things like:
1. CNI – Container Networking Interface
2. CSI – Container Storage Interface
3. Ingress Controller – Layer 7 ingress Load Balancing
4. Policy Management tools (OPA, Kyverno, etc.)
5. Load Balancing Solution – Layer 4 ingress load balancing solution
6. Monitoring suite for your applications
7. Logging mechanism for the platform as well as your applications
8. Backup solutions
9. Deployment tools (ArgoCD, Flux, Helm, Carvel, etc.)
10. Security Tooling – (Image scanning, Runtime protection, etc.)
Maintaining the interoperability of all of these tools is a very complex and time-consuming task.
Hard to configure and manage at scale
While managing one Kubernetes cluster is already a complex task, managing a fleet of clusters, sometimes across different clouds and geo-locations is even more complex. Every cloud provider has its own unique configuration of Kubernetes and its own technical stack that accompanies Kubernetes. Things like authentication, networking, and storage across vendors are always key points of difference, making the management of such environments even that much more complex.
Un-Defined Path to Production
When discussing platforms for applications, the path to production also needs to be considered. How do we promote an application between different environments all the way from development to production?
While this is possible on Kubernetes, as everything is declarative and can be managed via methodologies such as GitOps, it is all external to the Kubernetes platform itself and requires significant custom logic and orchestration to properly fit the needs of your environment.
No concept of an application
While Kubernetes is an excellent platform for running applications, there is nothing in the core Kubernetes world called “application.” Kubernetes knows, essentially, what containers, pods, network services, disks, etc. are, but doesn’t exactly recognize the concept of what an application is.
Why is this the case?
As Kelsey Hightower, the famous creator of “Kubernetes the Hard Way” put it, “Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.”
Having such a broad API surface is a huge advantage, as it means that from a single interface you can manage all aspects needed for an application platform, such as Storage, Networking, Resource Management, and much more.
The pluggability of Kubernetes and the lack of a standard way to do things is actually a design decision. The pluggability of the system makes Kubernetes a relevant layer for almost any environment and allows for the idea of becoming a “universal control plane,” as Joe Beda, one of the creators of Kubernetes, likes to call it.
PaaS of the past
One way of approaching these challenges throughout the years has been through PaaS (Platform as a Service) systems such as Cloud Foundry, Heroku, OpenShift, etc.
These systems make deploying applications easier, but they have their limitations.
A traditional PaaS platform is basically a very opinionated, closed system that acts as a “Magic Box.” You give it code as an input, and it outputs a connection URL for your application.
While this makes the life of your developers very easy, it doesn’t solve many needs of organizations today.
The opinionated nature of these systems was developed based on a “one size fits all” approach, which is simply not relevant anymore.
Further, by using a closed system, there is a risk in certain cases of becoming locked into a specific platform. It becomes very difficult to move from one PaaS to another because each of these PaaS systems do things a bit differently and there is no clear migration path from one PaaS to another.
Another key challenge in the PaaS world is that, typically, a PaaS platform is scoped to a single Cluster/Foundation. This means that while for a single environment we can have a good developer experience from Source Code to a running app in a very short amount of time, there is no easy way to have a promotion path for our application from development through staging and QA and finally into production.
The Nex Gen PaaS with Tanzu Application Platform
Tanzu Application Platform (TAP) is a packaged set of components that helps developers and operators to build, deploy, and manage apps on a Kubernetes platform more easily.
TAP is the latest innovation in this space from VMware and is a true game-changer.
TAP builds upon the community-adopted tooling and the existing products within the Tanzu Advanced Suite to offer a Next Gen PaaS Solution that aims to solve the same challenges the Traditional PaaS systems solve, while at the same point tackling the issues they brought along with them.
TAP aims to simplify the development workflows as well as the deployment workflows.
When defining these workflows, we can separate them into 2 main categories:
1. Inner Loop
2. Outer Loop
The inner loop is the local development environment. This is where the developers spend most of their time. It includes tasks such as writing code, committing that code to git, and deploying to development and/or staging environments.
The key pain points that TAP offers solutions for in this area are:
1. Integration with the developer’s IDE (for example VSCode)
2. Quick Iterative development workflows
3. Quick feedback on issues in your code
4. Easy debugging of your application
5. Easy start for building Apps according to your companies’ standards
TAP solves this issue with proprietary tools like the VSCode extension for TAP, which offers amazing capabilities for live updating code running on a local or remote development cluster directly from your IDE, utilizing the industry-standard tool, Tilt. It also offers live debugging of your running application directly from your IDE.
Another key tool in this space is the Application Accelerator. Application Accelerator is an amazing tool that allows SREs, Architects, or Platform teams to create custom boilerplate templates for the types of applications that will be developed within the organization, which include within them all of the companies’ best practices and conformant configurations. This allows a developer to begin with a pre-configured template whenever developing a new service.
Through App Accelerator, the Accelerator Author can provide input parameters that the developer can fill out that will be applied to the template so that the developers’ inputs are automatically updated in the generated code, again allowing for a very quick and simple process to start on any new project.
The Outer Loop is the workflow of deploying apps to production and constantly maintaining them over time in a secure manner.
This outer loop contains additional key components such as image scanning, source code scanning, image signing, CI integration with Tekton, and more, which are all integral parts in the process of promoting Apps to production.
Key Components in TAP
Some of the key components in TAP include:
1. Tanzu Build Service – The commercial offering from VMware, which is based on Kpack, an open-source Kubernetes native implementation of the Cloud Native Buildpacks Specification. This allows you to easily provide Source to image capabilities with constant updating, security patching, and image signing, all based on industry standards with efficiency and security at the forefront.
2. Tanzu Cloud Native Runtimes – the commercial offering from VMware for Knative. Knative is built on top of Kubernetes, abstracting away the complex details, and enabling developers to focus on what matters. Built by codifying the best practices shared by successful real-world implementations, Knative solves the “boring but difficult” parts of deploying and managing cloud-native services so you don’t have to. Knative offers amazing features such as scale to zero, revision management, traffic shaping, and many other amazing features in a simple and composable way.
3. Application Live View – A lightweight insights and troubleshooting tool that helps application developers and application operators to look inside running applications. This is based on the Spring Boot Actuators concept and brings amazing visibility into applications running on the TAP platform.
4. Source Controller – Based on the industry-standard Flux GitOps tooling, The Tanzu Source controller allows the platform to work in a fully managed and supported GitOps manner.
5. TAP GUI – this is the UI portal for TAP that is based off the amazing upstream highly adopted Backstage project. This UI allows for a simple and yet very powerful UI for the platform, which can be a single plane of glass into your company’s applications. The GUI can give you a single place to see the status of your applications, where the source code lives, what dependencies exist between your different components, and even view the technical docs for your application all from a single UI. The UI also integrates with the Application Live View and Application Accelerator making it a true end-to-end UI experience for you developers and platform operators to manage and visualize your environment.
6. Application Accelerator – A tool that helps bootstrap the development of applications and their deployment in a discoverable and repeatable manner. It allows Enterprise Architects to define and codify best practices and organizational standard based boilerplate code and then let the developers simply consume these starter packs when beginning to develop a new application or microservice.
7. API Portal – Enables API consumers to find APIs they can use in their own applications. Consumers can view detailed API documentation and try out an API to see if it will meet their needs. An API portal operator can add any number of OpenAPI source URLs to be displayed in a single instance. This can allow for greatly simplifying the API discoverability in your organization and make the integration points between your different microservices a much more streamlined process.
As you can see, TAP provides true value in many different areas of our application lifecycle. While we briefly discussed seven of the components in the platform, there are actually thirty different components of the platform, each solving a unique need and challenge in the applications lifecycle.
What Makes TAP different
TAP has a lot of great tooling to help with our lifecycle management of applications from the time of development to production and beyond. But with full transparency, so do other PaaS systems.
What truly makes TAP a game-changer is the Key tool we haven’t even discussed yet, which is the Supply Chain Choreographer for Tanzu. This component is the heart of TAP and is based on the open-source project Cartographer.
This tool is basically a way of choreographing a supply chain for the lifecycle of our application in a modular and composable manner.
By having the system use a system Cartographer as its backend, we gain the huge advantage of composability and modularity that were the key pain points of the traditional PaaS platforms.
We can create multiple Supply Chains in our cluster, each targeting a specific type of application needs. These supply chains, as they are fully modular, allow us to switch out components or configurations in a very simple and declarative manner.
We can, for example, replace Tekton with JenkinsX or ArgoWorkflows for CI tasks. We can replace Tanzu Build service with other technologies like Kaniko, we can replace the source code scanning and image scanning from using Grype to using something like Aqua, Snyk, or really anything that we would like to use. We could also replace the Knative deployment mechanism with raw Kubernetes manifests or Helm Charts based on the needs and conventions within your own organization.
Having this type of flexibility within a PaaS platform is a true game-changer. We can adopt the fully opinionated approach like a traditional PaaS with the built-in best practice suggestions and configurations provided, tested, and validated by VMware, or we can go as wild as needed to adapt the platform to our own custom use cases and existing Tech Stack.
Installing TAP is also a simple and streamlined process.
TAP is probably the easiest PaaS to install, as it is a single-click install and can work on nearly ANY Kubernetes cluster.
I have personally installed TAP on GKE, EKS, TCE, TKGm, TKGs, Minikube, and Kind clusters and it is truly awesome to see that TAP is really built for any Kubernetes platform and can offer the amazing capabilities and flexibility of the first of its kind Next Gen PaaS platform to you no matter what Kubernetes distribution you decide to use or where that cluster is running.
We utilize the amazing Tanzu CLI to install TAP. The installation is a fully composable process allowing for installing the full stack as a single installation or choosing to install only the packages you care about again in a single installation command.
TAP’s roadmap and vision are amazing, and I can truly see it becoming an industry standard for Kubernetes-based deployments across any cloud and any distribution.
TAP is still in its initial days and will have some growing pains at the beginning, but I have never been so impressed with a platform in its initial days.
While I think that watching what VMware will do with the product is going to be a very interesting and amazing thing to watch, what I am most excited about is seeing where organizations take this platform. Thanks to its flexibility, the sky really is the limit, and I can’t wait to see how companies utilize this first-of-its-kind, flexible PaaS within their environments to improve the developer experience and truly enhance the security, reproducibility, standardization, compliance, and visibility in their Modern Application platform.
Building on top of industry-standard tooling like, Tekton, Grype, Backstage, Tilt, VSCode, Knative, Flux, Contour, and others allows for a truly amazing experience and easy onboarding to the system.
Having the composability and flexibility of Kubernetes with the Dev experience of a PaaS is going to be a huge asset to many organizations.
I am truly excited for what is to come with the Tanzu portfolio as a whole, and with TAP in particular.