If you're in technology, chances are you don't go too many days without hearing something about DevOps. Maybe your organization is thinking about transitioning from a traditional operations model to a DevOps model. In this series of blog posts, I plan to delve into DevOps to help you determine if it's right for your organization and illustrate how to start down the path of migrating to a DevOps model. Because DevOps means different things to different people, let's start by defining exactly what it is.
- It's supposed to be the best combination of both dev and ops working in really tight coordination
- Automation of basic tasks so that operations can focus on other things
- It's glorified script, in other words, developers trying to understand network and storage concepts
- It's the ability to get development or developers and operations to coexist in a single area with the same workflow and workloads
- It's something for developers, but as far as what they actually do, I have no clue
A lot of these responses hit on some of the big definitions we discussed earlier, but none of them really sums up the many facets of DevOps. That’s okay. With the breadth of what DevOps encompasses, it makes sense for organizations to pick and choose the things that make the most sense for what they want to accomplish. The key part, regardless of what you are doing with DevOps, is the tight integration between development and software operations. Whether you’re looking to automate infrastructure configurations or support custom-written, inventory-tracking software, the message is the same. Make sure that your development and operations teams are closely integrated so that the tool does what it needs to do and can be quickly updated or fixed when something new is encountered.