Is DevOps Just a “Rehash”?

Gartner refuses to define DevOps as a segment or a market. Forrester takes largely the same view though they have started to work on ARA (Application Release Automation) as a market.

DevOps, according to many enthusiasts is not about using new tools. It is about changing mindsets and the culture within an organization. Developers working closely with testers and operations staff and everybody owning the application collectively is not such a revolutionary idea provided you understand the history of enterprise software.

rehash

Earliest software was written on mainframe by the folks who both developed it and then provided support to their customer. As software grew and developers’ social skills were put to a test, it was fairly obvious that we needed a new breed of technology workers who will empathize with the end user and will dedicate their time in supporting their needs. That was the birth of operations.

DevOps has mashed developers (and testers) with operations again and tools that we considered to be old and archaic are suddenly at the centerstage again.

Lets take a look at APM. After rapid growth in late 90s and all through 2000s, the growth in this sector crawled to almost zero. With DevOps, resurgent operations teams started looking at the performance data again and for that they revived their APM tools. The result was the rise of the new vendors like New Relic and App Dynamics even as legacy APM providers continued to take a beating in the market.

I am observing the same trend in Test Automation. DevOps demands IT to move closer to Continuous Delivery and one of the biggest hinderance to that has been old automation paradigm (More on this in next post).

DevOps is not a new space or a market – it is a better model, a new philosophy on how to leverage tools (some old and some new) and how to change paradigms that have brought IT to a stage where more time is wasted on upfront planning and downstream fixing of critical issues rather than developing new and better quality code that could be called “production ready.”

BTW, going back to the title of this post, somebody decided to rehash coding. At Livecoding.tv you can watch developers code for hours! Try it. Let me know if you like it.

Velocity without risk

There’s an age old saying in the world of Project Management – every project has three aspects – Risk, Cost and Time. The paradox is that you can deliver on no more than 2 at any given time.

DevOps however, promises to deliver all three – provided the practitioners understand what what each means. In this post, I will talk about what Release Risk means in today’s world.

  1. Release Risk talks about Integrity of the “Release Package” – a blackbox of disparate assets/artifacts that may be deployed to hybrid environments but together make up the whole Release Package. Enterprises today can guarantee that a particular Release artifact (lets call it “Deployment Unit” or “Release Unit”) was tested and released but as far as the whole package is concerned, that remains a mystery.  Ability to create this immutable object, promote it from environment to environment and report on it is the key to determine Release Risk.
  2. Historical Data – how successful/problem ridden this particular Release has been determines how risky it will be this time around. Collection and display of historical data is a must to determine the risk of this release. 
  3. Number of changes – The (new) content in the release is a critical factor in determining the risk. The greater the number of changes, the more risky the release is.

The three factors above, combined with the preliminary test results give a fairly accurate and quantifiable Risk associated with your releases.

Who is buying Application Release Automation

In one word – The operations guys (Directors/Leads/VPs)

While ARA refers to applications being deployed on target environments and hence should be the focus of the developers, the fact is that most IT organizations see this as an Ops function. Their logic is simple – any deployment to the production environment is a “change” to that environment and hence has to be managed by Infrastructure and Operations (INO) team.

Developers still influence the tool but it is the operations team that doles out the budget for any such tool.

Surprisingly, too many vendors don’t understand this nuance and keep positioning their ARA tools to developers – who have an opinion but little purchasing power in this space.

In the PaaS World, Azure takes the lead

Did you know that in the world of public cloud, Azure (not Google) is (a distant) second, behind AWS? I didn’t and was quite surprised when I came across this information and related data.

Since the launch in 2010, Azure has shown >100% growth. It’s 2014 revenue exceeded $1 Billion. Also in 2014, Azure grew by 125%. Their annual run rate is close to $2.5 Billion. And while AWS is still struggling to make that IaaS to PaaS transition, Azure has been recognized as a leader in both segments!

Looking at the growth, AWS has 27% of the market share (down from 28% last year), Azure, meanwhile has surged to 10%, up from 6% last year. GCE/GAE is less than 5% and IBM is about 7%. 

Finally, Microsoft has put all its cloud eggs in the Azure bucket. They want to be successful and are desperately looking for developers and customers.  In other words, anybody writing new apps has a big opportunity with Azure.

Among public cloud players (IaaS and PaaS), Azure could be the cloud of choice for you.