One of the key features in Tanzu Application Platform is a tool called “Application Accelerator”.

In this blog post, we will try to cover what the tool is, why we need it, what makes up an accelerator, and try to give some examples of how these features can be used to build your own custom accelerators.

What is App Accelerator

App Accelerator helps you bootstrap developing your applications and deploying them in a discoverable and repeatable way.

You can think of app accelerator as a way to publish a software catalog to your end users, which will allow them to fill out a simple and customizable form, that will then generate a templated set of files which they can start iterating on for there new project.

Enterprise Architects author and publish accelerator projects that provide developers and operators in their organization ready-made, enterprise-conformant code and configurations.

App Accelerator, is based on the Backstage Software Template plugin, and enriches it with additional capabilities and features to make it extremely easy to use.

An accelerator is built up of 3 key components:

1. A Git Repository based on which projects will be generated
2. A file in that repository called accelerator.yaml with the definition of how to template the project
3. A Kubernetes Custom Resource pointing at the base Git Repository

Lets examine these different components.

Base Repository

The base Git repository is a standard git repository where we can define whatever we want. this could contain for example a sample applications source code, kubernetes manifests, backstage configuration files, or really anything we want.

One of the great parts of App Accelerator is that we can literally template anything we want. You could for example build an accelerator that generates a base structure for a Carvel package, or perhaps a TKG cluster config file. Truly, the sky is the limit!

This Git Repository can be either public or private based on your needs. It also supports sub-paths within a repo making the structure of how you lay out your accelerators very flexible.

The only special thing in this repository is the next component we will discuss which is the accelerator.yaml file which we must have in the repository.

Accelerator Yaml

As mentioned above, the only unique file we have in our base repository is the accelerator.yaml file.

By including an accelerator.yaml file in your Accelerator repository, you can declare input options that users fill in using a form in the UI. Those option values control processing by the template engine before it returns the zipped output files.

An Accelerator Yaml file, has 4 key parts which are accelerator, options, imports, and engine.

Accelerator Section

In this part of the yaml file, we define metadata about our accelerator. This can include things such as, the name of the accelerator, tags to assign to the accelerator to ease searching for the right accelerator via the UI or API, a description for the accelerator, and an icon to use in the catalog for the accelerator.

Options Section

The options section is where we build out the inputs to our accelerator, that will be used to template our project.

Options are defined as an array or objects with a few different options of keys we can define for each option, which will effect how i is exposed to the end user:

Name (Required)

This field which is the only required field, defines the name of the option which can then be used in our templating steps later on.

The name field must be provided in a camelCase format and cannot include special characters.

Label

The label field allows us to set a User Friendly string to be used as the label for this option in the App Accelerator form.

By default, if we don’t set a label, the name field will be used as the fields label.

Default Value

This field allows to define a default value for our option. This can be very helpful when a sane default value is available, but we still want the user to be able to customize the field if needed.

Input Type

This field allows us to specify the type of field we want to expose for this option. There are many different input types available such as:

1. text (default) – a single line text box
2. textarea – a multi-line string input field
3. checkbox – allows an easy and elegant checkbox based list for either single or multi option inputs
4. select – a dropdown list
5. radio – a radio button list for single option inputs

Data Type

This field allows us to define the type of data we expect to receive in this input.

The valid types for this are, string, number, and boolean.

We can also accept an array value by simply using square brackets arount the type we want for example dataType: [string] for an input that expects an array of strings.

Required

This field accepts a boolean value, which denotes whether a field is required to be filled in by the user or not.

This can be extremely helpful when building out complex and rich accelerators, where we can decide as the architects, what a user needs to fill out for us to have enough information to template the new project for them.

Display

This field accepts a boolean value, which denotes whether this field should be displayed to the end user or not.

By using this value along with the default value field, we can hide specific inputs, but make the value usable by the templating engine.

Choices

This field can be used when the input type is of the types select, radio or checkbox.

This field is an array of objects with 2 keys, text and value. The text key is what will be shown to the user and the value key is what will be passed to the underlying engine.

Depends On

This field is an object with 2 keys, name and value.

This allows us to specify a dependency on a different option for whether this option will be visible or not.

A very common use case for this could be having a field called for example “Advanced Options” which is a boolean checkbox. when that value is set to true, we can display additional options we support, while making the initial form more palatable and easy to approach for the general use cases.

Validation Regex

This field allows us to define a regex in SPEL format which will be used to validate the input provided by the end user.

Using this field is a very good practice, to limit user input mistakes, and to ensure that the generated project contains a valid format.

Options which always exist

While nearly everything is up to the architect there is currently, one option which will always be included even when not specified which is “artifactId”. This option is displayed via the request form with the label “Name” and the description “Provide a name for your new project”.

Imports Section

The next section in the accelerator yaml file is an optional field that was added in TAP 1.2.

The imports section allows us to import one or more fragments (more on fragments later on in this post) into our accelerator, allowing for reuse of generalized functions across multiple accelerators.

This section receives an array of objects referencing the app accelerator fragments we want to use in this accelerator.

Each entry in this section must include a key “name” which will include the name of the fragment we want to import and can optionally include an additional key named “exposes”.

