DevOps for Companies with No Software Developers
I was having a conversation with a long-time college buddy over lunch today. He works at a local hospital as a SAN administrator and general jack of all IT trades. This is a traditional hospital where they use hundreds of applications, yet none are built in-house. They purchase lots of off-the-shelf software, implement it, support it the best they can and call vendor support if something major breaks. They have no software developers except for the occasional web developer in charge of their website.
Many companies are in this boat. Not everyone has an army of developers cranking out code all day, doing deployments and fixing bugs. I know lots of businesses that get by just fine with purchasing software, customizing it a little to their needs and calling vendor support then they need help. Do you think these businesses could use DevOps? I think so.
I was trying to explain the value of DevOps to my friend. After explaining to him what it was and how it builds business value, he asked me a question that caught me off guard, “We have no software developers. How does this pertain to us”? It took me a minute to think about a good response, and this is how the conversation went afterward.
The answer is in how companies choose to apply DevOps and how they define developer.
DevOps is not Binary
DevOps is a broad topic with many facets. It’s not binary. A company simply can’t just be or not be a DevOps company. It’s perfectly OK (and advisable) to not eat the entire DevOps elephant. It’s fine to adopt certain patterns and practices of DevOps and use those.
Regardless if your company has software developers or not doesn’t mean you can’t adopt all of the cultural aspects that makes DevOps awesome. Remember DevOps is more than just tools! DevOps means trusting people with keys to the kingdom. It’s about mutual respect, learning from one another, transparency and having a tolerance for failure. All of these concepts can be applied in one way or another to any organization.
DevOps is also about making small, iterative changes instead of ginormous planning sessions spread out over many months or years. Even though this typically means with software, it doesn’t have to. You can apply this same concept across infrastructure as well. Begin to start doing instead of doing extensive planning. Start writing scripts to test your infrastructure, making small changes and iterating from that.
There are so many more facets of DevOps you and your team can use. Read The Phoenix Project sometime and begin to see how your company resembles Parts Unlimited. Don’t get caught up in the software development terminology. DevOps itself didn’t come from software development after all. It came from Lean, a car manufacturing methodology. Since DevOps wasn’t born from software development, there’s no reason you can’t adopt certain DevOps principles and practices to be considered a DevOps organization.
If your company has no software developers doesn’t mean you don’t have “developers”. When I say this to a traditional infrastructure team, they look at me like I have a third eye. “We are NOT developers!”, they say. “We are system administrators. We buy the software and support it. We don’t write it.” is another common theme I hear.
These system administrators have a traditional outlook on what constitutes a “developer”. To them, a developer is someone who’s sole job is to write code all day, release new features, fix bugs, compile their code and release it to others. They consider developers those that write applications in C, C++, C#, Java and the like. What they don’t realize is that scripting languages like Perl, Python, PowerShell and others can also be considered development languages as well.
A “developer” is about context. It’s not about writing code that compiles and it’s not about only being part of a big team and releases huge software applications. A system administrator can be considered a developer if you control your infrastructure with code. You are a developer if it’s commonplace for you to write a few lines of code in PowerShell or Ruby to make configuration changes to servers rather than RDPing into each server and doing it.
You are a developer if you understand and practice infrastructure as code. Don’t just think as a developer as someone that writes software. For a system administrator, a developer is someone that writes code as recipes for your infrastructure. You write the recipe; your tool delivers the recipe and when it’s done instead of baking a cake, you’ve provisioned a new environment.
DevOps is not just Software
DevOps is not just software. Realize that everyone does DevOps differently. If you can understand that DevOps is not an all or nothing decision and rethink your view of a “developer”, you’re well on your way to achieving DevOps success without a traditional software development team.