RedMonk's James Governor Brings DevOps Progressive Delivery to Light

RedMonk's James Governor shares his insights with Sacha Labourey on progressive delivery in DevOps and how IT can let the business side of the enterprise roll out software and services at their own pace. But first, listen to one of the funniest stories from Sacha's and James' history at an industry event. Who has the better recollection? 

Sacha Labourey: So welcome James on this episode of DevOps Radio.

James Governor: Thank you.

Sacha: And so we're at the DevOps World | Jenkins World in Nice. Nice is a pretty ugly place; the weather is horrible.

James: It's terrible, all those palm trees.

Sacha: Yeah, yeah. So what I think we should talk about before we talk about all good things DevOps is potentially talk about the past because there's some pretty funny stories. Sometimes we talk about them but we never fully did our coming out on this one so maybe now is a good time.

James: Okay, well it was – it's a moment that's sort of pretty much burned on my mind and I think what's interesting is when I met you maybe a couple of years ago back in London is that your memory was not the same as mine.

Sacha: Which is even better.

James: And so we'll see how much you embarrass me now. But this was JBoss's first European customer event. And you know you had lots of high-profile, different kinds of organizations, telecos, maybe the military was there, financial services, and so on and I think you wanted and outside view from somebody who understood open source and was going to be able to talk to the customers about open source not necessarily being a huge risk. And you know certainly here we were looking at customers that were spending a good lot of money on WebSphere and WebLogic and JBoss was very interested in going after some of that money. So you invited me to do the event and this is the bit where my memory is coherent but you say it may have been slightly different. So anyway, I show up and I'm ready to go and I'm doing my talk and I was talking about the difference between distribution models and revenue models in open source. You know this is something at the time we were still all very much in the process of working out, JBoss had come out very much in terms as a training in terms of the revenue model and then the certification came along afterwards. But I was talking about the fact that there was a decoupling and I said, "Well look, it's like this with open source: Suppose you're Marc Fleury, you're JBoss. Maybe you want to have everyone on the planet using JBoss and then you can worry about making money from that later." I said, "I don't want to put words in Marc's mouth." From the back of the room, "No, especially when you're talking hogwash."

[Laughter]

And I just froze and you know I think some blood appeared in my head and I was blushing a little bit just trying to work out where to go and how do we recover from this situation and I was –

Sacha: Mayday, mayday.

James: Probably doing a little bit of bluh, bluh, bluh, and then Bob Beckel, who fantastic, fantastic guy, was he at Bluestone?

Sacha: Bluestone, yeah.

James: Bluestone, some HP thing in there because Bluestone I think was acquired by HP and he was working with JBoss, he just – he sort of came up to the stage, "I think what Marc meant was…" and I just was still and Marc was standing there in an absolute fury and rage from the back of the room and that was not my finest moment as an industry analyst.

Sacha: No and so what I remember I got the other side of the story.

James: This is where it's going to get embarrassing.

Sacha: Well so what happens is – well first you have to know that – well we all know Marc and he has these moments of extreme passion, let's put it this way, and he was not quite fresh that day I'm afraid. You know he had gone out with some salesperson and potential customers the night before so you know he was – he was tired probably that morning. And what was surprising I think to a number of people at JBoss is you arrived and you were taking notes but you were working I don't want to say in real-time but it felt like you were really making up your mind, listening to people presenting because you were talking after Marc and after each customer had presented their story about what they do with open source, right? So you were listening and you're good at that; I know that now. You're good at listening to things and you can make a nice synthesis of what was discussed and create a narrative, right? Except we used to have those customer advisory boards in the U.S. where we would invite analysts like Accenture and Forrester – well not Accenture but Forrester – and they would come with pre-made method, already very structured you know the traditional way. And you were kind of crafting a few slides as we're talking, taking some notes, and so on and then you step up and you make your pitch and I think this was very disturbing to the team because it's like, "What's going on? Is he even prepared?" and that's when I guess Marc interrupted and made that comment. I think you were not feeling great. What I can tell you is that all of the customers around the table were not feeling great either. They felt between a rock and a hard place and they were like, "What's going on? What is this? What is this?"

James: Well I'd never seen anything like it because it's really quite an amazing thing because you were paying me a significant amount of money to shout at me and it was – no, it's funny. I may have made a couple of corrections to the slides but I'm pretty sure I didn't come with nothing.

Sacha: Yeah, well that's the funny part of the story, right? But so this story has a follow-up because a few years after you did an Internet of Things conference right, and you still operate maybe one?

James: Yeah, I think we're going to do it. In fact this year we've had a couple of issues and it's a little bit delayed, but yes....