The exposes key, accepts an array of objects, that allows us to define which options from within the imported fragment we want to expose in the current accelerator. we can define specific dependent options here as well via the dependsOn key, and we can also in case of name clashes between different fragments, rename the value within the context of our accelerator via the “as” key.

Engine Section

The Engine section of our accelerator yaml file, is where we define the actual templating steps that will utilize the inputs the user has provided (defined in the options section and those imported via fragments) to generate our project for the requesting user.

When the accelerator engine executes the accelerator, it produces a ZIP file containing a set of files. The purpose of the engine section is to describe precisely how the contents of that ZIP file is created.

When you run an accelerator, the contents of the accelerator produce the result. It is made up of subsets of the files taken from the accelerator’s root directory and its subdirectories. You can copy the files as is, or transform them in a number of ways before adding them to the result.

As such, the YAML notation in the engine section defines a transformation that takes as input a set of files in the root directory of the accelerator, and produces as output another set of files, which are put into the ZIP file.

Every transform has a type. Different types of transform have different behaviors and different YAML properties that control precisely what they do.

A few key terms and concepts must be understood before discussing the different transformation types we have at our disposal.

SpEL Expressions

SpEL or in full the Spring Expression Language is used with our accelerator yaml file, to express logic and conditionals, within the yaml structure itself.

SpEL is a powerful expression language that supports querying and manipulating an object graph at runtime. The language syntax is similar to Unified EL but offers additional features, most notably method invocation and basic string templating functionality.

While similar to OGNL and MVEL, SpEL was created and is supported within all of the Spring portfolio, making it a logical choice for VMware to implement within the product.

The use of SpEL allows us to for example make options and transformation steps conditional based on specific criteria, it allows us to perform regex validations and much more.

one key thing to note that can be a bit difficult at the beginning until you get used to it, is that SpEL notations, also include for example quotes and other special characters we need to make sure we escape correctly in our accelerator yaml file so that it is always a valid yaml document. If we don’t do this our accelerator will not succeed to be executed due to parsing issues.

While learning SpEL notations can take a bit of time, the power it gives us and the flexibility we gain through it, make the learning curve a worth while endeavor.

Conditional Transformations

As mentioned above, just like with options and imports, we can add conditional logic to a transformation step within the accelerator engine specification.

This allows to to for example, include a pom.xml file if the user selected a value in the options called useMaven, and to not include it otherwise.

The conditional transformations, are a key functionality in most modular and custom accelerators, allowing us to write more generic accelerators that can produce different subsets of projects based on inputs, rather then needing to create a whole new accelerator for every permutation we may want to expose to our end users.

Now lets take a look at the transformation types we have at our disposal.

As mentioned, there are multiple (14!) types of transformation types.

Combo

This is a meta transform type. VMware refer to the combo transform as the “swiss army knife” of transforms.

This transformation type, allows for a simpler and more natural structure of our other transformations nested beneath it, which get “combined” together into a single combo transformation.

A combo transform allows us to combine the behaviors of Include, Exclude, Merge, Chain, UniquePath, and Let transformations in a way that feels natural.

Include

When performing transformations, we often only want to run a specific transform on a set of files, and sometimes based on different inputs and transformation logic, we may want to the zip file of the generated project to only include a subset of the files in the base repository.

The Include transform retains files based on their path, letting in only those files whose path matches at least one of the configured patterns (configured via a simple SpEL expression). The contents of files, and any of their other characteristics, are unaffected.

You will almost never use an include transform on its own, but combined together with other transformation steps that manipulate the selected files, this becomes one of the key steps which almost all accelerators will end up having.

Exclude

The Exclude transform retains files based on their path, letting everything in except those files whose path matches at least one of the configured patterns (configured via a simple SpEL expression). The contents of files, and any of their other characteristics, are unaffected.

This is very similar to the include transformation, as it is almost never used on its own but is very useful and commonly used, when combined together with additional transformation steps.

Merge

The merge transformation type, is a very useful “meta” transformation mechanism.

A Merge takes the outputs of several transforms executed independently on the same input source set and combines or merges them together into a single source set.

Basically this allows us in the engine to specify many independent transformations, and have the end results of the transformations be merged together to provide the final output of the project.

A very useful and common use of the merger transformation is to use merges with overlapping contents to apply a transformation to a subset of files and then replace these changed files within a bigger context.

While this is great that we can use overlapping paths, within a merge transformation when this occurs, it is important to note, that the default behavior, is to use the last instance of the conflicting file paths and have its result be the final one.

This means that if we have 2 steps manipulating a README.md file within our merge transformation block, by default the README.md outputted by the second transformation step will be the one we receive in the final projects files.

The Merge Conflict resolution options however are configurable and we will discuss that further on in this document.

Chain

The chain transformation type, is a very useful “meta” transformation mechanism.

While a merge runs each step within it independently and then merges the outputs, in a chain transformation, step are run sequentially and the output from previous steps is fed into the following tasks.

I common example of the usefulness of chain transformations is with the ReplaceText transform. Used by itself, the ReplaceText transform replaces text strings in all the accelerator input files. What if you wanted to apply this replacement to only a subset of the files? You can use an Include transformation step to select only a subset of files of interest and chain that subset into a ReplaceText transformation step.

Using chains is almost inevitable when building a production ready accelerator, and the freedom it gives us is huge!

Let

The let transformation type, is a mechanism that wraps another transformation step and can provide it with additional variables uniquely available in the scope of that transformations scope.

We can define variables via a simple array of objects, where each object includes a “name” key with the name of our local variable, and an “expression” key, where we can provide a SpEL expression to be used as the value of that local variable.

This transformation, is especially helpful when using transformations such as YTT or InvokeFragment, in which we are executing an external mechanism, which often times may have many options we simply want to hard code in our specific accelerator.

This is a common case when using fragments which we will cover in depth later on in this blog post.

Invoke Fragment

As we discussed above, and will dive deeper into later, we can import “sub-accelerators” as sorts of reusable functions into our accelerators via the fragments mechanism.

While they are imported like traditional functions in any programming language above, the InvokeFragment transformation is the mechanism by which we can run these fragments.

At the point of invocation, all currently defined variables are made visible to the invoked fragment. Therefore, if it was import-ed in the most straightforward manner, a fragment defining an option myOption is defining an option named myOption at the accelerator level, and the value provided by the user is visible at the time of invocation.

To override a value, or if an imported option has been exposed under a different name, or not at all, you can use a let construct when using InvokeFragment. This behaves as the Let transform: for the duration of the fragment invocation, the variables defined by let now have their newly defined values. Outside the scope of the invocation, the regular model applies.

An invoke fragment also allows us to cope with situations where the base file structure expected by a fragment is different then that which is present in the accelerator itself by use of the anchor field which allows us to basically get a “chroot” like behavior for the files of our accelerator in the context of the fragments execution.

Replace Text

This is one of the most important and highly used transformation types available.

This allows us a “sed” like transformation type, which can replace a specific string with another string, or can also do more complex tasks such as replace text found based upon a regex, with the contents of a file.

We also have a set of helper functions that we can use with this transformation, that make certain tasks much easier.

The additional helper functions we have include a variable called “files” which has a function defined on it “contentsOf” which allows us to replace a string with the contents of a file.

We also have helper functions for converting cases of our strings. We can convert between camel, kebab, pascal and snake casing of strings by using a function in the format of 2, for example camel2kebab or snake2pascal.

As this transformation manipulates the text data of our files, we must use this with caution as unlike other transformations, this is pretty much a “free for all” and we must test our accelerators adequately to make sure we don’t mess up formatting.

Rewrite Path

The RewritePath transformation type allows you to change the name and path of files without affecting their content.

This transform has 3 main fields which we can configure.

The first field is “regex”. this is where we define the regex in SpEL format for finding the source files we want to rewrite the paths of.

The second field is “rewriteTo”. This is where we define a SpEL expressin where we can define how to rewrite the path.

The third and final field is “matchOrFail”. This field accepts a boolean value, and defaults to false. This is where we can define what happens if the regex doesn’t match a file. Setting this to true can help prevent misconfigurations if you expect all incoming files that are coming in to this execution to match the regex.

This is commonly used for changing paths of source code files based on for example application name which the end user would input, or moving for example a project specific README.md file which you way have in a sub-folder to the root of the generated project which can be helpful if you want to have a README.md file in the accelerator repo itself that is dedicated to the accelerator and a different one for the generated project.

Open Rewrite Recipe

While using the power of both the rewrite path and replace text transformations we can really manipulate any file content and file structure, when dealing with Java specifically we have a better option.

The OpenRewriteRecipe transformation type allows you to apply any Open Rewrite Recipe to a set of files and gather the results.

Open Rewrite is an open source project which enables large-scale distributed source code refactoring for framework migrations, vulnerability patches, and API migrations with an early focus on the Java language.

While the Open Rewrite project has many different categories of recipes, App Accelerator currently supports only the Java related recipes.

The Open Rewrite version used is 7.24.0 and java code is interpreted based on the Java 11 grammar so if using a different Java version be warned their could be some unexpected behaviors. The official Open Rewrite docs should be consulted to see all of the available recipes, and how to use them.

While only the Java subset of recipes is currently supported, this already includes 25 different recipes which can be extremely helpful when constructing an accelerator for a java based application.

While the scope of this transformation is much more limited then both the rewrite path and replace text transformations, because this transformation is not doing text based manipulation, but rather it understands the data it is dealing with, we get a lot of advantages such as type safety, and additional nice feature like correctly dealing with imports in our java code, and it can understand fully vs. non-fully qualified names and treat them accordingly without needing to write replace text functions for all permutations a package name for example could be defined as.

The scope of Open Rewrite as a project is growing and I hope we will see more integration with it and its different recipes, as well as similar tools for other languages and frameworks over time.

YTT

This is bar far one of my favorite and my in my opinion most useful transformation types we get access to in app accelerator.

YTT (Yaml Templating Tool) is an amazing project which is part of the Open Source Carvel toolset, developed and maintained by VMware.

This transform by default will take all files passed to it as well as expose all variables in the accelerator as data values, and execute YTT as an external process.

While we don’t need to pass any parameters to a YTT transformation, we do have access to an optional parameter “extraArgs” which receives an array or strings which can be plain strings or SpEL expressions, and will be passed along to the invocation of the YTT process.

