Pioneered by progressive web companies, DevOps came together as a discipline out of a desire to break the traditional waterfall approach to delivering software. Working with an agile mindset, they developed automation tools and processes that enabled products to be delivered in a more iterative way. After open sourcing these tools, an open source community formed, providing further tools that helped to streamline the software development process. The resulting methodology, which continues to mature, is what we now call DevOps.

As the world moves towards cloud and services, DevOps adoption is increasing. This is because organizations that utilize cloud services are more likely to have dynamic architectures that can accommodate continuous delivery, and so lend themselves to more iterative deployments. Conversely, legacy structures require legacy development practices, so a waterfall approach will remain in place until system architectures are evolved to more modular states. Once this is achieved, DevOps is as inevitable as the automated manufacturing assembly line, with practitioners moving much faster than their legacy counterparts 

A new state of mind

One of the main aims of DevOps is to break down the walls that exist between teams involved in the software delivery pipeline. Destroying silos means development teams and operations teams are no longer protective of processes they once owned. Instead, skills and knowledge are combined within a single team that has complete ownership of the entire product lifecycle, as well as the tools and processes that aid development. This means there are no handoffs from team to team as the DevOps team’s work is only done when the product itself is delivered.

The long-term benefits of DevOps include consistent speed, delivery, quality, and resiliency, as well as reduced time to address issues for customers and a more sustainable product lifecycle. To achieve these, as well as a lower total cost of ownership, software providers must keep up with the automation requirements that come with DevOps. Continuous innovation and development, development tooling for telemetry and support, and quality automation are just a few examples of tools and processes that are generally neglected. But if developers are engaged effectively and given ownership over these areas, such shortcomings will be avoided.

Organizations that fail to address the automation requirements will end up with a traditional operations team they call DevOps because they want to seem connected to the product, but this is DevOps in name only. They will continue to suffer from the problems that exist with a segregated operations team: inefficiencies of handoffs and the product quality issues that come with a lack of product knowledge and ownership.

Architectures for automation

Automated deployments are a prerequisite of DevOps, so architectures that make automation easier are an inevitable result of DevOps adoption. Microservices reduce the size and testability of a unit of deployable code and so make the automated asset easier to manage. Microservices also infer APIs as the only means of interaction, and so provide a more stable, contract-based relationship between software components of a system. APIs combined with microservices allow a contained amount of flexibility within a system, without compromising it.

The contained context of microservices also allows customers and developers to depend on tested and stable features that can be seamlessly swapped out or changed at any moment, without affecting the product. Such alterations are unthinkable when working with monolithic architectures as there is no way to verify the quality of the software in a short period of time. So, when a microservices architectural approach is taken, DevOps is accelerated.

What’s next for DevOps?

As major cloud providers continue to educate the software development community on the benefits of DevOps, adoption of the methodology will continue to grow. Many of the major players are also making it simpler for developers to support their products with fully managed services, and providing excellent tooling to automate it, which lowers the bar to entry.

With support from large organizations, as well as the thriving open source community, DevOps tools will likely advance to the point where intelligent automation allows self-service of IT requests, commonly referred to as NoOps (no operations). Whether ops can truly be automated is a contentious topic within the software development community, but if the advancements of the last few years are anything to go by, such a proposition can hardly be ruled out. What is important to remember is that DevOps is a journey with no finite destination. As new tools and practices are developed, DevOps will continue to evolve.

Attitudes must also evolve. DevOps requires a rethink about the responsibility of development and operations teams. When done right, this emphatically means one team. In an organization where this is not the case, the legacy of traditional ops forces its own existence in a future state. Territorial disputes abound, and politics tend to rain on the DevOps parade. So, before going down the path of DevOps, an organization must be committed to becoming culturally as well as structurally lean.

Joseph White is Senior VP of Enterprise Architecture at Finastra. Over the past 20 years, Joseph has designed cloud systems and APIs across several industries. In his current role, he is responsible for software architecture, security, and developer practice.