Codeship’s Mo Plassnig Talks Cloud Native with Charles Betz and Jeffrey Hammond of Forrester

Andre Pino: In this episode of DevOps Radio I'm joined by three very special guests; Jeffery Hammond, vice president and principal analyst at Forrester Research, Charlie Betz, principal analyst at Forrester Research, and Moritz Plassnig, founder and former CEO of Codeship. Gentlemen, welcome.

Jeff Hammond: Nice to be here.

Charlie Betz: Good to be here.

Moritz Plassnig: Nice to be here.

Andre: So one of the things that has shown a great deal of interest in the market is cloud native for DevOps and for development, software development. So the idea that a developer or a development team can very easily and simply get the services that they need to do their continuous integration, continuous delivery in building their software project out.

Jeff, you cover a lot of the developer trends. What are you seeing in this area?

Jeff: Well, in some ways this is a natural evolution of where we've come out of core development services, and when I think about, you know, 10 or 15 years ago when you'd want to do software change configuration management you'd have to go find somebody to set up the server and maintain that server and you'd have an administrator to maintain that server onsite, and then we got, you know, SCM as a service. We had CollabNet and then we had GitHub and we had Bitbucket and those sorts of things, and all of a sudden from a developer's perspective I never had to really worry about my repositories getting corrupted and there wasn't an administrator around to be able to help me do things. And I think one of the reasons that we've seen a lot of devs move toward DBCS in general and hosted DBCS solutions in particular is because it lets devs do what they want to, which is spend less time dealing with infrastructure and more time writing code, writing code that solves business problems.

And so if we extend that – what's after SCM? It's build. What's after build? It's test. What's after that? It's deploy to production. Why wouldn't you want to begin to take more and more out of that – of that out of developer's hands? We survey developers on a yearly basis and one of the things that we see is that devs don't get to spend as much time writing code as they might like. In fact, we see that about 30 percent of developers say they spend at least an hour a day either deploying code or configuring infrastructure.

What's the value in that, from a business perspective? Why couldn't we start to, you know, ram that down so that it's 20 minutes or it's 10 minutes or it's even 5 minutes? Because when they want to push, they just push. And so I don't see how you do that without really providing that on a service basis and making it as easy to do as setting up a VM inside a cloud or setting up a container. So this feels very natural to me.

Andre: So, Mo, this is something that you've experienced firsthand, having started Codeship over five years ago. What can you tell us about, you know, the adoption patterns that you've seen around it?

Moritz: Yes. I think it's interesting. When we started – and that's now five, six, seven years ago – I think we back then had this assumption that as a developer you really don't want to spend any time on something else than developing software and creating features, writing code, create a product with value for your customers, and it's good to hear that you see actual data behind that because for us it was always – it was our own maybe gut instinct and we knew a lot of people that struggled with it. But it's great to see that in the data because I believe for especially larger development needs it's a big waste of time if the developer spends an hour or even more per day not writing code – and writing code is what creates value – so where we were coming from is, we said, "Okay, we really need to minimize the time the developer needs to spend on anything else," and that's only possible through automation.

So it's not just about I think having the right tools, because I think there are now a lot of tools compared to five, six, seven or ten years ago. It's not just about having the tools – I think there are too many tools nowadays – it's really about how do all those tools integrate with each other and can you get to the level of automation so that the developer spends less time and not more time, right? It will be interesting to see if maybe the time – like maybe they spent 90 minutes a couple of years from now.

Jeff: It's a classic cobbler's children problem. It's like it takes so much time for me to automate the pipeline –

Moritz: Yes.

Jeff: – that I never automate the pipeline.

Moritz: Exactly. [Laughs]

Jeff: And so I spend more time than it would've taken me to automate the pipeline.

Moritz: Exactly.

Jeff: Yeah. You just – it's a shame.

Charlie: That was the subtitle of my book, making shoes for the cobbler's children.

Yeah, it's true. And then, of course, you then have diversity in larger organizations, you have people actually sourcing for good reasons, and they're being autonomous and they're, you know, inventing locally, and then all of a sudden you realize, hey, I have five different continuous integrations and deployment pipelines I need to rationalize and at that point I think it really does become a pretty compelling conversation. It's like, okay, where's the value add? And having five and not, you know, one, maybe two but, you know…

