Production Ready is not User Ready

Continuous delivery is the penultimate goal of organizations’ embracing DevOps. It is not the ultimate goal, because that would be continuous deployment.

Much ado is made in the alleyways of DevOps with respect to the ability to deliver production-ready software umpteen times a day.

That’s nice.

The reason I don’t get too excited by that is, in the majority of enterprise organizations – even those embracing DevOps – delivery is only the first step in the ‘get to market’ phase of an application lifecycle. Few applications are “ready” for users upon that final build and release notification. It still has to be deployed into production where a variety of procedures and policies will ensure its proper delivery to users.

See, continuous deployment is (should be, might be, will be) the ultimate goal of organizations’ embracing DevOps. Even if it isn’t, the larger issue that simply delivering to production does not make an application “delivered” to its constituents. That requires deployment, in production, along with any services required to scale, secure, and speed the application to ensure it presents an optimal application experience to users, both corporate and consumer.

That might mean load balancing, to ensure scale and availability. It almost certainly means security – at least at the firewall, hopefully app security, and possibly more. It may also imply access and identity. Perhaps not for consumer-facing apps, but corporate-facing ones may need to be included in SSO or federated policies to ensure smooth, painless access. Speed, too, in terms of performance may be required.

All these things need to happen before an app is “ready” for users. And “production” knows it. Of the 32% of respondents in our 2017 State of Application Delivery who fell in the “we have 1-10 of these services deployed,” the majority fell on the “we have more than 5 side,” with 63% indicating 6-10 deployed today.

Irrespective of “continuous deployment” issues, these services are critical to ensuing that apps are “ready for users” and not just “ready for production.”

Delivering umpteen times to production is great, but delivering more frequently to market is the real goal. Even if DevOps edges into production (come on in! the water’s fine, really!) to handle the app and its immediate infrastructure, there are still going to be services upstream that must be provisioned, configured, and tested before the app can actually be considered “delivered.”

Releasing apps to production more often does not actually impact the deployment schedule. There’s a reason open source projects have a “stable” branch and a “nightly build” option. Sure, I can get the latest and greatest, but as a user I’d prefer the “stable” option, because having apps break or randomly crash is in no way contributing to a positive application experience.

The deployment schedule has to be driven by the business and implemented by IT, and that means getting IT (all four ops) on board to start automating as much of the process as possible. Because an app isn’t user ready into its secured and sped by the services that surround it in production.