Peace in Our Time: Bringing Ops and DevTogether
Frustrated by long delays getting new code into production? Worried that developers are adopting unapproved technologies? In an increasingly automated, containerized world it’s time to adapt your processes and policies so that developers can utilize the latest and most appropriate technology ― and operations have full awareness of everything running in their environment.The Problem and How to Solve It
IT processes, driven by business reliance on Mode 1 applications, have not been designed nor are equipped to handle rapid change. This creates friction between management and operations on one side, and developers on the other. For example, when developer teams want to employ new or different tools than the standards accepted by operations it often creates friction. It doesn’t have to be this way, though.
In this post, we are going to take a deeper look at the collaboration that happens between development and operations when building and working with the “latest and greatest” technology stack.
As developers and operations become more and more familiar with the collaboration inherent to building and deploying containerized applications, we can speed up adoption of new tools.Getting the Balance Right
Instead of developers taking on the burden of new tooling, they can pass requirements to operations and get the tools they need to build apps on top of baked into base images. The ability to move swiftly in adopting new tools can become a point of strategic differentiation.
Updating both “legacy” and “modern” (most often called Mode 1 and Mode 2 ) applications to make use of a new (and ever evolving) cloud native software stack can be a little bit of a challenge. The new world of cloud native/containerized applications requires developers and operations to have an understanding for how to keep the base container images up to date by implementing a standard operating environment , and how to update the container platform itself . If new images are published by their vendors , and by the way: not all vendors publish such detailed information about their new releases.
Looking at the diverse and agile behavior/organizational structure of the future, containerized IT, the implementation of clear interfaces between developers and operations will get a stronger focus.
By leveraging each team’s strengths, our customers get a broader and higher quality tool chain. The development team gets rid of monitoring upstream projects for new versions, or at least can move into a position where they notify their Ops team that a new version is available. The operations team knows exactly what software is being run in their containers on the production container platform, ensuring high operational quality.Nomenclature
Throughout this article I will refer to Red Hat’s distribution of the Kubernetes container platform as OpenShift Enterprise Container Platform . In addition, to familiarize yourself with other (potentially foreign) nomenclature I suggest reading through this post on container terminology .
Finally, for this article I assume that we are looking at a private cloud, running (mostly) workloads and applications developed “in house.” When developers release new versions of their software (a.k.a. “…it’s just a small bug fix!”) OpenShift’s BuildConfig is responsible for compiling the source and assembling all the artifacts to compose a new container image and push it into the registry.Defining the Roles
Let’s have a look at the core user story we are exploring:
As an Application Developer, I want to use a Source-to-Image builder that carries a newer version of NodeJS than that Source-to-Image builder provided by Red Hat, so that I can use the latest and greatest NodeJS.
Let’s agree, that our developers should not and will not roll and maintain their own builder images, which they probably did in the past. It’s neither efficient nor conducive to a standard environment to have developers and admins doing the same work.
So here is one promise Ops will give: Ops will always provide an up to date builder. The SLA for this will vary from company to company, but the important thing is that Ops commits to keeping builders up to date. That is the promise that will make Ops cool (again, like back in the 80s when ops people wrote their own hardware driver, but I digress)!
Dev will promise not to roll their own (maybe a little guided by their management). That is the promise that will make Dev cool. Both promises constitute the DevOps contract, but that’s a whole different story to tell.
More importantly, this agreement draws a clear line between Dev and Ops and separates an application’s software stack in a set of layers, whereas each layer is owned by a different party.Stack Layers and Owners
In general operation, maintenance, and support of the whole application software stack has been separated into different layers (shown below). This is true for Mode 1 applications, but also still true for Mode 2 applications.
In a Mode 1 universe operation, maintenance, and support maps directly to ‘virtual machine provisioning’ or ‘release a new version of a package content view.’ For each layer a separate role may be responsible.
Figure 1: Application Stack and Content Layer Environment Layer
Built on top the Application Definition Layer this layer includes settings for examples secrets required within different environments (for example the CI environment or production).Application Definition Layer
This will define the relations between content of the application (eg. databases, infrastructure components, datasets for CI tests) and the Content Layer.Content Layer Within the Content Layer the whole software stack constituting the application’s logic lives. This means different versions of components of the standard operating environment, like different versions of RHEL RPMs, versions of OpenShift Container Platform RPMs and container ima
本文标题：Peace in Our Time: Bringing Ops and DevTogether