Application definition is the process of creating a codified operational runbook. It formalizes the process of describing in code everything an application needs to be built, run, and managed.
By openly defining in code all of the requirements for building, running and maintaining an application at the outset, we not only gain consistent delivery across all environments regardless of the underlaying technology but we also eliminate repetitive work across teams and minimize the number of tools and manual gates involved in delivering the application. We not only have all the “pieces” we need to successfully deliver the application but we also have fewer “pieces” to assemble and manage.
For those familiar with the 12 Factor App Methodology many of the following ideas will look familiar, as many of its principles were adopted in the design of Chef Habitat. Chef Habitat is an open source and patented automation tool that enables companies to apply a consistent approach to application definition, packaging and delivery across all applications and environments. By applying the same 12 Factor App Methodology that customers use for creating applications to the design for Chef Habitat’s application delivery and management automation, we enable customers to achieve the same agility in the operations side of the house as they have already achieved on the development side.
Below is a brief description of each of the 6 key requirements that are described as part of Chef’s approach to application definition: Application Codebase, Configuration Instructions, Build Instructions, Dependencies, Relationships and Run-time Instructions.
A single version control for an application’s codebase is the first principle in the 12 factor application methodology. By storing all of the requirements needed to build, deploy and manage an application alongside the application codebase, build teams create an immutable object that can be consistently delivered to any environment with little knowledge of the underlying technology on the part of DevOps and release teams. A Chef Habitat artifact includes the application codebase along with all the codified instructions for building, deploying and managing the application.
Explicitly declaring and isolating dependencies into atomic plans may be the single most important task any application delivery team focused on driving consistency, repeatability and scale can do. It not only eliminates run-time errors caused by missing dependencies but also enables teams to easily update a dependency without updating the entire application. In addition to providing a modular structure for isolating dependencies into atomic plans, Chef Habitat also provides a clean room environment (Chef Habitat Studio) for testing and validating builds, ensuring that what is built and run in development will be exactly the same in production. This approach eliminates the age-old “worked fine on my machine” excuse.
In order to have a running application, you need a subsystem to monitor the application process. The subsystem is responsible for ensuring required services are available before the application starts. Typically, in many modern architectures, some responsibility for resilience also depends on application developers coding with unreliable backing services in mind. With Habitat, all of those responsibilities are the domain of the Habitat Supervisor. The Habitat Supervisor is a light-weight intelligent agent built upon patented technology (US Patent #10,380,365, August 13, 2019) that handles run-time operations. The supervisor can be programmed during the definition phase to do a number of advanced run-time functions including environment readiness checks, sequencing, service discovery, deployment pattern execution, roll-back and real-time data reporting.
Traditional configuration management tools were designed to write configuration files, using a declarative language to manage a server. These tools focus on building working servers by installing and configuring system settings, system libraries, and application libraries before an application is installed on the server. Chef Habitat focuses on the application first instead of the server. Habitat builds and packages your application’s entire binary toolchain, including the system libraries, application libraries, and runtime dependencies necessary for your application to function. As a result, Habitat can be used to replace many use-cases that configuration management tools perform related to installing system binaries, application dependent libraries, or templating configuration files.
Continuous integration solutions like Jenkins and Azure DevOps automate the process of building applications but can be complex to maintain in heterogeneous environments. Differences between languages, dependencies, or deployment methodologies historically needed to be addressed uniquely for each application, making pipelines difficult to scale. In contrast, Chef Habitat ensures all of the instructions and dependencies needed to build the application are specified within its plan, minimizing the amount of custom scripting that needs to be done within the pipeline. By consolidating all of the build steps into a plan that travels with the application, developers not only test using the same build that will be used in pre-prod and prod but also gain control of how their apps are built and run. This not only improves the overall quality of the application but also drives productivity by eliminating the need for DevOps teams to “learn” how to build each application.
Application Relationships (Backing Services)
Principle 4 of the 12 Factor App Methodology is to treat backing services (datastores, load balancers, messaging systems, caching systems etc.) as attached resources which is exactly what is done when defining relationships as part of a Chef Habitat generated artifact. In addition to being able to explicitly declare what services an application requires to start and run, Habitat packaged applications can also export the services, configuration, and ports the application offers to other applications. This allows you to easily bind services to one another, and once again this knowledge of exposed services is baked into your Habitat application artifact.
This knowledge of these service dependencies is stored in the Habitat application artifact, allowing you to easily query what services an application needs directly against the application itself.
In conclusion, application definition shifts the bulk of the work for building and releasing applications to the design and development phase. Tasks that were done throughout the pipeline are shifted to the onset of the process enabling application delivery teams to drive efficiency across the pipeline.
Application Definition Typical Results
Creating codified, shareable, searchable and auditable runbooks that encompass all of these tasks takes time and effort but it is the only way to scale and consistently deliver complex applications. Learn more about Chef Habitat.