TAG | IT operations
What is DevOps?
In the first post of this series, my colleague Jim Hirschauer defined what DevOps means and how it impacts organizations. He concluded DevOps is defined as “A software development method that stresses communication, collaboration and integration between software developers and information technology professionals with the goal of automating as much as possible different operational processes.”
I like to think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way.
From developer to operations – one and the same?
As a developer I have always dabbled lightly in operations. I always wanted to focus on making my code great and let an operations team worry about setting up the production infrastructure. It used to be easy! I could just ftp my files to production, and voila! My app was live and it was time for a beer. Real applications are much more complex. As I evolved my skillset I started to do more and expand my operations knowledge.
When I was young you actually had to build a server from scratch, buy power and connectivity in a data center, and manually plug a machine into the network. After wearing the operations hat for a few years I have learned many operations tasks are mundane, manual, and often have to be done at two in the morning once something has gone wrong. DevOps is predicated on the idea that all elements of technology infrastructure can be controlled through code. With the rise of the cloud it can all be done in real-time via a web service.
When you are responsible for large distributed applications the operations complexity grows quickly.
- How do you provision virtual machines?
- How do you configure network devices and servers?
- How do you deploy applications?
- How do you collect and aggregate logs?
- How do you monitor services?
- How do you monitor network performance?
- How do you monitor application performance?
- How do you alert and remediate when there are problems?
Combining the power of developers and operations
The focus on the developer/operations collaboration enables a new approach to managing the complexity of real world operations. I believe the operations complexity breaks down into a few main categories: infrastructure automation, configuration management, deployment automation, log management, performance management, and monitoring. Below are some tools I have used to help solve these tasks.
Infrastructure automation solves the problem of having to be physically present in a data center to provision hardware and make network changes. The benefits of using cloud services is that costs scale linearly with demand and you can provision automatically as needed without having to pay for hardware up front.
- Amazon Web Services
- Windows Azure
- RackSpace Cloud
- HP Cloud
- OpenShift by RedHat
- Ubuntu Cloud
- Citrix CloudPlatform
Configuration management solves the problem of having to manually install and configure packages once the hardware is in place. The benefit of using configuration automation solutions is that servers are deployed exactly the same way every time. If you need to make a change across ten thousand servers you only need to make the change in one place.
There are other vendor-specific DevOps tools as well:
Deployment automation solves the problem of deploying an application with an automated and repeatable process.
Log management solves the problem of aggregating, storing, and analyzing all logs in one place.
Performance management is about ensuring your network and application are performing as expected and providing intelligence when you encounter problems.
Monitoring and alerting are a crucial piece to managing operations and making sure people are notified when infrastructure and related services go down.
In my next post of this series we will dive into each of these categories and explore the best tools available in the devops space. As always, please feel free to comment if you think I have missed something or if you have a request for content in an upcoming post.
I recently had the luxury of sitting on a beach for a while to unwind, de-stress, and recharge my batteries. Even though I really shouldn’t have been thinking about work, the IT performance geek inside of me is always lurking. He can’t be switched off so I allow him to enter the picture, run away with my thoughts for a while, and then lock him away until the next time he breaks out into the wild. This blog post is about one interesting observation the IT performance geek made while I was watching crabs go about their business on the beach.
On my first day of vacation I saw a bunch of holes in the beach with mounds of sand piled up outside of each hole. I thought this to be quite interesting and wondered what sort of creature was the excavating genius. After some time passed by I noticed some suspiciously crabby eyes peering out of the holes at me. If I made any moves the crabs would dart back deep into their burrows and let some time pass until they peered outside again.
Later that day the tide came in and washed away the sand piles covering up the holes that the crabs had made. I wondered what happened to them while the tide was up. Did they stay under the sand and water? Did they go somewhere else? Did they rebuild their holes every single day after the tide subsided? I needed to pay attention during the rest of my vacation to figure this out.
Tides of Change
The tides brought serious problems to the crab burrows. My inner IT performance geek immediately likened the tidal damage to the problems brought about by an onslaught of user activity to a web application. As the tide built the sand pile outside of the burrow washed away. In my head I was imagining a swell of user generated workload eroding away business critical application performance. Only after enough pounding did the sand pile completely give way and the crab burrow collapsed under the stress of the ocean.
This is how I’ve seen most IT performance problems develop as well. It’s usually not an immediate collapse (system crash), but a degradation over a period of time that leads to a failure of the application.
Where Have All the Good Crabs Gone?
How did the crabs respond to all of this? At first I didn’t know where the crabs were while their burrows were under water. After some observation I realized that some had retreated to the tropical woods at the edge of the beach and that others had found shelter on, in, and around a rock wall that ran from the beach into the water. This isn’t really relevant to my story but I thought you’d be interested in finding out. The interesting part to me is what happened when the tide subsided. As the day wore on and the tide became compliant with crab low tide regulations I noticed a massive crab undertaking. Most of the crabs returned at nearly the same time and started re-digging their burrows.
I was amazed at how much sand these little crustaceans could move with a single scoop of their crabby claws. These crabs knew exactly how to fix the problem that the tide had burdened them with and within 30 minutes their burrows were completely restored.
Crabs and IT Operations
This entire process reminded me of my days in IT operations when an alert would fire, we would figure out what the problem was, and soon after problem isolation we would have service restored. That is all fine and good but here is the big problem. The crabs did the same thing every single day of my vacation. They built a burrow, the tide washed it away, and they rebuilt their burrow when the tide subsided. Day after day after day forever.
Many of us did the same thing in IT operations. After the problem was fixed and service restored we congratulated each other and enjoyed our burrows instead of taking the extra time to figure out automated detection and remediation strategies for problems we had seen before. As IT practitioners we usually have more on our plates than we can possibly handle. We live in an age of “do more with less”. The problem is that if we don’t take the extra time to automate our detection and remediation of application issues we will endlessly repeat the cycle of the crabs.
Crabs can’t use complex tools, but thankfully we can. AppDynamics application runbook automation is the cure for the crab cycle. It detects problems and remediates them automatically (you choose if you want to authorize the action or not). We’ve written a couple of other posts that describe the functionality in detail, so please read through them and get familiar with this amazing set of features…
If you’re tired of the crab cycle do yourself a favor and fix it for good. Click here to get started with your free trial of AppDynamics Pro and see how powerful, easy to use software can make your life better today.Link to this post:
DevOps is scary stuff for us pure Ops folks that thought they left coding behind a long, long time ago. Most of us Ops people can hack out some basic (or maybe even advanced) shell scripts in Perl, ksh, bash, csh, etc… But the term DevOps alone makes me cringe and think I might really need to know how to write code for real (which I don’t enjoy, that’s why I’m an ops guy in the first place).
So here’s my plan. I’m going to do a bunch of research, play with relevant tools (what fun is IT without tools?), and document everything I discover here in a series of blog posts. My goal is to educate myself and others so that we operations types can get more comfortable with DevOps. By breaking down this concept and figuring out what it really means, hopefully we can figure out how to transition pure Ops guys into this new IT management paradigm.
What is DevOps
Here we go, I’m probably about to open up Pandoras Box by trying to define what DevOps means but to me that is the foundation of everything else I will discuss in this series. I started my research by asking Google “what is devops”. Naturally, Wikipedia was the first result so that is where we will begin. The first sentence on Wikipedia defines DevOps as “a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals.” Hmmm… This is not a great start for us Ops folks who don’t really want anything to do with programming.
Reading further on down the page I see something more interesting to me … “The goal is to automate as much as possible different operational processes.” Now that is an idea I can stand behind. I have always been a fan of automating whatever repetitive processes that I can (usually by way of shell scripts).
My next stop on this DevOps train lead me to a very interesting blog post by the folks at the agile admin. In it they discuss the definition and history of DevOps. Here are some of the nuggets that were of particular interest to me:
- “Effectively, you can define DevOps as system administrators participating in an agile development process alongside developers and using many of the same agile techniques for their systems work.”
- “It’s a misconception that DevOps is coming from the development side of the house – DevOps, and its antecedents in agile operations, are largely being initiated out of operations teams.”
- “The point is that all the participants in creating a product or system should collaborate from the beginning – business folks of various stripes, developers of various stripes, and operations folks of various stripes, and all this includes security, network, and whoever else.”
Wow, that’s a lot more comforting to my fragile psyche. The idea that DevOps is being largely initiated out of the operations side of the house makes me feel like I misunderstood the whole concept right from the start.
For even more perspective I read a great article on O’Reilly Radar from Mike Loukides. In it he explains the origins of dev and ops and shows how operations has been changing over the years to include much more automation of tasks and configurations. He also explains how there is no expectation of all knowing developer/operations super humans but instead that operations staff needs to work closely or even be in the same group as the development team.
When it comes right down to it there are developers and there are operations staff. The two groups have worked too far apart for far too long. The DevOps movement is an attempt to bring these worlds together so that they can achieve the effectiveness and efficiency that the business deserves. I really do feel a lot better about DevOps now that I have done more research into the basic meaning and I hope this helps some of you who were feeling intimidated like I was. In my next post I plan to break down common operations tasks and talk about the tools that are available to help automate those tasks and their associated processes.
As always, please feel free to comment if you think I have missed something or if you have a request for content in an upcoming post.
A few months ago I saw an interesting partnership announcement from Foursquare and OpenTable. Users can now make OpenTable reservations at participating restaurants from directly within the Foursquare mobile app. My first thought was, “What the hell took you guys so long?” That integration makes sense on so many levels, I’m surprised it hadn’t already been done.
So when AppDynamics recently announced a partnership with Splunk, I viewed that as another no-brainer. Two companies with complementary solutions making it easier for customers to use their products together – makes sense right? It does to me, and I’m not alone.
I’ve been demoing a prototype of the integration for a few months now at different events across the country, and at the conclusion of each walk-through I’d get some variation of the same question, “How do I get my hands on this?” Well, I’m glad to say the wait is over – the integration is available today as an App download on Splunkbase. You’ll need a Splunk and AppDynamics license to get started – if you don’t already have one, you can sign up for free trials of Splunk and AppDynamics online.