Similar to the advantages of using OpenRewriteRecipe for Java files, the YTT transformation give us amazing capabilities for transforming and manipulating yaml files, in a data structure aware manner.

As everything we do today seems to include some yaml, especially in the kubernetes ecosystem, having a tool like YTT at our exposal inside App Accelerator, opens up huge capabilities.

Use Encoding

Whenever we are talking about manipulation of textual data, for example in the ReplaceText transformation, the engine needs to be aware of the encoding to use for the file.

As the idea is to make App Accelerator as easy to consume, and simple, while at the same time, provide customization capabilities, a default encoding is assumed which is set to UTF-8.

If any files must be handled differently, use the UseEncoding transform to annotate them with an explicit encoding.

While the vast majority of files we deal with are UTF-8 encoded, it is great to see that even niche use cases like this are covered in the platform, allowing us to be comfortable that we are covered with whatever we need to do.

Unique Path

This is a transformation type that can be used to ensure there are no path conflicts between files transformed. You can often use this at the end of a Chain transformation.

This transformation type receives a single parameter named “strategy”. The value of the strategy key can be any of the conflict resolution strategies supported in the platform which we will cover in the next transformation type.

If you are using the Combo meta transformation type, an implicit UniquePath transformation is embedded after the merge transformation.

Conflict Resolution

As discussed multiple times above, if you’re using Merge (or Combo’s merge syntax) or RewritePath transformations, a transformation can produce several files at the same path.

If and when this happens, the engine must take an action: Should it keep the last file? Report an error? Concatenate the files together? etc.

The ConflictResolution transformation type, can be used to resolve these conflicts.

There are 6 different resolution strategies which can be defined via this transformation:

1. Fail – when used, on the first occurrence of a path conflict, the accelerator will stop being processed
2. UseFirst – when used, the first file produced at this path is the one that will be retained
3. UseLast – when used, the last file produced at this path is the one that will be retained
4. Append – when used, all files at the conflicting path or concatenated together in the order in which they were defined from first to last
5. FavorOwn – When using fragments, this will prefer the file coming from the current executing fragment if possible, with a fall back to the accelerator version otherwise.
6. FavorForeign – When using fragments, this will prefer the file coming from the accelerator if possible, with a fall back to the fragment version otherwise.

We also have some defaulting behavior for both Combo transformations and for Chain transformations.

When using a Combo transformation, the default behavior is set to UseLast as the conflict resolution strategy. To change this implicit behavior, you can add at the end of the combo a field “onConflict” with the value of the conflict resolution strategy you would like to use.

When using a Chain transformation, the default behavior is implicitly set to Fail. to override this behavior, you can explicitly set a UniquePath transformation at the end of the chain transformation, and specify the resolution strategy you would like to use.

As you can see, our options for configuring an accelerator are huge, and the options truly are endless. Now that we understand the ideas and capabilities around our accelerators repository, lets take a look at how we connect that repository to the platform.

Accelerator CRD

As is the case with almost everything in TAP, we configure our application accelerators using CRDs.

The cluster on which we will add the custom resources will be the cluster on which TAP GUI and Application Accelerator are installed. In a multi cluster setup this will be the view profile based cluster and in a single cluster setup it will be on that single cluster.

The main CRD we will cover is the accelerator resource, which is a namespaced resource that must be created for each accelerator we want to make available in the platform.

This resource must be created in the namespace the App Accelerator UI deployment is configured which is by default accelerator-system.

Because this is a standard kubernetes CRD, we can manage our Accelerator CRs via any mechanism we would like such as imperative kubectl commands, CICD tooling or a GitOps mechanism like Kapp Controller, ArgoCD or FluxCD.

The spec of the accelerator CRD is extremely simple and basic with just the right amount of options in my opinion.

Like all kubernetes resources, we have a standard metadata section where we can specify labels, annotations, the name of the resource and the namespace in which we want to deploy the resource.

Next within the spec itself we have 3 main types of fields:

Visualization Fields

The visualization fields are similar to the options one could define in the accelerator.yaml file under the accelerator section.

This includes the following optional fields:

1. tags – An array of strings that will be applied as filtering strings to the accelerator within the platform
2. iconUrl – A URL for an image to represent the Accelerator in a UI
3. displayName – A short descriptive name used for an Accelerator as the label
4. description – Description is a longer description of an Accelerator

Setting these in the CRD or in the accelerator.yaml file within the repo is completely a matter of preference, where i personally prefer to define it in the repo itself and keep my CR manifests as simple as possible but as mentioned it is simply a matter of personal preference.

Git Source Fields

The Git section is the section in which most of our configuration is done in a typical situation.

This is the section in which we define the connection between the accelerator CR and the Git repository where our accelerator.yaml and templated repo resides.

their are many different options for configuring the git source where most of them are directly mapped to fields in the Flux Source Controller GitRepository CRD which is used in the backend to pull and monitor our git source for updates.

The fields we can configure are:

