Not long ago, we told you about Pivotal Cloud Foundry (PCF) buildpacks and service brokers, and all the ways you can deploy AppDynamics agents in a PCF environment.
Buildpack is the key concept here. When you do a deployment to PCF, the buildpack is your foundation. You include the app with the buildpack, which incorporates all the logic needed to connect to various PCF services. Because the Cloud Foundry platform includes a mechanism for adding support for third-party services like AppDynamics, it’s really easy to add our APM instrumentation to all your applications without having to make any code changes. We’ve been doing this for some time, of course, and Pivotal recently recognized AppDynamics for our outstanding solutions and services, specifically our support for .NET in the Pivotal environment.
Here’s a new example of how we’re staying on the front edge of PCF development. For the first time, we’re using an innovative Cloud Foundry feature called multi-buildpacks. Starting with v4.5.514 of the AppDynamics Application Monitoring for PCF tile, we’re offering an AppDynamics Extension Buildpack that works in tandem with standard buildpacks using Cloud Foundry’s multi-buildpack workflow.
The .NET team at PCF has been leading the way in multi-buildpack development (more on this in a bit) and we’ve recognized the value of this approach. Now our goal is to apply the same model to AppDynamics’ APM support for all PCF applications.
The Standard Buildpack Model
With a traditional buildpack, we build the logic for integrating AppDynamics agents directly into the official Cloud Foundry community buildpack. We test our code against the main buildpack code, which is maintained by Pivotal on behalf of the Cloud Foundry community. We then send a pull request to Pivotal, which takes our code and releases it as an official part of the buildpack. This is a well-established model carefully managed by Pivotal and adhered to by third-party service providers like AppDynamics. It works because it’s a well-known and understood mechanism. But there’s a better way to do it.
The Advantages of Multi-Buildpack
Pivotal’s multi-buildpack concept is like a layer cake. The main buildpack—the base layer—is the official community buildpack. Third-party providers like AppDynamics provide additional functionality (or layers) on top of the base layer. The end result is a multi-buildpack that can be deployed as essentially a single piece. For example, here’s how we’d push a .NET HWC application with the AppDynamics-specific extension (appdbuildpack) and the base buildpack from Cloud Foundry (hwc_buildpack):
cf push -b appdbuildpack -b hwc_buildpack -s windows2016
This is a good model with many benefits, including a clear separation of responsibilities. Pivotal is responsible for the core buildpack and how it links to the service broker and other parts of the Cloud Foundry platform. It also manages all the services your application needs, such as routing and deployment. Third-party providers like AppDynamics are responsible for how their agent installs. If a third-party service introduces a bug, the glitch won’t break the main buildpack.
From our perspective, another benefit of this model is that it gives AppDynamics more control over what goes inside our buildpack, such as custom configuration for our APM Agents. Suppose, for instance, you want to include a custom configuration definition file or custom logging capabilities. It’s very easy to do so. Our buildpack extension defines a folder where you can include the appropriate custom files when you push the application. Once deployed, the application will have the AppDynamics agent installed with the custom configuration file in place. This eliminates the need to fork a buildpack for the sake of customizing agent behavior.
From the customer’s perspective, the multi-buildpack model provides a strong support system. It’s very clear who they need to work with (e.g., AppDynamics or Pivotal) for help with specific components or services. Another plus is that we bundle this buildpack with the AppDynamics Service Broker tile. So when you install the latest version of our tile, it will automatically install the buildpack in your environment. And when you deploy an application using any of the main language buildpacks, our extension will be applied on top.
AppDynamics and Multi-Buildpack
Our goal isn’t simply to make AppDynamics work on PCF, it’s to make it work in the best way possible. We already have added support for .NET HWC applications and .NET Core to our AppDynamics Extension Buildpack, and we will soon bring this approach to other dynamic language environments as well, including Python, Go and NodeJS. We will also add support for the Java buildpack to do advanced configuration of AppDynamics Java Agents, although we will, of course, continue to support basic configuration in the standard Java buildpack.
See for yourself how the AppDynamics Extension BuildPack (Multi-BuildPack Approach) can make your life easier!
