What? DevOps? Do I really need that?
When doing an Internet search on DevOps I very quickly came across a number of definitions about how it helps me to “deliver business agility” and “business IT alignment” by “bringing Dev and Ops together.” I read that it “improves my productivity” by enhancing “communication, collaboration and integration” and in general can make me faster, better and more shiny if I would only be willing to adopt DevOps.
But what challenges are really out there that have to be addressed? I've talked to a lot of development and operations teams in small to large organizations, and not one complained about not being able to “deliver business agility.” Most of the problems they face are of a more practical nature, and they struggle with understanding, how DevOps might help them. So I've collected the top five topics I discussed with them and how DevOps will help to get rid of them.
Five challenges where DevOps can help
1. Test N-1 release
While working on the upcoming release N of an application and using up all test environments just for that, all development organizations I talked to still have to maintain release N-1. In the not very unlikely case of having to provide a fix for N-1 nearly everybody is unable to test it, because the effort to downgrade the test environments is just too high. So while I am always afraid of releasing untested (or not fully tested) fixes to production, that's normal in most cases.
If you had a deployment automation together with an artifact repository holding all N-x versions of applications and environment descriptions, it would be very easy to just deploy that version, run a test and free up the resources afterwards to be used again by the main development on release N.
2. Our apps are too complex
When I look into large enterprises I commonly see applications that have been there for more than 10 (or even 20) years, growing in complexity with every release. They come together with huge test environments and a lot of time is spent by the developers and testers to manage all the interdependencies between the app components.
That is normally not a nice situation to be in because it cuts down on flexibility. The key here is to aim for automation in the test and deployment space as well as capabilities to decouple dependencies for the early test stages. Both of these features are in the DevOps strategy for you.
3. Disparate test environments
This point is a bit of an exception to my list. Nobody will tell you straightforwardly that his test environments are all configured differently. But if I ask for a config description, it always immediately becomes apparent. Very few Dev departments apply configuration management to their test environments.
Why is that even important? Even small changes might cause something to go wrong, and those are normally the ones that haven't been tested.
By having standardized environments that can be reliably and automatically provisioned (perhaps using a cloud for that) you get not only faster but also more consistent across the test stages. And again, that touches the core principles of DevOps.
4. Our production deployment fails
“We have eight releases a year and every time we deploy a release to production it fails and takes us a week to recover.” I actually hear this quite often. Many times it is connected to problem 2. The change window on weekends is not large enough to do both deployment with verification tests and rollback in the case of failure.
If I examine the situation more closely, I quickly find out that there are different deployment mechanisms used in test and in production. The differences might be small, but it always comes out that the production deployment approach was not fully tested before and test environments use a different technology.
A standardization of deployment routines across environments and testing against production-like systems, as DevOps proposes it, would have helped in most of these cases.
5. A load test takes us two months
So here is a conversation I had with a load test professional: we were talking about how complicated a load test is for him to do and that they are run very rarely. And he explained to me why it takes him two months to run a load test suite:
That's clearly a case of very bad communication and collaboration as well as a lack of standards to exchange the required information in an easy way.
By applying a deployment and configuration automation together with a better collaboration system, he probably could have saved three quarters of the time or run four times more load tests to find out problems earlier.
So, what is in it for you?
Do you have one of the challenges described above? Then looking at a DevOps approach could certainly help you, and you should get started as soon as possible. Your challenges are not mentioned above? Well, my list is far from being complete!
If you want to add something to the above experiences or if you have different opinions, I'm more than happy to discuss your thoughts on DevOps. Just leave a comment to continue the conversation.
Technical Sales: Service Management Solution Architect, ITIL Service Manager