Every company should understand the development and operations (DevOps) movement. Even if your startup isn’t building software, software is still relevant to your business. All companies are therefore software companies. Below are some of the lessons shared at the DevOps session during Denver Startup Week.
So let’s start with the basics. What’s the definition of DevOps?
In essence, DevOps is a word used to describe an optimization process that gets your applications from developers into production (operation) as efficiently as possible. It’s a cross-disciplinary approach that blends development and operations to take the best of both and integrate these disciplines (dev and ops) into the mindset of your team.
As such, there are two necessary components of DevOps – cultural and technical. And, they reinforce one another – you need automation tools to be able to implement DevOps (technical), and you also need to embrace the right mindset and be open-minded (cultural).
- Culture. For DevOps to work properly, your ops team and dev teams must be in constant communication with each other – better yet sitting together and working together hand in hand on every problem. Go out for beers with each other, and establish rapport to build trust. This will help build a working relationship that is focused on solving problems, reducing friction and avoiding the blame-game when problems arise.
- Technical. From a technical perspective, successful DevOps teams can benefit from collaboration tools like Fog and Chef – orchestration tools to enable those two teams to work together and speak the same language. There are also ticketing tools like JIRA (which our team uses), that both dev and ops team members can use to collaborate on defects and enhancements.
The reason why both culture and technical systems are important is that together they enable both groups to have “skin in the game” when it comes to the various phases of product development. If dev has no skin in the game during the post-launch stage (where ops typically has to be on call) – then you can’t do DevOps effectively. Part of the cultural challenge is making development care about operations blowing up, and vice a versa.
After culture and technical tools, the next piece of the puzzle for successful DevOps is deployments. There are many theories on deployment – continuous integration, continuous deployment, a hybrid methodology, etc. It all depends on the application you’re building or supporting. But, the bottom line is that DevOps is about solving business problems and creating a great experience for your customers. And for a better customer experience, we need to closely involve the ops teams in the product development process (scrum, testing, customer demos, etc.), and vice versa, to help developers understand the ops mindset. This forces the often separate groups to come together and have the same amount of skin in the game. As a result, dev and ops feel more involved in the process and are both holistically “bought in” together.
The ultimate goal of DevOps is to roll out a process where any developer, anywhere, can manage and administer the product infrastructure and code. Implement a policy and process that encourages your ops people to code too – they can and should do more than just SSH (Secure Shell protocol) into boxes and fire things up. Cross-pollination of teams is another way to mix things up; send an ops guy to work on the dev team for a while and an ops gal to drink the dev Kool-Aid–you will be surprised at what comes out of it.
What’s next for DevOps?
One of the biggest problems going forward is the rising complexity of choice. It’s rare these days to own every element and every process within your data center. Most companies are outsourcing a larger chunk of operations (even caches are going the way of SaaS). With such a spread out architecture, it is a challenge to grow and build a framework when there are so many different interfaces (scripts, GIT push etc.) and processes. This leads to the natural next question – how do we enforce security and policy across dashboards we don’t control? Policy enforcement has very serious compliance implications.
But startups don’t care about compliance law.
When does DevOps start to matter for a startup?
Sooner than you may think. You will quickly get to a point where you have to put everything on Heroku and your bill is $15,000/month and you don’t have any customers. Then you “grow-up” and transition to AWS, then to a hybrid cloud, and ultimately you hire someone to save you money – now that’s where importance of DevOps begins to emerge.
The potential of the dilution of the idea. Another threat facing the future of DevOps is an investment in the movement without really understanding the movement. Just because you cleverly give someone a DevOps engineer title, doesn’t mean that suddenly that person knows how to do DevOps.
The expansion beyond just dev and ops. QM/QA (Quality Management/Quality Assurance) is also increasingly important in the DevOps world – quality automation and overseeing the build process to make sure its meeting QM standards is just as important as the development and the post-launch management. QA/QM will be incorporated into the DevOps movement too – and perhaps the name will settle on a steady-state called DevQops.
Now that we’ve provided you some context and a framework for what DevOps is, our next blog will explore some tips and tricks to help build a successful DevOps team and make the movement work for you. In the meantime, as always, feel free to reach out to the cooks at Baked & Branded if you want to continue this conversation. We are here to help.
And if you’re still hungry for more, check out this awesome tech talk on DevOps by Gene Kim of NewRelic.