“We’re doing DevOps wrong” – Shippable on the problem of DevOps “automation islands”

SUMMARY:

DevOps is loaded with hipster terminology and adoption debates. Shippable thinks there is a better way. But will easing DevOps integration help us serve customers better?

businessman-tornI’m a sucker for a contrarian pitch, so when I got the “We’re doing DevOps wrong!” email, I couldn’t resist finding out why. This fits into a bigger question: why does DevOps matter in the first place? The DevOps catch phrases don’t help – from “continuous delivery” to “continuous deployment,” (two CD acronyms for different concepts), it’s easy to get lost in the techno-utopian weeds.

If you’re not sold on DevOps, join the club. But there is something to be said for breaking down organizational walls. That “continuous” buzzword can translate into some nice outcomes – if we can automate manual tasks and, hopefully, deliver better experiences for our customers. So what are we doing wrong?

That was the kickoff of my chat with Shippable’s Co-Founder and VP Product Management Manisha Sahasrabudhe. She told me that the roots of Shippable go back to her days at Microsoft with Shippable CEO Avi Cavale. They launched Shippable out of the frustrations that lure many tech folks into DevOps thinking:

Avi and I met at Microsoft… We were pretty frustrated that it took so long from the time developers wrote a piece of code or a new feature to the time we actually got it in the hands of our customers. This was really the driving force of us wanting to do something different and make that workflow much easier and much faster. In early 201,3 we got together and we said, okay, how do we start?

Startup motivations – “There has to be a better way to do CI”

Early iterations of Shippable tackled a piece of the DevOps challenge. They began with tools to support Continuous Integration, (CI), an area fueled by Jenkins adoption. That soon led them to the rise of Docker:

We looked at Jenkins, and we said there has to be a better way to do CI. The first version of Shippable was really basically a CI service, and Docker was open sourced around the same time.

Supporting CI with Docker brought new twists which kept the Shippable team busy for a couple years. But as they built out CI tools for Docker, they ran into more and more dependencies with other DevOps processes and tools. This led Sahasrabudhe and Cavale to dramatically rethink:

We started thinking a little broader, and we said, “Okay, what is DevOps really trying to achieve?”

The DevOps holy grail is automating all the way to production:

At the end of the day, if you do continuous deployment then you make a code change, it goes through an automated set of tasks, and can be deployed to production without any human touching it. At that point you’ve solved all these problems, so that’s the holy grail of DevOps.

But that wasn’t the current state of DevOps at all. Talking to customers and developers, Shippable heard the same refrain: the proliferation of DevOps tools were creating disconnected “islands of automation.”

What happened was a bunch of tool vendors came and said, “Hey, here are some tools to automate your tasks.” We have all these CI tools. We have infrastructure provisioning tools like Chef, Puppet, Terraform, Ansible – all these guys. Then we had test automation tools. I can keeping going…

These tools solved problems, but they didn’t cover end-to-end workflows:

These tools were still helping people only automate a part of the end-to-end workflow. You can’t ship a release with just CI. You can’t ship a release with just infrastructure automation. None of these was really enough by themselves to actually achieve continuous deployment. When people started automating individual tasks using all these tools, they started creating what we call an island of automation within their teams.

DevOps doesn’t scale – and culture doesn’t solve it

It’s the “quick win” problem – starting small is great, but eventually, you run into integration-at-scale. It’s an open source pattern seen before. The Facebooks and Amazons of the world solved this by throwing all their tech resources at the problem. But the Shippable team realized that building your own automation framework was beyond the reach of most companies:

The more we talked to customers, the more we realized that that’s actually a big problem now. We have all these tools but there’s no real continuous deployment anywhere.

Companies have tried to cope with this in two ways: first, by building point-to-point integration between tools (not a viable approach for the long term). Second – and I found this point interesting –  by covering it over in DevOps culture.

In other words, lots of meetings between different teams to iron out the disconnects. I tend to think of culture building as a positive, but as Sahasrabudhe sees it, if “culture” is about being in meetings trying to figure out how to stitch tools together, then we could do with less of that kind of culture. Build culture by solving problems you can’t automate:

When we say “They’re doing DevOps wrong,” we are saying that there’s too much focus on culture, and they really believe that these individual tools are going to get them there.

Shippable had their mission:

What we’re building is assembly lines for DevOps, where you connect all your disconnected islands of automation.

Shippable’s modest employee count (about 25) belies their current reach. They have over 100,000 developers on their platform from about 10,000 organizations (a smaller percentage are paying customers). My big question: with such an obvious problem, why aren’t more people talking about it and more vendors addressing it? Sahasrabudhe thinks it’s just a matter of time:

If you look at DevOps maturity, at the beginning it was all about cultural stuff. There’s been a lot of focus on the cultural aspect of DevOps. It’s kind of difficult for somebody to do the full end-to-end thing right from the start… I think that’s how it naturally just evolved. I just think it’s the next step of the evolution, so if you look at one or two years down the line, I think everybody’s going to talk about this.

On customers – and results

What’s an example of a DevOps disconnect? Sahasrabudhe cited one scenario: when test automation is disconnected from infrastructure provisioning. Perhaps a security patch needs to be applied. Test automation scripts should be updated automatically – no manual intervention required.

So how are customers using the platform?

Some of our customers have taken it beyond what we even imagined. What they’ve done is they’ve created, templates of assembly lines for each service. Then, when any team is working on a service, they take this template, they change some names of variables and things like that, and within ten minutes, they actually have a whole shipping assembly line for their service. That was amazing to us.

One customer has more than 250 services to automate; Sahasrabudhe says they onboarded it all in three weeks. Though it’s only a small, aggressive group of customers using the platform in that manner, they’ve pointed the way, and Shippable will be adding more templates out of the box. Customer results include faster release cycles, less manual intervention, better alerts, and more end-to-end visibility:

Since this is a complete assembly line, they have the information about what other people are doing. They can plan better, for example, because they know that the ops team is doing this, and the dev team is doing that, and this is what they need to plan for.

My take

Sahasrabudhe and I debated the idealization of continuous software deployment. For example, a company running global cloud HR might not want that system refreshed daily, weekly, or even monthly. But where “CD” becomes persuasive is with customer-facing apps, especially in the cases of performance issues, security flaws, and adding new features/sales/content. Frequent daily web site refreshes are a tangible result of a good DevOps process.

I found the critique of DevOps culture interesting. We idealize culture change, but the purpose of automation is to free people up to create new models, not meet to discuss tools that should already be automated. DevOps should help break down silos, not create new ones by fetishizing tools the business could care less about. Besides, tools change quickly, as in the rise of Kubernetes. Platforms that get us closer to plug-and-play are worth a look.

Creating platforms to manage open source tools is a theme we’ll see more of; I recently wrote about this in the NoSQL/database management arena (NoSQL, MySQL, and the database as commodity debate). I believe Shippable is right; this problem will gain momentum. I hope to talk to one of their customers for a closer look.

Image credit - Businessman in difficult choice concept © Elnur - Fotolia.com

    Comments are closed.

    1. I have been in the IT business for 30 years across the world. I believe there is a misconception of Devops. I believe that I have spent ,more than 10 years integrating systems in a continuous integration, build and delivery, but people miss one point. Lets adhere to ITIL, CMMI or ISO standards and have processes in place from conception to delivery regardless what time of day it is. Some believe that going back to SOAP and REST API’s are the answer. Give me a break, that is why I still believe in true SOA processes placed in place correctly and we would not have this muddle.