How many letters in the word DevOps?

[SimonMorris]

Last week I wrote about "Unicorns are cool, but DevOps horses carry a lot of weight", describing some of the conversations I've had with ServiceNow customers in pursuit of a winning DevOps strategy.

In that post I mentioned that it had taken since 2009 from the point of "Technology Trigger"; that moment when a new technology comes into the collective consciousness - to get to a point where customers are demanding more guidance and thought leadership.

DevOps is gaining momentum amongst the "horses", meaning companies that have to deal with legacy systems, entrenched cultures and a lack of opportunities to align their people, process and products behind a DevOps initiative.

And what changed in that intervening period, since 2009? Maturity of tools - enterprise companies require a vendor and partner eco-system in order to deploy toolsets like Puppet, Chef, CFEngine and the other popular ones out there.

Maturity of skills and available candidates. The market is more buoyant with engineers that have experience with DevOps tools and culture which certainly makes the transition easier.

And the maturity of process management and workflow platforms like ServiceNow to tie the whole story together. This is where I am hearing excitement from customers in recent months.

DevOps has 6 letters... so why does Dev get all of the attention?

In my opinion there is an imbalance in peoples thinking about DevOps that is weighed towards the "Dev" part of the equation. Theo Schlossnagle says that "DevOps is incomplete, is interpreted wrong and is too isolated". In fact he recommends renaming the movement to ^(?<dept>.+)Ops$ (that screaming you can hear is a marketing executive somewhere wailing into his keyboard). Theo is recommending that DevOps needs to incorporate operations across the whole of the business behind the goal, and not just Dev behind Ops.

MarketingOps, SalesOps, HROps (PeopleOps?), FacilitiesOps (MopOps??). You can see where he is aiming.

Here ServiceNow is perfectly placed to provide platform capabilties across the whole business, with applications for HR, Facilities, Legal and Marketing, but for this blog post lets stay focussed on Dev and Ops.

The Development part of DevOps gets more attention in the conversations that I have with customers. Is it because development teams are "closer" to DevOps because the Agile methodology is so pervasive? Or maybe because IT Operations teams are stereotypically more resistant to change? Answers in the comments if you have them please.

IT Operations is a good starting point

Certainly a lot of the focus seems to be on optimizing the release process so that applications are deployed into production more easily. After all that was the original promise right back in 2009, the technology trigger presentation of 10+ deploys a day at Flickr.

The Application Deployment value chain is the main focus for customers when they start to think about DevOps. How to minimize the time it takes to release software or how to maximize the quality of the release, with improved testing and the ability to rollback to a known working state.

One point I make to customers, and one of the main messages in this blog post, is that the Application Deployment value chain is only part of the story, although obviously an important part. You can't have frequent, high quality releases into your environment if that environment isn't predictable and repeatable. There is a lot of emphasis on the Environment Deployment value chain in those two attributes, and it's firmly in the world of IT Operations.

In the past few years ServiceNow has invested heavily in tooling useful to Development teams. The Demand Management, Scrum Process Pack, Visual Task Boards, Project and Portfolio Management, Project workbench and Test Management are all aimed at smoothing project delivery, and are great components to building a winning DevOps strategy.

But key capabilities of ServiceNow are overlooked in the DevOps thinking of new practitioners. Deploying the application is almost a preoccupation if you don't have solid delivery of the infrastructure environment. If you need to deploy 100 new Linux servers to support a release and you need all of them to be built the same (exactly the same) can you do it without an orchestrated, automated infrastructure?

If you need to deploy a MySQL configuration change to all of your database servers ahead of a code deployment, and a key part of the improved DevOps quality is the ability to rollback to a known good configuration the answer can't be manual configuration.

The conclusion here is that ServiceNow has moved ahead of the pack in the past few releases with it's investment in tooling to support the application specification, build and test. But a huge part of the challenge in DevOps is the automation of the infrastructure and it's worth checking out the advancements in ServiceNow workflow, especially with the add-ons for VMWare provisioning, Puppet and Chef.

Our tooling allows you to define graphical workflows that can deploy servers into the Amazon cloud, and then send configuration via Puppet or Chef to define the right configuration. These workflows tie into CMDB configuration data, system approvals and the single system of record to ensure traceability.

The ability to reliably deploy infrastructure changes is a precursor to reliable application deployment in an organization pursuing the DevOps promise of more frequent deployments with higher quality.

Luckily ServiceNow has you covered for that too.