1. git.url – The repository URL, can be a HTTP/S or SSH address.
2. git.interval – The interval at which to check for repository updates (defaults to 10 minutes)
3. git.subPath – When an accelerator is not at the root of the repository, subPath can be used to specify the root directory of the accelerator
4. git.secretRef – If the source repository requires authentication, this should be set to the secret name containing the git credentials. For HTTPS repositories, the secret must contain user name and password fields. For SSH repositories, the secret must contain identity, identity.pub, and known_hosts fields.
5. git.ref – an object with different keys underneath that can support which git reference to use for pulling the correct version of the accelerator repository.

• • • git.ref.branch – the Git branch to checkout (defaults to master)
    • git.ref.tag – the Git tag to checkout. This field has precedence over the branch value
    • git.ref.semver – the Git tag semver expression to use to find the latest relevant tag. This field takes precedence of the tag value.
    • git.ref.commit – the Git commit SHA to checkout. This field has the highest priority.

While as we will see in a moment we can use accelerators without a Git repository, it is highly recommended and much easier to maintain long term, when using Git as the source of our accelerators.

OCI Bundle Source Fields

The final section of configuration options in the accelerator CRD is nested under the “source” key.

Like with most other parts of the platform, we can use an OCI bundle which is generated via the imgpkg tool from the carvel toolset, to store our manifests inside a container registry instead of within a Git repository.

While this is supported to be used for all use cases, the main use case for it, and the only one I would personally consider using it for, is for quick iteration on a accelerator when doing the initial scaffolding.

The quick iteration workflow is performed in a similar manner to how it is done with the VS Code Local iteration workflow, where the Tanzu CLI accepts a flag “–local-path” where we point it to a path on our local filesystem, and we also provide a flag “–source-image” where we define the image URI for where to push the auto generated OCI bundle. This process will automatically generate the OCI bundle, push it to our registry (you must be logged in to the registry on your machine via docker login), and configure the accelerator CR to point to that image URI.

The fields available for configuration under the source key are:

1. source.image – This is a reference to an image in a remote registry.
2. source.imagePullSecrets – ImagePullSecrets contains the names of the Kubernetes Secrets containing registry login information to resolve image metadata.
3. source.interval – the interval at which to check for repository updates
4. source.serviceAccountName – the name of the Kubernetes ServiceAccount used to authenticate the image pull if the service account has attached pull secrets.

This can make local iteration easier, especially in organizations with stricter configurations on the Git server, which can delay the time it takes to be able to test out the accelerator.

As you can see, while simple and concise, the accelerator CRD offers us just the right level of configuration knobs, to define from where, and how to access the source code of the accelerator.

Fragments

After tossing around the term “fragment” many time throughout this post so far, lets now actually look at what a fragment is, why we would use them, and how we can use them.

Why do we need fragments

When we build out more and more accelerators, one of the things we can notice pretty quickly, is that there is often a lot of repetition and copy paste work involved between our accelerators.

More often then not, our accelerators will contain at least a few shared aspects whether that be options or transformations, and it can become difficult to manage at scale a fleet of accelerators, without being able to pull out shared logic and reuse it easily within all of the relevant accelerators.

This is why App Accelerator introduced a composition feature in the tool that allows re-use of parts of an accelerator, named Fragments.

What makes up a fragment

A great aspect of how this feature was implemented, is that a fragment is designed to look and behave nearly the exact same way as an accelerator does. It is made up of a set of files in a git repository, and contains an accelerator.yaml, with options, imports and engine sections exactly the same as within an accelerator.

This difference is that they are exposed to the platform via a different type of CRD namely a fragment.

How is a fragment added to the platform

The fragment CRD is a stripped down version of the accelerator CR, with the same git key under the spec section allowing us to point at our source code in a git repository in whichever manner we would like. it also contains a displayName field which provides a short and descriptive name for the fragment.

All other fields are not present in this CR, as you don’t invoke a fragment directly, nor is it visible in the catalog of App Accelerator. It also doesn’t support being based on an OCI bundle and requires the source to be a git repository.

Example use case for fragments

While the examples are endless, some common examples for fragments could include:

1. Backstage configuration files – this could be an easy way to manage templates for different backstage configuration settings for components, domains, systems, apis etc. This then can be imported into any accelerator to allow configuration options for managing the backstage configuration yaml files.
2. Language version selection – In many organizations, we may want to standardize on a set of specific versions of a language or framework we support. While we could give a dropdown for example in a Java based accelerator to select the Java version to user, or the same goes for any other language or framework, wouldn’t it make a lot more sense to pull this config out of our accelerators, and simply import this fragment into all of the accelerators based on that language? this would allow us to easily update the list of versions we support in one central place and not need to update dozens of accelerators anytime we want to support or remove support for a version.
3. Live update Tiltfile – we can extract the Tiltfile to a seperate fragment and simply import it into our accelerators that support live update functionality. This allows us to update the base Tiltfile in a central location and simply reference it within all of our relevant accelerators.
4. TAP Workload Yaml – the number of permutations of how one could configure a workload CR are huge with the OOTB supply chains, let alone with custom supply chains. Pulling out the workload yaml templating into a separate fragment allows us to make changes and expose new options for configuration in a centralized way and gain the benefits automatically across all of our accelerators.

The options are truly endless, but I hope that the above examples give you an idea of how fragments could be used to help simplify and accelerate the process of building and maintaining a fleet of accelerators.