Sacha: Yeah and so we were talking and I told you, "Well, maybe you should invite Marc," because Marc had created Open Remote and was doing some cool stuff in that space, plus it's open source so that could be a good thing. And you told me, "Well, do you think it's going to work because of what we know?" And I'm like, "I'm pretty sure that Marc won't bother. If he's able he's going to be happy to do it." So I said, "I'm going to try," and so I call Marc and say, "Hey, would you be entrusted to attending this conference?" and he said, "Yeah, yeah, why not?" And I say, "Well the only thing is do you remember James?" you know this story and he's like, "James who?"

James: Oh okay.

Sacha: He had no freaking clue and he absolutely remembered nothing of that story.

James: Okay, well I certainly have. I've remembered it for many years and yeah, it's quite a thing. I mean I think in the long run, I mean once you've had that happen to you you can deal with a lot of sort of stress on stage.

Sacha: Yeah.

James: It's pretty amazing because it really was, "No, especially when you're talking hogwash." I mean I think even the fact that Marc knew the word hogwash was...

Sacha: I learned that word that day.

[Laughter]

James: Well anyway, so I'm doing a keynote in a couple of hours and I believe it's going to be very light on the hogwash and the slides are all in place. I'm not writing – but I may well address HSPC on stage because they're here, they're doing some really interesting work in the spaces I'm talking about, so yeah. But in fact, they were on my slides before I knew that they were here.

Sacha: Nice.

James: I'm not just making it all up. Wait, I just have to make some slides.

Sacha: Yeah. So one of the concepts that you're talking about that I think is pretty interesting is progressive delivery, right?

James: Yes.

Sacha: And it's not that it's a new concept per say but it has the advantage of creating a name around the concept that a lot of people cannot talk about but it's fuzzy; it's not clear, right?

James: Yeah.

Sacha: And we mix up names of technology in-between and so on so we tend to forget what's the big idea, big picture. Can you talk about that?

James: Yeah, so I think from my perspective I look at, you know you're always interested in the moment I think in what's the bridge between sort of the enterprise customer and some of them are very advanced, but really the bridge between the enterprise customer and what we're seeing from the web companies and the way they behave.

Sacha: Right.

James: And the enterprise wants to become more like them. You know we want to – and possibly over-rotated a bit but we want to be like Netflix. We want to be doing multiple production deploys a day or at least be able to, at least be able to think what that could look like. And I just felt there is a basket of approaches more so than technologies, although I'll get to how we implement them in a minute, that we see very much from the web companies in terms of how they do things. So being able to do experimentation across a particular subset of the user population to me is a really interesting idea. So you could do A/B testing where obviously you've got a couple of different options and you decide what you go with. They use strategies like blue/green where you take two environments the same and start gradually cutting over some of the traffic from a network perspective to the new environment until finally all the traffic is there rather than just turning to the new deploy and everyone has the new experience.

Sacha: Right.

James: Canary-ing, another one, you take a very small subset, and I mean the organizations that are doing this in a very sophisticated fashion are able to say okay – so I was talking to Microsoft and in fact the progressive word came from a discussion with Sam Guggenheimer who's on the VSTS team and he talked about they do progressive experimentation so that's where the progressive in progressive delivery comes from. What's the blast radius? Let's roll this out to our employees before we roll it out to our customers and see what that experience is like. So it was basically trying to think about a way of talking about this and then I think the other implication once you realize you've got the technical capability of doing that is that has some interesting – oh, the other one I shouldn't – feature flagging would be – the other one, feature toggles, moving between two tickler options, pulling data back, I began to ask myself, "Well if we can do this what does that say about the interaction between IT and the business?" because if we're decoupling deploy from release then suddenly you're into a different sort of world. I talked to Comcast, 30,000 customer service agents, they don't want to roll out a new application immediately to 30,000 people because they have to train them first. But what if they could – you know they should be rolling out the application on a staged progressive way to the user population as they teach it and I think having – we grew up Sacha in a world where IT was always the slow people. It's always our fault that the new business feature hasn't been implemented. But as we get better and better at writing software actually progressive delivery is about saying IT can just get on with it and then the business can decide when it wants to roll out the new service and activate it.

Sacha: Yeah, what I like about this is that DevOps keeps talking about how this is not just about technology, right, and not just about IT. If you really want to have an impact you need to have this feedback loop to the business; otherwise you're just creating a black box that's more efficient but it's still a black box. So you have an IT machine that spins faster but who cares?

James: Right.

