Maciag: We're hearing a couple of things. And one of the big things that we've heard in the last year is: How do I get my operations team and my development team more aligned in terms of quick software releases? Because they fundamentally get paid to do different things.
The development guys are getting paid to innovate and turn things around as fast as they can, and we've all seen agile software development take off over the last five to eight years. The ops guys get paid to keep the lights on -- and keeping the lights on means being very careful about the change I'm going to put in my production environment. So how those two things get reconciled is a big concern that people are bringing up more and more? And what they want is more visibility into what's going on in the development environment -- knowing that stuff that gets tested in dev is going to run in the ops environment -- and being able to easily manage the workflow and promotion of those things.
Knorr: The ops side is under a lot of pressure these days, isn't it?
Maciag: Yep, absolutely.
Knorr: What's your value proposition to ops specifically?
Maciag: Our value prop for ops is twofold. Number one, our product allows them to automate the deployment of software. With automated deployment of software, they know it can get done, not in an ad hoc kind of script-driven way, but the same way every time. If it goes wrong, they can push a button and roll it back. The other value prop for them is they get a good visibility into where the software is coming down the pipe and specifically what the dev team has done. They know what version has been built, what version has been tested and passed the test, and which version is ready for deployment.
Knorr: Let's turn that around and ask: What's the value prop to the dev side? And what do you do to bridge the gap? That's what dev/ops is all about. What's the role that you play in that?
Maciag: The value prop on the dev side really is giving people the automation workflow, that acceleration to be able to run their process very fast and to be able to reuse those processes from one piece of software to the next -- and to be able to run it on any platform that they want, whether physical, virtual, or cloud. As the gap gets bridged, what it really is is one set of tooling, one set of procedures, and one set of workflow that can go from end to end.
I think for devops to meet its promise, we can't have different toolsets going on, at least on a platform level, on the dev side and the ops side. This is really the communication platform that they use to get things out.
Knorr: There's communication and there's automation, in terms of being able to reconfigure development environments easily and that sort of thing. To what degree do you overlap with such open source products as Puppet or Chef? Or do you get down to sort of that configuration type stuff at all?