Tanzu Application Accelerators

Today's post will continue where we left off, discussing the Tanzu Application Platform. Last time we discussed an overview of the various components of the platform.

The following topic will be covered in this article series.

Today we will take a deeper look at Application Accelerators.


First, let's remind ourselves of our Personas.

  • Cody. - Cody is an application developer who loves to be productive. He doesn't want to get bogged down in learning technologies not related to what he loves to do. Since coding is his passion, he wants to be able to code within the curly braces and not worry about platform abstractions such as Kubernetes, building containers, how to connect to databases, and implementing single sign-on,

  • Alana - Alana is a platform Operator. Her job is to help developers run their apps in Kubernetes. In addition, she is responsible for ensuring that applications meet the security requirements of her organization and have no Critical CVEs.

We will also introduce a new persona.

  • Naomi - Naomi is an enterprise architect responsible for ensuring the development teams have the tools to develop new applications quickly and in a way that conforms to company standards.

Application Accelerator

Enterprise Architects such as Naomi use Application Accelerators to provide developers in their organization with ready-made, enterprise-conformant code, and configurations.

Developers like Cody can consume these accelerators by selecting options that will then be fed into a templating engine to create the finalized skeleton project.

Accelerators are created by publishing the templates into a Git Repo and publishing them to be consumed within the TAP user interface.

Accelerator Architecture

How does Application Accelerator work?

Application Accelerator allows you to generate new projects from files in Git repositories. An accelerator.yaml file in the repository declares input options for the accelerator. This file also contains instructions for processing the files when you generate a new project.

Once the desired options are selected, the inputs are fed into the Application Accelerator Engine. Finally, the inputs are combined with the template project to produce the desired output.

Application Accelerator UI

The Application Accelerator UI gives you a searchable list of accelerators from which Cody can choose. After Cody selects an accelerator, the UI presents input fields for any input options.

accelerator ui

the ui allows cody to search for curated starting points based on tags such as java or spring.

a real world example

in the past, naomi has directed developers like cody to head over to start.spring.io to generate templates for their projects. the problem with that site is that it generates projects that are not fully adapted to acme corp requirements. accelerators allow her to go further and create customized starting points that implement configurations specific to acme corp.

naomi has determined that her first starter should create a basic spring boot web application with the proper configurations for acme's internal maven repositories and generate tap configuration files.

choose options.

  • maven artifact
  • maven group
  • maven version
  • maven description
  • maven module name

if a tap workload* is selected, the user should be required to choose

  • namespace
  • component name
  • github url and branch

if a tiltfile is selected for live-debugging the user should be directed to choose a registry to publish the artifact to

also, since the maven group corresponds to the names of specific acme organizations, naomi would like this to be a picklist that automatically maps various departments to their maven groupid.

accelerator templates.

naomi starts the process by creating a git repository to store her work. the git repository will have a basic maven java project that will be customized by the accelerator based on cody's selections.

she needs to make sure the proper versions of spring are used, in addition to making sure maven is configured to obtain artifacts from acme's internal repository.


transformations allow an accelerator to convert specific text based on rules defined in the accelerator.yaml file.

for example:

replace the placeholder text acme-webapp-version with the artifact version the developer picked.

1- include: [ "pom.xml" ]
2  chain:
3  - type: replacetext
4    substitutions:
5    - text: acme-web-app-version
6      with: "#mavenartifactversion"

in the above fragment, the relevant sections of the pom.xml will be replaced with the selection. the pom.xml sourced for the transformations is in the same git repository as the accelerator.yaml.

transformations can depend on what the user has selected. in our case, if cody decides not to generate a tiltfile, we don't need to replace the text in that file. nor do we need to include it in the output.

1- include: [ "tiltfile" ]
2  condition: '#createtiltfile'
3  chain:
4  - type: replacetext
5    substitutions:
6    - text: tanzu-java-web-app
7      with: "#artifactid"

a more sophisticated example is to move the files from the sample app into the appropriate package structure. naomi wants to encourage developers to use the format com.acme.department.artifactid.

if you look at the template project layout in github, you will see the package used is com.example.demo, not only will we need to move all of the sample files to the correct path, but we will need to replace the package declaration inside them. this renaming can easily be accomplished by combining the replacetext and rewritepath transformations.

 1- include: [ "**/*.java", "**/*.properties" ]
 2  chain:
 3  - type: replacetext
 4    regex:
 5      pattern: com.example.demo
 6      with: "#pkgname"
 7  - type: rewritepath
 8    regex: src/test/java/com/example/demo/(.*)
 9    rewriteto: "'src/test/java/' + #pkgname.replace('.', '/') + '/' + #g1"
10  - type: rewritepath
11    regex: src/main/java/com/example/demo/(.*)
12    rewriteto: "'src/main/java/' + #pkgname.replace('.', '/') + '/' + #g1"

for the rewritepath example, we needed to replace the dots in the pkgname with slashes to represent the folder structure. we did this using spring expression language (spel)

putting it all together

the completed accelerator looks like this.

accelerator ui

publishing the accelerator

to publish the new accelerator, naomi has two choices. use the tanzu cli create an accelerator resource and apply it to the kubernetes cluster.

the cli

1tanzu accelerator create test-demo2 --git-repository https://github.com/jeffellin/acme-corp-java-accelerator

The K8s Way

 1apiVersion: accelerator.apps.tanzu.vmware.com/v1alpha1
 2kind: Accelerator
 4  name: modular-java-app
 5  namespace: accelerator-system
 7  git:
 8    ref:
 9      branch: main
10    subPath: accelerators/java-web-app
11    url: https://github.com/jeffellin/acme-corp-java-accelerator

Since this is a standard Kubernetes resource, Naomi could use GitOps to publish the new accelerator. She could use a tool like ArgoCD to automatically apply updates when changes she merges changes into the monitored Git Repository.

Consuming the accelerator

After publishing the accelerator to the Catalog, Cody can select it from the catalog in the TAP UI.

Once he fills in the blanks

He can generate the sample project and start coding away, by downlading the project zip file.

Finished Projects

What's Next

Coming Up We will show you how to get going today by deploying TAP to AWS.

Posts in this Series

comments powered by Disqus