Do a search on DevOps and you will find a heated debate on whether its real, if it’s new or if it matters. I think the question of whether it’s real or matters is difficult to argue against. Here’s why: business expectations have accelerated; technology is constantly changing and we demand more and we demand it faster. This pressure has cascaded across technology teams and has resulted in a refactoring of our processes, team organization and tools. Need convincing? Look at the agile movement as evidence. Development teams transitioned from a waterfall model to an agile model to accommodate fluid changes in business goals. Is DevOps new? The answer is Yes and No. Yes, as a strategic organizational goal. No, because it is typically perceived internally as a tactical response to specific challenges.
Whether we agree or disagree that DevOps is new is largely irrelevant. We can agree that business pressure and advances in technology have transformed how we deliver services to our customers. The idea of DevOps is just as the name suggests: alignment between development and operations. Ideally we should call it BizDevOps. Alignment between business goals, development and operations is the real change agent. I’ll stick with DevOps for the sake of popularity and acknowledge that business drivers are the catalyst.
So What Exactly is DevOps?
DevOps is about people, process, technology and communication across the application lifecycle. It’s about collaboration; it’s about efficiency and it’s about feedback across the intersection points. Have you ever heard the old adage “it worked fine on my dev machine, it must be your server”? If so, you have already felt the pain of a breakdown in the lifecycle. These are the types of situations that DevOps looks to address.
A Look Back:
I’ve been in the technology world for the last 17 years. In the late 90s I ran a software development project that was responsible for building a client-server application and deploying it worldwide to 100+ locations. Deployment was by far the most costly and painful part of the project. Every location had different implementation requirements and challenges. Development worked in a vacuum to revise requirements and address a constant stream of level 3 type issues. One offs became more and more frequent to accommodate field issues. In short, our waterfall approach and lack of focus beyond development caused us significant pain. Sound familiar?
During the project, web programming models came into popularity. This new paradigm brought the prospect of centralized management and deployment efficiency. This in turn changed the business economics and forced us to re-think the project. This disruption was good from an economic standpoint. But our organizational structure, methodologies and tools weren’t agile enough to capitalize on the full benefit across the software lifecycle. Eventually we got there and we focused on operational success along with the end user requirements. But we weren’t well equipped to manage constant change in the process and maintain our deliverables. Luckily this worked in the 90s … it doesn’t work now.
A Look Forward:
I would sum up our world today as one of constant change and delivering services to our customers. Virtualization, cloud computing and automation are re-shaping the future and accelerating our ability to deliver business value. Our world demands agility. We have seen a big shift on the development side with agile methodologies. This has impacted how the business views the development process. We need this same agility and collaboration across the entire lifecycle. It’s beginning to happen. Customers are defining roles that focus on the Dev/Ops divide; collaboration is starting to happen across teams and tools are helping to enable this transformation.
That said, most organizations are far from having the efficient processes, tools and culture in place to effectively capitalize on the constant changes. It’s typical to see an emphasis on one area without the others. It requires commitment across the organizations that are involved in delivering technology services and applications. It requires rethinking processes, especially at the intersection points. And it requires leveraging tools to automate and manage.
Private and public cloud strategies are driving a focus on self-service IT, automation and time to market. The goal is to accelerate the delivery of applications and services to meet business demands. Many argue that DevOps becomes irrelevant as we embrace PaaS solutions and abstract the infrastructure. I would argue that we only shift focus and the concept of DevOps becomes even more critical to delivering on the benefits.