Sacha: It's not impacting the business. And here what you're talking about is how can we also involve the business and the users essentially are not just the developers and QA and product people; the users are the actual consumers of the service and you make them part of the release process, right? They become part of your 'pipeline' in some fashion and you can decide whether it's the right time to further expand or roll back but they become part of the equation as first-class citizens.

James: I think that's really important and you know we spent years on all that sort of crazy iTell stuff and you know in a world frankly where we were so far removed from being able to do that. We're going to have – it's a three-year IT project and we're going to get every requirement from the business, then we're going to write everything down in a 400-page document that we send offshore to an external SI or outsourcing company to build the thing and we were sort of talking about alignment but doing a really bad job of delivering it. And I like what you just said there about it's not enough to just spin the IT wheel faster; you need to make sure that you're – this is a kind of new way of aligning the business with IT and that's I think one of the things that is potentially exciting about – and we may come up with a better word. I just don't know what the word is. We don't like to make up terms at RedMonk but until someone comes up with a better one that's the way I'm going to talk about this, I think useful issue.

Sacha: Yep, that's really cool. Actually, we came at it from a different angle at CloudBees. You've seen the keynote on Wednesday and we talk about the continuous economy and we pitch how continuous delivery it great. It means you can continuously reshape the value of your company. If you have new features in production it means you are different every time a new feature hits production. But if you don't leverage this as an organization to leverage those advantages, those changes to impact your business model then really it's just a black box that happens to be more efficient at aiming for the center of the target, right? What you want is leverage. Tesla is the perfect example of that because they're not just releasing continuously software. They're saying, "Hey guys, you should buy my car because it's going to be self-driving or it's going to be providing that." Do they have it today? No, they're selling on premises, right, but it's a very powerful tool they're leveraging. This week Audi was saying that they're going to postpone the release of the e-tron car because they have to make some software updates and it's going to be delayed by a month. I'm not sure Tesla would have slowed down the release of a new Tesla car by a month because they have new software to update.

James: No, I don't think they would.

Sacha: Right. That's the business model that got impacted.

James: I think that's exactly right and when we look at – I mean in some ways this is nothing new. I mean in the software business that was absolutely how Microsoft addressed markets. They never had the best thing in version 1 but it was usually pretty good by version 3.

Sacha: 3.11 was actually...

James: 3.11 was actually – those were good times; I remember it well. So yeah, but actually I think that Amazon today reflects some of that. Amazon services stand up but they're not fully realized and over time they have – the approach is continuous economy, continuous delivery of new functionality. And I think that that's what's interesting about the parallel that you make. I mean Tesla, a very software-driven business, it's like a software business with a really good battery on the side.

Sacha: Yeah.

James: So but I think all businesses are asking themselves – I'm a little bit wary about this everyone should be a software company because I don't think that's true. But I do think that everyone should be a tech company and yeah, I think that Tesla is – that's a really interesting example of that.

Sacha: Explain the difference between tech versus software. 

James: Well I mean especially given the era we live in where there's so much software that is open source, we've been through some eras of value and certainly at the moment if you're Netflix or Comcast or Capital One you're now making open source contributions. You know you're not of the obsession that every single piece of software that you write needs to be kept inside, neither do you want to support and maintain that as a business. I mean you know Netflix doesn't want to have a business selling Chaos Monkey but they think there's a value to them in open sourcing it. It's really hard to be a software company. What we see is software companies are actually saying, "Oh wait a minute, SAS model, we want to be a software and services company, more broadly a software and services and data company." I think it's just a bit reductive to think of yourself as a software company because software company has various specific things associated with it that are hard. I mean you want to leave being a software company up to an expert like Sacha Labourey, right?

Sacha: But so you're thinking – when you mean software you actually mean a software company would be proprietary software. You mean as soon as you do open source you might not be a software company anymore?

James: No, it's not that. It's more that as we've seen software companies being worried, you know MongoDB changing the license.

Sacha: Yep.

James: We've got this sort of Bain Capital commons clause thing because everyone's worried that actually it's Amazon is not a software company. Amazon is a services company, right? So they write software but they don't sell software. I think software companies sort of sell software…

Sacha: Ah, that would be my misunderstanding.

James: Yeah and selling software is really hard.

Sacha: But if Amazon was not good at producing business values through software they wouldn't have much services to sell.

James: Oh no, absolutely. The software is a means to an end but they're selling services that you run on.

Sacha: Okay, so we agree on that.

James: It's a packaging question.

Sacha: Yes, yes.

James: And so yeah, I'm always very interested in packaging and I think that companies need to not get confused about what their mission is. They should be doing a better job of delivering digital experiences, digital services, taking advantage of the telemetry in their business to create even better services and new businesses, try and turn waste products into real products that they sell to customers, but yeah, I think being a software company is really hard.

