Tanzu Application Platform just released version 1.2 and it is a huge release!
The release not only has many bug fixes and security patches but also includes a whole set of new functionality that really brings TAPs capabilities to the next level!
Support for Air Gapped Installation (Beta)
One of the key things added in TAP 1.2 is the initial support for Air Gapped installations.
Having these capabilities is a critical feature, as it will allow highly regulated environments such as insurance companies, governmental agencies and also companies in the security fields to utilize the amazing capabilities of TAP within their environments which is not an easy task when dealing with Kubernetes platforms.
While the Air Gapped Support is currently in Beta, this means we are on the right direction and can hopefully see a fully supported air gapped topology in an upcoming release in the not to distant future.
Support for new workload types (Beta)
TAP from the beginning was very well suited for web applications similar to the TAS (Cloud Foundry) platform supported.
As the use of TAP grows, new types of applications need to be supported as well, and due to the pluggability and customization capabilities of TAP, in the 1.1 release we saw an additional type of workload added which was the function type of workload.
Function workloads similar to what one would typically deploy to a system like lambda was a logical next step and in TAP 1.2 not only were enhancements made to both the web type and to the functions type of workload, we also get 2 new types of workloads:
TCP Workloads
The tcp workload type allows you to deploy traditional network applications on Tanzu Application Platform. Using an application workload specification, you can build and deploy application source code to a manually-scaled Kubernetes deployment which exposes an in-cluster Service endpoint. If required, you can use environment-specific LoadBalancer Services or Ingress resources to expose these applications outside the cluster.
The tcp workload is a good match for traditional applications, including HTTP applications, that are implemented as follows:
-
- Store state locally
- Run background tasks outside of requests
- Provide multiple network ports or non-HTTP protocols
- Are not a good match for the web workload type
Applications using the tcp workload type have the following features:
-
- Do not natively autoscale, but can be used with the Kubernetes Horizontal Pod Autoscaler
- By default are exposed only within the cluster using a ClusterIP Service
- Use health checks if defined by a convention
- Use a rolling update pattern by default
Queue Workloads
The queue workload type allows you to deploy applications that run continuously without network input on Tanzu Application Platform. Using an application workload specification, you can build and deploy application source code to a manually-scaled Kubernetes deployment with no network exposure.
The queue workload is a good match for applications that manage their own work by reading from a queue or a background scheduled time source, and don’t expose any network interfaces.
Applications using the queue workload type have the following features:
-
- Do not natively autoscale, but can be used with the Kubernetes Horizontal Pod Autoscaler
- Do not expose any network services
- Use health checks if defined by a convention
- Use a rolling update pattern by default
Application Accelerator Enhancements
Another key area that got enhanced greatly in TAP 1.2 is the Application Accelerator.
The key new features for App Accelerator are:
- Fragments
- Sub Path Support
- VS Code integration
Fragments
While Application Accelerators have always been great since TAP 1.0, one of the key things we always heard from customers was that they end up duplicating many of the options of their accelerators for all the custom accelerators they build.
While this can work at small scale, VMware recognized that at larger scale this can be very tedious and can be hard to maintain.
To address this, VMware introduced in TAP 1.2 Accelerator Fragments.
Accelerator fragments are reusable accelerator components that can provide options, files or transforms. They may be imported to accelerators using an import entry and the transforms from the fragment may be referenced in an InvokeFragment transform in the accelerator that is declaring the import.
This basically means we can have a set up accelerator fragments in a shared repository and utilize them within our larger accelerators in a really simply and DRY manner!
Sub Path Support
Another key functionality that can make integrating Application ACcelerator into your workflow easier is the support for Git Sub Paths.
This is accomplished via the git.subPath field in the accelerator CRD, and the value is the folder inside the git repository to consider as the root of the accelerator or fragment. Defaults at the root of the repository.
This makes it possible to consolidate accelerators into a single mono-repo for example and not require a git repo per accelerator which could get cumbersome to manage over time.
While this may seem like a small change, in practice it is changes like this that give an overall smoother onboarding to the platform and make it easier to integrate into existing processes within customer environments.
VS Code Integration
Another key aspect of this release is enhancing the experience of developers inside of their IDE.
While TAP GUI is an amazing platform that i believe gives huge benefit to customers of all shapes and sizes, integrating into the IDE is a must for a DevX platform today and VMware understand this and are working to make this story even more compelling!
In TAP 1.2 one of the enhancements to the VS Code integration is the addition of an Application Accelerator extension.
The application Accelerator Visual Studio Code extension lets you explore and generate projects from the defined accelerators in Tanzu Application Platform using VSCode.
This allows the developer to jumpstart a new project using the accelerators the Platform team has supplied them with directly from their IDE, again shortening the time it take to get from an idea, to actual code in a really unique and simple manner!
Application SSO
One of the key challenges people encounter when building out distributed micro service based architectures is the whole area of managing an authentication mechanism which should preferably be an SSO system.
Application Single Sign-On for VMware Tanzu® (AppSSO) provides APIs for curating and consuming a “Single Sign-On as a service” offering on Tanzu Application Platform.
With AppSSO, Service Operators can configure and deploy authorization servers. Application Operators can then configure their Workloads with these authorization servers to provide Single Sign-On to their end-users.
AppSSO allows integrating authentication and authorization decisions early in the software development and release life cycle. It provides a seamless transition for workloads from development to production when including Single Sign-On solutions in your software.
It’s easy to get started with AppSSO, deploy an authorization server with static test users, and eventually progress to multiple authorization servers of production-grade scale with token key rotation, multiple upstream identity providers, and client restrictions.
Having this addition in TAP is pretty awesome and can make the lives of developers and operations teams so much easier while keeping security at a very high standard as is required.
Support For Kaniko
TAP is a very pluggable and customizable system built with very good defaults, but also with the ability to override these defaults when needed.
Since TAP 1.0 we were able to go from source code to a URL very easily! much of this was possible due to the use of Tanzu Build Service which is the default image building tool in TAP.
TBS utilizes the Open-Source Kpack project, which is a Kubernetes operator that allows us to build container images using Cloud Native Buildpacks.
When using TBS, no Dockerfile is needed and we gain huge amounts of added features like, smart caching, auto rebasing of images, SBOM generation etc.
While this is great, some use cases simply are not possible with Buildpacks, and in other situations, even if they could be done with Buildpacks, companies may prefer for one reason or another to utilize Dockerfile based builds instead.
In TAP 1.1 a new feature was added which allowed us to supply a pre built image to TAP, and it would utilize that image for the remaining steps of the supply chain instead of building the image itself within the supply chain.
Now in TAP 1.2 we have a huge improvement to the flexibility and set of options we are provided OOTB, and TAP now can officially support Dockerfile based builds as part of the supply chain itself using the Open-Source project Kaniko.
This means that whether we use the default and highly recommended TBS approach, or decide to use Dockerfiles via Kaniko, we will get the same UX and the same outcome for our developers which is indeed a pretty awesome thing to see in action!
TAP GUI Enhancements
TAP GUI is the central portal of the platform and as such, enhancements are almost always to be expected in this realm and TAP 1.2 doesn’t let us down in this aspect either!
TAP GUI enhacements include:
- Better support for Multi Cluster Topologies
- PR Based flow visibility
- Security Scan Data visbility
- Customization capabilities
- Pod Log viewer
Multi Cluster Enhancements
One of the enhancements made in TAP GUI, is related to the multi cluster topology of TAP which is available since TAP 1.1!
With the enhanced visibility in TAP 1.2, we can now see the supply chain steps across all clusters correlated in a simple and intuitive UI. this means we can track our workloads across all of our clusters from Build time till the actual deploying of the app in production from a single plane of glass!
PR Based Flow Visibility
Another key enhancement in TAP 1.2 is that for the multi cluster scenarios, we now get OOTB support for a PR base promotion cycle. this means that TAP will create a PR for us with the updated manifests when a change is made to our app manifests for whatever reason that may be.
Not only does TAP support a PR based flow though, it is also integrated into TAP GUI!
This means that when visualizing the workload, if a PR based flow is configured, you will be able to see that there is a PR that needs to be merged in order for the workload to proceed in the promotion flow, and will have a simple button to click that will direct you to the relevant PR, where you can review and then merge the changes to have the workload proceed in its lifecycle steps.
Security Scan Data Visibility
One of the key focuses in TAP is around the whole idea of image and platform security.
A key part in this is the metadata store, where image and source code scan results, which occur as part of our supply chains are stored.
By having a central place where our vulnerability data is aggregated, we can easily use this data to our advantage and understand the security status of our images.
TAP 1.2 has added the ability to now have the vulnerability results visible within TAP GUI, allowing for a shift left approach, and allowing our developers to easily see where they have issues in terms of security, and allow them to have a quick and simple iterative loop of feedback when building an app, to make sure it is secure and up to the companies standards, without the toil of traditional ticket based processes.
Having this visibility is a huge step in the direction of really shifting as much as we can left and making our platforms and application even more secure and protected without adding complexity and slowing down the development process.
Customizing the UI
While TAP GUI is nice looking, in most organizations we need the ability to customize and “brand” our UIs to be inline with our companies logos and general branding considerations.
TAP GUI as of TAP 1.2 now supports customizing the Portals Icon, Title, Header, Org name, Help menu links, Authentication page title and more!
While this may seem like a small addition, this is a reason nice ability that just makes the experience of using TAP GUI that much nicer in an organization.
Pod Log Visibility
One of the great plugins VMware have built for TAP GUI that has been around since the beginning is the Application Live View plugin. This plugin allows us to view Realtime metrics of our containers using the spring boot actuator mechanism.
While this has always been great for debugging and understanding the status of our apps, one key thing was missing from TAP GUI in order to really support a debugging workflow.
TAP 1.2 now adds the ability to view pod logs for our workloads! This allows us to get much better visibility and to be able to truly understand what is going on in our applications without needing to constantly jump back and forth from the UI to our terminal.
VS Code Extension Enhancements
The VSCode extension for TAP is really great and as is the theme with TAP 1.2, it also had a huge revamp and got some great attention and upgrades!
The key enhancements that were added in TAP 1.2 include:
- Workload Panel
- Apply and Delete Workload commands
- Live Hover integration for Spring Tools
- Support Multiple Projects in a workspace
Workload Panel
A very nice enhancement in the VS Code Extension from a UX perspective, is the Workload Panel widget that has been added.
The current state of the workloads is visible on the Tanzu Workloads panel in the bottom left corner of the VS Code window. The panel shows the current status of each workload, namespace, and cluster. It also shows whether Live Update and Debug are running, stopped, or disabled per workload.
Having this simple view of the status of your workloads is a really nice addition to the extension making the feedback loop to the developer simpler and more streamlined.
Applying and Deleting Workloads
The extension since 1.0 supported inner loop workflows by allowing us to start an app via the Tilt integration with the live updates capability.
While this is great, it also limited the scope of the plugin to Java based apps only as that is the only live update integration currently in TAP.
In TAP 1.2 the extension enables you to apply workloads on your Tanzu Application Platform-enabled Kubernetes cluster no matter what the language is. While this doesnt mean Live update is supported, we still get basic functionality and integration in our IDE for workloads written now in different languages, which paves the groundwork for a better polyglot integration I’m sure we will see being added into TAP in the next few releases.
The ability to apply and delete workloads via the IDE plugin, while a simple and small addition, is a truly welcome addition as it again limits the amount of times i need to switch over to using my terminal which means greater productivity, and an overall better DevX for our end users.
Live Hover
TAP has a great integration with the Spring ecosystem, and amongst the integrations it has, we have a very deep integration with the Spring Boot Actuators mechanism which we can see being fully utilized in Application Live View within TAP GUI.
Another way to integrate with this data, which is part of the Open Source Spring community, is through the Spring Boot Tools extension for VS Code which includes amongst other things, a Live hover functionality.
The Spring Tools 4 can connect to running Spring processes to visualize internal information of those running Spring processes inline with your source code. This allows you to see, for example, which beans have bean created at runtime, how they are wired, and more.
The Spring Tools 4 shows hints by highlighting sections of source code with a light green background. Hovering over the highlights with the mouse pointer, data from the running app is displayed in a popup.
All of this data is collected via the Actuator endpoints which can be configured simply in TAP via the conventions controller.
In TAP 1.2 experimental support for this functionality has been added which again just makes the developers lives that much better!
As can be seen in the following example, the contextual info we recieve can be amazing to have when developing and iterating on our workloads.
I am very excited to see this functionality mature over time and hopefully through frameworks like Steeltoe, grow into Polyglot solutions that can support over time more and more use cases and languages for apps deployed via TAP.
Multi-Project Workspaces
The TAP Dev Tools extension for VS Code previously only supported a single project per workspace. Now as of TAP 1.2, when working with multiple projects in a single workspace, you can configure the Tanzu Dev Tools Extension settings on a per-project basis by using the dropdown selector in the Settings page.
This is a great UX enhancement that will make the usability of the Extension much better for developers.
Intellij Extension
Tanzu Developer Tools for IntelliJ is VMware Tanzu’s official IDE extension for IntelliJ IDEA to help you develop with the Tanzu Application Platform (TAP). The Tanzu Dev Tools extension enables you to rapidly iterate on your workloads on supported Kubernetes clusters with Tanzu Application Platform installed.
This extension, just like the VS Code extension, enables live update capabilities and the ability to debug our workloads deployed on TAP enabled clusters directly from our IDE!
Currently in this first release of the extension, Only Java apps are supported and the extension only works on MacOS, but I’m sure we will see additional functionality added and support for additional platforms and languages in upcoming releases of TAP!
It is great to see that VMware are extending the IDE support and meeting the developers where they love to be which is in the IDE of their choice!
Support for ECR Container Registry
For those that work with kubernetes and have dealt with controllers that need access to a container registry, understand the complexities that are inevitable that come along with ECR (Amazons Elastic Container Registry).
While ECR is a great registry, the authentication mechanism is very difficult to integrate with.
The typical approach of using an access token for authentication to a registry via an image pull secret in kubernetes works against ECR, but only for a few hours.
The access tokens have a very short lifetime, and there is no way to auto renew them.
This makes integration with ECR complex to say the least.
To overcome this issue, VMware have integrated and added support for using ECR with IAM role bound service accounts.
The Tanzu Application platform supports using ECR for both Tanzu Build Service images, as well as the images created as part of a workload in a supply chain.
While you can use the typical “secret” configuration to store credentials for ECR, the token that is used to authenticate to ECR expires every 12 hours. For this reason, it is suggested to use an AWS IAM role bound to a Kubernetes service account to allow the Tanzu Application Services to authenticate to ECR.
While I personally am a big fan of harbor, and think it provides great benefit even when running in AWS, making it superior in my personal opinion to ECR, having the ability to integrate with such a popular registry, despite the complexity is a great sign and shows that VMware are truly working hard to meet their customers where they are and give the a true choice of tooling and not lock them into a specific set of tooling that VMware perscribes.
Maven Artifacts as a source to a supply chain
While TAP provides a full solution for CI and CD, and with the builtin Testing capabilities of Tekton and Build capabilities of TBS, we can go directly from source code to a URL, replacing an existing CI system such as Jenkins can be a difficult and sometimes undesirable task.
VMware understand this, and want to allow people to utilize TAP and integrate it in their existing workflows, at whichever point makes the most sense for the customer.
A key move that shows this in TAP 1.2, is the addition of a new capability to build a workload from a Maven artifact built outside of the supply chain.
This approach aids integration with existing CI systems, such as Jenkins, and can pull artifacts from existing Maven repositories, including Jfrog Artifactory.
With this mechanism, you can have a build process in Jenkins for example that will build your jar/war files and push them to a maven repository and have a TAP workload watch the repository for new builds using version selectors on the workload yaml.
Currently, this supports only java artifacts and has limited authentication mechanism support, but overtime, this will become a more feature rich integration, and will hopefully support additional language artifacts and authentication mechanisms.
It is great to see the flexibility provided to end users via TAP, and how it can integrate into existing pipelines, while at the same time not giving up on the UX and single plane of glass ideals that the platform offers.
Application Live View Enhancements
Application Live View, is a great functionality that exists since TAP 1.0 and gives us a really nice UI (Within TAP GUI) to see our spring boot applications Actuator Data and in some cases like log levels, actually make live changes directly from the UI!
While this has always been great, it was limited to Spring based applications.
In TAP 1.2 we now have App Live View support for Steeltoe based applications.
Having this capability now extended to be a polyglot solution, shows the huge effort VMware are putting into making the platform meet the needs of its customers, no matter what language or frameworks they decide to use.
It is great to see the platform extending in these directions, and I’m sure we will see more and more integrations with languages and frameworks in this space in the future.
Snyk Integration
Another integration that has been added in TAP 1.2 is the first ISV integration with TAP!
This integration allows us to utilize Snyk for image scanning within our supply chain instead of the default scanner which is Grype.
The Snyk integration is currently in Beta, and only supports image scanning and not source code scanning, but it definitely shows huge promise, and I’m looking forward to see this integration and others get added to that TAP ecosystem over the future releases!
The integration with TAP brings along with it, a lot of backend changes to make the scanning tool more easily pluggable, by adding in support for not only CycloneDX formats which Grype for example can provide, but also for SPDX formats, as is provided by Snyk.
Currently the world is undecided on which of the 2 standards (CycloneDX and SPDX) will become the de-facto standard, and it is great to see that VMware are building their solution to support both standards, making integrations much easier, no matter which direction things go in this regard in the broader ecosystem.
Community Standardization
One of the things I believe we will see repeat itself down the road again and again is that VMware especially in the security area, may release things ahead of the majority of the community.
A good example for this is the integration we have had since TAP 1.0 with Cosign, to not only sign our images but also a validating webhook, which will make sure that only images we have signed can run in our clusters.
This is a topic that many people are talking about, and slowly it is being integrated, but at the time TAP 1.0 was being released, VMware were one of the first to actually implement a solution for this into their platform.
Over the past year or so, the community, including VMware have been working hard on developing the correct tooling and practices around the idea of image signature verification, and the tool that seems to be the appropriate candidate to be a community standard is the Policy Controller, which is a validating webhook developed and maintained as part of project Sigstore.
As such, VMware in TAP 1.2, are deprecating the initial proprietary implementation of an image policy webhook and are integrating the community standard policy controller mechanism.
This is part of a general approach which I find great in TAP in particular, and the wider Tanzu ecosystem at while, which is that VMware are trying as much as possible to stay aligned with the upstream community, and not to simply build a solution that is proprietary and only take from the upstream. VMware have put large amounts of engineering time into cosigned as an example to help push the tool forwards. By doing this, VMware, its customers, and the broader ecosystem all win.
I am very excited to see these community standards grow and mature overtime, and see how VMware integrates them into the Tanzu ecosystem, making it a truly Open-Source based Enterprise solution.
General Usability Improvements
Amongst the key features mentioned above, TAP 1.2 also includes some general usability improvements that simply make the lives of our developers and platform operators better.
Tanzu Apps CLI Plugin Enhancements
The App command in Tanzu CLI is a key access mechanism to the platform for our developers. In TAP 1.2, we have some new features that make the usage a lot easier, and remove the need in many cases to revert to using yaml files and kubectl to apply them.
- Added a –sub-path flag to allow specifying the sub path in the repo or image to use as the base of the application code
- Added a –service-account flag to allow specifying the service account to use for the workload
- Added support for ignoring local files when in the inner loop development via a .tanzuignore file.
- Added additional info when running “tanzu apps workload get”, including source information and supply chain step information