Example Custom App Accelerator

I have put together a few custom app accelerators, that implement a lot of the different transformation options, different input types and and configuration capabilities as well as some heavy usage of fragments to emphasize the benefits they can bring.

The example accelerators and fragments are available in a public Github repository and will be updated overtime with more and more examples.

If you have any questions, suggestions or things you would like to see in that repo, feel free to open up issues or PRs!

Now that we have covered what an accelerator is, how we build one, how we add one to our platform, and also how we can use fragments to make them composable and enable reusage of shared functionality, lets now take a look at App Accelerator from a consumption perspective.

How to invoke an accelerator

An accelerator can be invoked via 3 main interfaces where 2 of them are UI based wizards and the other is a CLI based mechanism.

Lets take a look at the features, pros and cons of each of these different interfaces, and try to understand in which use cases, each of these tools would make sense to be used.

TAP GUI

The main User interface for App Accelerator is provided via a custom Backstage plugin provided as part of TAP GUI.

This interface allows end users to view the catalog of available accelerators, filter based on tags or search for them via a search bar.

It also provides a button which can open up in a new tab the source repository that backs the specified accelerator, and also a button to choose an accelerator to use, which will open up the accelerators input form in a simple graphical UI.

If we take for example the OOTB accelerator for the sample “Tanzu Java Web App” the input form is very simple and basic:

Once we have filled in the options available in the accelerator, we can simply click next and will receive the following page:

In order to generate the final project we can simply click on the “Generate Accelerator” button which will run the accelerator engine for our new project and that will provide us with the following screen:

We can see in the right hand side, the logs of the accelerator generation task, and on the left we are provided with 2 options.

We can click the download button which will open a window to select where we want the zip file with our templated project to be saved on our machine and we are ready to start iterating on the code locally!

We can also click on the “Explore zip file” button which will open a file browser modal where we can view the generated accelerator files

Just to show what a more complex accelerator form may look like here is the form for one of my custom highly customizable accelerators for a Java web app that integrates with App SSO:

Overall, the experience using the TAP GUI interface is pretty great and simple!

While this plugin works great, and provides a very good UX, one thing that is becoming ever so clear these days in all sorts of polls and research, is that developers want to live within their IDE and want to stay within the boundary of their IDE as much as possible. This is where the next interface comes into play.

VS Code Extension (Beta)

In TAP 1.2 amongst all of the amazing new capabilities, we also got a new VS Code Extension which is for App Accelerator.

This plugin enables us to explore the available accelerators in our platform, and generate a new project from one of them.

The configuration of the plugin is extremely easy and we only need to provide the URL of our App Accelerator server’s Ingress:

Once we have configured the accelerator URL in the VS Code extensions settings, we can go to the “Tanzu App Accelerator” extension in the list on the left and view the list of accelerators.

Once we click on a specific accelerator we want to use, a form is opened on the right to generate the project:

As we can see, we have a very similar form UX as we get in the TAP GUI interface, however this is provided directly in the IDE!!!

The other great feature of this plugin, is that when we click on the “Generate Project” button, we are prompted with a popup to select where we want the generated project to be saved, and once we set that, the accelerator will run, and a new window of VS Code will be opened with the workspace set the the newly generated project!

While their are some rough edges currently in the extension, the overall approach and UX is pretty awesome!

Being able to consume accelerators directly from the IDE is an amazing feature, and I really think that this is a perfect example, of how VMware are really focusing in TAP on meeting the different personas where they are, and providing the integrations into each personas natural ecosystem of tooling in a truly awesome way!

While UIs are great, and we often really like the experience they provide, some people or certain use cases, simply require a CLI or API based approach, and that is where the next interface comes into play.

Tanzu CLI – Accelerator Plugin

The Tanzu CLI has a dedicated plugin which is fully dedicated to App Accelerator.

Through this plugin, we can create, apply, update and delete accelerators and fragments.

We can use the CLI to view which accelerators we have:

We can then get the input options and details for a specific accelerator:

And now we can generate a project from the accelerator:

And that generated in my current directory a zip file with the newly generated project!

Summary

I am a big fan of the Application Accelerator functionality in TAP, especially with the new features that have been added in TAP 1.2!

I hope that this blog post has been helpful in organizing the subject of Application Accelerators for you, and given you a bit more of an understanding on the features available within the tool, and truly how extensible and customizable we can make our platform by creating some custom accelerators that are really well adopted and suited for your organization.

I am excited also to see where this project goes moving forwards in terms of new features and UX enhancements!

It is great to see how VMware have built a truly awesome technology, based on upstream open source plugins in backstage, and added that additional enterprise grade wrapper and feature enhancements to create a very cohesive and good experience for both the Enterprise architects or SREs that will define the accelerators, as well as for the developers who will be consuming the accelerators.

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:

1. Fragments
2. Sub Path Support
3. 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:

1. Better support for Multi Cluster Topologies
2. PR Based flow visibility
3. Security Scan Data visbility
4. Customization capabilities
5. 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:

1. Workload Panel
2. Apply and Delete Workload commands
3. Live Hover integration for Spring Tools
4. 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.