Jeff: Okay, I'm gonna test you on it.

Charlie: All right.

Jeff: That's the EA in you coming out.

Charlie: It is, yeah.

Jeff: You have to move toward standardization.

Charlie: Yeah.

Jeff: And I understand why that's a classic thought, because you don't want, you know, five separate vendors that you have to deal with and, you know, all the licensing and you have five different servers–

Charlie: Yeah.

Jeff: – to support those things and different administrators and that sort of thing.

Charlie: Yep.

Jeff: One of the things I think you can have in a hosted world is you can tolerate a little bit more of that flexibility because you're not paying for the upkeep, you're not necessarily paying for the administration, you're not paying necessarily for the configuration at least as much, and so the cost of aligning a pipeline with a platform can potentially be a lot less onerous and I think that's one of the things that's gonna become more important in the cloud world. Because as we start to see a certain number of platforms – AWS, Azure, Google, Cloud Foundry, Alibaba – you know, there will be some value in integrating with those platforms from a developer perspective, and whether or not, you know, one tool can do it all is gonna be I think an open question.

Charlie: Oh, yeah. No, I'm no fan of mono cultures and, you know, the quest for one throat to choke can quickly become the one throat that starts choking you.

I like to have a – you know, but when it's, like, 10 or 15 – when it's crazy – but we're here to talk about Codeship.

Andre: So let me ask you a question. How did you at Codeship sort of strike that balance between opinionated and flexibility? How did you determine what to – what things would be rigid and what things would be flexible?

Moritz: Yeah, to be honest it's very hard.

I think it's an ongoing quest and it depends a lot on the customer, on the size of the customer, and on I think for us, we think that flexibility and customizability comes with a lot of overhead sometimes. We see that a lot of our customers are – they are getting more sophisticated but then there are also a lot of customers that don't want to be able to do everything. They come to us and they want to get a solution that forces them to a certain degree, to apply certain best practices and follow a certain workflow because they don't necessarily know how to do it best and they've heard of 10 different ways and maybe different development teams doing it in a different way and they come to us for that solution. So I think it's hard. So what we try to do is we try to be opinionated and give the people that don't necessarily know how to do it basically a template or dictate the way how they should do it, but then if you have a very experienced team that's already practicing continuous delivery for quite a while then it's very sophisticated and there's a lot of automation, then they should be able to still customize and do whatever they want and to implement their own workflows. So we always look at like what's the level of sophistication the customer has and then we take it from there.

Jeff: I think that's a very important point because the professional developers, the, you know, kind of the alpha devs, if you will, really demand transparency. They want to understand what's going on. So as long as you are prescriptive while being transparent you kind of balance the needs of the help me learn how to do this with let me push it to the limit.

Moritz: Yeah.

Jeff: And it becomes really important as part of, you know, templates and extension points and APIs and plugins as part of an overall strategy from a tool perspective.

Andre: So, Mo, as you created these guardrails, let's call them, that would keep developers sort of in line and but moving very fast, what were some of the areas – the flexibility that those developers were asking for when they did want flexibility?

Moritz: That's a good question. I think the first area is always the build and deployment pipeline. I think when we talk to 100 different customers they probably give us 100 different answers on how they want to do things.

It heavily depends on what other tools they're using. I mean there's a big difference if you use something like Cloud Foundry or you use a certain Amazon product or you're using Kubernetes, so I think it depends a lot on that. So that's sort of an area where the customer wants us to give them flexibility. But then again, ideally there's still if you don't know then do it in that way type of scenarios where we tell the customer how they should do it if they don't know it. I think the other area where it's getting really interesting is data and analytics and everything around matrix, and I think there's also interest in when it comes to – I think it's good that the developers should have choice and if there are different development teams that they should be able to pick different tools if those tools do the job better, but then there's one person in the organization that really wants to know, like, where are all those applications, what's been deployed, what isn't deployed, like, how f fast are those things moving? And answering their push I think is very, very hard or even impossible right now across different tools.

Charlie: Right.

