It seems like the biggest buzzword now in IT is DevOps. I personally will be attending the DevOps Enterprise Summit in Vegas this year, and the event grows every year. They had to change the venue because San Francisco can no longer accommodate the growing event which sells out every year.
The idea of DevOps is to focus on the three ways of DevOps:
- Pushing from left to right - Getting our apps out to production. In this post, I'll focus on the first way of DevOps.
- Establishing a feedback loop - How are our apps doing in production? Are we getting feedback from our users and our application architect on how they're doing?
- Providing that consistent feedback from our apps and easily pushing from left to right in order to support constant innovation from our product teams.
If you read the Phoenix Project, then much of what I'm writing isn't going to sound new, but I'm writing from experience. My experience comes from manufacturing. Back in the late 80s, and early 90s, I worked on the production floor in a corrugated box plant. We received raw materials in (paper, and starch), and the final product was bundled boxes on a pallet shipped out the door.
So what does a box plant have to do with developing applications? We'll primarily focus on the value stream. In a box plant, it's about making corrugated board from three layers of paper and starch, and sending it to a printer/flexo or die-cutter printer to create the final product and send it out the door.
Most of the manufacturing process is automated flow using conveyors (another big thing in the 80s was building out automation, think lean manufacturing), by using automation we could increase the flow of production from the corrugator out to the shipping docks. This focused on reducing the bottle neck of manually taking dollys or trucks to the machines, the focus was sending paper directly to the printing press, even more automation was put in place to reduce the manual labor of placing corrugate by hand into the machine, and having to manually load the bundles on the pallet. All this was focused on reducing the bottleneck, remember, product can only go as fast as the constraint will allow it to. If the paper isn't feed into the machine fast enough, or paper isn't there for the machine to load, or on the back end if the palletizer can't stack the bundles fast enough, eventually the production line will stall and you can end up with a mess that can cause hours of downtime. On the production line, downtime is money lost.
At the point where you have that bottleneck in the production line, all focus then needs to shift to the point where the bottleneck is occurring, if not you end up with a mess of backed up product, mistakes, and stress on employees. So the company needs to focus on clearing out the bottleneck so product can move through the value stream.
Sound familiar? This is what the DevOps folks mean when they say "subordinate to the constraint." This is part of what DevOps is about, moving software from left to right. It's pretty obvious when we're using the manufacturing line as an example and can actually see the line being backed up by physical product, but in the software development world it's not always as obvious.
In the DevOps world, it may not be bundles of boxes being jammed on the conveyor that's creating the bottleneck, rather it may be things not as noticeable. That's when you have to really evaluate your current process and find out what items are blocking the development stream. If you're agile and using kanban or scrum, you can see items that are blocking, over time you can perceive which items appear to block more often. A few things I can think of:
- Do you have a CI/CD pipeline? Are deployments automated, is testing automated, how about security policies, and deployments to environments?
- Are your environments auto provisioned using some kind of cloud provisioning either on-prem or off-prem. Are you still entering in tickets to build out VMs that can take a few days to build out environments to support development?
- How about your people? Are they up to task on skills, should you be doing paring with more senior people? Remember, people don't want to be the blocker, but provide the skills they need so they're not.
You need to constantly evaluate your value stream and find those bottlenecks, focus on it, and eliminate, then go to the next one. Prior to automation, it will be difficult to identify the constraints without some solid data to back your perception up, but many times what we perceive at this early stage in the game will provide some big returns. It can become more difficult as we move through our DevOps journey. For example, by implementing an automated CI/CD pipeline you can see drastic increases in the amount of deployments, as well as huge reductions in the deployment times. What may have happened on a quarterly basis may now occur daily. Early on your automated deployments will rise exponentially as teams implement automation, but later on you will see a leveling out of the deployments. Don't worry though, we can borrow from Total Quality Management (TQM) concepts from back in the manufacturing days to refine our process by looking at our feedback (the second way). I'll write more about this at some later time.
I won't focus on which technology solutions to put in place as there are many. From Jenkins, to Team City, to Ansible, Chef, Puppet, Octopus, and so many players in the game to numerous to list. You'll need to do the research and figure out what's going to work for your organization.
When you start going from quarterly deployments to daily, you'll need to think about the second way, and that's getting the right feedback from your deployment pipeline. That sounds like a topic for another article. Have fun DevOps'ing.
Random thought - Since I've started working in manufacturing back in the late 80s, that gives me around 30 years experience in DevOps then. :)