Insights on the Notion of DevOps in AWS
I often get asked what DevOps means, particularly with regards to Amazon Web Services (AWS). The more I thought about it, the more I thought about the fundamental philosophy of DevOps and how there are many schools of thoughts around what DevOps means to different organizations. Is it a framework? Does it mean “Infrastructure as code?” Or is it just a mindset? Based on my experience, it is a mixture of all of that.
Before we can even begin to discuss DevOps and how it relates to AWS, I should lay some foundational thoughts on how I view DevOps in general.
Back when I started my career (mid 90’s), we called it “automating ourselves out of a job.” Now, we really didn’t think we’d be jobless. We knew by leveraging automation; we’d be able to work on other things that would ultimately make life better for us, (implementing monitoring, creating documentation, etc.). We also tried to implement standards and get out of the business of hand building servers. The intent was to have predictability and stability, and it worked pretty well. We had a small group maintaining thousands of servers and millions of customers at the height of it.
Fundamentally, that school of thought hasn’t changed very much almost 20 years later. What is different, however, is that there are now many “off the shelf tools” that do a lot of the heavy lifting. New Relic, Chef, and Puppet are excellent examples of some of the tools out there. Amazon Web Services (AWS) gives you most of the building blocks to quickly spin up a robust architecture. The magic comes when you can put it all together. Sure, you can spin up hundreds of EC2 instances in AWS, but are you going to maintain each one by hand? You can, but that’s incredibly inefficient and error prone, (remember that statistic that said 80% of all outages are due to human error or are self-inflicted?).
The challenge I see most often is culture, not technology. There has to be a vision and a cultural shift in the way of thinking about infrastructure and operational support before an organization can even begin to think about DevOps. The roadblock is usually culture, and it starts with leadership.
If leadership isn’t tolerant to change, it’s not going to fly. If leadership doesn’t have support or have any driving force behind continuous improvement (please see ODAA loops), then doing things new or differently is going to be the most difficult obstacle to overcome. Compared to this, the technology adoption for a DevOps methodology is small potatoes.
So with regards to DevOps within AWS, I have seen it done beautifully, artfully, and have had the privilege of working with some brilliant people who put it all together.
By leveraging the various pieces in AWS and leveraging the experience and knowledge of people who have built better mousetraps, I know it can be done. The building blocks are all there, and you just have to learn how to do it. As leaders, you have to empower your people to learn, try, fail, succeed and back them up as they progress.
The meaning behind “DevOps” can vary greatly depending on who you talk to. Some get it, most do not (yet). Those willing to take the time to learn, grow, and see things differently will have great success. Those who say, “But we’ve always done it this way!” will not likely be great “DevOps” candidates in the near future, whether in the cloud or not.