Moritz: And what we see people then doing is maybe and they build their own analytics around it where they extract data out of all those tools, and I think that's also not the solution. So I think the industry still needs to evolve a little bit with our product and I think it's really a hard question to answer, like, what should live, for example, inside Codeship? Should an analytics product around the build and deployment pipeline? Should it be features that live inside Codeship or should it be an external tool and then you can log in and out of tools, you can log out of tools in the market so that you really get the overview of what's going on. I tend to say that it should be an additional product versus all built into one.

Andre: Charlie, from an enterprise standpoint, what's the data telling you about this trend? Do you see it as a major trend within enterprises?

Charlie: The trend – so clarify for a moment what you mean by this trend.

Andre: The trend towards “as a Service” offering for continuous integration.

Charlie: I don't know that we have data on that right now. I mean I think that there's going to be questions about how do we make this work in on-prem datacenters and you've got, you know, questions about, you know, having the management control over the network and getting into a conversation with networking and firewall teams real quick here. I imagine you have that conversation frequently. And on the other hand though, there's a strong case to be made that, you know, is this really a value-add? You know, is it really stitching together your integrations between source and build and all the rest? And if you've got a turnkey solution that will just work, you know, I think that people are going to be looking at that very carefully.

Andre: Well, let me try from a different angle.

Charlie: Sure.

Andre: So we talked earlier about centralization and, you know, consistent set of tools and so forth.

Charlie: Right.

Andre: What do you see happening in the enterprise? Do you see this centralization of here's how we're going to do CI and CD and here's the tools you're going to use, versus do you see centralization with some flexibility out at the project level versus the wild, wild west where projects can do anything they want?

Charlie: There's gonna – there's still gonna be variation for the next five years or so. There will be – as people scale up – it's simply – it's a natural conversation. You have innovation at the edges – people try a lot of stuff. The stuff that goes well starts to become sticky, it starts to gain momentum. People start to attract – become attracted, and then you – and then the stuff that doesn't work tends to fall away. Then at some point you get into a conversation and the CFO gets into a couple conversations and the CFO realizes that, hey, if we can consolidate from three to two, I can get better vendor leverage and this is no longer a trivial amount of money. I mean having a – the costs of an overly diverse supplier base have been a thing in business for about 2,000 years maybe.

You know? Not to mention we didn't talk – I wasn't gonna mention this – back to one of your comments – is this thing called security attack, and the more products you have the bigger your attack surface. So there are these structural pressures, and the pressure for innovation is there, and if you standardize prematurely you're at risk of shutting down innovation. If you impose the wrong toolset on an innovative team then you might start incurring this thing called cost of delay, which is a very, very important next generation metric in the DevOps and Agile communities. It comes from a guy named Don Reinertsen whose thought kind of underlies most of what we're talking about – but most people haven't heard of Don because he talks math and stuff like that.

Jeff: Yeah, I'll play the counterargument here, the risk of over standardization here.

Charlie: Yes.

Jeff: Is…

Andre: As we would expect a developer to do.

Jeff: Yeah, exactly.

Well, you know, if I'm building Swift, you know, is it gonna help me in that world? If I'm starting to do serverless and I've got some Python functions or I've got some Node functions, is it gonna support those as part of my building chain? If I'm doing AI and now I'm starting to write in Python or if I'm starting to write in R, you know, is it gonna support that or do I need a different supportive sort of code pipeline?

I only see, at least for the next 5 to 10 years, the language surfaces that developers are working in getting more varied instead of less. You know, JavaScript may be the one language to rule them all, the outlier, but I see a lot of new language workloads coming in and continuous delivery tools are gonna have to support those in that cloud environment.

Charlie: Yeah. And that's fair. I would not – yeah, you're absolutely right there. But at the end of the day, if it's all represented as text can we at least get to one source control tool?

Moritz: Are the different technologies really the problem or is it still the people at the end of the day, right? I think technology-wise, is it serverless or is it monolith or is it microservices? I think that's the easier part to figure out, at least when we talk with our customers. I think they're pretty strong on the technology side and I think we as a vendor can provide a great product for that, but then looking at workflows I think the workflows are trickling up because of the technologies that are involved but, right? And data is I think where the industry is falling behind, then it's simply hard, right, to standardize all those teams around.

