June 30, 2014
Two freight trains steaming toward one another. One has been at cruising speed for decades. The other, an upstart, has appeared in the past ten years. Neither knows that the other is on the same track, much less that they are headed for one another. There’s going to be a big collision, and a lot of destruction as a result.
This isn’t a story problem for you math phobes out there, but itis the best analogy that I have for collision course that DevOps and traditional application development are on. Paying credence to the old adage the “software is never ready, it’s just released”, DevOps is a completely unique methodology to development of applications. It utilizes the concept of rapid application development and release to a massive number of end users. Bugs are caught very quickly due to its live use, and patches are applied in near real time fashion.
Think about it this way. You want to build a soapbox derby car. Rather than having to fully think it through with others outside your “design expertise”, you make all the decisions about engineering, useful life, operability, etc. You build it. You give it to the kid for the race. They wipe out spectacularly. You then see what caused that, fix it in about an hour or two, and then give him the new one. And the process repeats–possibly with one or more new kids. Eventually, you will have one kick ass soapbox car that any of the Little Rascals would be proud to steer.
This is the world of eventual reliability. Negative impact is immediate and widely felt. Most of the time, you can survive it. Adobe’s massive database outage. Netflix down over the Christmas break. Facebook’s recent worldwide 31-minute outage. Heartbleed bug on all the Cisco routers. What do these things have in common? A DevOps mentality to design and some unflattering headlines every now and then
The old school method was as follows:
- Requirements gathering
- Charrette development and review
- Test (from testing engineers – not the designers themselves),
- Alpha release to a small group
- Beta release to a larger group
- Final release to everyone
It costs a lot to do it the old school way.
The way of Native Cloud Apps is completely different. It is as follows:
- Have an idea
- Implement it
- Release it to everyone
- Fix bugs
- Release it everyone
- Fix bugs
- …repeat forever
A lot of CIOs think the cloud solves all of their problems. I posit that the biggest collision we have coming in the IT space is the collision of old school software development and the DevOps mentality. Eventually, someone behind a very large company will make the mistake and think that their DevOps app that runs most of the business was mission critical. To paraphrase the Bard, “Cry havoc and let slip the dogs of customer dissatisfaction”.
I don’t know which way will win out. It will probably be a combination of the two – with a lot more DevOps than old school. But as a CEO, I will tell you that if my business relies upon mission critical apps, I would not want to find out that what I really paid for in my IT was a solution developed on the foundation of “we’ll get it right…eventually”.…