Building a Solid Foundation: The Role of the Build Command in Tanzu Platform

The first command we will cover is build. As the old saying goes, “The strength of a structure lies in its foundation.” If the goal of your platform is to get code to production, building and packaging your code in a repeatable and secure manner is core to that goal. 

So, what exactly do we mean by “build”? It’s the process by which a developer’s application code is compiled and packaged into a container. One common, and often default, method is to first build the code into an artifact, like a JAR file, and then create a Dockerfile to containerize it. At first glance, Dockerfiles seem simple and straightforward, and in fact, they are… in the beginning. However, Dockerfiles are like pigs—individually, they can be cute and manageable, but when you have lots of them, things quickly become a muddy mess. Managing multiple base operating system images and ensuring consistency across development teams can introduce significant challenges, particularly in maintaining secure and compliant containers at scale. This is why it’s crucial for top-tier platform teams to exert control over this process to avoid the inevitable, “Well, it worked on my laptop!” scenarios.

Alternatively, our build command leverages buildpack technology. Although Cloud Native Buildpacks is currently an incubating project with the CNCF, the underlying technology is robust, mature, and has been evolving for over a decade. To better understand this, let’s take a brief look at the history of buildpack technology:

Buildpack technology was first introduced by Heroku around 2011. As an early PaaS provider, Heroku created buildpacks to simplify the deployment process by removing the complexity of setting up the environment. Developers could simply push their code, and the buildpack would take care of the rest, including dependency management and configuration. After Heroku, Cloud Foundry, another major PaaS platform, adopted buildpack technology as well. Cloud Foundry’s implementation helped standardize the approach and extended its utility beyond Heroku’s ecosystem, making buildpacks a widely accepted technology in the cloud-native space.

The Cloud Native Buildpacks project, a joint effort between teams at Pivotal and Heroku, was initiated to standardize and further develop buildpack technology. This project is now governed by the Cloud Native Computing Foundation (CNCF), underscoring its maturity and significance in the cloud-native landscape.

The purpose of this history lesson is to highlight that buildpacks are a well-established and mature technology, ideally suited for platform engineering control over container-based deployments. So, what makes them particularly ideal in the context of the build command? Let’s explore the Top 10 Reasons.

1. 1. Simplified Development Workflow: Buildpacks automatically detect the language and framework used in an application and apply the appropriate build and runtime configurations. With just a call to the build command, developers can generate a secure, platform operator-approved container.
   2. Consistent and Reproducible Builds: Buildpacks create standardized and reproducible builds, ensuring that applications behave consistently across different environments. This reliability is crucial for successful deployments and scaling across various development teams.
   3. Security: Buildpacks come with security best practices built in, such as using minimal base images and regularly updating dependencies to patch known vulnerabilities. This reduces the attack surface and helps maintain secure images, while also removing the burden from development teams to choose the right base image.
   4. Automated Dependency Management: Buildpacks automatically handle dependency installation and management, ensuring that applications use the correct versions of dependencies. This reduces the risk of incompatibilities and simplifies updates. Additionally, a bill of materials can be generated for tracking and managing dependencies externally.
   5. Operational Efficiency: By automating the container build process, buildpacks reduce the operational overhead associated with maintaining custom Dockerfiles and build scripts. This allows development teams to focus more on coding and less on infrastructure concerns.
   6. Integration with CI/CD Pipelines: The build command is designed to integrate seamlessly with continuous integration and continuous deployment (CI/CD) pipelines. It can be used with tools like Jenkins, GitLab CI, or GitHub Actions to automate the build with buildpacks, test, and deployment processes.
   7. Compliance and Best Practices: Buildpacks encapsulate industry best practices for building and running containerized applications. By using the build command, teams can ensure compliance with these practices without needing deep container expertise.
   8. Customization: While buildpacks provide automated workflows, they also offer flexibility for customization. Developers and platform engineers can extend or modify buildpacks to meet specific requirements, combining the ease of automation with the flexibility of custom builds. For instance, runtime optimizations can be added to configure Spring Boot settings based on target runtimes, and pod conventions or application observability can be pre-wired automatically.
   9. Community and Ecosystem Support: The Cloud Native Buildpacks project is supported by a strong community and ecosystem, including backing from the Cloud Native Computing Foundation (CNCF). This ensures ongoing development, support, and a wide range of available buildpacks for different languages and frameworks.
   10. Centralization of Control: In many organizations, the platform engineering team may not have direct control over how developers manage their inner-loop development. However, their “table stakes” for operating on the platform involve ensuring that containers and workloads conform to the required standards on their managed production environments. The build command and buildpacks facilitate this centralized control, allowing the platform engineering team to enforce these standards and maintain security while still offering a straightforward and user-friendly experience for developers.

Tanzu Platform for Cloud Foundry and Tanzu Platform for Kubernetes each have an implementation of the build command as part of their core capabilities.  For Tanzu Platform for Kubernetes, it is implemented in the tanzu cli as either tanzu build or tanzu deploy  (which executes the build) and on the Cloud Foundry side, it’s implemented as part of the cf push and cf scale commands. Although the implementation is slightly different, the core value proposition, the process used in the containerization of applications, of build is consistent across Tanzu Platform.  

The build command is a fundamental component of the Tanzu Platform, streamlining the process of building and packaging applications into containers. By leveraging mature buildpack technology, it ensures consistent, secure, and efficient builds across different environments. This not only simplifies the developer’s workflow but also centralizes control for platform engineers, making it easier to maintain compliance and adhere to best practices. As we continue to explore the Golden Commands, it’s clear that the build command sets a solid foundation for a repeatable and reliable path to production, reinforcing the importance of a robust build process in achieving seamless application deployment.

You can find all three parts of the ‘Unlocking the Golden Commands’ blog series on Dan Baskette’s LinkedIn:
Part 1: Building a Solid Foundation: The Role of the Build Command in Tanzu Platform
Part 2: Harnessing the Bind Command: Streamlining Service Connections Across Tanzu Platform
Part 3: Automating Application Operations with the Deploy and Scale Commands in Tanzu Platform