The growing interest in DevOps shines a spotlight on how organisations are approaching automation. This matters because automation tooling represents a significant investment decision. When not done well, automation efforts can potentially result in the accumulation of considerable technical debt. Moreover, tooling that is complex to operate may be inaccessible to many of participants in the software delivery process. This can further alienate rather than unite Developers and Operators and QA Engineers. Not exactly the DevOps outcome we were seeking.
A source of such risk may be the recourse by automation engineers to familiar “infrastructure as code” techniques to implement application automation requirements. Alternatively, automation calibrated to a container aware level of abstraction may make possible a more application centric and inclusive solution for DevOps automation.
OpenShift as a _platform as a service_ presents a range of entry points empowering users to engage at a level appropriate to their skills and needs. This makes possible an exciting range of features for DevOps enablement and automation including container-aware primitives to realise powerful Cloud deployment patterns. We can label this approach Containers as code.
Design decisions are a matter of balancing competing tensions across available choices. Which point in the infrastructure as code to containers as code spectrum is right for you is a ultimately matter of context. But with this book we, hopefully, can help you to begin to consider where should infrastructure automation end and application automation begin. Let’s start by considering that context.
The Complex Adaptive Organisation
For many of our established clients, disruptive new entrants are prompting a renewed sense of urgency for both introspection and extrospection. To survive and continue to thrive, these large complex enterprises are aspiring to become more adaptive. Innovation and a positive learning mind-set are key elements in reaching this future state. Change is never easy journey, fortunately, DevOps principles and practices provide useful way-markers to navigate this transformative journey.
Where the Innovation Magic Happens
We aspire here for an innovation process that is inclusive and accessible to all. The seed of the next great product could have diverse origins. It may well result from within the Chief Technology Office researching far ranging Industry trends. But it could just as emerge from a moment of insight by a Client Service Representative tapping into a simple, actionable customer need. The innovation magic happens when diverse, cross-skilled participants are empowered to engage and then effectively collaborate to a shared goal. That is how you reap the talent dividend.
Dev and Ops
The constituencies of Developers and Operators draw our particular attention, positioned as they are at the edges of the software delivery innovation pipeline – where requirements are defined and where value is delivered. We look to foster an environment which embraces diversity in skills and expertise of all developers and all operators, whether they be a UX designer, integration specialist, Linux syadmin or database admin. Uniting these factions as _DevOps_ need not necessarily imply that Developers become expert at Operations or vice-a-versa, but that an empathy exist whereby each has an appreciation for the other’s sensibility. Get this right and you have the makings of a workable feedback loop between product inception and consumption.
The Last Mile Problem
Innovation is creativity at commercial scale. DevOps helps to bridge the juncture that often exists between creation and commercialisation. This is the one of the hard problems in software – the last mile problem of value delivery. Indeed, for some, DevOps as concerned with _value-delivery_ offers a simple operational definition. For our complex adaptive organisation that means quality production code that can be quickly respond to changing client circumstances. But as we lay down our innovation pipeline, we need to address a flow-control challenge. A rapid deployment cadence requires commensurate investments in continuous integration (CI), continuous delivery (CD), continuous security (CS) and related software practices.
The ABCs of Better Software
One interpretation of the DevOps proposition is that certain behaviours (B) such as experimentation, teamwork and feedback are reinforced by value-delivery relevant consequences (C) such as increased velocity, improved quality and reduced waste. It remains, then, to create the conditions – antecedents (A) – by which such desirable behaviours are encouraged. Antecedents, behaviours, consequences – B. F. Skinner’s operant conditioning reborn as the ABCs for better software, done faster and at lower cost.
The Siren’s Song of Automation
Automation for CI/CD/CS is an example of a technology centric intervention that impacts working conditions – its concrete and actionable. It can nudge the actors within the system towards positive choices – to change behaviour change the environment. But as we flagged earlier, potential perils await. Automation software that is complex to operate can create entry barriers into the innovation process. Tooling express using infrastructure as code (I-as-C) is difficult to port and so risks the accumulation of technical debt. This is can be a siren’s song of automation.
Containers as Code
An abstraction layer instrumented at the container level can mitigate some of these risks. Containers as Code (C-as-C) suggests automation tooling that operates with native container/orchestration primitives. This shields you from provider specific I-as-C tied a specific Cloud service provider. In this way, the automation will be reusable should you choose to shift workloads amongst Public Cloud, on-premise, off-premise or hybrid targets. The portability benefit extends to skills transferability as learned automation process competencies become applicable across different hosting models.
A DevOps Esperanto
The container image format enables agreement on a standardised software work product that is language polyglot. Container orchestration, concerned as it is with deployment and workload life cycle management, sets a consistency for quality of service. C-as-C combines both to encourage a vernacular shareable amongst the different specialisations that team for software delivery – development, quality assurance and operations functions. Operational application workload matters such as telemetry, logging, instrumentation, image provenance and elastic scalability can be managed uniformly. Similarly, expertise to implement development concerns such as CI/CS/CD, pipelines and automated builds becomes reproducible.
Accessibility and Inclusiveness
To circle back, we are looking at a role for technology to help release the innovation genie. A virtuous feedback loop where desirable behaviours are reinforced – teaming, feedback, experimentation results in even better software, done faster with less waste. We described a place for automation as a technology intervention fixed on a foundation of standards consisting of a container format and its orchestration. With this we can expose a set of infrastructure agnostic primitives useful to all constituents in the software delivery lifecycle – C-as-C. The final rung on the standard/automation ladder is autonomy or self-service. We desire tooling is accessible and inclusive so all are empowered to contribute, from the 10x software engineer to the Citizen Developer.
Platform as a Service
Building your own C-as-C automation layer is a significant and recurring product management burden. Instead, the OpenShift project curates the many fast moving open source projects in the container management space for you into a coherent platform as a service (PaaS) offering. It implements a container model (Docker) and orchestration strategy (Kubernetes) with the necessary complementary infrastructure services, e.g. registry. OpenShift provides DevOps productivity and operational features that make it easy and safe to build, deploy and manage container based applications. Graphical and command line tooling make powerful C-as-C automation strategies possible including CI/CD, configurable pipelines and Cloud deployments patterns. Accessibility fits the user, source-to-image builders for those not interested in Docker details through to direct edit of configuration files for those so inclined. The user experience is autonomous as containers are launched instantly on-demand. Bureaucratic provisioning friction can be removed as workloads are securely multi-tenanted on existing compute resources.
Application Centric Infrastructure
C-as-C sets forth a case for automation tooling strategy that is application centric rather than infrastructure specific. In this scenario, I-as-C is applied to prosecute the “heavy lifting” needed to provision PaaS system infrastructure. But once established, C-as-C interfaces enables the application concerns to dominate. Infrastructure becomes the servant and application the master, a utility to service application needs in an on-demand, accessible cloud agnostic manner. This is a positive development as its situates the locus of control closer to the application and thereby closer to the customer.