Sacha: Okay, that makes sense. So one thing we talked about as well was the fact that we can have pretty much 'unlimited' resources changes the way we can do things. And I was thinking about the A/B testing thing where at some point when we were talking before you were saying, "Well you know some companies if they need 10 of something like 10 PM's they're going to create 100, measure, and take 10; they take only what matters."

James: Yeah.

Sacha: And this – the fact that we are not really limited in terms of resources changes a lot of things like we see testing approaches where you don't really try to write tests to say, "This is how a good application or a working application is. If it passes that test then it's green." But it's more like, "Okay, this is good enough to baseline and as long as we're as good as this then it's fine and I have other ways to measure this good enough." So what do you see on the market taking place right now in terms of a change of perception where engineers are always very focused on doing what's right, it needs to be checked boxes, right, but we're moving more towards the statistical model and being a bit less anal about those things essentially?

James: Yeah, I mean I think that – I think that I wish we'd discussed this one a little bit more before this podcast because now I'm thinking I don't know the answer so it's a good question. You know I mean I think that there are some really interesting meta questions there about what is the nature of quality, what is something that runs, what is something that passes the tests? I think in terms of the mathematical questions that's a very – those set of disciplines, I mean we're clearly seeing them from the likes of a Google or a Facebook or even an Uber. I mean I think my favorite example of like Uber and it doesn't directly get to testing but it sort of does in that what's the stuff we throw away? False positives. The way that Uber decided when they – I think it was their 2nd or 3rd city, the way they decided that they would go to Chicago was that so many people were getting out of – getting out at O'Hare, pressing the button, and finding out that they couldn't get a car. Now traditionally that's sort of the fact that there wasn't something there wasn't something we captured. We didn't know the user experience was broken. They were smart enough to go, "Oh, it's really important where people are and when the experience is broken and that can help us to drive our business forward."

Sacha: Right.

James: So I think that's sort of more – that's not exactly the question you asked but I think it's that kind of thinking about what can we do when we can store so much more data to rethink how it is that we're doing our business planning, new experiences for users and so on. There's a lot of really interesting thoughts on what happens when programming is done by adversarial networks and stuff. That begins to tie into that but I think it's a little bit early in the day. I think that again obviously if you are much like when Yahoo created Hadoop, right? They had a thing, which was how can we make as much compute resource available to our data scientists at any possible given time because Yahoo had a huge number of servers and that's where Hadoop came from; it came out of that question.

Sacha: Yep.

James: I don't think that we've quite got there yet in terms of testing frameworks but the companies that have the most available resource to start doing that kind of stuff are going to be the cloud companies. So that sort of creates interesting questions and challenges for you but I do think a more statistically-driven approach – we're talking about insecurity actually so understanding differences between things, that's a counting – that's a counting issue you know.

Sacha: Right.

James: So I think security testing might be one of the first areas where that sort of thinking really begins to come into its own. Terrible answer.

Sacha: No, no, no.

James: Are you going to tell me I'm talking hogwash?

[Laughter]

Sacha: I'll wait for the keynote to do that from the back of the room.

James: I hope so. That would be – actually it would be okay. I'll be ready for it today.

Sacha: So we talked about cloud, we talked about essentially the benefits of having a critical mass as well, right?

James: Mm-hmm.

Sacha: And so you made a reference before to open source licenses and that's a topic that I know is very close to your heart because you've been in open source for a while.

James: Yeah.

Sacha: I've been also in open source and so what's your take on this protection we are increasingly seeing from companies around trying to protect from those big vendors with amazing critical mass?

James: It's difficult. I mean we are we're talking about smart people who I greatly respect but I am a little bit worried that open source is maybe solving the wrong problem. Here's the thing: MongoDB and Mongo, they became tremendously successful because they were the most convenient. They made things so easy. They removed all friction from the decision/buyer/developer. And you know I've heard people, "Oh, MongoDB, it was because of marketing." No, it wasn't unless marketing is being the easiest thing for a developer to use. They hit that wave it was like we had JavaScript programmers needing a document database, Mongo is so easy to get your hands on, no questions, just get on with it, build applications, and that's where they came from.

Sacha: Yep.

