By Steve Jin, VMware R&D
entry was reposted from DoubleCloud.org, a blog for
architects and developers on virtualization and cloud computing.
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 in 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.
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. The DevOps is more about a
movement than the merging of two roles. The basic idea behind the DevOps is to breach
the wall between development and operations.
Traditionally developers ship products that 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 – usually 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 wear 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?