Jeff: Well, like for example, in the mobile world there's unnecessary part of the workflow that includes vendor approval –

Moritz: Yeah.

Jeff: – for the IPA or the – you know, the APK, and you just can't get around that.

Charlie: Yep.

Jeff: And so you gotta make sure that that's part of your workflow and, you know, if you're automating testing, you know, is there an X unit for that particular language or else do you have to go find something else because, you know, there's no support for Python or for Rust or something like that. You could argue, well, then we should just get those languages out of there.

Charlie: Yep.

Jeff: But, you know, there is some value to the innovation in that language space, especially for something like an AI where there's some real framework that enables some really cool things from a developer perspective and certain types of languages.

Charlie: That would be one of the last areas where I would be running off trying to standardize.

AI and cognitive. I mean, you know, let it – let those skunk works teams do whatever they need to do.

Jeff: But it does, you know, give you a clue to balancing this sort of thing –

Charlie: Yeah.

Jeff: – where, you know, as we start to see similar types of workloads, can we standardize around those workloads? Or when we start to see similar types of workflows, can we standardize around those workflows as opposed to standardization for standardization sake?

Charlie: Yeah, yeah. It is never –

Jeff: And I think that's where you start to get into a good balance of the flexibility that you need to support innovation but also appropriate standardization when it can truly drive that.

Charlie: Agreed.

Andre: And so the other question I have is what's the role of the enterprise architect in all of this?

Charlie: Oh, boy.

Jeff: Oh, you're an EA [enterprise architect] so...

A former EA so you go ahead.

Charlie: Yep. Been there, done that. Well, I think that it's a lot of what we have been talking about and, you know, there's been I think you know, a lot of premature predictions of the death of EA and yet it still is there in a lot of big organizations. And I think that EA has been remarkably bad at articulating its value proportion, but the – and the value proposition can be quantified and it should be quantified along things like, well, what are the costs of supplier diversity in a particular case? And they need to be quantified with the fact that, yeah, sometimes innovation requires it and so you don't just mindlessly shut it down. What are the benefits of when you standardize?

There should be some derivative benefits having to do with having to hire a less diverse workforce in the skills sense, obviously. There should be some benefits with the security attack surface and there should be some benefits that when you have arrived at a platform that works, promoting the reuse of that platform because R&D is expensive and you want to get the teams out of that risky R&D space and into that nice middle ground where they are cranking out the platform features. And I think EA plays a role in all of that but it has – it's really got to reconceive itself.

Jeff: Yeah, I want to pick up on that. There's a model that I like to work with our clients with respect to EA and I call it the community of practice model as opposed to the center of excellence model.

Charlie: Yeah, yeah.

Jeff: And in a community of practice model you go out and you find those emergent best practices and you find those tools that teams are getting success with and you go and you find the data and then you become the reflector for the organization.

Charlie: Exactly.

Jeff: You make sure that those practices get communicated and that opportunities are seized, and I think that EA has an extremely important role to play in that community of practice model.

Charlie: Yep, I would agree. Absolutely.

Andre: Mo, Codeship was recently acquired by CloudBees, and as most people know, CloudBees is a very Jenkins-centric organization. Codeship, however, doesn't utilize Jenkins, so what's the relationship?

Moritz: Yeah, I think it goes back to what we just discussed, right? I think there are different workflows, different technologies, different architecture types, different organizations and because of that there are a lot of different requirements, and so I think there is a subset of the market where Codeship is really strong and then there is a large subset of the market where Jenkins is really strong, so I think we as an organization don't believe it has to be standardized completely because there are simply customers that prefer one over the other and I think that won't change, and so we will continue developing both products and to try to make it easier to use both so that if you know how to configure Jenkins it's easier for you to also get started with Codeship or vice versa. I think there is some overlap where we should make it easier and have a unified experience, but I think it's important to clearly state that because there's so many different workflows and requirements there is a need for multiple requirements –

Andre: And choice is good.

Moritz: Choice I think is very, very good, so…

Andre: Well, gentlemen, thank you very much. This was a great conversation. I think our audience will find it very interesting and something that I'm sure we'll we talking a lot about at Jenkins World this year. Thank you.

Jeff: Thank you.

Charlie: Thank you.

Moritz: Thank you.