This article is more than 1 year old
Are you a Salesforce or an Uber? Choose wisely, devs
Know when to break out the emergency release tools...
Comment There’s no one-size-fits-all when it comes to DevOps. In small operations DevOps will likely mean very little as developers will probably already be managing production environments in addition to the deployment of applications.
At the other end of the scale, in very large organisations - where there are well-defined lines between the different roles of development and operations - DevOps is seen as a major change. In between, there is a whole spectrum.
Hence, there will be a range of views when you mention DevOps – from those who see it as a marketing ploy to those who view it as transformational.
Whether you appreciate the term or not, the objective of smoothing the movement of an application from development to production will resonate with organisations of all sizes.
It seems we can't stop hearing about how organisations need to be more agile and move faster to support innovation in order to be successful. Often the industry looks to startups for inspiration as to how to achieve these goals. Uber and Airbnb have become poster children for the very types of IT organisation that many traditional businesses now aspire to be.
But more recently DevOps has come to be conflated with the concept that of continuous deployment. This is often taken to mean that updates to an application can be delivered to production almost instantly and that this should happen very frequently. A good example of this is Amazon, which delivers updates every few seconds. The result is that many businesses whose ambition is DevOps end up trying to achieve continuous deployment. That can lead to other problems.
So, if the objective of DevOps is not continuous deployment what should it be and why should organisations care?
The truth is that we now live in a world where stakeholders demand new software and updates to existing products faster than ever. This has been driven by the experience of using applications on mobile devices and from the use of cloud-based applications. These apps are smaller and more lightweight point solutions compared to many of the big enterprise applications of the past.
This creates a challenge for organisations in terms of speeding up the delivery of their software far beyond what they have done in the past. It makes sense that mobile apps can be delivered and iterated upon quickly as new use cases rapidly emerge and user requirements change. But for many of the more traditional, and core critical applications, the quarterly release cycle may still be very suitable.
Salesforce, who could be seen in the same ilk as Amazon or Uber, still sticks to this type of release cadence. That is because their customers – enterprises – do not actually appreciate constant changes and such an approach could have significant cost implications for them. But for anyone involved in application development there are other important concerns aside from just adding new features.
For a bank, a bug in an application could cost large amounts of money every minute, hour or day that it remains unfixed. For many businesses a security breach could have significant legal, cost and brand image implications. The longer it goes on the worse the problem becomes. In these scenarios, the ability to develop an appropriate change to the application, test, approve and deploy it as rapidly as possible is incredibly beneficial.
This is what DevOps is about: the old adage of just because one could deploy continuously does not mean one should. It is not that putting in place the necessary processes DevOps requires should result in organisations deploying application updates every few seconds, minutes, hours or even days. But that in the important event they need to move super fast the ability is there.
This might be because a bug needs fixing, a security hole patching or some user feedback needs addressing. Each organisation will need to decide for themselves the main reasons just as long as one recognises why DevOps is important to them. We should not all be chasing why it’s important to someone else such as Amazon.
DevOps is like the fire safety procedures in any office. You won't need a fire extinguisher or an evacuation plan every day but they are there because when there is a fire having them is incredibly helpful. For this reason, whether a business is large or small they should care about DevOps. ®