DevOps != sneaky, reckless, or process-adverse hooligans
Operations has one primary mission above all else… uptime. This often gets them labeled by the rest of the organization by names such as, “the brick wall”, “organization of ‘no’”, and a host of other names I won’t use on a PG blog. With automation coming to IT operations teams are being asked to ensure uptime while allowing a more rapid evolution of the environment. The days of an 18 month release cycle are over. So how exactly do we accomplish this without wrecking things? Proper testing, visibility, and a scale staging environment.
Almost all application deployments are iterations and evolutions of existing applications. They also aren’t a single function system so changes to one application can impact the performance or availability of others — this is why operations has become the organization of “no”. To prevent bad things from happening first you have to understand what is happening. You need to have monitoring that can show network, operating system, platform, and application performance.
Now that we can see what is going on with production we need to create a small scale version of production used for staging. When creating this scaled down version of the environment you’ll need some understanding of how increasing size and load impact the system. If all of your algorithms are O(x) then it is easy to scale down and predict what it will do in a larger environment. This won’t be the case though — some things will be O(log(x)) where it takes more resources at a smaller scale than it will once scaled up and others will be O(#x) or even O(x^#) where as you grow they consume resources in a linear multiple or exponential manner.
So then where does DevOps come in?
It isn’t just a crazy idea by the developers to try and find a way around “no”. If implemented properly it will build a strong cooperative effort between development and operations — get rid of the “Us vs. Them” mentality. It will also eliminate duplication of effort where a development team writes unit, integration, and system tests and operations will write all different tests in their monitoring and management systems.
This divide also creates problems where new releases get delayed as operations find issues in staging because they weren’t involved with the test case development early on. With continuous integration and automated development testing many of these tools also make great operational monitoring systems as well. This can allow for the operations management team to write unified tests with development that are used throughout the process — everyone is working from the same goals — no more meetings of, “Why didn’t you catch this in development?”, “It works fine in development, you screwed up the installation.”
The next benefit you’ll get from a DevOps culture is tasks will be automated in other areas decreasing error rates and increasing delivery speed. Today developers use distributed source repositories with version control to deploy applications onto development and testing systems. Operations will then package up those applications into an installer that introduces another step in the process that has to have additional testing and new tooling. DVCS platforms have authentication and tracking built in, all of the audit controls an operations department wants.
I know I’ve glossed over the details in this post. I plan on putting together some detailed future posts covering examples of how I’ll be implementing each section using open source tools to help with work my team is doing on OpenStack.