Forget DevOps, let’s do OpsDev

This means a customer’s experience with a brand or company will spans many interconnected applications, all comprised of different code bases, data sources, hosted at the different datacentres, designed and developed by different teams, using different technologies, APIs and so on.

The operations responsibility

From an operations standpoint, while the applications and code might be separated, in this always-connected world, there’s a need to ensure all the components of the service are always running smoothly and that no service interruptions occur. Clearly, the delivery of inter-connected and personalised software applications has an impact on application design, development and operations paradigms.

DevOps has emerged to help companies be better and delivering software to their end users. DevOps practices have traditionally originated on the Development side of software delivery, as they first emerged to address developer-led challenges with practices such as Agile development, code review and code standards, build automation and continuous integration, and more.

But, ultimately, DevOps spans the spectrum of the entire software delivery pipeline – from Dev to Ops… and its true value (and biggest ROI) is ultimately in the Operations side – once the application is promoted into Production and the value is actually being delivered to end users.

In that sense, we can coin a new term: OpsDev – which begins with that end in mind.

OpsDev means front-loading Ops considerations – relating to applications’ operability, security, scale etc. early on in the process.

Questions such as “how will we manage this”, or “how will it scale” or “how do we migrate this to a new datacentre” are addresses from the initial design stages of the application.

In addition, the automation of the delivery pipeline itself – including all the toolchain, processes, tests, etc. that ushers code from the CI stages all the way through to deploying into Production is being designed and developed in parallel to designing the product.

The pipeline itself is a critical component of the application, and not an afterthought. This ensures fidelity of artifacts and configurations across all the environments throughout the software delivery process, better quality product, less errors caused by manual tasks, accelerated delivery, and streamlined operations in Production.

Remember, first pants THEN shoes

For example, the dependencies of the various application components must be understood and modeled before the software development process begins.

• In addition, the consideration for infrastructure stability, environment modeling, security and audit/compliance measures are first and foremost. Application components are stubs and they do not need to be in their final forms.
• Secondly, the environments in which the components will be deployed for production must be modeled.
• Third, the processes to deploy the various components to the target environments must be automated as much as possible.

By doing the above, the design and development teams can replicate the application and environment models, and automated processes in the development and test phases in a consistent and repeatable way.

By easily replicating the production environment and processes in development and test phases, the independent design, development and testing teams will know the production constraints and parameters very early on, such that they develop the applications with those constraints and parameters in mind. OpsDev ensures more predictability and reliable operations.

Whereas, in the traditional model of application delivery, often a lot of time is wasted troubleshooting applications that have been approved by QA in the Staging or Production data centers but do not run well in Production. And often times, the release to end users must be significantly delayed because the applications are dead on arrival once deployed in Production, due to configuration drifts, etc.

Release pipeline

In the OpsDev approach, a Release pipeline that orchestrates the deployment of applications to dev, test, staging and Production environments not only accelerates the overall process of deployments in various environments through automation and parallelization, but it also improves quality by minimizing error-prone manual tasks. The Release pipeline aggregates several Commit pipelines that make up a Release. A commit pipeline is the individual CI or feature/component pipeline and a Release may contain several application components developed by several teams.

The Release pipeline has to understand the interdependencies among the application components and marshal those into Staging and Production environments. The Release pipeline can have manual and automatic approval gates to make sure that the Release is approved and is going in the right deployment schedule.

ITSM integration

From the OpsDev approach, the Release pipeline can be integrated with ITSM (Information Technology Service Management) and APM (application performance monitoring) solutions. The pipeline can “report back” to those tools to ask for an approval to an automated task, record a task as completed as code is promoted through the different stages along the pipeline, or these tools can trigger certain next-steps that are automated by the Pipeline orchestration.

Similarly to integration with service desk tools, the Release pipeline can also kick off the APM solution to monitor the performance and load testing once an application has been deployed, or perform automatic tasks – such as scaling or auto failover – upon receiving certain signals from the monitoring tools.

Final thoughts

The proliferation of software in every aspect of our connected lives and the role software applications play in the user-experience of today’s consumers all make mastering the way we deliver and manage software updates critical to the success of businesses today. Because of the increased interdependencies between these digital services and application components (SaaS, software in devices, software in datacenter, mobile apps, web app, and more) we need to encourage developers to think Ops-first, to accelerate the mind shift from DevOps to OpsDev.