So your development team wants to start using DevOps, but the ops team has dug in its heels, the infrastructure team is throwing up roadblocks left and right, and management is oblivious to the whole disagreement?
Sounds about right.
Most organizations are DevOps-resistant by nature. Even if they say they value innovation, nine times out of 10 they'd prefer to stick with the manual, inefficient status quo.
So the cycle begins. Your team needs DevOps to be faster and stronger, but you've got zero buy-in. You aren't doing DevOps in any meaningful sense, and the longer you go without it, the more product quality slips, along with your chances of winning support.
Whether you're fighting apathy or ignorance, often the only way to change the situation is to get scrappy.
Here are five guerrilla strategies for achieving small DevOps wins to showcase what's possible, make your life better in the process—and maybe even start a revolution.
Your investment usually starts with your time. Figure out which pieces of DevOps are going to give you the best return and focus on those first. Continuous integration, automated testing, static analysis, monitoring, and notification usually give you the biggest bang for your nights-and-weekends buck.
Specifics will differ depending on whether you're running on premises or in the cloud, but you'll need some CPU cycles one way or another. If you’re going to go on-prem, old hardware is your best bet. Most infrastructure shops have boxes of RAM and floor-to-ceiling stacks of old laptops.
When you make your request, be sure to tell them you expect zero support from them for the old hardware. Swap RAM, and upgrade the HDD to SSD, or stack HDDs in a RAID configuration. Mac Minis and iMacs are also great machines to leverage, since they're easy to upgrade and can run the latest version of OS X headless.
If you're going to get your compute from the cloud, there's a smaller barrier to entry, but there's more risk if you don’t set things up correctly. Ask for approval for a $50 spend per month to do a proof of concept.
Follow that up with a demo of what you've built. You need to prove you know what you're doing. Don't go dumping company secrets into the cloud or expose your code to the world.
If you're running on last-gen laptops sitting under your desk, apply DevOps to your DevOps and put everything into source control. You should be able to throw away the laptop and provision a new one without batting an eye. Consider everything a source.
Sometimes a little bit of personal spend goes a long way. Want to learn how to set up a cluster for Kafka or Kubernetes? You can do that with a few Raspberry Pis. Want to add some automated text messages that ping you if something goes down? Sign up for Twilio.
If it's my own dime, I like to limit the exposure with a prepaid gift card or set limits on the spend. If you turn the throttle way down on many hosted services, you can get them for a few pennies a day. I spent 51 cents last month on Kafka.
Yes, it's spending your own money on work, but it's worth it on a variety of levels: You'll strengthen the team, enhance your skill set, and make yourself more employable if you need to jump ship. Remember that you're the only person who can improve your career.
Once you've established your skunkworks DevOps, socialize your progress. Show groups that were resistant that their work lives can be better, too. Once you've made the investment, invite others to use what you've built and contribute themselves.
What can you expect from your guerrilla efforts? Best-case scenario: The larger organization picks up DevOps, and you'll be forever immortalized as a hero. Zero-sum scenario: The status quo sticks, but you're still doing cool stuff.
Worst-case scenario: The organization freaks out and makes you tear it all down. If that happens, you've just made yourself a hot commodity (is the worst-case scenario really so bad?). Polish up your résumé with your new skills and start interviewing.
Nate Berent-Spillson is a technology principal at Nexient. His specialties include enterprise architecture, regulatory compliance, and Agile development across a wide variety of technologies. He frequently writes and speaks about Agile and DevOps.