The secret is performance management

When is innovation restricted? The promise of DevOps was one of “continuous delivery” – enabling incremental development to foster continuous, ongoing improvement to software projects, move testing to every branch and modification to an application, minimising the amount of time teams need to judge whether that change will break things and fast-tracking deployments. All of these pieces hope to ensure that bug fixes and new features move through to production consistently, rather than twice a year, resulting in more regular feedback and improved experiences for customers.

But continuous delivery isn’t without it’s own limitations – there are certain rules in place meant to ensure that nothing unexpected derails the workflow. For example, standard practice is not to deploy on a Friday, because even with all of our tests in place something can go wrong, and that might mean spending the weekend fixing any uncaught issues that make it into production. For the same reason, businesses don’t deploy close to or during peak seasons, when a bug in production risks losing customers in the most profitable time of the year.

Every minute of downtime for your site is potential money taken out of your pocket. A site going down will not only cost you potential revenue, but also the confidence of your customers. Who will trust a site that crashes and does not work properly? Keeping your site stable is essential to your business.

The problem here is that some aspects of the DevOps model almost discourage deployment, which is the exact opposite of what we want. These restrictions remove all of the flexibility DevOps is supposed to be giving our developers. If they’re unable to confidently deploy fixes when in response to or anticipation of major traffic events – even on Fridays – innovation is hindered rather than enabled. This is just one example of innovation lock-in, and it poses other business threats too.

Innovation lock-in does not allow businesses to keep up with customer demands. The pandemic has meant that many of us have spent more time online and as a result, our expectations for online services have increased. A lack of innovation will present formidable challenges when businesses attempt to scale to meet the demand for both services and information.

It also has a negative impact on staff morale. Developers become developers because they want to tinker, to create, to push boundaries. A lack of innovation can dilute their purpose and damage team spirit. To avoid this happening and to stay at the forefront of innovation, companies must place developers at the core of everything they do, empowering them with the tools they need, and avoiding unnecessary limitations.

So how can businesses avoid innovation lock-in?

A performance management approach is required. Take online retail as an example – the pandemic has accelerated what was already a worldwide shift towards e-commerce, with online spending in May 2021 hitting $82.5 billion, up 77% from the previous year. With that rise comes heightened end user demand and a greater sensitivity to things going wrong – if people are switching their shopping entirely online, they need to know it is reliable.

But e-commerce sites are not static, unchanging things. Online retailers constantly add new products and launch promotions, as well as installing security patches to keep their businesses and customers safe. Any issues with these changes may require taking at least some of the site offline for a time. And as every change to a site has the potential to introduce bugs and failures into the application, a performance management approach is needed to guard against them before they become disasters.

To achieve the continuous release cycles that support the uptime and response time users expect, developer teams need to know about potential issues before they affect the application. Performance management helps by providing predictive analytics to identify anomalies and alert teams before a service is affected. The faster a problem can be identified, the faster the developer team can get to work and mitigate the impact.

Performance management does, however, need to be specific to customer needs, particularly at application level. It needs to enable continuous improvement of all tooling with every change being logged and fully visible to the rest of the team. The workflow for updates also needs to be well-established, which means strictly defined and enforced standards that ensure a repeatable process for review and deployment.

By having a platform that gives development teams the ability to experiment with changes – whether that’s to application code, to a database or to some broader configuration – before its release to production, it means they can deploy with confidence using full production level copies of the environment (applications, databases, servers). This process prevents bad deployments and means dev teams can develop new campaigns knowing that their changes are guaranteed to work when they push to production.

Hardware limitations and the need for capital expenditure were often a hindrance to this approach before, the cost of provisioning production-like environments for every new feature and test was simply too high. The modern world is better. Everything is tracked in version control, provisioning tasks have become more intricately tied to the Git API, and the cost of creating strictly-defined replica environments with containers has reduced drastically.

Thanks to cloud computing, SaaS, infrastructure costs shifting to operational expenditure, and the connected toolchains now available, there is no longer an excuse not to release on Fridays.