I heard about DevOps a while back but didn’t really look into it. My initial understanding was that the roles of developer and system administrator would merge into one called devops. Last week, I attended a DevOps meet up at Palo Alto and got the chance to learn from others about DevOps.
The hosting organization even wrote up a good blog defining what a DevOps is. According to the blog,
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
DevOps is, in many ways, an umbrella concept that refers to anything that smoothes out the interaction between development and operations. However, the ideas behind DevOps run much deeper than that.
So the DevOps is more about a movement than merging of two roles. The basic idea behind the DevOps is to breach the wall between development and operations.
Traditionally developers ship products which are then run by operators in other companies. In this new age where much of software is delivered as services, the developers run their software directly. When there is a problem, the developers must fix it right away. That is why you see engineers at Google required to rotate on calls for support. When more companies ship software as services, it’s natural that more engineers will have two hats on their heads. The DevOps concept is not really new, but the terminology is.
With the DevOps movement, it doesn’t mean there won’t be a need for system administrators. We still need system administrators who manage core infrastructure such as storage, networking, and such, but fewer administrators to run and monitor applications. Whoever designs and develops the software needs to take care of the operations and support. As infrastructure gets bigger in scale, companies continue to expect their system administrators to become good script developers who can drive the most operational efficiency out of automation.
For the development side, there are even bigger impacts. For one thing, you have to carry pagers over the weekends. Whenever there is a problem, you have to fix it no matter how late it is. With this pressure on, all the architects and developers need to think carefully about operations as they develop software: how to make it stable? How to make it scale? How to prevent system scope outage? How to quickly and silently recover from outage? How to recover quickly without hurting SLAs? This change in traditional roles forces them to come up with more scalable and reliable architecture, better quality software, and easier to manage services. This is good for the people, good for the companies, and good for customers!
Not every developer will be directly affected. We will still see software as products in the future. But when enterprises move to private cloud computing, more of these products will be architected to run as services or applications on top of services. Having a DevOps mindset and corresponding expertise will definitely be a big plus for every architect, developer and system administrator.
As a cloud professional or would-be, are you ready for the challenges and to embrace the changes?