James: Absolutely about convenience and removing any points of friction. So to me when I see them saying that the license needs to add friction I do worry just a teeny bit about that. I spoke to Kohsuke earlier and he spoke about this as well that it's really important that we remove friction. Now that said I clearly remember sitting down with Jeffrey Walker and Mike Cannon-Brookes years ago and Cannon-Brookes said that money, enterprise money, came in how you manage points of friction. So, at last, he had done a pretty good job of that. But I think on licensing Mongo is a good business. It's growing, Atlas is kicking in; we look at them as a successful and excellent business. And so I don't – we're not entirely sure what the implication of the licensing change is. I think in terms of the commons clause that recently came out of Bain Capital I think it's kind of interesting. I mean Heather Meeker has got as much experience as anyone else in the world about open source licenses and everything else but we just look at it as a bit problematical. Some of the definitions feel like we're not quite sure how they're going to look like in court if they're tested and how do you define a business that is driven by software. It gets to our conversation earlier. When is your business wholly or otherwise driven by software value? And if I'm a customer of that and I want to become more like a tech company I might be worried that I might end up in trouble because I was investing in the thing that they're trying to get me to use. So I think anytime you make the customer or adopter a little bit wary, "Oh, if I use too much of it…" I mean at what point am I at what point is my business based on the thing? That's I think a significant challenge. So example: YouTube, there would be no YouTube were it not for MySQL, right because YouTube couldn't have done what they did on Oracle because they would've been more than the world GDP; that was just not possible. MySQL was a great answer to the problem because it took away the question about can we do this. Now, and this gets back again to hogwash, you know maybe you want everybody on the planet to use MySQL and then find some people who will pay you for it, Oracle seems to have built a reasonable business on that, so I just I understand that when you look at Amazon it does seem annoying that they're packaging open source software very successfully and getting market advantage and a huge evaluation and huge revenues than everybody else. I understand that's annoying for people that have worked really hard to build this core software, but I'm not sure that adding greater restrictions and trying to be more specific in that way is really the answer to the problem.

Sacha: Yeah, it's interesting because if I look back in time if you remember back in the early 2000s everything was about open source and when the open core business model came up there was huge defensiveness. It was like that's not true open source, that's not pure open source, and now open core is the new normal and open source feels a bit idealistic and not, not really realistic from a business standpoint. The same is true with licenses. It all started with GPL and LGPL and AGPL and so on and there was this big move to move away from street licenses as such to try to adopt more liberal licenses that are EPL that are ASL and so on. And what's interesting is that now it feels like we're going the other way. We're going back to GPL type of licenses because you could argue that the GPL could be achieving what they're trying to achieve, right? If you look at the GPL normal.

James: That was the intention of the AGPL.

Sacha: Well but even the GPL that's the funny part. If you look at GPL it says it triggers the reality once you start distributing code.

James: Mm-hmm.

Sacha: Well all of those cloud companies actually have subsidiaries in those companies so they're distributing code application from 1 legal entity to another one. So it's – I'm not a lawyer as everybody says even lawyers these days, but it feels like we're kind of mimicking that type of behavior. It can be critical mass, it can be distributing to others, but you want to somehow protect some specific use case where you think they should be paying on it. James: I think you're right and you know then as a question is the pendulum going to swing in a different way or something, but I sort of feel really that in many regards the genie is out of the bottle. I go back to you've got enterprises making open source contributions now.

Sacha: Yep.

James: I think it is the job of tech companies – so maybe it's that. Maybe there just shouldn't be software companies. It is the job of tech companies to package software and services and data in ways that are amenable to customer acquisition.

Sacha: Yep.

James: It's – yeah, you don't want to be a lawyer. You want to be creating great experiences that customers want to pay for and I think that's the – that's our sort of slight concern. We understand at RedMonk and for a while have said that the cloud is a threat to business models of open source companies.

Sacha: Yeah.

James: However, response to the threat I think is do a better job of serving the customer. You know it's interesting I, and perhaps to close or some final thoughts, so, for example, it's interesting you know Heroku still runs on AWS. They feel that they're providing a higher level of value, they can afford to do that, and I mean in fact Salesforce runs on Oracle; they may be slightly more grumpy about it. But I mean these are decisions to make but the key thing is are you creating great services and products for customers, not how do we stop Amazon from using something that we built.

Sacha: So your point is don't fix the license, fix your business model.

James: I think so.

Sacha: All right, thanks a lot James. This was really great.

James: It's great to be here. Thank you.

Announcer: Like what you've heard today? Don't miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz follow CloudBees on Twitter, Facebook, and LinkedIn.

Sacha Labourey

Sacha was born in Neuchâtel, Switzerland and graduated in 1999 from EPFL. It was during Sacha’s studies at EPFL that he started his first consulting business - Cogito Informatique. In 2001, he joined Marc Fleury’s JBoss project as a core contributor and implemented JBoss’ original clustering features. In 2003, Sacha founded the European headquarters for JBoss and, as GM for Europe, led the strategy and partnerships that helped fuel the company’s growth in that region.