DevOps is a new buzzword in computing circles. It encompasses many common sense ideas about the integration between business and technology and provides the narrative to bring development, delivery and operations together.
DevOps is the practice of operations and development engineers participating together through the entire service lifecycle, from the design and development process all the way to production support. It replaces the traditional silo setup where you have a team that writes the code, another team to test it, yet another team to deploy it, and even another team yet to operate it.
It is characterized by operations staff making use of many of the same techniques as developers for their systems work. In DevOps, system engineering works like a development workflow. All the assets are checked into source control and have tests associated with them.
We have several core DevOps themes: values, principles, methods, practices, and tools.
Values
Engineers are solution centric by nature, and that can often turn into negativity about new technologies or avoiding attempts to try new things, from “Not Invented Here” Syndrome, to disruptive attempts at niche protection. To truly embrace DevOps thinking is to acknowledge and overcome these temptations. No technology, not even Docker, Kubernetes or Amazon Web Services, will solve your problems if the value proposition is not understood.
“people holding hands” by rawpixel on Unsplash
Principles
The Verifa set of principles is based on The Three Ways. This model was developed by Gene Kim, author of “Visible Ops” and “The Phoenix Project,” and Mike Orzen, author of “Lean IT.” We encourage building an environment that encourages systems thinking, amplifying feedback loops, and a culture of continuous experimentation and learning.
Always keep thinking about the whole system. Ask yourself, How can I build in more feedback loops? Monitoring, metrics, and logging are three feedback loops that bring operations back into design. The successful DevOps environment will encourage processes that can create short, effective feedback loops, such as incident control system, blameless post-analysis, and transparency…
“ two person handshaking in front of MacBook Pro” by rawpixel on Unsplash
Methods
Lean Management
Lean = simple. Break your project into small batches of work, build in progress limits, feedback loops and visualization. This is my favourite element to bring to a project; lean management practices lead to better organizational outputs, including system throughput and stability and less stress and greater personal satisfaction.
People over Process over Tools
One of the first methodologies coined by DevOps pioneers is called people over process over tools. Within Verifa we recommend identifying who’s responsible for a job function first… Then defining the process that needs to happen around them… Then selecting and implementing the toolchain to perform that process. It’s common sense on paper but engineers and managers, often driven by a flashy sales pitch from tool vendors, are tempted to do the reverse and buy a tool and go back up the chain from there.
Continuous Delivery
This is a term heard so often that people even wrongly equate it with DevOps. In short, it’s the practice of coding, testing, and releasing software frequently, in really small batches so that you can improve the overall quality and velocity. This is the key element to get in place early on in your project and is the driver to successful DevOps implementation.
Change Control
In my experience, there is a direct correlation between operational success and control over changes. This doesn’t mean you need a traditional control process which slows you down and can do more harm than good. The requirement here is a scalable, resilient continuous delivery platform. Focus on eliminating fragile artefacts, creating a repeatable build process, managing dependencies and creating an environment of continual improvement.
“Matrix movie still” by Markus Spiske on Unsplash
Infrastructure as Code(Configuration as Code… Everything as Code)
One of the revelations I’ve had from working with Verifa is that systems can and should be treated as code. System specifications are checked into source control and go through code reviews. Using modern deployment technologies such as Docker and Kubernetes it is possible to automatically build, test, and create real systems from the spec and manage them programmatically. With this kind of approach, we can compile and run systems, instead of creating labour intensive permanent fixtures that are difficult to evolve over time.
Practices
All IT organizations I have worked with have approached projects with the philosophy of, let’s make something… then put someone else in charge of testing and deploying it. This doesn’t usually work to plan. Timescales slip and once the development team moves to the next project it becomes impossible to solve operational issues.
“roller coaster under white clouds and blue sky” by Priscilla Du Preez on Unsplash
What we advocate at Verifa is to keep developers in the loop for the service they created and take ownership of the Ops. This creates more efficient feedback cycles, allowing development teams to respond much faster not just to bugs, but also to new features and ensure the right product is being developed.
Tools
At Verifa we love tools! They enable engineers to code, build, test, package, release, configure, and monitor both systems and applications. We are tool experts and have seen the full spectrum of what the open source community and commercial vendors have to offer. Before the rise of DevOps, innovation and tooling had stagnated. I had been using the same toolset as I did when I started as a developer back in 2000. Many DevOps enabled tools are impressive in terms of the capabilities they bring to the service life cycle.
“assorted handheld tools in tool rack” by Barn Images on Unsplash
It is necessary to define a robust DevOps toolchain. There’s not a single tool that will do everything, you will need a series of tools that can be composed into a toolchain to address your needs. And you want them all to work together… a tool is only useful to the degree that it supports your entire system.
You need to select tools which fit well with others in the toolchain. It should be able to perform its work in an automated manner. You should be able to call it and invoke it from an API, or the command line. Generally, UI driven tools are a poor choice and don’t sit well in an integrated toolchain; you want the tool to be verifiable.
And Next…
Pull down a docker image and begin experimenting. Fork someone else’s code and just start building on it. Spin up a server or cluster of servers using Kubernetes. You’re doing DevOps. Start on your own computer, and then in the cloud.
“boy standing on ladder reaching for the clouds” by Samuel Zeller on Unsplash
When people first hear about infrastructure as code or continuous delivery, the first response is always, that’s not how we do things here. To succeed with DevOps you have to start somewhere with these techniques, they’re not difficult. For many years, the advice that has been given to the industry has been completely opposite to what DevOps pioneers have found to work.
