In every industry, automation has enabled scale and ushered in new eras. The first precisely datable printing of a text is recorded as the 31-line indulgence on the 22nd of October in 1454. The Gutenberg Bible, the printing of which is widely held as the beginning of the age of printed books in the west, was first officially recognized in 1455.
While it is believed that preparation to print the Bible began nearly five years earlier, once ready, it is believed to have churned out either 158 or 180 copies, based on an authenticated letter from then Pope Pius II. Prior to the printing press, it took a scribe, on average, 15 months to copy the Bible.
The printing press shifted reliance on manual work left; that is, the bulk of human tasks occurred before the printing press was engaged. The text had to be set up, of course, and that took time. Once engaged, the machine was able to perform the task of replicating that text incredibly fast (for the time, of course) without much human intervention.
This should sound a lot like automation today. The task of setting up configuration artifacts and pipelines still requires a great deal of human attention. But once in place, toolsets are able to churn out deployments without requiring manual interaction. After deployment, manual intervention is often required to adjust configuration artifacts – particularly policies that enforce security actions – and subsequently to "push" the update into production.
But what if we could automate even more of that process? What if there was enough information (data) available from all the infrastructure and application components to automatically make the right changes based on a set of target service level objectives?
That is the goal of adaptive applications, and we are closer to seeing it realized than you might think, thanks to modern architectures.
Artifacts and automation
One of the key components to enabling adaptive applications is that we first need to treat infrastructure as code. That means, at a minimum, that configuration and policy artifacts are extracted, stored, and managed like code, in some sort of repository. This separation of configuration from component is necessary to enable any third-party – human or machine – to modify and redeploy without impacting the rest of the environment.
Modern applications - mobile and cloud-native - support this concept naturally by reducing the scope of changes to individual components. Microservices are an excellent example of the kind of decomposition of logic that enables operators today to start, stop, and change the configuration of the "component" without impacting other components. When infrastructure (application services, app server, web server, etc.) are all able to participate in a pipeline driven by an infrastructure as code philosophy, we have the setup to enable adaptive applications.
Another part of the equation is being able to deploy automatically. And for that, we today rely on control plane APIs that provide an easy means for machines, scripts, and people to push a configuration artifact to an application, its infrastructure, or the application services delivering and securing it. Modern applications are often developed with an API-first strategy, and the use of environments like Kubernetes and OpenShift provide these APIs as well.
By treating infrastructure as code and using modern application architectures with open APIs, we can put in place the foundation for adaptive applications. This is the "setup" necessary to enable adaptive applications.
The missing piece
Just as the setup for the Gutenberg Bible appears to have taken years, you aren't going to setup adaptive applications overnight. Adaptive applications need something to drive the decision to modify configurations and policies; we don't want them willy-nilly changing things that don't need changing. That data is the fuel for analytics capable of ingesting, analyzing, and then producing the insights that will ultimately drive changes that result in truly adaptive applications.
The data generated by the application and its supporting services is ultimately what will drive the automation that enables adaptive applications. Auto-scale is a rudimentary example of this kind of closed-loop system. Adaptive applications take this well-beyond simple scale to recognizing components in a digital workflow, causing performance degradations and taking actions appropriate to resolving the issue.
Modern application architectures are well-suited to accelerating the setup due to their inherent reliance on automation, API-first development strategy, and their tendency toward localizing functions in a way that insulates the entirety of the application from undesirable consequences of changes.
Adaptive applications are an inescapable evolution driven by the need to scale business that increasingly relies on the ability to keep applications fast, secure, and available.