DevOps – its not Culture, and its not a Movement

What is DevOps? If I had one scenario to pick for which to use the phrase “everyone has a different definition of X”, it would be to define DevOps. In my entire career in business and technology I have come across similar confusion only twice – the first time was with the definition of “cloud“, and the second is with the definition of “omnichannel“.

So what is DevOps? If you look up with definition of DevOps on Google you get this – “DevOps (a clipped compound of development and operations) is a culture, movement, or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes.” Ok – now even I am slightly confused? So DevOps is a movement?

Well to me a movement looks something like this:


or at least like this..


& not like this…

Credit: New Relicdev-ops

Well, what if its more of a culture? Hmmn, again, when I think culture, I think something like this:

Credit: Listversesamural

or this…

Credit: mausspacebeatles


& less this…

Credit: Sakthi Vadivelu

DevOps Culture.png

What about practice? Now are we on to something. “Meditation” is a practice, “martial arts” is a practice. Generally a practice is associated to something that you a) do consistently, and b) that enhances your well being in some way. Well to do DevOps right – a) you have do it consistently, and b) if you do DevOps right, it will enhance the well being of most development and IT organizations. So yes, DevOps is a practice, and like with most practices, it involves a “philosophy”, a “methodology”, and a “toolkit”, however unlike say “meditation”, “DevOps” is a team practice. What this means is that in addition to a philosophy, methodology, and toolkit, DevOps requires an “operating model” in which a team or a set of teams can effectively operate. Additionally, like with any other practice, the more you do it, the better you get at it.

So with this as a foundation, how would I define DevOps? I would say “DevOps is a practice with an associated philosophy, methodology, toolkit, and operating model, that enables the rapid deployment of software“. I have used some words very deliberately here, in particular the words “rapid”, “deployment”, and “software”.

Rapid vs. continuous: Continuous deployment or continuous delivery implies a level of instantaneousness that while it might be an ideal final state, is probably not a realistic near or even medium term state for most IT organizations adopting DevOps. Rapid is fast, but its not continuous, and its certainly not instantaneous.

Deployment vs. Delivery: Software can be delivered as quickly as it has been developed and tested, but that doesn’t necessarily imply that the software has been put into use. In the IT world, for software to be used, it has to be deployed.

Software vs. Infrastructure Changes: Infrastructure changes might or might not be software changes or software-driven changes. For the purposes of this definition I have excluded infrastructure changes that are purely hardware changes.

Additionally, note that I haven’t used the words “to minimize risk” or to “reduce time to market” in my definition of DevOps. The reason is simple, its because in my mind those are value statements of DevOps, and hence imply why we should care about DevOps, but do not constitute the definition of DevOps.

Hope this helps!

DevOps – its not Culture, and its not a Movement


In my first post I spoke about why cloud computing represents the “Fourth Act” of enterprise computing – with mainframe, PC, and client-server representing acts 1, 2, and 3 respectively. So what characterizes the cloud computing era? In one of the better posts on the subject, Ben Kepes, one of the worlds foremost enterprise IT thought leaders, characterizes “cloud computing” based on guidelines provided by the National Institute of Standards and Technology (NIST), with the following key characteristics:
  • On-demand service: ideally allowing users to self-provision
  • Broad network access: access via standard platforms viz. web, mobile etc.
  • Resource pooling: resources pooled across multiple customers/end users
  • Rapid elasticity: ability to scale to meet demand peaks
  • Measured service: utility like billing
He then goes on to describe the cloud computing stack including Software as a Service (SaaS), Platform as a Service (PaaS), and IaaS (Infrastructure as a Service), and the characteristics of each of these layers of the cloud stack.


While this approach to characterizing cloud computing makes perfect sense, in order to understand why cloud computing represents this “Fourth Act” of enterprise computing, we have to consider not just what characterizes cloud computing from a technology perspective, but also understand it’s impact on how enterprise IT is governed, and ultimately the business value that the cloud drives.

Below is my perspective on what characterizes each era of enterprise computing from a technological perspective:

Technology Characteristics v04 MA 2Jun2016


 A few points to key in mind when viewing the table above:
  • While each era of enterprise computing has a primary enabling technology, there are other parts of the technology ecosystem that are quite important. In the case of cloud computing ubiquitous broadband access is one such key enabler. That said, even without ubiquitous broadband access the cloud can exist, but without the adoption curve that we have seen. Without virtualization though, there is no cloud computing.
  • People have often compared cloud computing with the mainframe era, and while cloud computing is in some important ways a modern adoption of the computing concepts pioneered in the mainframe era, in particular resource pooling and remote execution of compute workloads, there are some significant differences. In particular in terms of it’s ability to scale, both from a capacity and time perspective, cloud computing is far removed from it’s early mainframe predecessors.
  • From my perspective what’s game changing about cloud computing, particularly in relation to traditional client-server computing, is this ability to self-provision, to be billed only for utilization, and to scale almost instantaneously. However as things currently stand in large complex organizations the ability to self-provision and instantaneously scale is usually theoretical. Most large organizations have systems and processes in place that cannot stop from coming in their own way, and significantly slow down these important benefits of cloud computing.
All this being said where cloud is truly very different from previous eras in computing, is in relation to the impact that cloud drives on governance models and business itself. Below is a table that outlines key differences:


Governance & Business Value v06 MA 3Jun2016


As mentioned above, it’s the ability to self provision, to scale almost instantaneously, and to be charged based on utilization, that’s most game changing about cloud computing. It provides the coming to fruition of the concept of utility computing, that unsurprisingly also has its root’s in the mainframe era. Have an idea for a new app that the company wants to prototype? Spawn a new EC2 instance, set up your code libraries, and you are off to the races. Your app needs to be able to scale on demand? Execute your application using AWS Lambda and let it auto-scale.


From a governance perspective this changes almost everything. In particular moving compute workloads to the public cloud impacts who supports the workloads, how workloads are provisioned, and more broadly how IT change is managed. What was previously in the domain of infrastructure architects, system administrators, and build teams is now largely in the domain of SaaS, PaaS, or IaaS  providers, or even cloud MSP’s. It doesn’t mean all of these roles, or all of these areas of enterprise IT competency become irrelevant, but it does mean the that the nature of these roles will evolve and where these skills are needed will shift (from enterprises to service providers).


All of this aside, the greatest impact of cloud computing though is on business itself. Even up to about 12 years ago, when Facebook had just launched, it needed a capital investment of approximately $20,000 on infrastructure to get started. Today that cost would probably be in the range of $200 on the cloud – a 100x decrease! For this reason among a few others, startups today are challenging established players in nearly every industry – from transportation to financial services to hospitality. In addition to the dramatic up front costs savings, startups are additionally taking full advantage of the agility (near instantaneous provisioning and auto-scaling) provided by the cloud, to fail fast, rapidly iterate, and go to market.


Established enterprises realize all of this, but are often bogged down by their own systems and processes, which were developed and optimized in the client-server era. In the client-server era the primary function of the CIO, and more broadly IT, was to keep the lights running. This was because information technology was largely thought of as an OpEx optimization play. That view is now turning on its head as increasingly businesses ranging from GE to Ford to Coca-Cola are realizing that information technology is no longer simply a way to optimize cost, but central to their product and growth strategies. In this new world, incumbents will be required to fail as fast, iterate as rapidly, and launch as quickly as startups are able to do. In order to do this though, enterprises will have to take advantage of the cloud computing paradigm in its truest sense and to its fullest extent.