As-Code: The Continuous IT Stack
There are always terms with any technology trend that quickly become so full of hype that they can be virtually useless. Cloud was one, in the beginning. In some ways it still is. DevOps took several years to sort out (if it even has). Machine learning and AI are currently barefoot surfing on the hype wave and show no signs of wiping out anytime soon.
Close behind them all is "as code."
Suddenly everything is "as code". The market can't get enough of "as code", even if most of it can't tell the difference between C, C++, and C#. "As code" has become the answer to life, the universe, and everything. There's no problem that "as code" can't solve, and everyone is doing it.
It's important when terms are thrown around without boundaries or clear definitions that we pause and make sure that we're clear about *our* definitions. It would be nice if there was a standards committee with an RFC-style definition to refer to, but there isn't. The closest we have is NIST, and we saw how well they were able to quell the cloud conundrum.
There is more to "as-code" than just infrastructure as code (IAC). Aiman Najjar @ Pythian wrote up a great overview of the current infrastructure-as-code landscape. While I disagree that containers should be their own layer (it's just infrastructure from the perspective of the network and application services) and that Jenkins doesn't belong, in general his blog was an excellent way to understand the relationship of the 'as code' layers and map the right tools for the right job. Too, most infrastructure as code discussions are focused on continuous delivery - that is the pipeline that builds, tests, integrates, and releases an app to production. This is not the same process as continuous deployment, which is focused on taking the released application and deploying it into a production environment along with its required network and application services.
NOTE In app utopia, the delivery and deployment pipelines are converged. But most of us (still) live in app reality, where production and development are separate environs with different sets of requirements and constraints. Hence the need to recognize this separation when we apply automation to the pipeline.
There are three distinct layers rising to cover the eccentricities innate to IT and the deployment pipeline. Foremost amongst them is the complexity inherent in the environment. That straight line from client to app we draw in network diagrams isn't fooling anyone. There's just far more going on under the hood than we have time (and patience) to diagram.
The diversity of the pipeline itself - comprising purpose-built hardware as well as virtual and container-based software deployed on COTS - also provides the impetus for slicing and dicing 'as code' into separate layers. While it's true that more modern hardware can be managed via an as-code approach, legacy (shared) hardware can be nigh unto impossible to squeeze into the process. Separating the layers, then, to more closely mirror the deployment process itself can provide a way to include both legacy and modern hardware-based solutions along with software-based services in the pipeline.
The goal is to build up a continuous IT stack capable of supporting per-app deployment schedules and architectures in a multi-cloud environment. And because deployment is only the beginning of an application's active lifecycle, there needs to be a fourth layer that focuses on post-deployment operations. This is in addition to the three core layers covering infrastructure provisioning and onboarding, service configuration and management, and the deployment pipeline.
The list of tools is not to be considered all-inclusive. There are many other tools and toolsets. For example, we know from multiple surveys and research that the bulk of NetOps prefers bespoke Python scripts for the task of automating network and application services. And we also know that network automation systems and stacks like Cisco ACI, VMware NSX, OpenStack, and Red Hat OpenShift are popular means of implementing many functions in the continuous operations stack. There simply isn't enough room in the visual to include every tool, and thus a sampling has been included based on popularity of the tools with DevOps. This is because standardization across the delivery and deployment pipeline will be an essential component of success and it's hard to argue against leveraging existing skills and expertise in your organization with the tools most commonly used to implement 'as code' delivery pipelines. Of note, I have not listed any tools for "operations as code" because many of these are bespoke (custom scripts) or specific to a vendor technology - at least for now.
NOTE Operations as code is the IT equivalent of business process management (BPM). With BPM, business processes are automated. Some BPM focuses solely on very specific workflows, others may cover the length and breadth of a customer interaction from purchase to payment to delivery. Operations as code is a nascent practice in IT today, but it will need to mature into operational process management if businesses will be able to capitalize on optimization operational processes in the same way they've learned to take advantage of BPM.
Continuous Operations Stack
Infrastructure as Code (IaC)
Whether in the cloud or in the data center, there is still a network that needs configuring. Even higher order services (those operating at layer 4-7, a.k.a. application services) require some knowledge of network topology in order to operate. Some of it may need to be activated (a.k.a. licensed) if you're deploying a brand new pipeline. Infrastructure as Code is necessary to enable a self-service approach to deployment, as without the infrastructure (software and services) in place, there's nothing to configure or deploy an app to.
Responsibilities: infrastructure onboarding, licensing, provisioning
Configuration as Code (CaC)
This is a separate issue from configuration, which specifically speaks to the need to, well, configure policy and behavior specific to the service in question. Configuration may recur with every major application update. It may recur with every minor update, as well. For security-related services, it may occur on an emergency basis to patch, update, or upgrade a given service. Configuration as code is critical to supporting per-app deployment schedules and pipelines, and to enforcing the isolation of application data paths important for ensuring stability of the production pipeline as a whole.
Responsibilities: service configuration, upgrade, and patch
Pipeline as Code (PaC)
Then there's the overarching process that defines the entire application and its services from beginning to end. It's the entire pipeline, and it's codified into an executable process that automatically drives deployment. Pipeline as code is the link between IaC and CaC that ties it together to describe what we call a deployment pipeline. It is in the pipeline that the most gains in speed and efficiency will be found, as it enables the elimination of wait times between the steps required in the process.
Responsibilities: deployment process automation
Operations as Code (OaC)
This layer is the ongoing operational layer. It's where monitoring and alerting, auto-scaling, and discovery occur. In this layer, we are concerned with codifying operational processes into a system capable of executing them on their own. Auto-scaling is one of the most often codified operational processes and involves multiple systems. But gathering telemetry for analysis is another operational process that needs attention, as does the possible actions taken based on that telemetry that enables (automatic) adjustments to optimize the data path or application performance. These operational processes have their own configuration and come into play after the deployment process is complete.
Responsibilities: operational workflow automation
Viewing continuous deployment through the lens of the continuous operations stack can provide a strategic approach to automating the production pipeline. By separating the layers and responsibilities it is easier to approach the very daunting task of automating IT duties in a way that enables the self-service approach desired by many organizations and increasingly demanded by the business. It also enables a path to continuous operations via operations as code, which is a necessary evolution in the use of automation within IT.
Now, this may not be the 'one true way' to view the automation efforts associated with the deployment pipeline. But it is one way, and it does provide the ability for the market to speak clearly about what it is they do or don't do.
It means you can be certain what it is I mean when I say infrastructure as code or configuration as code, especially with respect to F5 products.