1. 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
2. Added a –service-account flag to allow specifying the service account to use for the workload
3. Added support for ignoring local files when in the inner loop development via a .tanzuignore file.
4. Added additional info when running “tanzu apps workload get”, including source information and supply chain step information

One of the great features in Tanzu Application Platform is that it supports a multi cluster deployment.

Many people may ask, Why does this matter? and also may ask is this really needed?

To answer these questions lets take a quick look back at TAS – A great VMware maintained PaaS solution and how it handled or didn’t handle the multi cluster story.

Tanzu Application Services (Cloud Foundry)

In TAS, the entire solution is deployed in a per environment basis. This means that the entire stack otherwise referred to as a foundation, must be deployed in every environment I want to run a TAS based application.

If we take a simple use case where a company would have 3 different environments (Dev, QA and Prod) this would mean that i would deploy the entire TAS stack 3 times.

There would also be no connection from a platform level between the 3 different environments.

This means that when i move from Dev to QA and finally to prod, in each environment the platform would compile my code, Build the Container / Blob, Create the deployments manifests and finally deploy my application.

This also means that whenever I make a change in one environment I must manually or via some custom automations, propagate those changes the same to each of my additional environments.

While writing these automations is not a terribly complex task, it is a level of overhead we must maintain over time.

Another key issue with this approach is that my artifact is being built multiple times and not just once. while Buildpacks and the overall CF platform do offer the benefit of reproducibility making the multiple builds outputs be essentially the same, it still is a repeated task that can make things like attestation, artifact tracing and overall confidence in the idea of artifact promotion much more difficult to achieve.

Another key aspect that makes the multiple foundations a challenge is the fact that it takes up A LOT of resources!

For example, when running on vSphere, the minimal footprint as documented on the TAS documentation would require:

82 vCPUs, 120GB RAM and 2TB of storage.

Now if we times that by our 3 environments, and this is all speaking of a single AZ deployment which is not suggested for a production deployment, we are talking about at minimum, 246 vCPUs, 360GB RAM and 6TB of storage!

That can become very expensive overtime.

Tanzu Application Platform

In TAP, the story is very different.

One of the key reasons that TAP can support a Multi Cluster topology is that unlike TAS, TAP is built to be customized, manipulated, and tweaked to your needs.

Because the steps in our software supply chain on TAP are configurable, we can have each cluster that has TAP on it, perform different tasks and steps.

TAP also is based on an OSS project called cartographer. Cartographer as the underlying tool for choregraphing the supply chain, has a clear separation between CI and CD.

while for CI we have what is referred to as a Cluster Supply Chain, In the CD world we have a Cluster Delivery. both Resources are similar in there structure, but each one is purpose built for its specific domain.

When it come to promotion between environments, we are given 2 OOTB solutions that can offer us a great mechanism for promoting artifacts from one environment to X other environments.

The first option is to use GitOps. TAP will build our image for us and also generate our Kubernetes manifests amongst other tasks it performs. once the generated manifests are rendered, not only can TAP apply them to the cluster, it can also push the manifests up to a Git Repository. This can allow for traceability, and also can help us promote artifacts, as the artifacts are now saved outside of the cluster, in a central location.

The other OOTB option is to use what i refer to as OCIOps or other places may refer to as RegOps. this is where the manifests are stored not in Git but rather in an OCI bundle in a Container registry. While the technology used is different the underlying objective and outcome is the same in this regard. In both cases our configuration is pushed to a central location, from which it will be pulled and run in additional clusters.

So Why Multi Cluster

The reasons for wanting to go down a multi cluster approach can be split into multiple general sections:

1. Resource Utilization
2. Security
3. Artifact traceability and attestation
4. Scalability
5. Multi Cloud
6. Industry Standards
7. Visibility

Lets break these down and understand how Multi Cluster Topologies can help.

Resource Utilization

As mentioned before, It is inevitable that we will need multiple environments. while that is true, the need to deploy the entire platform in every environment can get very costly in terms of Cash, Resources and also Time. The time aspect is key as well and is often overlooked. The need to rebuild an app at every promotion can be a timely task and when you deal with large scales, this can quickly build up and become a true bottleneck.

The fact that you don’t need to run Tanzu Build Service, Tekton, Image Scanning mechanisms and more in every cluster can save huge resources, and the fact you don’t need to run knative and contour in your build cluster for example also save huge amounts of resources.

While the numbers may not seem huge at the beginning, when we start to scale out our landscape, the numbers simply keep growing and that’s where this type of a multi cluster topology can really shine!

Security

Another key aspect that Multi Cluster Topologies can hep with, is in the realm of security.

Many organizations have regulations and security requirements that can limit the accessibility to the internet for example from our clusters. not only this but we overall want our environments to be as locked down as possible, and to only open up our clusters to the bare minimum needed, even if it is within our companies network.

By separating out the Build aspects from our runtime aspects into separate clusters, we can for example have our build cluster open to either the internet for pulling down dependencies from sources we need or to our internal artifact registries, but at the same time we can lock down our runtime clusters to only have access for example to our container registry for pulling images and our git server for pulling down manifests, without the need to have the runtime clusters open to our build time infrastructure.

