Moving Day 2 Operations from Production to Development – InApps Technology 2022

“Shifting left” has become something of a mantra for IT professionals, no matter what their specialties are. The earlier in the development lifecycle that functions like security, compliance, and data management can be integrated, the more effective they can be in ensuring the proper protection and performance of code and applications.

In traditional software development, requirements and coding are situated on the left side of the spectrum, while delivery, testing, and security live on the right. But traditions in software development are not like the venerable traditions of holidays — they are far from being sacrosanct. And in the case of formulating new software, that linear model just described has become obsolete. There are several compelling reasons why.

If we consider software development lifecycle as a number line with Day 1 in the middle, where developers install platforms, applications, and infrastructure and bring them online, Day 2 is on the right, where all the operations that happen once the application is built, released, and deployed into the field — upgrades, backup, disaster recovery, scaling, security patches, and all the other ways that software integrates with the real world.

Microservice architecture is said to enable rapid, frequent, and reliable delivery of large, complex applications. A new operational pattern is required to reflect this change.

To the left is Day 0, where developers build software, create code, and configure infrastructure. In essence, the left side of the number line, Day 0, is the ground floor of the development process where decisions about an application’s fundamental architecture are made. This is important because if functions like automation, security, testing, compliance, data management, quality assurance, etc. can be enabled before takeoff, the chances of the successful deployment, improved security posture, and continuous operation of an application are significantly higher than if they are deployed after an application is live.

Pushing the critical elements of software development leftward that had been typically reserved for the right — Day 2 and beyond — can ensure that vital mistakes are identified and remedied early on, before any significant damage occurs. Indeed, according to IBM research, defects that are identified and resolved during the design phase are about 100 times less expensive to fix than those discovered after the release of a product. 

Abandoning Tradition

There are several reasons this approach has grown outdated.

One is that software development has become largely atomized, with the process becoming an arrangement of microservices where an application is configured out of a fine-grained collection of loosely coupled services rather than formed from a monolithic architectural design. Microservice architecture is said to enable rapid, frequent, and reliable delivery of large, complex applications. A new operational pattern is required to reflect this change.

Another is that the traditional development sequence tended to visualize the process as having discrete stages running from left to right, from its beginning to the end, at which point the project was considered done. But the process today, with the growth of DevOps, is more circular than linear. Feedback and further iterations lead to constant revision, additions, and enhancements. Continuous delivery of updated applications, augmented by automation to help developers keep ahead of those changes, is widely understood to represent continuous improvement in today’s digital enterprises. And for that reason, the automation mechanics of that continuous delivery pipeline also need to shift left.

But perhaps the most significant reason for retiring the linear tradition is that most new applications today are created in the cloud, whether it be a public, private, or hybrid cloud. These cloud native applications are predominantly built using containers with Kubernetes, the leading container orchestration platform, serving as application infrastructure. The Kubernetes platform is developer and application-centric instead of being infrastructure-focused. Given that developers not only control the entire application stack but also underlying infrastructure using Infrastructure as Code (IaC), it would be a big disservice to also not give them influence over traditional Day 2 operational requirements from the beginning of their development journey.  

 Automation to the Rescue

However, while containers and Kubernetes are tremendously useful, they are unlike anything found in legacy systems, and legacy tooling simply will not work in this developer-centric environment. For example, all VM-based backup products don’t work with Kubernetes given that there is no mapping of containerized applications to servers or virtual machines and Kubernetes using dynamic placement policies, automatic rescheduling, and autoscaling. These legacy systems also cannot scale down to where development happens (e.g., a laptop).

As a result, Kubernetes-native tools that auto-scale with the environment are needed to shift traditional Day 2 processes to the left. Beyond that, to take full advantage of the shift left of operations, new Kubernetes-native platforms that account for secure multi-tenancy, role-based access control, and self-service will be needed to provide capabilities for backup, application migration, security, compliance, and other essential functions. This is particularly true in inherently complex enterprise environments where multi and hybrid cloud strategies are common and development teams are many.

The emphasis on the shift left and automation of Day 2 operations will become one of the lasting legacies of DevOps and DevSecOps adoption. For example, adding responsibility for application migration, backup, and disaster recovery on DevOps teams might seemingly add increased pressure development resources. However, with the advent of tightly integrated Kubernetes-native data management platforms, integration with data management functions for cloud native applications will require minimal development effort and improve tooling support for developer and ops teams.

The same integration trend is being observed with other traditional Day 2 functions such as security and observability. When considered together, the accelerated speed of the cloud native development alongside the expanding complexity of scaling cloud native systems is driving the urgency to adopt critical operational functions early in the development lifecycle to ensure the protection of key enterprise resources and potentially sensitive data in production.

Finally, for the shift left of data management to accommodate the workflows of developers, it needs to offer a low-friction pathway to be integrated into the application development process as soon as or even before it begins. In this respect, the use of automation is necessary. Doing so can simultaneously help to achieve a series of critical goals. It can help to address the chronic shortage of skilled personnel. It can increase the company’s agility. It can improve product quality. It can elevate the customer experience. It can improve the Developer Experience (DX) and increase developer happiness. It can help create a culture of continuous improvement. And it can nudge an organization along its path toward full digital transformation. The future is going to be exciting!