What is DevOps and Why Is It Important?
I’m sure there are hundreds of posts out there trying to define DevOps. Here are my two cents:
If you subscribe to the lean software development way of thinking, you think about a pipeline of value that results in working software. For example this might be:
Analysis -> Dev -> Test -> Deploy -> Monitor
As with any pipeline, there is likely a bottleneck somewhere that restricts the flow of value. Lean is all about identifying and attacking these bottlenecks. Ten years ago—before Agile—the bottleneck was probably Analysis, or maybe Test. With Agile development becoming mainstream over the last decade, it has done a pretty good job of attacking those bottlenecks, resulting in analysis and test becoming more just-in-time, spread out over the course of a project, and embedded in the regular dev workflows. They are no longer the bottleneck.
A New Bottleneck Has Risen
This occurs at the boundary of the dev/test team and the operations team. These teams tend to be very separate with a clear hand-off between them, resulting in friction and a bottleneck in the flow of value.
Here are a few common ways this bottleneck manifests itself:
Creating environments for dev/test/uat/prod, and managing or making changes to those environments.
Deployment to Production
Still often done by writing word documents with deployment instructions, scheduling a time for Operations team to do the deployment, then delivering the document and deployment packages to Operations.
Production Support / Monitoring
Is the application available, are there errors, what is the load on the servers.
My Definition of DevOps
“DevOps is recognizing that a bottleneck exists between Development and Operations, and doing something to address it.”
How to Address It
When I hear people talk about DevOps, I often hear 3 common approaches:
Closer collaboration between the Dev & Ops team.
Perhaps having an Ops team member actively involved with the dev team throughout the project.
Increased Dev Team responsibility.
Writing automation scripts to provision / manage environments, deployment automation scripts, etc.
New role: DevOps Engineer.
Introducing a new role specifically to sit between dev and ops to facilitate the automation and collaboration.
Although #2 is the approach I see most often, I believe all 3 approaches are perfectly valid ways to attack the problem.
Was this article helpful?
Let us know in the comments and feel free to share this with your network!
If you want help adopting DevOps practices or technologies, Imaginet is always happy to help. Check out our DevOps offerings.