This could offer huge flexibility to on one hand not impede on developer agility and speed while at the same time, keeping our environment safe.

Artifact traceability and attestation

Another key aspect that Multi Cluster Topologies can hep with, is related to security but has many other implications and benefits as well.

The idea of artifact traceability and attestation is not new, but it is getting a lot of attention these days, especially since we have seen multiple large scale attacks happen in the industry that could have been prevented it such mechanisms were in play.

the general Idea of being able to trace the provenance of an artifact throughout its lifecycle is a key aspect in making sure that our Software supply chain is secure and that nothing malicious has altered our software throughout the supply chain.

This is a topic that is being heavily invested on in TAP, but is already seeing its first steps of integration through the built in integration with Cosign, which will automatically sign our images when they are built in the build cluster. The next step is a built in configuration we have in the runtime clusters, that can validate and enforce that only images signed by a specific build cluster for example can be run in the cluster. this allows us to be certain that only images we know the provenance of can be run in our clusters.

Another key aspect is that because TAP uses Cloud Native Buildpacks by default to build images, we get an SBOM attached to each of our images built which is a key feature and needed info when trying to attest to the origin of an image, and to what is in that image.

While much more work is needed in this area, by having the signing and SBOM generation capabilities built in from the beginning into the platform, we are already in a pretty good place.

This is a huge improvement over the traditional PaaS approach of rebuilding an artifact in every environment as the attack vectors in that case are much wider, and we don’t actually have the traceability back to the original source which is our development environment. in TAP this is all possible with little to no configuration post deployment of the platform which is pretty amazing!

Scalability

Another key aspect that multi cluster can help with is scalability of our platform.

Typically we see customer starting with relatively small kubernetes clusters, but as time passes, these clusters keep growing. we have had many instances by customers where for many reasons including scalability issues, the need to split clusters has been required.

This is easily dealt with in TAP as we can simply add another CD target which would be our new cluster, without effecting our running environment.

Multi Cloud

TAP is truly a multi cloud PaaS.

While tools like TAS could be run on different clouds, there were complexities involved in getting this to work and to manage it at scale.

A key factor that differentiates the 2 tools in this regard is where the platform begins, and what it needs to integrate with.

TAS included within it the container runtime and container orchestrator as well as the platform itself. this meant that the platform was tightly coupled to the underlying container orchestration tool. This also meant that the integration point between TAS and our cloud or clouds of choice was specific to each cloud provider. TAS had to be deployed with a specific cloud provider interface (CPI) that knew how to interact with the specific cloud provder to perform tasks such as managing VMs, LBs, Security Groups etc.

This means that with every cloud provider, the configuration was different, and that you could only deploy TAS on a cloud, that had a TAS Cloud Provider implementation.

In TAP, the platform does not include a container orchestrator, rather it simply relies on you installing the platform on a conformant Kubernetes cluster which could be of any form shape or size.

Because the integration layer for TAP is simply Kubernetes, you can run TAP anywhere that has Kubernetes. This can be vSphere, GCP, AWS or Azure which are all supported in TAS as well, or it could even be Bare Metal servers in your datacenter, or any other Cloud Providers Kubernetes offering as long as that Kubernetes Cluster is a conformant kubernetes cluster.

Decoupling the runtime from the platform is a huge benefit as it means, the TAP development team can concentrate on building out the platform itself and not need to worry about the underlying cloud provider the platform is running on.

This also helps us as users be assured that we could migrate to a different cloud, or add another cloud into our environment and onboard it into TAP very easily, without any special configurations or changes!

Industry Standards

When we look at the broader ecosystem today, the idea of a multi cluster supply chain, with purpose built clusters that artifacts are promoted between using GitOps principles is becoming a De-Facto standard.

TAP as a platform itself not only is built up of industry standard tools such as Kubernetes, Knative, Contour, Cert Manager, Buildpacks, Tekton, FluxCD etc. but it also enables us to utilize industry standard practices such as GitOps in a really easy to consume manner.

This can be extremely helpful when onboarding new developers or platform engineers into our environments, as the concepts and methodologies used in TAP are industry standards which means that we have a much better chance of finding people that are familiar with these approaches then other proprietary and tool specific approaches we see in other PaaS platforms.

Visibility

Another key aspect that TAP in a multi cluster topology offers us is in the realm of visibility.

When we have multiple environments, visibility across our landscape becomes a challenging topic to tackle.

TAP which uses the CNCF Backstage project for its GUI, has a huge advantage because Backstage is built in a way that easily allows connecting multiple clusters into the same GUI, and giving a true single plane of glass visibility across our entire landscape.

TAP GUI includes within it built in support to visualize our workloads across clusters, side by side, allowing us to see how a particular service is performing and where it is running across all of our clusters.

Summary

The idea of a multi cluster PaaS is truly exciting in my opinion. I think that having this capability brings the opportunity to think of how we build out our environments in ways we haven’t thought of as possible till today.

I’m truly excited to see how the Multi Cluster TAP functionality will grow and evolve over time.

For those interested in how i set up my Multi Cluster TAP environments in my vSphere environments, you can check out my Github Repo which has a simple BASH script that can deploy 5 TKGm clusters and fully configure TAP on them in a simple and automated way.