At the Unlocked session at OSCON this week, I presented how DevOps is key to help power applications on the hybrid cloud. One of the hardest things about DevOps is defining what it is; several people had differing definitions in our session. I feel that DevOps brings together a culture and work methodology for both developers and operations engineers/admins to work on a common goal.
Historically, developers have focused on new features and pursuing the next big thing, while people in operations have strived for stability of the system. You can see the inherent conflict that can arise when these two teams become one. There are several things that can be done, however, to help a transition to a DevOps organization.
Having a set deployment method can be helpful to iron out all sorts of problems before the code hits production. For example, have the code go from a Dev environment to a Staging environment for your automated tests to check it out and kick the tires before it arrives in the Production environment.
We have done this with Margarine, an open source application made to help train cloud application design, to help ensure that the shipped code is ready for prime time. However, even working on our application wasn’t without bumps in the road. Early on we discovered that our developer was writing the code on Gentoo while we were deploying it to production servers running Ubuntu. Just because those Linux distributions rhyme doesn’t mean that they work together very well. Working on a DevOps team can help you identify these issues early on.
Once the code is deployed, it is good to have exceptional monitoring in place. You want to make sure that things are online that are supposed to be online, and that if something goes offline it can be recovered quickly. Equally important is that the metrics you are monitoring on make sense. As a team, you should understand what you want to monitor above and beyond just measuring the old standards of CPU, RAM and disk I/O. Not monitoring your app means that it is a black box and you don’t have any idea what is going on underneath the covers.
When you are performing development and operations tasks together, you want as little manual work done as possible. In fact, if you can eliminate the manual work it is even better. Having automation in place means that if something goes down it can be replaced rapidly in a systematic way. You can also set up alerts to automatically go off if part of the code breaks. Automation is what makes the world go around and applies to not only testing and deploying code, but also setting up and maintaining infrastructure.
The most important discussion is about the set of tools that you will use together as a team. One of the first things you should discuss is the code repository, or where you will keep the code that controls both your application and infrastructure. Options like GitHub, Bitbucket or Subversion can help you with the version control of your code. You will also want to consider a tool for code review; Gerrit is what OpenStack uses for code review.
When it comes to continuous integration, Jenkins is a Java based software that can perform tasks on a schedule or event. Not only can Jenkins build, test and deploy software based on an event, it can also link tasks together to make a build pipeline.
Another thing that your team should discuss is which infrastructure management tool to use to deploy and destroy servers. Chef, Salt Stack and Puppet are all popular options that do essentially the same thing: treat the infrastructure as code. Now this can be a little daunting for operations folks like myself, because now that infrastructure is essentially code, we will encounter the problems that developers have grappled with forever: what version of code is running in production, how to quickly fix bugs and how to test while deploying software.
To solve these problems, operations people have to adopt the best practices that developers are quite familiar with. First, we have to tag and branch our code. Second, we need to have different phases during our application life cycle, such as Dev and Staging, to help squash those bugs before going to Production. Finally, we need to continuously test our environment, measuring to ensure that it is performing the way we would expect it to perform. This represents new ground for the average Systems Administrator.
My team has found that having a deployment strategy, measuring the application, placing automation in the application and working with a common set of tools has enabled us to blend together in a DevOps team.
What have you found helpful while transitioning to a DevOps team structure? Be sure to let me know in the comments below.
Want to learn more about the hybrid cloud? Stop by our booth (No. 507 ) in the middle of the OSCON exhibit hall and ask us any questions you may have. While you’re there, play our Unlock the Cloud Game to get a t-shirt. You’ll also have a chance to win a Game of Thrones Sigil pint glass set and to be entered to win the grand prize, a Game of Thrones Stark Infantry Shield.