What is Tanzu? A Customer’s POV
Authors from Tanzu Vanguard Super User community
Let’s begin by explaining who we are: We are a group of VMware Tanzu customers referred to as Vanguards. The Vanguard community consists of engaged, vocal super users who share best practices with each other, share our stories publicly, and actively share our feedback with the product team within VMware Tanzu. In this post, we’re sharing our reasons for, and experiences with, using VMware technologies as part of our Kubernetes strategies.
What is Kubernetes, really?
There is, of course, a technical definition of Kubernetes that anyone can go and read on their own, but here is how we tend to think about Kubernetes as it relates to our daily lives running large platforms:
Why use a managed Kubernetes distribution?
The last two points above are the main drivers for deciding to use a managed, or vendor-provided, Kubernetes distribution rather than building and managing a Kubernetes environment from pure open source and/or best-of-breed components. Most of us view our primary responsibility as providing developers (and our organisations) with the platforms and tools that we can, although that goal is balanced against desires to (1) not break the bank, (2) not unnecessarily lock us into proprietary software, and (3) spend our time providing business value rather than managing Kubernetes clusters.
So, we look to vendor distributions to provide the things we need to deploy Kubernetes and have it be usable:
The VMware-Kubernetes connection?
VMware products are the most successful on-premises software for creating and managing VMs and their associated virtual infrastructure, like storage and networking. As a result, VMware is already very well positioned to extend its offerings into the container world as containers continue to consume certain VM workloads. This strategy is so important to VMware that it went as far as to integrate Kubernetes into its core ESXi hypervisor product.
But “just Kubernetes” is not enough. You need an ecosystem of capabilities around Kubernetes to make it work in production. Tanzu is VMware’s addition to this ecosystem (and the broader cloud native space), comprising a collection of commercial products and open-source projects. Often, the commercial products are built on top of or otherwise utilize open source.
It might seem like there’s a mismatch between VMware—which made its name selling proprietary virtualisation software—and the Kubernetes and cloud-native world—which is largely driven by open source projects—but that’s not entirely true. In fact, it was VMware that built and released the open-source Cloud Foundry project back in 2010, and VMware is once again?leading development on the open-source Spring framework (a role it first took on in 2009 upon its acquisition of SpringSource).
As it built out its cloud-native portfolio, VMware also acquired a handful of important open-source companies whose work is now part of the Tanzu portfolio, including Pivotal, Heptio, and Bitnami. VMware also manages a number of popular open-source Kubernetes-ecosystem projects, and the CNCF projects Harbor and Contour were created by VMware.
The result: the VMware Tanzu portfolio provides an opinionated, integrated, and commercially supported collection of proprietary and open-source software, meant to create an extensive managed Kubernetes offering. It also includes an integrated suite of tools to help developers build and deploy modern applications, or cloud-native, applications that don’t run on Kubernetes.
We buy and use Tanzu products because they help us meet the goals we laid out above. We’re improving on technical measures like developer productivity and application reliability while taking advantage of open source technologies. By doing this, we’re increasing the abilities of our organisations to compete in a digital-first economy.
So, what is the Tanzu portfolio?
The Tanzu portfolio covers a large number of products to achieve various levels of abstraction, developer experience, and capabilities. Some products of particular interest in the current Tanzu portfolio are:
However, it can be daunting to figure out how all these modern tools apply to your particular situation, especially if your organisation is only getting started with modernisation. So we’ll walk through them from the perspective of someone whose job is to manage infrastructure and platforms, but who isn’t yet a cloud-native or Kubernetes expert.
Level 1: (infrastructure and runtime)
First of all, you need a runtime platform suitable for your organisation. A runtime platform is basically what runs the application (or the service) you wish to expose.. In theory, a runtime could be as highly abstracted as a SaaS offering (you’re simply exposing an endpoint, but the application is running on the provider’s platform) or as minimally abstracted as hosting an application on bare metal. For the types of applications we’re talking about, however, your runtime platform will more likely fall between those two extremes.
Before we go over some of the options in the Tanzu portfolio, though, it might help to think about the typical IT consumption model—specifically by considering how much your developers need to bring along in order to get an application running at various levels of abstraction. We’re using “Pizza-as-a-Service” as an example to avoid getting too technical:?
领英推荐
CaaS gives you the ability to spin up Kubernetes clusters quickly to meet demand from developers (for custom software), or to host COTS software., However, when you choose CaaS you will still need to bring your own runtime (pizza), scaling (beer), functions (friends), and configuration (conversation).?Every public cloud provider has a native CaaS offering, although choosing an offering from a traditional software vendor (e.g., Tanzu Kubernetes Grid) gives you the option of running Kubernetes in your own data center or on the cloud instances of your choice. If you use Tanzu Kubernetes Grid, you also have the option to use Tanzu Application Catalog to deploy backing services (databases, backend systems, messaging, etc.) from a curated catalog, and Concourse for CI/CD and automated maintenance.?
Alternatively, your organisation may wish to push more to the right and use a PaaS (i.e., Tanzu Application Service). In this approach, you deploy a more opinionated platform where the developers do not need to know quite as much; all the developers need in order to get something up and running is the application code. As a generalisation, the further to the right you go, the quicker that things can be deployed.?
While moving to the right is very tempting and indeed makes deploying applications quicker, you must consider the tradeoffs of an opinionated system and make sure that the PaaS offering you choose will meet the needs of your applications and developers. Sometimes, they simply can’t support the same use cases that a less opinionated, more modular system (in this case, a CaaS offering like Tanzu Kubernetes Grid) can support. You can, however, build a PaaS-like experience on top of Kubernetes, if you’re so inclined (VMware has done this with Tanzu Application Platform, which we discuss later).
There are three versions of Tanzu Kubernetes Grid, each providing different capabilities, integrations, tooling, versioning, etc. It is important to note, however, that they are all using the same underlying conformant Kubernetes binaries and are all supported and maintained by VMware.?Tanzu Kubernetes Grid Integrated?is the oldest of the three flavours and is based on the same underlying stack as Tanzu Application Service (notably, BOSH is the resource manager). This version currently supports some features that are not yet available in the others, such as NCP (NSX Container Networking) and support for Windows Kubernetes nodes.?
Tanzu Kubernetes Grid Standard?embeds Kubernetes into vSphere. This approach is a very easy way to get started with Kubernetes from a VI admin’s perspective. It allows the VI admins to continue to utilize the tooling and interfaces they are used to, with minimal change, in order to provide a CaaS platform for their end-users. In this model, the VI admin during configuration turns the vSphere ESXi cluster into a Kubernetes cluster, as well. By doing this, they can deploy pods (containers) directly on their ESXi hosts (if using NSX-T for networking), which can be very beneficial in terms of performance. Another option in this version is to create “guest clusters” that are managed like standard clusters by the Tanzu Kubernetes Grid platform.?
Because it is baked into vSphere, Tanzu Kubernetes Grid Standard is the most opinionated of the versions. It is very easy to use and has huge benefits, such as the VM service, vSphere SSO as identity management for clusters, UI for quota management within the vSphere UI, and vSAN data persistency platform capabilities. If you are looking for a solution for your on-premises data centers and are just getting started down the Kubernetes path, this is a very good option.
The final flavour is?Tanzu Kubernetes Grid Managed. This is the core Tanzu Kubernetes Grid offering that allows provisioning of clusters on multiple platforms, including native cloud platforms and vSphere running anywhere. This version is also the least integrated with the VMware software-defined data center products such as vSphere, NSX-T, and VROPs.?
However, it is by far the least opinionated and most customisable of the versions. Tanzu Kubernetes Grid Managed is the best offering if you truly need a multi-cloud offering, and advanced Kubernetes functionality and tuning capabilities that are currently not possible in the other versions.
Level 2: (observability and compliance)
You probably also want—or need—to see what's happening inside your clusters and how the apps are performing. To do this, you have to add monitoring (i.e., Tanzu Observability) to see what's going on and to be alerted of potentially bad conditions. You may also want to enforce company compliance rules to either be compliant to certifications or to prevent Kubernetes users from doing things that will harm your platform. This is where Tanzu Mission Control comes into play. The Harbor container registry also strengthens compliance by providing a private and secure place to store container images. And Tanzu Service Mesh enables end-to-end mTLS encryption across all of your Kubernetes clusters, wherever they are located.
Level 3 (developer experience)
Kubernetes is evolving into the standard platform for running applications. This is great for some companies, but less great for others because it can be difficult for developers to use such a flexible and open platform. Therefore, it’s useful to build a platform above Kubernetes that will limit this flexibility—creating a platform with opinions, so it’s easier to consume, but that supports customization so users aren’t limited in what they can do (remember that this is a limitation of PaaS offerings). You could build this yourself or look for open source projects (cf-for-k8s is an option for Cloud Foundry users), although VMware has just announced a product called?Tanzu Application Platform?that accomplishes this. It’s currently a Beta release, but the promise is that it can be deployed onto any Kubernetes cluster and optimizes the experience of deploying and configuring applications. Importantly, although it does come with default settings, operators can get as deep into the Kubernetes APIs as they want to in order to customize the platform.
At this level, the specific expertise needed to “run and manage” the stack typically goes beyond what the traditional VI admin is trained for. This is where personas, or roles, like “DevOps engineer” or “platform engineer” start to appear. These are people that typically have one foot in traditional IT, and one foot in modern application development; usually people will orient either in one or the other direction. Bringing these people together commonly results in the “platform team”, “PaaS team”, “Cloud Center of Excellence”, and other creative department names like that.?
Level 4 (developer efficiency)
Beyond platforms, runtimes, and tools for managing and monitoring them, VMware Tanzu also puts an emphasis on developer efficiency. For example, developers can use the Spring ecosystem to create resilient cloud-native applications, and Tanzu API Portal helps in creating a company-wide API ecosystem.?Tanzu Labs helps teams learn how to effectively work in a DevOps model, and also to make the best use of the technologies on which they’re building.?
Using Tanzu to Fast Track Progress??
There are any number of options at each level above, in the form of open-source projects, vendor software, and public cloud services. Purely open source options are free to download but can be difficult to integrate and costly to manage (in terms of the number of people dedicated to maintaining those systems). Cloud services are easy to adopt but typically lock you into that provider—you use it there or you don’t use it. Of course, this isn’t an ideal option for organizations running multi- or hybrid-cloud environments, which often is the case for those concerned with compliance and/or lock-in.
Tanzu, on the other hand, is built largely around those same open-source projects but is bolstered by VMware’s investments in product development and support. By choosing VMware Tanzu offerings where feasible, then, we’re able to find a good middle ground between those two extremes.??
---
To learn more about the Tanzu Vanguard super user community or to apply for membership, please visit: https://tanzu.vmware.com/vanguard?