Tanzu Application Service 4.0 Deep Dive: Exploring the new TAS Portal
With the release of VMware Tanzu Application Service 4.0, the engineering teams have introduced the next level of developer productivity within the platform. The new TAS Portal encompasses these new developer productivity enhancements based on the widely popular open-source project Backstage.
This blog will dive deep into the TAS Portal and how it brings new functionality and value to Tanzu Application Service.
Let’s explore the three main features of the TAS Portal:
The TAS Portal currently has three main areas of functionality that I will describe in detail below.
Please note: As of the TAS 4.0 release, every feature in the TAS Portal is considered to be in Beta, and VMware aims to add more functionality and features in future releases.
Software Catalog:
The organization software catalog within the Tanzu Application Service portal allows developers to register their applications and search for existing applications within the catalog. The software catalog can reduce the risk of duplication of effort by providing developers with a single location for registered services to be discovered and integrated into new projects.
The TAS Portal is depicted with sample applications registered in the software catalog. Since the catalog is based on Backstage, it's incredibly flexible and can be molded into your own organizational requirements. Registering applications to the catalog is simple as importing a few yaml files that define your organizational resources. See the registration process below:
I have built a sample catalog for my demo application, “spring-music-homelab”. You can find the code on my Github page. This catalog is not an exhaustive example, but it provides the basics to register an application into the catalog and provides base examples and structure of organizational relationships common in a real-world use case.
The image above depicts “kuhn-labs.yaml” file, the main file used to import information into the software catalog.
I will be importing the following:
- Domain: The “kuhn-labs-domain” will be imported. It can be viewed as a high-level organization or domain of a collection of applications. Perhaps this can be considered an organization's business line or specific vertical.
- System: The “kuhn-homelab-apps” system will be imported. I view a system as a lower-level grouping of applications that could be tied back to a specific team. Perhaps this is a good mapping back to a Cloud Foundry Space?
- Component: The “spring-music” component will be imported. I view components as a direct correlation to applications. This component ties directly to an application called “spring-music-application” on the platform.
- Group: The “kuhn-platform-eng” group will be imported. If you dig into this file on GitHub, you see that I defined the actual group “kuhn-platform-eng” and a single user: tehkunz. This represents the different groups and their respective members within an organization, which is extremely helpful when playing the “who owns what” game within an organization.
The image above depicts the hierarchical structure of the resources I imported into the system. This feature is shown within the runtime resources view.
Runtime Resources
Registered applications within the Tanzu Application Service portal will display application runtime information such as CPU and memory utilization, instance counts, application logs, and application lifecycle history. This information can help the developers keep track of their applications and how they are running without leaving the Tanzu Application Service portal.
To appear in the Runtime Resources tab, applications must have matching labels within Cloud Foundry and their component definition in the software catalog.
Let's look at what I defined in my component/spring-music.yaml :
You will notice I set the label selector for my component = 'app=spring-music-homelab'.
We must match this with a 'cf set-label app spring-music-homelab app=spring-music-homelab' or manually set it inside Apps Manager.
Now that we have defined labels on the software catalog and within TAS, your applications will populate runtime resources (depicted below).
Additional view of the Runtime resources tab:
Application Accelerators
Pre-packaged Application Accelerators for Tanzu Application Service are now available in beta within the Tanzu Application Service portal. This enables developers and operators in their organizations with ready-made, enterprise-conformant code and configurations. New software projects can be quickly assembled from accelerators and allow developers to kickstart their application development by having many organizational best practices predefined in easily consumable software project templates.
Please note: Adding custom-built accelerators is not supported during this initial beta release.
If you have been following Tanzu Application Platform, you will notice the TAS Portal also contains Application Accelerators. The engineering team has added support for App Accelators to deploy for Tanzu Application Service and Cloud Foundry deployments. Here is the sample view of the Accelerator page within the TAS portal:
When you drill into an Accelerator, you will notice that you can select both TAS and TAP deployment configurations:
Last but not least, when you generate the accelerator, you see instructions for our beloved “cf push” workflow 🙂
Conclusion:
The TAS portal is a very welcome addition to the Tanzu Application Service Experience. It’s a great example of how the collaborative engineering teams within Team Tanzu are building a cohesive developer experience, no matter what underlying platform your developers use. In my humble opinion, it's also an excellent example of how VMware is bringing some of the work they are leading within the Kubernetes ecosystem into the Cloud Foundry ecosystem. This is a big win for TAS customers as they can use the TAS portal free of charge. 😎
Want to see this blog in action?
If you want to see this blog in action, check my TAS Portal video! It should serve as a great companion to this blog.