TAG | DevOps
DevOps is gaining traction according to a study at the end of 2012 by Puppet Labs. Their study concluded that DevOps adoption within companies grew by 26% year over year. DevOps is still misunderstood and has tremendous room for greater adoption still but let’s be clear about one very important thing: DevOps is not a replacement for operations!
If you’re not as well versed in the term DevOps as you want to be I suggest you read my “DevOps Scares Me” series.
Worst Developer on the Planet
The real question in my mind is where do you draw the line between dev and ops. Before you get upset and start yelling that dev and ops should collaborate and not have lines between them let me explain. If developers are to take on more aspects of operations, and operations personnel are to work more closely with developers, what are the duties that can be shared and what are the duties that must be held separate?
To illustrate this point I’ll use myself as an example. I am a battle hardened operations guy. I know how get servers racked, stacked, cabled, loaded, partitioned, secured, tuned, monitored, etc… What I don’t know how to do is write code. Simply put, I’m probably the worst developer on the planet. I would never trust myself to write code in any language to run a business. Now in this particular case it comes down to the fact that I simply don’t currently posses the proper skills to be a developer but that’s exactly my point. In order for DevOps to succeed there needs to be a clear delineation of duties where expertise can be developed and applied.
Operations is a mix of implementing standard processes, planning for the future, and sometimes working feverishly to try and solve problems that are impacting the business. Just like writing good code, providing good operational support takes experience. There are many areas where you need to develop expertise and you shouldn’t just start doing operations stuff unless you have some experience and a peer review of your work plan.
You do have a work plan don’t you? A work plan could be something as formal as a change control (ITIL would be good to read about) or something as informal as a set of steps written on a bar napkin (hopefully not, but it’s possible). The point is that you need a plan and you need someone to review your plan to see if it makes sense. Here are some of the things you need to consider when creating your plan:
- Implementation process – What are you going to actually do?
- Test plan – How will you be able to tell if everything is working properly after you implement your change?
- Backout process – How do you revert back if things don’t go right?
- Impacted application – What application are you actually working on?
- Dependent application(s) – What applications are dependent upon the application you are changing?
The point I’m trying to make here is that DevOps does not change the fact that well defined operations processes and practices are what keep companies IT departments working smoothly. Adopting DevOps doesn’t mean that you can revert back to the days of the wild west and just run around making changes however you see fit. If you are going to adopt DevOps as a philosophy within your organization you need to blend the best of what each practice has to offer and figure out how to combine the practices in a manner that best meets your organizations requirements and goals.
Bad operations decisions can cost companies a lot of money and significant reputation damage in a short period of time. Bad code written by inexperienced developers can have the same effect but can be detected before causing impact. Did someone just release new code for your application to production without testing it properly? Find the application problems and bad code before they find you by trying AppDynamics for free today.Link to this post:
Today the AppDynamics team made our way to Raleigh, North Carolina for All Things Open. If you aren’t familiar with All Things Open dedicated to open source in the enterprise. It was a great event and a chance to interact with some of the brightest people in technology. AppDynamics was in full force at All Things Open:
DevOps has proven itself across many smaller organizations but large enterprises are usually slow to change. It can be a daunting task even identifying where to make changes since there are so many processes and organizational silos to get in the way. As a veteran employee of small, medium, and large enterprises I have figured out ways to drive organizational change based upon getting results. In this presentation I will describe my methods for creating change within and across organizations and provide specific examples of how to begin a meaningful shift towards making DevOps a standard practice within your organization. I’ll detail some of the roadblocks to making DevOps a reality and explain how to overcome these obstacles.Link to this post:
Taken from DevOpsDownUnder in Sydney, Australia, July 2013.
DevOps, when done right, usually goes unnoticed. It’s only when something breaks that all eyes turn to IT. If your boss only sees you when the app is down, however, that’s not really doing your career any favors. In this session we’ll talk about how to prove your value to the organization by looking at the positive side – that is, how much money you’ve saved your company. We’ll take a look at how you can use tools like Chef, Puppet, Sensu and Logstash to quantify your value to your company. After this session, you’ll be able to walk into a meeting with your boss ready to talk about your value to the company (and to ask for a raise)
Taken from DevOpsDays in Barcelona, Spain, October 2013.Link to this post: