Application-centric DevOps
DevOps is about running applications not infrastructure. For all we talk about DevOps, closing the gap between code running in dev and code running in production, it’s odd that Ops is still forced to take an infrastructure-centric view of the world, while Dev continues to take an application-centric one. Shouldn’t we care most about the application itself? After all, it’s the sum total of all the parts of an application--the code, the dependencies, the infrastructure, the deployment policies, the integrations--that is valuable to the business.
The solution to this--packaging everything required to install and run an application on a target--was solved a long time ago for desktop software with installers. Since then, the steady waves of disruption to both engineering and operations practices have led to the decentralization of applications and infrastructure alike and proliferate ways to address and automate all of it. Interestingly though, the idea that we should be taking all those increasingly distributed and disparate components and version controlling them as a package has not been compellingly reincorporated.
How did we get here?
In Ops, IaaS forced us to consider that infrastructure existing at any given moment is not, in fact, a given. We planned for failure. We imaged things and launched infrastructure from those images. When that proved to be too inflexible for the agility of cloud, we adopted launch-time configuration management and orchestration as a best practice. Let’s start with a golden image that’s versionable. Let’s layer in scripts to configure the machines, also versionable. Let’s tie it all together with orchestration so we get a fully functional deployment that can run the application that Dev provided us.
PaaS promised to simplify this tier by tier. We incorporated that into our orchestration and stitched these services together with IaaS and other API-driven resources, again in the aim of running the code that Dev provided us.
Meanwhile, Dev ran down the path with ubiquitous source control, continuous integration and continuous code deployment processes. We ensured they too could iterate quickly, partying on issues, testing and releasing early and often, breaking and fixing things with haste.
Then Dev hopped to the other side of the philosophical lemniscate with containers. Suddenly Dev is the one imaging things and could hand something to Ops to run in staging or production that they had just been running locally. Immutable image building was back in style and each tier could be more easily versioned once again.
Containerless...ahem...serverless is the next wave washing over us. The code just runs in the box[es]. Pay no attention to the man behind the curtain! Now we can incorporate all the best microservices from the most appropriate providers, and the middleware that glues them together with the datastores they need.
Ops trudged along and while they were happy to argue less frequently with Dev about what's going into the box, they were simultaneously dealing with exploding application architecture complexity. We continue to do our best to stitch things together. Though increasingly we’re dealing with broadly heterogeneous environments leveraging containers, instances, APIs, managed and unmanaged services (RIP CMDB). An application can be made up of one, some or all of these.
What’s the alternative?
Reconverging on the center of the DevOps leminscate, and bringing back the application-centric view of packaging and versioning everything as a unit. Take the code itself, its build dependencies and boot logic, the orchestration required to configure and deploy it and the governance policies it needs to follow to successfully run in a target platform, and make that an immutable, versionable object. You now have the packaged concatenation of DevOps. In this approach, the leminscate connects, it doesn’t overlap and chase its tail. It creates a trusted handshake between development, security and operations whereby all of their requirements, opinions and policies are converged.
Dev maintains control over the application, its version, the explicit dependencies they care about and the application’s boot logic within their tool chain. Ops and security lock things down, orchestrate the requisite cloud services, and integrate deployment and operational dependencies and policies using their preferred tool chain. The creation of a versionable, immutable, deploy-ready Application Package during the asset build and assembly process ensures that everyone’s requirements and policies are factored in at a point in time. Whenever we have a question about what is running and how, everyone knows exactly where to look--the Application Package.
When fully automated, the upstream CI tool converges the code and places a trusted code asset in an artifact repository and development manages their dependencies and application configuration requirements in source control. Continuous Application Packaging consolidates the code and other artifacts with the policies and automation required to run it whenever there is a change and places a trusted Application Package back into the artifact repository. Changes can be triggered by new code updates or external events such as a CVE that affects an included system package. Downstream, a CD tool or orchestrator would pick up that Application Package and deploy it. The deployment automatically wires up everything that was packaged in as a requirement, such as operational monitoring and logging tooling.
By acknowledging and packaging the hand-off of applications from Dev to Ops, we are establishing new trust in the Enterprise between these teams, that their requirements, policies and opinions will be factored in. We are allowing them to work with their preferred tooling and specialize in their domain knowledge. We’re advancing our understanding of immutability by applying those principles to the entire application. And we’re preparing ourselves for the next wave of disruption as applications continue to break apart into microservices, functions, and whatever the next building blocks will be called.
Packaging applications is as easy as v1, v2, v3 with Bitnami Stacksmith. Stacksmith does the packaging, logs everything that goes into them and continuously monitors components and repackages applications with security and system package updates. It provides a self-service and/or API-driven way for Dev and Ops to finally close the gap.