Software Engineering has always been dependent on IT operations to take care of the deployment of software to a production environment. In the various roles that I have been in, the role of IT operations has come in various monikers from “Data Center” to “Web Services”. An organisation delivering software used to be able to separate these roles cleanly. Software Engineering and IT Operations were able to work in a somewhat isolated manner, with neither having the need to really know the knowledge that the other hold in their respective domains. Software Engineering would communicate with IT operations through “Deployment Requests”. This is usually done after ensuring that adequate tests have been conducted on their software.
However, the traditional way of organising departments in a software delivery organisation is starting to seem obsolete. The reason is that software infrastructure have moved towards the direction of being “agile”. The same buzzword that had gripped the software development world has started to exert its effect on IT infrastructure. The evidence of this seismic shift is seen in the fastest growing (and disruptive) companies today. Companies like Netflix, Whatsapp and many tech companies have gone into what we would call “cloud” infrastructure that is dominated by Amazon Web Services.
There is huge progress in the virtualization technologies of hardware resources. This have in turn allowed companies like AWS and Rackspace to convert their server farms into discrete units of computing resources that can be diced and parcelled and redistributed as a service to their customers in an efficient manner. It is inevitable that all this configurable “hardware” resources will eventually be some form of “software” resource that can be maximally utilized by businesses. This has in turn bred a whole new genre of skillset that is required to manage, control and deploy these Infrastructure As A Service (IaaS). Some of the tools used by these services include provisioning tools like Chef or Puppet. Together with the software apis provided by the IaaS vendors, infrastructure can be brought up or down as required.
The availability of large quantities of computing resources without all the upfront costs associated with capital expenditures on hardware have led to an explosion in the number of startups trying to solve problems of all kinds imaginable and coupled with the prevalence of powerful mobile devices have led to a digital renaissance for many industries. However, this renaissance has also led to the demand for a different kind of software organisation. As someone who has been part of software engineering and development, I am witness to the rapid evolution of profession.
The increasing scale of data and processing needs requires a complete shift in paradigm from the old software delivery organisation to a new one that melds software engineering and IT operations together. This is where the role of a “DevOps” come into the picture. Recruiting DevOps in an organisation and restructuring the IT operations around such roles enable businesses to be Agile. Some businesses whose survival depends on the availability of their software on the Internet will find it imperative to model their software delivery organisation around DevOps. Having the ability to capitalise on software automation to deploy infrastructure within minutes allows a business to scale up quickly. Being able to practise continuous delivery of software allow features to get into the market quickly and allows a feedback loop in which a business can improve itself.
We are witness to a new world order and software delivery organisations that cannot successfully transition to this Brave New World will find themselves falling behind quickly especially when a competitor is able to scale and deliver software faster, reliably and with less personnel.
| Reference: | The Emergence of DevOps and the Fall of the Old Order from our JCG partner Lim Han at the Developers Corner blog. |
The problem I see in this DevOps paradigm is that I often spend 30% of my project time on Ops rather than developing. In the mad rush to “get stuff out quicker”, the concept of proper planning has gone out the window and DevOps is an excuse for lack of planning.
Well, I guess 30% on Ops is a reasonable amount of time spent on getting the IT infrastructure running but maybe this could even go down further if we are able to automate deployment and environment setup. Of course, proper planning should still be required for any deployment exercise and just because we are automating it doesn’t mean that we need not plan and design our solution with careful thought. It’s a fallacy to think that adopting a DevOps approach to your organisation means throwing planning out the window.
This all depends upon how DevOps is implemented. But it is not a fallacy to think that adopting DevOps means throwing planning out the window. The Management that pushes the DevOps concept down one’s throat often wonders why you can’t just “spin up your app” immediately. Now, if it were done in an ideal manner, you have a point. However, most times it is not.
I agree that in a real life scenario, it is unlikely that a push-button deployment would “simply work”. In all practicality, there could be many different environment variables to consider when we try to perform a live deployment. That’s why even if an application had been properly tested, there’s no guarantee that a different environment setting somewhere causes it to break. That’s why the holy grail for sysadmins is to be able to replicate the deployment from development all the way to production in a consistent manner without breaking stuff. That said, there should always be planning for contingencies and… Read more »
DevOps is great if you wish to increase the speed at which you push out low quality software to your customers. Managers love the flexibility to deploy rushed untested code to production in order to claim meeting a deadline, safe knowing the devs will be the ones spending sleepless nights keeping the thing from imploding and taking the blame if anything seriously goes wrong.
Not testing code before pushing it to production is probably irrelevant to the topic. Having to setup environment and deploying code manually to production doesn’t guarantee that your code is robust. At the very least, an automated way of provisioning your environment and pushing code to production fast allows you to spot the problems quickly , not after you’ve spent 3 days bootstrapping the environment.