Cloud, DevOps, and the Enterprise

At last week’s CloudConnect conference in Santa Clara, California, a speaker asked the audience how many people were implementing Private Clouds. A few dozen of the fifty or so attendees raised their hands. Then he asked how many of them were implementing automated self-service. All the hands went down.

Now, we can argue that because automated self-service is an essential Cloud characteristic, nobody in the room was in fact implementing Private Cloud at all. But take a closer look, and the lack of emphasis on self-service Private Clouds is a telling indicator of the state of Cloud Computing (in particular, Infrastructure-as-a-Service, or IaaS) in the enterprise. If an enterprise IT shop were to truly implement a self-service Private Cloud, and actually got it to work properly, then the enterprise development teams would be able to manage the entire production environment for themselves. There’d be nothing left for the operational IT folks to do except make sure to replace bad hard drives and the like. No more server or network administration. No more break/fix. No more reason to get that healthy salary – or any salary at all, for that matter.

That’s the fear (often unspoken) of many an IT professional. Cloud will take our jobs! And not only that, giving the development team responsibility for managing the operational environment masquerading as IaaS is a recipe for disaster. It’s no wonder nobody in the aforementioned conference session admitted to implementing automated self-service. After all, automated self-service turns the Cloud into the Devil’s playground.

The Rise of Full Lifecycle Governance

It may seem that Cloud is playing the villain in this melodrama, but in fact, such challenges predate the Cloud by a decade or more. As we have long discussed in our Licensed ZapThink Architect (LZA) SOA course, the move to SOA requires full lifecycle governance. IT shops that divide their governance activities into separate app/dev and operations groups, or worse, have no governance at all, are ill-prepared to implement SOA, because with SOA, the fun begins after deployment of Services. The conclusion of the development phase, in theory, brings the publication of Services. Consumption, composition, and versioning of those Services takes place subsequently, now that Services are the responsibility of operations. Unless the IT shop coordinates their SOA policies across the lifecycle, expect no end of problems as the app dev team tries to monkey with production software.

Today, add Cloud to the mix. The rise of Cloud in the enterprise adds an entirely new dimension to the requirement for full-lifecycle governance, because we’re not just reinventing how to consume and compose application functionality and data as we did with SOA, we’re revamping the entire operational environment. IT will never be the same again. But in spite of the doom and gloom pronouncements of many an old-guard admin, the Cloud doesn’t put ops folks out of a job. It does, however, redefine their role.

Enter DevOps

The idea behind DevOps is to take the concept of full lifecycle governance and bring it down to the project level. Instead of the app dev team chucking code over the wall to ops, bring the ops folks together with the developers and testers so that code iterations can include the operational phases of the lifecycle as well. In essence, DevOps extends the principles of the Agile Manifesto – working with stakeholders to focus on delivering working software that meets changing business needs – to include running the software, not just building it.

Sounds good, but the multifaceted challenges facing successful DevOps are personal, technical, architectural, as well as organizational. On the personal level, ops personnel must change their working situation, often moving their desk and dealing with different people, learning different technologies, and following different processes. On the technical level, DevOps requires continuous integration, continuous testing, and automated deployment capabilities that even today’s more advanced Platform-as-a-Service (PaaS) offerings are only now in the process of rolling out. Next, layer on architectural considerations, including how well the existing code and integration environments support policy-driven automation, which is the essence of Agile Architecture that I discuss in my new book, The Agile Architecture Revolution. But the most significant change that DevOps introduces to the IT shop, even more significant than architectural issues, are the necessary organizational changes.

Typically, app dev and operations report up to the CIO through different managers, say a VP of development or engineering plus a VP of operations. This traditional organizational structure doesn’t make sense any more. Instead, there should be a VP of software programs or portfolios, where teams of developers, testers, as well as ops people report up through the single VP. However, even this simplified org chart doesn’t tell the whole story for most enterprise IT shops, because the focus isn’t entirely on software development. It’s also on integration. And as such shops move to the Cloud, the challenge then becomes how to implement and manage a Hybrid Cloud-based environment.

The Enterprise DevOps Challenge: Hybrid Clouds

As we discuss in our Cloud Computing for Architects and Enterprise Cloud Computing courses, it’s important to place the Cloud into the enterprise context. In other words, all that heterogeneous legacy you’ve been struggling with for years. Sure, it might sound good to the executives to simply move all that old code to the Cloud, but in most situations, such migration is impractical or simply impossible. Instead, some capabilities should remain on-premise while others will do just fine in the Cloud. Now the challenge is connecting them together.

Enter the Hybrid Cloud. In reality, there are many different types of Hybrid Clouds: on premise to Public Cloud, on premise to Private Cloud, Private Cloud to Public Cloud, and every other combination you can think of. Furthermore, most enterprise mobile development falls into the broad Hybrid Cloud category, with the rise of Mobile-Backend-as-a-Service or MBaaS (more about MBaaS in a future ZapFlash). Face it, the story of today’s technology is one of connecting things, rather than running apps in isolation. The Cloud multiplies the number of opportunities for establishing such connections.

This inherent complexity endemic to virtually all enterprise IT shops complicates the DevOps story. Instead of simply focusing on revamping development teams, now the CIO must consider on-premise vs. Cloud-based development as well as on-premise vs. Cloud-based deployment, and then how to integrate the whole shebang. In some cases, IT shops will have traditional on-premise development teams chucking code over to on-premise deployment teams while at the same time building Cloud-based development/deployment teams that follow the DevOps model. In other cases, some development will take place on PaaS in the Cloud for deployment on-premise, or conceivably some development will be on-premise for deployment on IaaS. If you’re confused at this point, you’re not alone.

Depending on the types of development and integration challenges your shop faces, therefore, you may find a different org chart to be in order. For example, you may have a traditional on-premise app dev division coupled with a traditional ops division, now supplemented with a DevOps-based Cloud portfolio division. Or if your organization is able to bring DevOps to on-premise development and deployment, then you might have an on-premise DevOps division to go along with the Cloud-based one. The bottom line, however, is that all these organizational models are as yet unproven. Only time will tell how many times we’ll need to shake up the IT org chart before the dust finally settles.

The ZapThink Take

Over a year ago, we pointed out that we were entering DevOps’ “golden age.” The automated self-service capabilities of the Cloud (in particular, Public Clouds) are driving organizations to rethink how they handle operations, while at the same time empowering developers and testers to provision IT capabilities for themselves. In the enterprise IT context, however, the story is necessarily murkier, as there are so many moving parts to existing legacy environments.

One important question remains: will DevOps gain traction in traditional, on-premise development/deployment environments independent of the move to the Cloud? Or will such environments remain stuck in the IT governance dark ages until such time as anything and everything moves to the Cloud? The answer to this question circles back to the personal considerations of the individuals involved. Which is better, to resist change when change isn’t mandatory, or to take a page out of the Cloud’s developing organizational playbook to shake up traditional IT, even before you move to the Cloud? To answer a question with yet another question: is the current way of doing things working for you? If not, then you may want to consider the move to DevOps independently of your decision if and when to move to the Cloud.

Image credit: Hobbies on a Budget