What Is ACS

ACS or Application Configuration Service, is a new optional component added in TAP 1.5. ACS, is a Kubernetes native replacement for the Spring Cloud Config Server, which was an essential part of a Spring Cloud based microservices based architecture, heavily used by Spring based workloads in the Cloud Foundry and Azure Spring Apps world.

Spring Cloud Config Server helped by enabling setting runtime config for spring apps, in Git repositories. These configs could be stored on different branches and in directories that could be used to generate runtime configuration properties for applications running in multiple environments.

ACS is compatible with the existing Git repository configuration management approach, and offers a Kubernetes native integration layer, making the configuration fit much more seamlessly, with application when deployed to TAP. ACS filters runtime configuration for any application by using slices that produce secrets, which can the be bound using Service Claims, like all other external configurations or service binding in a TAP environment.

When ACS Should be used

ACS is a great replacement for any usage you may currently have of Spring Cloud Config Server, and with minimal changes can replace it, without any major changes.

ACS is extremely beneficial if you are migrating to TAP for PCF/TAS environments, where SCCS is very commonly used, and having a native integration for the same features via ACS, allows for a much easier migration path for your applications.

What does the UX look like

The first thing one would do, is configure a CR of type "Configuration Source", pointing at the Git repository where your SCCS config resides. For example:

apiVersion: "config.apps.tanzu.vmware.com/v1alpha4"
kind: ConfigurationSource
metadata:
  name: greeter-config-source
  namespace: my-apps
spec:
  backends:
    - type: git
      uri: https://github.com/your-org/your-config-repo

Once we have our source configured, we then can define a slice, where points at a specific config in that source repo. for example:

apiVersion: config.apps.tanzu.vmware.com/v1alpha4
kind: ConfigurationSlice
metadata:
  name: greeter-config
  namespace: my-apps
spec:
  configurationSource: greeter-config-source
  content:
  - greeter/dev
  configMapStrategy: applicationProperties
  interval: 10m

As you can see, this is a very simple and clear UX. the spec of these resources can be much more complex, and these are just examples, but the idea is always the same.

You can find the full documentation on this service here.

Once we have configured the ACS resources, we can simply create a resource claim which will allow us to bind the config to our workload as such:

apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ResourceClaim
metadata:
  name: greeter-config-claim
  namespace: my-apps
spec:
  ref:
    apiVersion: config.apps.tanzu.vmware.com/v1alpha4
    kind: ConfigurationSlice
    name: greeter-config

And now we can reference this resource claim in our workload as such:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: greeter-messages
  namespace: my-apps
  labels:
    apps.tanzu.vmware.com/workload-type: web
    app.kubernetes.io/part-of: greeter
spec:
  build:
    env:
    - name: BP_JVM_VERSION
      value: "17"
    - name: BP_GRADLE_BUILT_MODULE
      value: "greeter-messages"
  env:
  - name: SPRING_CONFIG_IMPORT
    value: "${SERVICE_BINDING_ROOT}/spring-properties/"
  serviceClaims:
  - name: spring-properties
    ref:
      apiVersion: services.apps.tanzu.vmware.com/v1alpha1
      kind: ResourceClaim
      name: greeter-config-claim
  source:
    git:
      url: https://github.com/spring-cloud-services-samples/greeting
      ref:
        branch: main

Summary

While this feature may not be a game changing feature for many, the ability it brings to easily migrate apps from TAS/PCF/ASA environments into TAP, is a huge accomplishment, and is a huge step in the direction of TAP becoming the de-facto standard for running Spring based apps at scale in containerized environments!

I am truly excited to see these types of features being added in to TAP, making the migration story into TAP, that much smoother for brownfield environments.