devopsy.kinsta.cloud

Tag: podcast

DevOps Chat: Mik Kersten, Tasktop on Value Stream Visualization

In this DevOps Chat, we sit down with Dr. Mik Kersten, CEO and co-founder of Tasktop. Mik besides being the founder of Tasktop, is also the creator of the Eclipse Mylyn open source project. Tasktop continues to lead the way in value stream visualization and software delivery integration.

Mik gives us the latest on this and more in this conversation. Enjoy!

Alan Shimel:               Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud editor-in-chief, and we’re here for another DevOps Chat. Our guest on this episode of DevOps Chat is Mik Kersten. Mik, for those of you who don’t know, he’s almost synonymous with Tasktop. Mik, welcome.

Mik Kersten:               Thank you, Alan. It’s great to be talking to you again.

Alan Shimel:               So how does it feel to almost be synonymous with your company?

Mik Kersten:               Now that you mentioned it, it sounds good. It’s been an amazing journey with Tasktop. I think it’s just been a great now ten years of looking at how to bring those benefits of Agile and DevOps to large organizations. So it feels good is the short answer.

Alan Shimel:               Another one of those ten year overnight success stories in the startup world. Mik, all kidding aside, there might be some people in our audience who aren’t familiar with Tasktop. So, if we can, just maybe a real quick 30 second sort of elevator pitch on what Tasktop is, what it does.

Mik Kersten:               Yeah, absolutely. Most organizations now know that in order to get the up and coming productivity and efficiency that they’re after to be competitive in today’s world, they need to face an Agile toolchain and they need to deploy DevOps and continuous integration, and to do that you pick your issue tracking tools, your continuous integration tools, your release automation tools, and all of those bits and pieces. If you’re a large organization, you pick requirements management tools. If you’re doing any physical products, you need some additional tools for requirements and bills of materials and those kinds of things.

What’s interesting is that once organizations scale up there are DevOps transformations. They’re both hitting more tools and different kinds of partitioners. So the missing piece for making all of these benefits of DevOps work at scale is this piece of integration infrastructure. We can connect up all the tools to get an end-to-end flow, so to get the benefits of Agile and Lean, all the way from business idea to running software and the revenue results and delighted customers.

That’s what Tasktop has been doing. Over the last ten years, by release we’ve been connecting different stakeholders, processes and tools, so that you could have this end-to-end flow of information. So you could have the best of breed tools, the latest issue trackers or Agile planning tools, the latest continuous integration tools and so on, while getting this end-to-end flow, because really the problem that we’re addressing is that when you look under the covers in most transformations you’ll see that both DevOps and Agile have been deployed at these local optimizations. The team can do continuous integration or continuous delivery. Or the organization has continuous delivery, but has not optimized anything upstream, and that’s really the problem we’re trying to solve. Let’s get the entire IT organization to be Lean end-to-end.

Alan Shimel:               Fantastic. Mik, in us talking before we started recording today, you said that the most recent release of Tasktop and the hub is probably the most important and meaningful thing you guys have done in ten years. Why don’t you share with our audience why you feel that way? What is this great functionality and great feature set that came out in this last release?

Mik Kersten:               Absolutely. What we’ve noticed is that the way that – again, you take any large IT shop who has not yet deployed Tasktop and you look at how they support their transformation, and you’ll notice you’ll see all these point-to-point integrations. So you’ll see, let’s say, the Agile planning tool wired in through some APIs or Web hosts or some data integration technology into the requirements management tool, into the time tracking tool, into the quality management tool, into the automated test tool, into this _____ tool and so on.

What we noticed four years ago is that the slave connecting things point-to-point was going to blow up. Once you’re making point-to-point connections, you get this exponential factor. So it’s okay if you’ve got two or three tools. All of a sudden you’ve got four or five tools. Just the sheer number of API calls are bringing down your servers actually.

We know a lot of customers where they say their JIRA issue tracker is getting so many API calls from these integrations that it takes a minute to load an issue. So you get all these weird symptoms.

You also get this thing that’s very difficult to maintain, because as soon as one tool changes or someone adds some new fields to a project’s definition of a user story or something of that sort, multiple integrations break and you’ve got this spaghetti code of Web host and API integration madness.

So we realized four years ago we couldn’t even test all the integrations we’re supporting in that point-to-point way. It was already costing us hundreds of thousands of dollars of resources, of basically VM resources, just to test all the tools we support in a point-to-point based way. So we said four years ago, “We’ve got to stop doing things in a point-to-point way. It won’t scale. We need to support all the Agile and DevOps tools out there, and it won’t scale to supporting large scale DevOps transformations.”

So we started creating this notion of models. First you look to open standards. So we got our feet wet and we on the committee of OSLC, but to get everyone to adopt open standards just didn’t work. And these tools are so complex because the stakeholder tools right now have become very elegant, basically. The developer tools are very tuned to the developer process, and with that comes a lot of complexity specific to developers, to testers and so.

So we realized open standards won’t solve it. APIs alone don’t solve it, but are actually part of the problem. You need to take a different approach. So internally we made this integration factory so we could test everything, and we made these common models. The models are basically the currencies of Agile and DevOps and the ALM and SDLC systems, things like requirements, user stories, builds, releases, security, vulnerabilities, those kinds of things.

That’s how we started testing everything and then we said, “Okay. If you raise the slave abstraction, it actually makes it much easier to connect everything. With last week’s release of the Tasktop Integration Hub, we’re actually taking that model-based approach and exposing it to all of our users. So you simply define all of your models in your value stream, again, like user stories, requirements, builds, releases, chain sets and so on, and then you plug in however many tools you want into those models and you get this amazing thing. You get complete automation for your value stream.

So we’re calling that value stream integration, because end-to-end you can now have these flows and you can actually track things like cycle time, and you can basically get the benefits that a startup with 100 or 200 people is getting in terms of their speed of delivery at very large scales, at thousands or tens of thousands of IT staff. So you’ve got that value stream integration layer that we provide.

With that, you can also inspect what’s going on and you can basically support these large scale Agile and DevOps transformation, all because of the fact that we’ve raised the slave abstraction to make these models, have you map your different toolchain in your models and, as a result of that, what we’ve actually done is we’ve made the toolchain itself be modular. So you can plug in best-of-breed tools Here’s some dot-net. Here’s some Java. Here’s some JavaScript there, maybe some Python for your AI. You can plug all of those separate tool streams together into one end-to-end unified value stream. Really, the key thing that we’ve done here, the game changing thing is this notion of model-based integration.

Alan Shimel:               Excellent. I agree, Mik. You know what? Obviously you work at Tasktop. You’re very excited by what they’ve done. But for our audience out here who are generally pretty sophisticated technologists, I hope they appreciate really the – I mean it’s making people’s lives easier, right. When you can make people’s jobs and lives easier like that, it’s a good thing and this sounds like it could be a real game changer that way.

Mik Kersten:               Yeah. Alan, that’s a thing that’s absolutely near and dear to me. My whole background was from productivity tools, empowering developers and taking the waste out of their day with all the open source work on Mylyn and the dev tools that we’ve done. Our mission was to bring about that change in the way people work at scale, because it gets even worse.

You look at the large IT shops out there, the place where most of the world’s IT staff works, and we’ve measured what they do. Every developer or every tester, every business analyst, they’re spending at minimum 30 minutes, in some cases we’ve seen two hours per day of duplicate entering information for every code change they make, for example, because of all the governance and compliance and other rules which need to be there in large scale organizations, but all of that work is waste and it drives people crazy because they don’t like doing it, because it’s basically manual data entry.

When you think of what it actually is, they’re entering information and logging into different systems, all of which could have been done automatically if, again, we took this value stream-based approach. You make your code change. All that information propagates into however many tools the organization had to set up. You might have to track different kinds of requirements and changes differently. That’s okay.

So the most satisfying thing that we’ve seen with deployments of this, because we actually had customers in an early access program since April – the Tasktop Integration Hub is running in production at customer sites today – is that all of that waste gets taken out instantly. Basically our expectation is that the moment its deployed, and we’ve seen this, your employee engagement scores are going up that week or that month, that quarter, because you’ve taken out all that wasted work which drives the best people in their company crazy, the fact that you’re making them do it.

So that’s our whole goal. The person goal is just make the lives of all those people in IT better by removing all that waste. Then of course the organization economic goal is through that: make your organization more innovative, because you’re now able to deliver at the speed of a startup and get that promise of DevOps at scale.

Alan Shimel:               Absolutely. Mik, we’re running short on time, as we always are on DevOps Chats, but let me quickly pivot to something else I wanted to touch on with you, and that is the idea of the bridge of that job to DevOps or bridge between that job and DevOps. When I first started with DevOps four years ago, maybe more, five years ago, there was, “Well, DevOps really picks up where Agile leaves off,” but they were clearly two separate things. Agile is for developers. DevOps is for everyone.

But what we’ve seen is that DevOps is borrowing more and more from Agile, more and more from Lean. Where do you see the connection between Agile and DevOps, if that makes sense?

Mik Kersten:               It’s by different thought leaders, different vendors and so on. In the end, it’s all the same thing. It’s Lean for software and software at scale. So in terms of how organizations have aligned, I think what has happened is that so much of the bottleneck for software delivery for so many large organizations has been in deployment reliability and velocity and automation. DevOps has formed the big new movement and really picked up as a movement where Agile left off.

In the end, the technology is you need continuous delivery. You need to implement continuous delivery, but the DevOps movement has come from that side, from development and operations and said, “We need to deliver things faster, more reliably, and automate all the stuff that’s manual in their account.” That’s actually shifted and taking over where the Agile movement started, which is we need to track work and be responsive to change and bring customers into the feedback loop.

So there are two key components and I think the sheer velocity that we have right now behind organizations going to DevOps has made it the more important transformation agent. Everything that was going with Agile stays as a key part of the transformation. I think it’s very important for those leaders out there, putting together those DevOps transformations to not stop at code commit.

You have to actually take the Lean fast feedback loop, continual learning all the way into business analysis, design and so, because if you stop you’re going to have to solve the deployment bottleneck, but not the upstream bottleneck. For example, if you don’t have enough UI designers, it won’t matter how quickly you’re deploying. You’ll do bottlenecks on your UI design. You’ll need to higher there.

So I think we all need to take this end-to-end Lean view and DevOps is just a great transformation agent and a great movement to help us all do that.

Alan Shimel:               Good stuff. Mik, we’re coming up to the end of our time. I want to ask you one last question, not a trick question, but I always like to ask if possible. For our audience out there, if you could recommend one book that they read, and not an obvious one, don’t tell us The Phoenix Project or even the DevOps Handbook. It doesn’t have to be DevOps related. What book would you recommend?

Mik Kersten:               I’m holding it up right now. I know you can’t see it, but it’s the book Learning to See by Mike Rother and John Shook. If you even just flip through this book, you’ll see the value stream mapping and value stream integration and management approach that make the manufacturing work. As we go into this post-DevOps, post-Agile bigger picture world, it’s that same view of the value stream, focusing on the end-to-end value stream that I think need to inspire that next generation of leaders creating these transformation.

I think the DevOps Handbook contains a lot of this. It’s a great book. I’m nearly finished reading it. It has a lot of the right sources, but in terms of something that you might not have seen it’s this Learning to See book, which is really about learning to see production. We need to learn to see the flow of software across the value stream and most organizations have not done that yet, and that’s really – our mission is to help organizations do that, but the ideas are here. We’ve done them before. Again, it’s been done in manufacturing and now it needs to be applied to software delivery.

Alan Shimel:               Fantastic. Mik Kersten, Tasktop, thanks for being this episode’s guest on DevOps Chat. Continued success and looking forward to more, and maybe seeing you at DevOps Enterprise Summit in London.

Mik Kersten:               Absolutely. Thank you, Alan. Great chatting with you, as always.

Alan Shimel:               All right, Mik. You be well.

Mik Kersten:               Thank you.

Alan Shimel:               This is Alan Shimel for devopsy.kinsta.cloud.

— Alan Shimel

February 23, 2017
DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

devopsy.kinsta.cloud catches up with Chef’s busy CMO Ken Cheney. Ken give us the inside look at AWS’s OpsWorks for Chef Automate. While this is an AWS offering it is based on Chef and is a pretty big bet by AWS on Chef. In addition Ken brings us up to speed (pun intended) on other things regarding Chef. Ken is always a great person to chat with and full of great info. We are going to have Ken on every month or so, we can count on hearing more Chef and DevOps talk soon.

In the meantime, as usual the streaming audio of our conversation is below and the written transcript of our chat follows. Enjoy!

Streaming Chat

Transcript

Alan Shimel:                Hi, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I am happy to be joined in this episode of DevOps Chat by Chef CMO, Ken Cheney.

Ken, welcome.

Ken Cheney:                Alan, nice to hear your voice again.

Alan Shimel:                Nice to hear from you, Ken. Actually, I think the last time you were on our podcast or the last time we spoke you had maybe just been appointed CMO, or maybe it was even before you were appointed CMO at Chef, but it’s certainly been a busy time for you I’m sure.

Ken Cheney:                Yeah, it has. There’s been a lot going on in the past two months and some of it we’re going to talk about today, the work we’ve been doing with AWS.

Alan Shimel:                Yeah. I think the last time I spoke to you was right before AWS re:Invent, and there was some big Chef news coming down the pipe that we weren’t able to talk about then. It was still kind of under embargo, but it certainly is fair game now.

So, Ken, why don’t you share with our audience what was big for Chef at AWS re:Invent?

Other Great DevOps Chats to listen to:

DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey
DevOps Chat: Huw Price, Smart Automation Is Key
DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps
DevOps Chats: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

Ken Cheney:                First off, AWS re:Invent, a super-impressive show to go to. So if folks haven’t gone, I’d recommend this next year that they pencil it in. But at re:Invent we announced – actually AWS announced, it’s their offering, a new offering called AWS OpsWorks for Chef Automate. It really brings for the first time the full capabilities of Chef’s commercial platform to AWS as a managed service offering. So they provide support and they backup the offering 100 percent.

So it’s a new offering that makes that job of configuring, deploying, scaling, both in the cloud as well as on-premise infrastructure simple and secure. We get there by really doing what Chef has done best over the years, which is automating infrastructure as code.

I think to really highlight what I said, Jassy at re:Invent went out of his way to make the point that hybrid is the new normal in their view. So what’s interesting about what we are doing with AWS is you can manage both in the cloud with AWS as well as your on-premise workloads, and you can have that consistency in how you manage your resources across both.

Alan Shimel:                Absolutely. Now, Ken, our audience may not be aware, but I happen to have known this, that Chef was sort of the dominant tool in use for AWS customers now for a few years; I mean an outrageous amount. If I’m not mistaken, wasn’t it like 65 or 70 percent of AWS customers who use some CM are using Chef?

Ken Cheney:                Yes. A large proportion of AWS customers use Chef, and AWS themselves use Chef for many of their core services. It’s a platform that is really well suited to the job of: how do you get your workloads to the cloud, and how do you manage those workloads on an ongoing basis in the cloud?

Alan Shimel:                Absolutely. And of course, Ken, when we talked about hybrid – I actually had a conversation yesterday, actually with maybe some IBM folks. We were talking about mainframes aren’t going away any time soon, obviously, the mainframe market. It’s probably bigger than ever in terms of dollars.

But the idea of working with your systems of record and systems of engagement, and one is on a mainframe and one is in the cloud, is becoming more and more the norm for large organizations, right?

Ken Cheney:                Yeah. It really is.

Alan Shimel:                Yep. I mean they’re not going to just walk away from billions of dollars invested in mainframes and datacenters, but in order to compete with stuff that lends itself to it, it’s hard to beat the economics of the cloud. So for the foreseeable future anyway, probably the rest of our working lives, Ken, hopefully, hybrid cloud is going to be the dominant form there.

Ken Cheney:                Right. Then if that is the case, then manageability and that kind of consistency in your manageability becomes front and center, and that’s where Chef plays a big role in being that bridge that really allows you to have a platform where you can store those configurations in one place, where your resources are going to work perfectly every time at scale, and you make changes in that single place and propagate those changes across those environments. So whether you’re running under a mainframe environment or you’re doing dev, test, prod in the cloud you get that repeatability.

Alan Shimel:                Absolutely. Before we leave the AWS stuff though, Ken, I just want to, for our audience that may be interested, this is available now, today, through the AWS marketplace?

Ken Cheney:                No. It’s a core AWS offering.

Alan Shimel:                Okay.

Ken Cheney:                So if you’re an AWS customer, you login through the AWS console and it’s one of the offerings that you can select. So it bills through AWS. It’s managed by AWS. It’s supported by AWS. So it’s very easy if you’re an AWS customer to get started, and you can get started for free, up to ten nodes for free per month.

Alan Shimel:                Great.

Ken Cheney:                Yeah. You can get started and get all those advantages.

Alan Shimel:                That’s cool. All right, so people can go check it out right now. If you’re using AWS, it’s a core offering. And I guess that kind of makes sense because it is an AWS offering after all, isn’t it?

Ken Cheney:                That’s right. We’re partnering very heavily with them to make sure it gets the kind of traction and success that we have envisioned.

Alan Shimel:                You know what? That really is big news, Ken. Great job by the Chef people. Give my kudos to the business development guy. He did a hell of a job there.

Ken Cheney:                Will do. Thanks, Al.

Alan Shimel:                Weren’t you the business development guy, Ken?

Ken Cheney:                I was. I’m weird, so –

Alan Shimel:                Yeah, I know, just a little inside Chef joke. Ken, we talked a little bit about hybrid cloud and this new offering at AWS. Let’s look at the bigger picture. Here we are in January of 2017 and it’s not too late yet for – where do you see DevOps in 2017? Where do you see Chef in 2017? What big picture item should we be looking at?

Ken Cheney:                What’s interesting right now in the market is that – you and I both see this, Alan – the market is still very young. I saw some Gartner data where you can extrapolate out that 90 percent of the market is still untouched. Even that 10 percent that has started down the path of adopting is only partially adopting.

Yet what’s very clear, both at an industry level, if you look at industry data, as well as what we see with our own customers, is that DevOps has a significant impact on the bottom line. Companies that adopt DevOps have been shown again and again to outperform their competitors.

Alan Shimel:                Yep.

Ken Cheney:                And I think that DevOps – we’ve been talking about this for some time – but it’s really a full-on move from the early adopters, those organizations who figured out how to be disrupters, to the rest of the market who are being disrupted.

Alan Shimel:                Yeah. It’s DevOps or die, as I like to say.

Ken Cheney:                That’s a great statement.

Alan Shimel:                Yep. Ken, I saw some interesting statistics from a study that CNA had commissioned, 1,700 respondents, and it said something like only 34 percent, so just a third of organizations had adopted DevOps.

Ken Cheney:                Right.

Alan Shimel:                Which to me and probably to you too, right, because how many organizations do we talk to that either haven’t adopted DevOps or don’t want to adopt DevOps? We live in a DevOps bubble. We think everyone does, but yet the fact is it’s only about a third, 34 percent. When you look at it that way, it’s barely mainstream, right?

Ken Cheney:                That’s right. And even those who have adopted it typically adopted it in a small silo.

Alan Shimel:                Right, the pockets of DevOps, as they call them. I continually refine that, Ken. What I mean by that is you’ll have a team – a team – using DevOps, maybe a team here and a team there, but only when those multiple teams come together under a common DevOps sort of processes, framework, manager, whatever, do I really consider the organization doing DevOps. So for me, an organization that’s doing DevOps is doing it with multiple teams.

Ken Cheney:                Yeah. I totally agree, and I think this is the year where we start to see organizations really at an executive level begin to put their shoulder into what that means. How do you actually begin to go automated scale?

And at the same time they’re going through the tech modernization investments around embracing the cloud, embracing microservices, containerization. So I think this is going to be a really interesting year, where I expect many traditional shared services organizations are going to be under a lot of pressure to change.

Alan Shimel:                I agree 100 percent. It goes back to the DevOps or die thing. All kidding aside, if these organizations don’t change you’re going to start seeing them falling by the wayside.

But you know what else I think, Ken, and I’m interested in your opinion on this. DevOps tools have to change, too. They have to continue to mature. They have to continue to be enterprise-ready. They have to continue to deliver and meet the challenges that organizations are faced with.

Ken Cheney:                I totally agree. I think that there’s been a Cambrian explosion of tooling.

Alan Shimel:                Yes. That’s a great phrase for it, a great way to put it.

Ken Cheney:                Yeah. And there’s been a rapid kind of organic team level adoption, but what’s happening is that there’s been a lack of standardization, a lack of scale. When you look at the disrupters who have been wildly successful, and many of those are Chef customers, they have been successful automating at scale. Automating at scale means you do drive consistency across the board.

The path to get there though, from my view, is you have to be thinking about vertical integration. If you look at our strategy, like take what we announced at AWS, that is where we are actually vertically integrating into their platform in a very real, meaningful way. And we feel the same way about the broader ecosystem of _____ capabilities that we need to integrate in with, to make that job of automating at scale easy.

Alan Shimel:                Yeah, agreed. I do think you’re onto something with that, also vertically integrating, but it’s also integrating into the IT stack. For instance, for me and maybe it’s my own personal bias and history, if you look at 2017 as a year where we have to see security integrating with DevOps and we can call it DevSecOps or Rugged DevOps – I don’t really care what you want to call it – but there has to be that tighter coupling, that tighter integration into the IT stack of security shifting left as part of this DevOps.

I know Chef obviously has now some history in trying to bring compliance at scale and compliance in security and speed. But I think that has to accelerate.

Ken Cheney:                Yeah, it does. We are pouring the investment into that set of capabilities. When we look at what our customers are trying to get done, there are things like driving known vulnerabilities down to nothing, being able to remediate in minutes as opposed to days. To get there, that concept of shift left that you put forward is front and center. You have to start thinking about shifting risk to the left.

So we’ve invested a lot in, one, our InSpec open source framework that people should go check out, as well as the overall compliance capabilities, where you can have broad compliance profiles that ensure that the state of your infrastructure and applications is conforming to policy.

Alan Shimel:                Got it. You know what, Ken? You mentioned open source and it triggered something. What’s happening with Chef Habitat, anything new you can share with the audience?

Ken Cheney:                Yes. Chef Habitat has been in the market now for about nine months. We have been seeing a tremendous amount of traction. We’re going to be launching a Habitat road show in a few weeks, visiting multiple cities. So people should go to the Chef website and see if we’re going to be coming to a location near them.

We are really now moving into the phase where we have large enterprise customers moving workloads into production with Habitat, and they’re really targeting that job of: how do I easily encapsulate my applications and manage those applications, in a way that I don’t have to spend a lot of calories worrying about extraneous services and getting true portability out of it, meaning I can move that application workload anywhere I want?

So Habitat is definitely getting legs at the moment. We’ve had some new product news that will hit in a couple weeks, Alan, so you and I will be talking about that.

Alan Shimel:                Fantastic. All right, a little teaser. Ken, to tell you the truth, we’ve gone way over our usual time that we allot for podcasts. We don’t want to take up too much of people’s time, but let me just do a quick recap. For people who want to find out more about Chef Habitat, what’s the URL?

Ken Cheney:                They go to the website, which is Habitat.sh or they can go to the Chef site, which is Chef.io.

Alan Shimel:                Right, and it’ll just run through from there and they can find out about the Habitat road show there. The Amazon stuff you can get right through your Amazon portal or dashboard, if you’re an AWS user.

Ken Cheney:                That’s right. AWS just did a webinar yesterday that was recorded that does a nice walkthrough on it. So they are actively out there promoting it and pushing it for their customers.

Alan Shimel:                And the open source compliance and security?

Ken Cheney:                You can get that through the Chef website.

Alan Shimel:                Also.

Ken Cheney:                Yep.

Alan Shimel:                Okay. I just want to make sure people get it, Ken. Ken, we could probably spend hours talking. We’ll have to have you back on soon, maybe in a few weeks when you have your next bit of news. But until then, keep up the great work. Oh, we should mention ChefConf.

Ken Cheney:                Oh yeah, ChefConf coming up May 20th to 22nd in Austin, Texas. People can go and register today. We’re pretty excited. We just closed the call for papers last night and had a record number of submissions. So it’s going to be a great event.

Alan Shimel:                Cool. I went last year. It was a great event. I had a great time. It was some great content. The Alaskan Airlines was still my favorite, Ken. Actually it got me to fly Alaskan Airlines watching that guy present.

Ken Cheney:                It was amazing, yeah.

Alan Shimel:                It was the first time I ever flew them, and I was counting to see how quickly the door closed and how quickly they opened it, from his whole presentation. It was a great one.

Anyway, Ken Cheney, CMO Chef, thanks for being our guest on this episode of DevOps Chat. Continued success at Chef and we’ll be watching and listening to find out what’s new.

Ken Cheney:                Thank you, Alan.

Alan Shimel:                All right. Okay, everyone, this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening and we’ll see you on our next DevOps Chat.

— Alan Shimel

February 8, 2017
Welcome to the Continuous Delivery 101 Podcast

No matter what industry you’re in or how old your business is, your software often determines your success in today’s application economy.

Applications are the face of your business—both the way it performs and the speed with which you can incorporate new ideas and innovations, driven by the efficiency of your software development life cycle—determines whether your company can survive in this competitive market.

Software doesn’t just support the business today, it drives the business—and your organization’s livelihood in this application economy comes down to your ability to quickly deliver world-class capabilities. As a result, more organizations than ever are turning to the practice of continuous delivery (CD) to improve their ability to plan, build, test and release applications to market.

With this increased focus on continuous delivery methodologies and practices, we’ve established a new podcast that highlights the importance of utilizing CD, along with adoption techniques and other best practices.

Dubbed “Continuous Delivery 101,” the series features some of today’s leading experts in the field discussing where they’ve seen CD success, across some of the world’s top organizations and across multiple industries.

The first episode in this series covers CD fundamentals and the software evolution that has made continuous delivery so critically important.

Beginning in the ‘60s, this first wave of this software evolution saw mainframe systems brought in to automate business tasks. A second wave saw the emergence of ERP/CRM-based processes, so we could improve how we run contact management and transaction processes. Today we’re in the third wave, which started with the widespread adoption of mobile and web technologies, with all of these paradigms intersecting in perfect convergence.

Businesses that have mainframe and distributed systems, that have CRM and ERP system, that have web fronts and mobile apps, are utilizing these continuous delivery tools to innovate faster than ever before. These organizations are being forced to reinvent how they communicate with customers and how they deliver goods and services to stay relevant in the market. This third wave, where business is now driven by IT, is the biggest disruption that we’ve seen.

To hear a lot more on this topic, check out the first episode of the Continuous Delivery 101 podcast via YouTube or the iTunes store, where you can find it on the Podcast App by searching for “Continuous Delivery 101 podcast.”

Software delivery, fueled by CD, is evolving at a furious pace. Stay tuned for more expertise and best practices.

— Scott Edwards

January 18, 2017
DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

Our first podcast of 2017 is with Aruna Ravichandran, co-author of DevOps for Digital Leaders. Of course when not authoring books or helping financially challenged but gifted students attend college, Aruna is a VP of DevOps marketing at CA Technologies. I have interviewed Aruna before on DevOps TV and discussed her career that has seen her go from a million lines of code contributor at HP and Juniper to business line executive.

Aruna is a very interesting person who also has some great things to share. That is why I think you will find not only this DevOps Chat interesting, but her book as well. Also, we will be doing a full hour Q & A with Aruna on January 17th that you can sign up and attend for free. If you like this interview, don’t miss the webinar. Also, if you would like to download the book you can here: http://www.apress.com/us/book/9781484218419

In the meantime, as is usual on our DevOps Chats below is a streaming audio of our Chat with the written transcript below. Enjoy!

Alan Shimel:                Hey everyone, Alan Shimel here with our first DevOps chat of 2017 and we’re lucky to have Aruna Ravichandran, a VP DevOps Marketing at CA Technologies. Aruna welcome.

Aruna Ravichandran: Thank you Alan. Thanks for actually having me. I’m excited to be here with you.

Alan Shimel:                Well, you are leading of 2017 so we’re going to set the bar high right away Aruna and hope to live up to it.

But Aruna, truth be told, we don’t have you on today in your VP of DevOps role: you’re here as Aruna the author today and we’re going to talk about a book that actually came out I guess towards the end of last year but it’s still out there and we’re going to be doing a webinar on it later this month, and I wanted to really talk to you about that a little bit.

The book is called DevOps for Digital Leaders. Correct?

Aruna Ravichandran: Yes, that’s correct.

Alan Shimel:                And why don’t – just from the get-go why don’t you give our listeners a little bit of an overview of what the book is about.

Aruna Ravichandran: Sounds good. So this book is called DevOps for Digital Leaders, it’s all about how one can reignite their business with a modern DevOps-enabled software factory. I embarked on this journey on writing this book almost about a year-and-a-half ago along with two of my co-authors Karen Taylor as well as Peter Waterhouse.

We looked at all the different books within the market – there is no dearth for books in the market when you think about DevOps – but what we saw was that even though there are so many different books in the market nothing really talks about some of the pain points which we constantly encounter customers asking us when we talk to them.

Some of the pain points which customers constantly ask us are, “I want to be able to start this journey called DevOps. How do I start? What should my journey be? Where can I start? How do I develop? What should be my maturity model?” And so that’s one question which we constantly get across the board.

Second pain point which we have heard from customers is, “How do I actually measure the success of DevOps? What kind of metrics can I use? How is success actually going to look like which I can report back to my management chain that whatever initiative I have embarked on with DevOps is now actually successful?”

So we talked to several – over 100-plus customers – we learned from their experiences on what metrics are actually used and what is actually built practically in the industry and shared those in the form of use cases as well as actual metrics in the book.

So the book primarily focuses on DevOps adoption in terms of a journey as well as what are some of the key metrics one can actually use in order to embrace DevOps.

Alan Shimel:                Great. Aruna you hit on a couple things that are kind of near and dear to me. One is something that I’ve spoken about and talked to people now for a while which is too many people – you know, DevOps is so hyped and so many people are positioning DevOps to be, you know, it’s this great, white unicorn that’s crapping out rainbows for everyone but it doesn’t always work like that, right?

There are failures, there are challenges, there are hurdles, and not everyone who just wants to do DevOps can wave a magic wand and become a DevOps factory or a modern software factory. So I’m glad to hear that this is kind of something that you guys are exposing in the book.

The other thing is, you know, in almost three years of doing devopsy.kinsta.cloud now I find that our listeners, our readers learn the most from listening to how their peers have dealt with stuff: so case studies, case scenarios and these kinds of things. So the fact that you had access to hundreds – literally hundreds if not thousands – of customers who CA Technologies – CA has worked with – really gives us some great insight.

Can you give our listeners a little bit of a taste for the kind of – I know you call them case scenarios – and they’re kind of case studies, right? – can you give us a little flavor for what those are like?

Aruna Ravichandran: Yeah, absolutely. So if you look at the book it’s organized across the entire software factory. Let’s say if you think about customer deployments DevOps basically goes all the way down from planning to requirements to development, testing, release, and then into operations.

And so what we did was we talked to – we interviewed several different practitioners who are existing CA customers, sometimes we even talk to non-CA customers – understood the role DevOps plays in terms of culture and collaboration as well as the toolsets which they’re actually leveraging in order to implement DevOps within their companies.

And we looked at – we _____ the use cases around the whole software delivery to the chain. So if you look at the book – even though we talked with several thousand customers – you know, we couldn’t basically put all those case studies within the book, so what we did was we broke up the book across the entire software delivery chain and there is a chapter dedicated for every aspect of the software factory starting from planning to development to testing to release to operation and we leveraged one customer example on how they actually implemented DevOps best practices along with the underlying toolset and what are some of the metrics or the results they actually got in terms of being able to show what success actually looks like.

Alan Shimel:                Got it. So Aruna I wanted to touch on another aspect of DevOps adoption that you hit on in the book, and that is the idea that not everyone started their DevOps journey at the same time or are going at the same speed or at the same rate, right? Some organizations are relatively mature in their DevOps adoption and DevOps practices: others are still talking about starting. So is there something for everyone in the book or do you need to be sort of on-your-way DevOps expert to really get value?

Aruna Ravichandran: No. So, you know, like I said because we knew that there is no clear-cut framework, right – like if you think about I-_____ there is a very prescriptive framework in terms of where you can actually start and how you can actually end. With DevOps one can start many different ways.

So what we actually did was we looked at some of the best practices a lot of the customers have actually implemented and built a framework in terms of a maturity model and we shared that as best practices.

So if you think about accelerating the maturity we talk about, you know, three different examples of how customers could actually start. The first way is to basically build an end-to-end release management system; and the second one is to how can you operationalize with feedback loops going all the way from Dev to Ops and vice versa.

And the last one is how could you actually optimize the continuity stability pipeline?

So we shared some of the best practices in terms of where one can actually start and how they can actually modify their processes to give them a lifecycle regardless of where they want to start. They could start in Dev and end in Ops; they could start with Ops and make changes to Dev. But we shared some of the best practices in terms of maturity model which customers can actually implement.

Alan Shimel:                Excellent. Aruna, again, we only have 12 minutes or so on these podcasts but we’re going to spend about an hour – 45 minutes plus 15 minutes in questions – on an interactive Q&A webcast with you on this subject.

And I just wanted to, in our remaining time here, remind everyone or let everyone know that the webinar is scheduled for January 17^th – so about two weeks from today or so – a little less than two weeks – at 2:00 PM Eastern Time. And within these show notes – if you’re listening to this on Sound Cloud or iTunes – within the show notes there we’ll have a link to the webinar. And if you’re reading along or listening on devopsy.kinsta.cloud we’ll have a link to the registration there as well. You can get to the registration on devopsy.kinsta.cloud – go to the webinar section and of course it will be listed there.

But importantly Aruna I wanted to mention the book itself is free, correct, for download?

Aruna Ravichandran: So the software version of the book is free. If they want to get the hardcopy they can buy it through Amazon or through our publisher which is Apress. I also want to call out and say that if they buy a hardcopy version of the book we are donating all the proceeds – the royalty from the book are being donated to a nonprofit corps Foundation of Excellence – the Foundation of Excellence’s mission is to award university scholarships for exceptionally talented but economically underprivileged high school graduates in India in order to embrace stem carriers.

And so they can either go through the softcopy of the book or they can download the hardcopy and that all of their contributions are going to be donated to the nonprofit.

Alan Shimel:                That’s great Aruna. Fantastic. I also want to mention that for those who register and attend our webinar we are going to give out ten signed copies – signed by Aruna and her co-authors – to ten folks who attend the webinar. I have to mention that those are US-based folks only as the logistics of mailing hardcopy books make it prohibitive to send them across the oceans. But ten US attendees will win signed copies of the book and everyone who attends will get a link to download the soft version, and of course you can buy the hardcopy version – the hard-book version on Amazon or Apress. Again, we can register that at devopsy.kinsta.cloud.

Aruna, we’re almost here at the end but just to give some of the people – some of our listeners a little tease of what we’ve got going on. I know there’s some CA-sponsored DevOps research that’s due out shortly and that kind of reinforce this idea that organizations that do DevOps are doing better. Can you give us a preview or you’re not allowed yet?

Aruna Ravichandran: I can give a little bit of preview. But what I can say is we did our research with one of our analyst vendors and partners with over 1,200 participants around DevOps and what I can say is that 87 percent of DevOps adopters have reported an improvement in customer experience.

There is a lot of rich statistics which we uncovered as a result of that particular survey and we will be able to share the results from that particular survey report on January 11.

Alan Shimel:                Great. Maybe we can speak about it a little bit on the webinar for January 17 as well – or incorporate it into –

Aruna Ravichandran: Absolutely we will.

Alan Shimel:                That sounds great. Well, Aruna, we certainly look forward to the webinar on January 17, but more, you know, as importantly, congratulations on authoring or co-authoring what sounds like a great book, and kudos actually for your donating the proceeds of the book to a worthy cause: I think it says a lot about who you are and what are the kind of reasons behind that, so thank you.

Anything else before we wrap up?

Aruna Ravichandran: Nope. I’m very excited to partner with you in order to share our experiences around writing this book and the journey, and hope that this book will be insightful for all of our DevOps practitioners who are embarking or are already on their way within DevOps.

Alan Shimel:                Okay. Well, Aruna Ravichandran, co-author of DevOps for Digital Leaders, thank you so much for appearing on this episode of DevOps chats and we look forward to our interactive Q&A webinar on January 17 at 2:00 PM with you to continue our discussion. Thank you.

Aruna Ravichandran: Thank you Alan.

Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on another DevOps chat.

— Alan Shimel

January 10, 2017
The Secure Developer Podcast: Continuous Security at Chef

Welcome to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow. The Secure Developer is hosted by Guy Podjarny, CEO and co-founder of Snyk.

In this episode of The Secure Developer, Guy talks with Chef CTO Adam Jacob about the role security can play in DevOps and continuous integration/deployment. They cover the differences between baked-in and bolted-on security and how automation with Habitat can change the way developers approach secure coding. Adam Jacob is the co-founder and CTO of Chef, formerly known as Opscode, where he wrote the open-source, automated applications project Habitat.

This podcast is brought to you by Heavybit, a program that helps developer product companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/295763125?secret_token=s-AfcYk” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

Guy Podjarny: Hello, everybody, and welcome back to The Secure Developer. Today we have an awesome guest on the show, Adam Jacob from Chef. Adam, thanks for joining us.

Adam Jacob: Hi.

Guy: We’ll talk about various cool topics we teed up, that I think are interesting with the world of security and the world of DevOps and CI/CD, and some very interesting new package management, build system capabilities coming out of Chef that I think are very relevant to the security play.

Before we dig in, for the few of you that might not know Adam Jacob or Chef, Adam, do you want to give a quick intro of your background?

Adam: Sure, I think there’s probably more than a few who have no idea who I am. I’m Adam. I wrote Chef, originally. I’m the CTO at Chef, and I wrote a thing called Habitat not that long ago that does application automation. And that’s sort of new stuff.

Then, mostly what all of that really boils down to is, I spent the last 10 years going around talking to big web companies like Facebook and Google and Yahoo, and I’ve also spent a bunch of time with startups. And then I’ve also gotten to go see really large enterprises ranging from giant banks to insurance companies, retail companies like Nordstrom, Wal-Mart.

So I get to just travel around and see what everybody is doing and see what they’re worried about and try to help them get better in terms of the time it takes or the speed to deliver, or their organization or their culture. So a bunch of it is software, but a lot of it is just helping people sort of understand how better to build their organization.

Guy: Yeah, I guess there’s always this conversation about whether DevOps and, well, continuous deployment maybe is a little bit more specific, but DevOps is really more about the tools and more about the people and it tends to be a consensus that it’s more people.

Adam: It’s both, right? Like, if you have a great culture, it’s really easy to say that you want to have a good culture. It’s really easy to be like, “Oh, I want to empower people,” or, “We want to streamline a process,” or whatever. It takes nothing. It’s just words.

Usually, it’s the technology that reinforces those cultural behaviors that hold you back.

So, a good example is, “Oh, I want to do continuous delivery, but we use a terrible source control system that makes it almost impossible to do effective continuous delivery. But because that’s the source control system we use, we’ll never change.”

Therefore, which one’s true? Do you want to do continuous delivery, or do you love your bad source control system? So there’s this reinforcing circle that hides inside there, and I think you see that all the time in security, too, that same circle and that same behavior.

Everybody says, “Oh, we want to be secure.” I was working with a bank who I won’t name, and I was on an engagement for a couple weeks.One of my first questions that’s going to help them do continuous delivery, and they wanted to, their first target was, to harden the operating system.

I asked them, “Okay, do you have the hardening spec? Do you know what you want to harden?” And they were like, “Oh yeah, yeah, of course we do. We’re a global bank.” And I’m like, “That’s amazing, great! I would love to see that.” And they’re like, “Oh, we’ll have it for you on the day you arrive.”

I left three weeks later, and they had never found it. And what they had realized was it didn’t exist. Everybody thought someone else had built that, and that it was someone else’s job, and no one actually did. It was just this loose conglomeration of stuff that theoretically they were supposed to do, but no one actually could track or knew. And that’s a global bank. It probably should matter.

Guy: I think sometimes it’s about the mess or the fact that tools can help surface information and hold information in a way that is accessible. And sometimes it’s just the sheer obstacle for many of these more complex topics when you talk about deep ops topics around how containers operate or how some machines are orchestrated.

Or in the world of security, when you talk about deeper security, understanding about what’s an attack, what’s not, and that sort of a constantly moving landscape. Just fundamentally, you have to have the tools. You cannot overcome those problems by sheer education. And at the same time,

if you have tools and people don’t know how to use them, or they have no understanding of what they’re for, then you would eventually not achieve what you’re aiming for.

Adam: Context is everything, right? Tooling is great, but it’s not enough. One of the things that we do at Chef and in the security world, is we have a thing called InSpec, which is a language for letting you describe security posture and code.

So you can say, “This particular machine should have this particular policy. That policy means that port 25 should be open, you should be able to auth this way, you shouldn’t be able to auth this way.”You should be able to talk about packages being installed, you should be able to talk about all of those things and then relate them back up to the actual security line items and talk about their severity.

We care about this thing because of this piece of HIPAA, or we care about it because of this piece of CIS, or whatever. And those tools are great because they sort of combine the documentation of, this is what the standard is, with the check that actually is executable that says, “And are we meeting the standard, yes or no?”

I think whether it’s InSpec or tools like InSpec, when you think about that operational part of security and how it applies to those large enterprises, especially large enterprises, but the big web, too, more and more it’s becoming that policy is executable.

So that conversation between security and developers and operators becomes a conversation around code as opposed to a conversation around documents, and controls, which I think is really the conversation most people have now.

Some security guy wrote a control and then here’s the list of people that say that they can validate the control. But is the control any good?

Guy: Is it actually happening?

Adam: No. I mean, it’s not, right?

Guy: Yeah.

Adam: And that’s true everywhere. We wrote a control. Here’s the list of 10 people that you could go interview that know how to do that control. Okay, what about the other 10 people who could also do that, that aren’t on the interview list that wasn’t updated on the last year? Do they always do the procedure the right way?

Do they always make that process right? And of course, the answer is no. But we just sort of let it ride because the auditor passed.

Guy: Yeah, it’s the notion of protecting yourself from audits, not from attacks.

Adam: Exactly!

Guy: It becomes sort of increasingly there. I love that notion. So with InSpec or, in general, with security, one of the key challenges is that it’s invisible. So if you’re not doing it, you really have no immediate indicator to the fact that it’s not happening.

The user experience, if you will, of not monitoring, not watching for a certain vulnerability, and the user experience of watching for it and having nothing happen, is the same thing, which is, nothing happens, right?

Adam: Yeah, which is nothing.

Guy: Which is good news. So I think anything that helps define and articulate the controls that are supposed to be happening, giving you some mechanisms to understand that the action has been taken so you know that InSpec, the locking or whatever, say, if we use a simple example, the limiting of ports being open, that has been explicitly articulated and explicitly tracked by the tools here, and you can get informed that it has happened.

We see this in Snyk a lot. We watch projects for vulnerabilities, for vulnerable dependencies, and then you have really, again, it comes back to the fact that you have the same user experience. If you’re not watching a project, or if you’re watching a project for vulnerabilities and none happened there, and we have a lot of these conversations with users today about, “How do you want to hear about it? How do you want to know that you’re watching it?”

And today, we remain fairly simple. We just remain in this ongoing report that just sort of shows you, “Hey, you’re monitoring five projects” or something, and they have those things.

Adam: Right, it shows that it reacts often, or whatever, and we can measure change.

Guy: But it’s great to sort of increasingly have those and have some requirement, whatever, in your Chef and InSpec, and that defines it as well, project X is being monitored for X, Y, Z, so you know it’s being enforced.

Adam: Right, and then you stick that in the pipelines.

When you think about continuous delivery and security, security and the validation of that compliance is part of the process by which software goes into production.

And it’s part of the way that software gets maintained once it’s there, and it’s part of that build process. You bake it in sort of throughout the SDLC, instead of it being a thing that happens at the end.

And that’s one of those things that’s obviously a good idea. So, as soon as you hear it, you’re like, “Oh, of course, security should be baked into the process, all through the whole thing.”

Guy: The whole built-in versus bolt-on.

Adam: Yeah, right? Sort of, duh. But actually, doing it is actually completely–

Guy: A whole different ball game.

Adam: A whole other ball game. And the thing that we really came to realize, especially with InSpec, but just sort of in general, is that if you can’t figure out how to manage that security posture the same way you manage the rest of what you do, it’s really difficult to then tell a software developer that it’s their responsibility to ensure that that posture is good or bad. Because, sure, they can make that they write “good code.” You can’t hear the air quotes, but m I was making little air quotes in my brain, probably.

Guy: I can attest to that.

Adam: It’s good, but you can’t really ask them to understand the posture of what it’s going to be like when it’s deployed.

Because the distance from a software developer making a decision to a software developer talking about how that software should be in production, and what it’s posture ought to be, is so vast. And their ability to influence it is so low that it’s really difficult to come back to them and be like, “Oh, this was your responsibility.” Like, clearly it was on you.

And when those tools give you the ability to talk about it as code. They allow people to participate, you can code-review them. You can have security people audit the code as opposed to audit your documentation, and then have those things as a living piece of that deployment model, I think everything gets better and it gets a lot more secure.

One hard part of doing things that way is that it’s very not the way that most security regimes are set up right now. If you go talk to a security officer and you ask them, “Hey, could we remain compliant to whatever the standard is, HIPAA?” If everything we did was continuously delivered, nine times out of 10, the answer is just a flat no.

And what’s interesting is that there is, one out of 10, where that security officer is like, “I don’t know, maybe. Tell me more about how that would work.” And I think if I roll my clock back three years, it was 10 out of 10 that we’re telling me no and that was crazy. And now it’s like nine of 10. And I predict in six months, it’ll be six of 10. And then in two years, it’ll be like talking about, “Should you be doing continuous delivery or should you be doing Agile?”

Guy: It comes back actually to the commentations sometimes or even that document or something that big bank did not have. Like, these things eventually come back to the documents and to the guidelines. So at the end of the day, you go down the compliance route and you actually have that in the compliance document that it says, well, if you are using continuous delivery, then to be HIPAA-compliant, you need to ensure that you’re doing these things as opposed to just sort of having the goal in it.

Many of these regulations have the same flaw, the same notion that says, “Well, you have to do these actions,” as opposed to, “You have to achieve these goals.” So they give the vague goals, but then everybody prescribes to whatever recommended actions that have been prescribed, because that makes passing the audit the easiest.

Adam: Yeah, and I mean,

the relationship between the auditor and your security posture is pretty tight.

Like, the real test of your security posture, in most cases, is the auditor. Not like a pen test, or people actually trying to break you. I mean, they are, but you’re not doing it proactively.

I think when you think about those CD pipelines, the idea that they’re applied continuously, that as applications change, that you’re reapplying the security posture to see if that application has done something that violates that posture, and that when you change the security posture, you’re re-validating the applications and you’re doing it sort of throughout the whole cycle, it’s super powerful. It’s what people are starting to be able to do. I think you don’t see it a lot yet, but it’s sort of the future.

Guy: I think that’s interesting to understand, the potential versus what’s happening, right? High-level continuous deployment and your whole infrastructure’s code, the fact that you’ve prescribed it, built it in, allows you to get predictability. You know what’s where, and you know that a certain test or a certain enforcement has been done to the extent of bugs. But at least, not as human error.

On the flip side, it requires security auditors to change how they behave. It’s not just about that compliance, it’s also the fact that today, many of these security audits, you gave the example of a security auditor reviewing your code, are done as gates.

They’re done as a way that says ‘stop here,’ which is the antithesis to continuous.

The whole notion of continuous is just, you roll out. It’s okay to pause for a moment, but you can’t stop. You can’t accumulate a backlog, because otherwise it’ll deteriorate, unless you automate that.

Adam: Yes and no, right? There’s continuous deployment, and then there’s continuous delivery,and they’re not quite the same. So yes, in continuous deployment, there’s nowhere to pause. I think in continuous delivery, there is.

In continuous delivery, the idea is you’re shipping when you should be able to ship, any time that the business required shipping or it made sense to ship. And that’s different than saying, “We just ship every time you commit,” right? And so in continuous delivery, I think there’s plenty of space to say that, “Hey, this project, in order to ship, requires a security review.” And that process can still be continuous.

The question is, that should be the only gate between you and getting to production. So if they say yes, could you ship? And then the question of course is, is that true for every commit? Like, could you ship today, if today was the time? The answer to that is very rarely yes, and so that’s where the difficulty comes in.

Guy: Yeah, and I think it’s an interesting comment. I accept the delta between continuous delivery and continuous deployment, but it seems to me that from security route, well, first of all, even from a quality perspective, one of the values of continuous, both delivery and deployment, is the fact that you spot errors when they’re small, at any given time.

So definitely, for continuous deployment, when you ship every small code change, whatever, at some low resolution, when a problem occurs, it’s much easier to pinpoint to what was the issue, the source of the problem.

That value proposition is pretty compelling in security as well, right? If you are looking for a security flaw, being able to, only looking at it within the range of whatever the 100 lines of code to change versus the 100,000 lines of code or 100 million that existed, is very valuable. If you accumulate those changes and you need to now do the security audit, I would argue you’re not actually ready to deliver in that spot.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

— Malia Powers

December 5, 2016
DevOps Chat: Lucas Carlson, VP Strategy, Automic, Can Ops Thrive In DevOps?

In this DevOps Chat our guest is Lucas Carlson, newly appointed VP of Strategy at Automic. Of course, Lucas has already had a distinguished career. Here is his bio from Linkedin:

Lucas Carlson is an author, entrepreneur and executive. He also has a background of 20 years of programming to back it all up.

He’s written scalable software that has been downloaded millions of times and used by millions of users. As a keynote speaker in the technology arena and innovation leader in the cloud space, Lucas helps companies discover opportunities for growth.

Lucas wrote a bestselling book on Ruby for O’Reilly called The Ruby Cookbook and has created over a dozen open source libraries, some of which have been downloaded almost a million times.

Lucas was formerly the CEO and founder of AppFog, a massively popular DevOps startup acquired by CenturyLink in 2013. AppFog signed up more than 100,000 developers, raised nearly $10M in venture funding and has become an industry leading Platform-as-a-Service.

Before following his passion and writing books, Lucas served as the Chief Innovation Officer for CenturyLink, in charge of building next-generation Docker and Linux Container products for a $20B company.

Lucas also writes for major tech and entrepreneur publications including Inc, Business Insider, InfoWorld and InformationWeek.

I spoke with Lucas about why he joined Automic. Our discussion proved to be a provocative one, in which we explored Lucas’s view that DevOps is not a great thing for Ops. Ops needs its “own DevOps” that is more geared to its challenges and world view. Of course, many thought that DevOps is just that. Before you comment, have a listen to our conversation to see what Lucas said. I am interested in your thoughts and comments on this.

Alan Shimel: Hi, everyone. Alan Shimel, editor of devopsy.kinsta.cloud here for another DevOps Chat. Very happy to be joined in this DevOps Chat by VP of Strategy at Automic Lucas Carlson. Lucas, welcome.

Lucas Carlson: Thank you so much. Glad to be here.

Shimel: Thank you. Lucas, I know you’ve been at Automic now, what, about two or three months?

Carlson: Yep.

Shimel: But I’ve known Lucas Carlson for years before Automic and I don’t know if our audience is familiar with you, but you’ve had quite a storied career already at a relatively young age.

Carlson: Thank you. Yeah.

Shimel: Why don’t you give our listeners a little bit of the Lucas Carlson story.

Carlson: Sure. Well, I started out as a programmer: for 20 years I wrote code. I started code when I was in elementary school and ever since I’ve been writing code. And I wrote two programming books during my career. I’ve mainly focused on the open-source side of things so Ruby, PHP, Python worlds.

And then I started a platform-as-a-service startup about seven years ago and I used Cloud Foundry as the foundation for my startup and it was called AppFog. We signed up 100,000 developers, it was a lot of fun. It was a great time.

We were acquired by a telco and it was really interesting to spend a few years inside of a telco and watching them attempting a digital transformation—trying to move their applications into the cloud was a very interesting story.

And after that I quit that job, I moved to Paris for a while—it was a life dream of ours—moved my family, and after Paris I looked around for what to do next and this opportunity came at Automic, and I thought it was a very interesting opportunity for reasons we might get into.

Shimel: Great. Great. And of course, you know, interesting with your background and accomplishments Lucas that Atomic, which is an automation company, is where you wound up and as VP of Strategy there.

So as someone who was a chief strategy officer at the last company I co-founded, Lucas, I can appreciate the title of VP of Strategy. But for our listeners who are saying, “Well, that sounds like just another corporate title,” give them a little insight. What’s your role as VP of Strategy at Atomic?

Carlson: Yeah. Well, my role is to take a company that’s been around for almost 30 years that’s had a product that is battle tested, been around the block, really works, works at scale, has thousands upon thousands of enterprise scale customers, has a lot of pedigree and DNA, and yet is a company nobody’s heard of.

That’s actually why I kind of joined. I thought it was a really interesting challenge to take a company that nobody’s heard of yet has had a product that is—has stood the test of time, is very, very robust, very strong, and see if there wasn’t a way to kind of help that company get recognized for the work that they do, which is actually really great work.

And so I joined the company with that kind of concept in mind. And it’s been very interesting because fundamentally when I came into the company they called themselves a DevOps company and I come from a background—I’ve been doing DevOps for a long time. I grew up around Portland, I hung out with Luke Kaines who founded Puppet and he was one of my mentors when I was building AppFog and—so I knew DevOps inside and out. I used DevOps to build my own startup.

And so I came in and I looked at what Automic had and Automic has a very interesting, strong product, but it’s not DevOps, because DevOps is predominantly—you know, having grown up around it I know you know DevOps is not some mystical union of developers and operations into this perfect combination that can do both and is just as adept at writing Ruby as they are debugging MySQL.

You know, that’s kind of a story—a fairytale that people like to tell, but it’s not the truth. The truth is, DevOps was created by developers for developers to get around operations. They were sick and tired of waiting for operations to get around to provisioning their SQL server so they wrote some code that did it for them.

They were tired of kind of the delays and lags so they wrote code that got around it. It wasn’t really meant to create this mystical union it was really meant to bypass operations.

So, I guess, how does that apply to Automic? So, Automic came in saying they were DevOps—they weren’t a tool for developers and yet I thought they have this long track record. They’re doing something right, but what is it?

And I spent a lot of time thinking about that before I joined and when I joined I became convinced that there is a huge part of the DevOps story that is getting left out: it’s getting forgotten, it is getting sidelined and ignored that doesn’t deserve to be ignored.

I think that DevOps isn’t enough on its own. Having run a platforms and service company myself, having put platform as a service into major name-brand banks, having seen people trying to adopt these DevOps technologies—what I’m seeing over and over again is that one of the biggest struggles about DevOps is a myth that I’m trying to shatter. And the myth is that DevOps doesn’t need operations: that DevOps outsources operations, that operations isn’t necessary for DevOps.

In fact, I think the absolute opposite is true and I don’t think ops is becoming part of dev. I think that ops deserves its own practices equivalent to what DevOps brought to developers. Equivalent and yet different, because I think that fundamentally operations was a different world of developers: always will, always has.

To developers, failing fast is important and breaking stuff is totally acceptable. And going iteratively is great. So if you write some code, it doesn’t work you can fix it really quickly because you failed fast and it makes it better. And that kind of iterative approach is something that works really, really well for developers but it does not translate for operations. Operations cannot fail fast. If you fail in operations and your database goes down in production, that could be millions upon millions of dollars lost for the business.

So it’s not that operations doesn’t want speed—of course they want speed, it’s just that speed is not the primary. For developers, speed is primary; for operations, reliability, robustness, scalability trumps speed. It’s not that they don’t want speed, it’s that they have a different core value set—a different world view—and instead of trying to mush these things together, instead of making them one idealized person that’s never going to exist, what I say is, let’s raise up the ops side of DevOps, bring it to the same level that developers have been raised. When developers adopted DevOps practices, it raised them up to a new level as a power-up—it was a mushroom in Mario. And what we need is to give the ops side a mushroom.

We need ops to level up and be able to play at the same level as developers, but with tools built for operations, not built for developers.

The tools out there for developers in DevOps are not the right tools for operations in DevOps and that’s what –

Shimel: Hold on, I’m going to stop here because I’ve got to jump in—I’m sorry—I’ve been biting my tongue.

So this is actually a pretty—I don’t want to say radical, but a very different kind of view of DevOps and what goes on between dev and ops than I think we hear from most people.

And it actually reminds me I had a conversation—actually a DevOps Chat—with Dave West, who is the CEO of Scrum.org. And you know, obviously, Scrum and part of Agile is really aimed at developers. And though he saw sort of a potential bridge from dev to ops he had a similar view of yours that, you know, we have tools that are written for developers that developers are using that are letting them get more involved in ops but how much is ops really being involved in this DevOps, if you will.

But yet, you know, let’s look—like configuration management tools.

Carlson: Yep.

Shimel: Do you think those are dev tools not ops tools?

Carlson: Yep, I absolutely do.

Shimel: Absolutely. And –

Carlson: I could go into that more but I think it’s self-evident. I think that developers use those tools vastly more than operations. I think that the reasons are obvious. The tools were built for developers by developers.

Operations looks at the world through a different lens; they use a different way of approaching the same problems and they kind of—the way that configuration management works embraces a development mindset.

Shimel: Okay, fair enough. Let me ask—so how does this, Lucas, play into Automic and their future toolset? Will we –

Carlson: Well, I joined Automic specifically because I saw this as the biggest problem in DevOps today and that Automic has solutions on the ops side of DevOps. Automic’s solutions are the level-up for ops teams. They don’t say—like one of my biggest pet peeves right now is this rip-and-replace mentality. You see it … with Mesosphere, with Docker containers, with Cloud Foundry, with OpenShift. All the big vendors out, there they all have the same promise: “Take everything you’ve done, throw it away, import all of your applications into our platform that will do it all for you and it will solve all your problems.”

Well, I’m sorry, but that’s just not going to happen. Those platforms are generally underdeveloped, undertested at scale, they are a brand new way of managing applications that is untested. They don’t embrace the vast majority of enterprise scale applications architectures. They basically force you to rip and replace. And rip and replace is not just a thing for the code it’s a thing for all the IT processes that have been known to work for the last 10, 15, 20 years.

So you’re trading a potential promise for a solution to all your problems, but the risks are exponential and vastly untested. So this whole concept of rip and replace I think is very, very dangerous in our industry today and very prevalent.

And I joined Automic because their approach is to embrace what already exists and make it better. Instead of saying, “We’re going to have a new platform for you to import all your apps to,” they have a way to describe the topology of your existing infrastructure and built on top of that and automate that instead of throwing it out and replacing with something new.

And so, I think to me, it really levels up the ops side of DevOps—it makes operations a hero, the co-hero of the DevOps story. It doesn’t deny operations their vital role.

Shimel: Excellent. Excellent. You know what? Lucas, I’d love to see this at a Speak—you’ve got to submit to Speak about this somewhere.

Carlson: Yeah, for sure.

Shimel: Or, maybe we can do a webinar and get into it because honestly, our DevOps chat format being just 15 minutes doesn’t give us enough time to really delve in here and I’d love to get a counterview of these things too and let’s really have a discussion around it. I think I’m going to take that as my job. I’m going to go find someone and we’ll go back and forth on this.

But unfortunately we are just about out of time—we’re at 15 minutes already. As I said, it goes quickly.

Carlson: No problem.

Shimel: This has been a very interesting discussion. I would call it truly an ignite or a fire starter in that you’ve opened the door here and we’re not finished with this one Lucas. We’re going to come back to it.

Carlson: Sounds good.

Shimel: But for now we’re going to call it a wrap. I hope if you’re listening to this you found the conversation interesting. Of course on devopsy.kinsta.cloud you’ll also see a written transcript of the conversation so you can hold Lucas to his words here and it’s going to be in writing.

And if you have any questions, comments, feel free to also put them on devopsy.kinsta.cloud we’ll get them out to Lucas, and as I said we’re going to try to continue this discussion at a later date.

But for now Lucas Carlson, VP of Strategy Automic. Thank you so much for really kind of blowing the doors up today on this and we look forward to seeing what the follow-up’s going to be. And success at the new position.

Carlson: Thank you so much. I’m very happy to be here.

Shimel: Thank you. Yeah, no, it’s a great company. We’ve worked with Automic for some time and I’ve met a lot of great people there.

Anyway, that’s a wrap for this edition of DevOps Chat. Lucas Carlson from Automic was our guest and this is Alan Shimel for devopsy.kinsta.cloud. We’ll see you at the next DevOps Chat. Thanks everyone, have a great day.

— Alan Shimel

November 4, 2016
DevOps Chat: Panzura’s Cloud-Based File System Gives DevOps Big Savings

Have you heard of Panzura? If not, you are probably not alone. The company is relatively new to the DevOps market. But it’s not some new startup that grabbed some VC money by using DevOps as a buzzword: Panzura has been around for years, perfecting its cloud-based file system that can deliver eye-popping results in terms of speeding file requests, as well as the volume of data that you have to transport. For DevOps, this kind of speed savings is just too good to pass up.

I had a chance to sit down with Rich Weber and Barry Phillips of Panzura and discuss why DevOps teams are finding Panzura’s offering so enticing. Barry is the VP of Marketing at Panzura, but don’t let that title fool you—Barry is highly technical. Rich is chief product officer at Panzura and is also really knowledgeable. Together, we had a great conversation about this interesting offering and why the DevOps market actually came to Panzura rather than Panzura coming to it.

As usual, the streaming media player is below, followed by the written transcript of our conversation. Have a listen or a read, or both. Enjoy!

Alan Shimel: Hi. Alan Shimel, Editor-in-Chief, devopsy.kinsta.cloud here for another DevOps Chat and I’m happy to be bringing—I, well, I think introducing to our audience a new company or a new company to the DevOps face perhaps that we haven’t had a chance to speak to before and that company is Panzura, and I’m happy to be joined on this episode by Rich Weber, Chief Product Officer at Panzura, and Barry Phillips, Chief Marketing Officer at Panzura. Gentlemen, welcome.

Weber: Nice to be here. Thank you, Alan.

Phillips: Yeah. Thanks, Alan, great to be here.

Shimel: Okay and just for our audience, though, Rich, that was you first and, Barry, that was you second. So guys, I’m gonna guess right now that our audience may not be familiar with Panzura, can one of you give me the elevator pitch or a quick background on Panzura and we’ll go from there?

Phillips: Yeah, it’s Barry. I’ll do that. So yeah, so Panzura and it’s interesting as I start this off, most people may go I’m not really sure why you’re in this DevOps space, so what we do is have a hybrid-cloud storage solution and really what that means is we put all of our customer’s unstructured data in the cloud and we happen to cache the data that they’re using on physical or virtual appliances that’s set in the offices. And that happens to work really, really well for some specific use cases because of some unique technology that we have inside of our software so you know one of those is for manufacturing and it really makes CAD applications work really, really well across sites, architectural apps, engineering apps and just like those use cases we’ve have customers actually bring us into the use case into the DevOps use case and really specifically being able to globally distribute software builds and artifacts quite quickly. And so that’s really the part of DevOps that we play and it really kinda plays into the continuous development, continuous delivery, continuous integration space and essentially what happens is in the case of electronic arts you know we dramatically taking the time it takes to distribute globally you know 50GB build files from 10 hours to essentially minutes and we’ve got many different examples of customers like that, so it’s always great to be brought into a specific space by a customer need that’s taken a platform that you have and really using it for a specific use case.

Shimel: Absolutely. And, Barry, of course when we’re talking about a time difference of 10 hours to a few minutes, I mean that’s the kind of eye-popping differentials that we like to tell in the best of cases in DevOps, right, where we’re putting those kinds of savings, those kinds of numbers in front of people. So thanks for that background. Rich, if I can ask you so you know obviously there’s use cases here for the DevOps audience, for the DevOps market and DevOps use patterns, as we say. As chief product officer, Rich, what kind of—you know, how did you steer feature set? How do you plan your road map to kinda further help the DevOps community with this product/service?

Weber: Well, I mean typically it’s based on feedback from real customers that we have doing workflows and things that run through there and like so that eye-popping one that you were talking about is how do we reduce that time by so much? You know a lot of that came from working with software developers and one in particular is in the gaming industry where imagine their builds are very large, right? They’re building into like Blu-ray ISO images and things and enabled low-cost QA centers to test that. Now you can have anywhere from 20GB to 50GB resulting builds and transferring those takes a long time, right? Suddenly, you come to the point of, ‘Hey, I could probably get that data across the globe faster on FedEx than I can digitally over the line.’ Our product really helps do that by providing a global file system that’s available in each site and by virtue of talking to the Panzura device it’s automatically in the cloud. It’s automatically duplicated, compressed and transported and available in their real time. Especially if I’m doing many hundreds of builds very quickly, the deltas between those builds are very short so effectively I can make those available for tests, production and immediate use through my build process.

Shimel: Excellent. And, Barry, you and I spoke a little bit offline and you know I think I had asked you about so is this a product or service that is really only for big companies or for unicorns you know of the world? I mean who’s a good candidate, especially from a DevOps point of view, for Panzura?

Phillips: Yeah and I would even extend it, I would say, beyond DevOps, right? So if you think of any company that does any sort of global testing and development whether that’s pure DevOps, whether that’s somebody who is in the process of putting DevOps in place or even somebody who’s basically not even there yet that when you think of just the ability to move these builds and artifacts quickly that really increases the number of test cycles you can do on the software itself. Of course, that’s better quality software you know typically gets market—it gets software to market faster. It’s all those typical things. But I think it really encompasses anybody who is actually has dev and test teams essentially around the world.

Shimel: Yep. And another kind of phenomenon that we’re—that I’ve observed, Barry, in talking to a lot of people, obviously, is this idea of a multi-cloud. So let me back up. When we first saw the whole sort of cloud revolution, if you will, I think the—everyone agreed that hybrid cloud was the way to go. No one was moving a hundred percent of their infrastructure to a AWS or Azure, a public cloud platform, but there was a hybrid where some of it might be public. Some of it might be in a private cloud in a data center. Some of it may be on-prem, right, but it was that hybrid situation. Now we’re seeing multi-cloud, right? And I think it’s a different animal. Barry, Rich, what do you think?

Weber: I think multi-cloud is good and particularly for DR purposes but going to that hybrid concept that you were speaking of before and how do companies really bridge the, hey I’m working inside of my four walls or inside of my data center and how I take advantage of that cloud space that’s where Panzura really helps companies bridge that gap. So in particular, if I am working within my own data centers and my own sites and I’ve got multiple sites, that example that I gave you before not only was the time reduced from many hours of days down to minutes but in terms of that footprint that went down to one—from 1.5PB to 45TB by utilizing the cloud because I had one central location of the data and I didn’t have to store and move and transfer many replicas. So that cloud gives you the ability to aggregate and make that data available quicker. Multi-cloud I think gives you an opportunity to then further do a disaster recovery even redundant across clouds not only from sites but from cloud to cloud, right? That first step is really getting that data and aggregating it in the cloud itself and Panzura really gives companies the advantage on how to move there and take advantage of that and even burst inside of computing, not—and beyond data, as well.

Shimel: Absolutely. I mean and that’s exactly where I see with multi-cloud. Once I’ve been able to move that data to the cloud whether I have some of my infrastructure on Windows, let’s say in Azure and some other stuff on NOS and AWS and maybe something on OpenStack at Rackspace or somewhere doesn’t make a difference ‘cause my data is rather—you know my data is multihomed anyway or not multihome. That’s not the word I’m looking for. Panzura takes care of the data. I don’t have to worry about that. Is that—is that the gist of it?

Weber: Yeah, I mean, in fact, we’ve got customers who I would say maybe you didn’t start out as being cloud-forward customers or cloud-savvy but Panzura makes that simple, right? If all they have to do is make a mount, my workflow stays exactly the same as it is today and you don’t have to worry about where that replication it goes, what data center is getting used. Panzura makes that part simple. All you got to do is mount it regardless of where I’m at. It’s the beauty of having a global main space in a global file system.

Phillips: And maybe to further add on top of that, Alan, is you know Rich mentioned workflow and as you think of you know companies who essentially go from you know waterfall to Agile and then get into you know really this DevOps model. You know we can sit underneath there and it stays the same for them ‘cause we are just we look like a regular storage mount for them, so everything will remain the same as they move down this process into DevOps.

Shimel: Great. So let me get a little geeky on us. Rich, can you kinda describe what the Panzura stack, if you will, looks like? I know you referenced a Panzura device earlier. What exactly—give us a little—our audience a little bit more detail on that.

Weber: Yeah, so I’ll try and keep it simple but on the front end it looks just like a file server you know whether that be like a net app or even a Windows file server on the front end, so it integrates with AD or other authentication methods and you just mount it, right? So, on the front end you’ve got either an SMB/CIFS front end or an NFS front end. You mount that drive and you store your data there. As data comes to us, it runs through our stack and our stack begins with de-duplicating and that de-duplication what you need to know about Panzura is it’s not just for the data at that place. It’s for the entire footprint for all data written everywhere because that de-duplication information is part of the metadata that’s shared globally. Then it gets—after it gets de-duplicated it gets compressed, then it gets encrypted and none of the customer keys or security access stuff exist in the cloud, so none of our customers actually even have to trust the cloud provider themselves because no data sits in there in clear text. Then it all gets compressed, packaged up and put in the cloud and that’s done at the block level from a de-duplication standpoint. So as it run through our stack we integrate WAN optimization, as well, so moving that data becomes very fast and simple and on the other end everything works in reverse and the customer doesn’t have to manage all that; all that happens automatically. Again, all they see is a drive mount and access the data in exactly the same way they would from their filer today.

Shimel: Has anyone ever used the term data storage as a service or data storage and access as a service?

Weber: Yeah, absolutely –

Shimel: Would that be fair?

Weber: Yeah, I think you especially as you move into that cloud paradigm, right? You’ve got platform as a service, storage as a service, software as a service and this is where, like I said, Panzura makes the adaptability of that service very simple, right? That’s storage and object storage in the cloud without you having to write specific apps to do that. Panzura allows you to adapt those type of either storage as a service or platform as a service integrated into your existing data center or workflow.

Shimel: Okay and guys, if I can ask ya, can you give our audience a sense of how this is priced or sold or offered or however you want to call it?

Phillips: Yeah. We essentially sell controllers and those controllers are what sits in somebody’s office and that can be either a virtual machine or it can be a physical controller and the more capacity those controllers have on them the more expensive they are. The other thing we do is we do have controllers that run inside the cloud and so and they would run inside Amazon right now and we do have just a preview that’s running inside Azure and the whole idea there is now not only does every single office see the same file system across every office but also that cloud does. So if you happen to have some sort of application or service running in the cloud, let’s say it’s platform as a service and you’re looking to be able to access file data that may be on premise, you know right now what we provide there is the same exact cloud data everywhere. So in all those cases somebody would purchase a controller from Panzura and that would be either a physical controller on site, a virtual machine that they would put on top of their own hardware, or it would be a Panzura controller running inside the cloud itself.

Weber: Yeah, I mean it depends on what your needs are. I mean in our hardware system think of this as a lightning-fast flash filer that sits inside of here, where our algorithms concentrate on the cache or very fast local performance usage. But software-only deliverable inside of a VM for flexibility of the customers or, like Barry said, an in-cloud solution if I want to burst into the compute and have my data there, Panzura controller in there, we’ll help ‘em do that. And again, global file system and mail work in concert together.

Shimel: Got it. Guys, I’m curious. As part of maybe your market research customer feedback, what have you, what has the feedback been from people from DevOps teams, let’s say? I don’t want to use the term DevOps engineers. It gets people up in arms but you know from teams that are using DevOps within some of your customers have you gotten any feedback from them on this and is it different than your customers at large?

Weber: I think the interesting feedback that comes through is probably twofold, right? There’s two things that you hear. Most of the concentration really comes in productivity, right? It’s about that speed. How do I make things faster? How do I get bills done quicker and get product to market faster? And we give some examples of that and I’m not kidding. I’ve been into customers before and they say, you know, “Hey, can you beat FedEx bandwidth?” and it just blows me away. You’d think it was the nineties or something again. So when you’re dealing with big files that helps and it’s not only about delivery of the final executable but also about doing builds in remote locations. If I’ve got remote mounts on those build artifacts or dependencies, people hit builds for private builds and remote site and wait ‘til the next day. With us they hit a build and they enjoy the same performance that they do at the headquarters or where the files reside. The second portion is, of course, the economic side, right? How do I save money? And I think that most of the feedback comes in as they pick us up or productivity gain, get products back to market faster and then they found out without having to do replicas and manage multiple file loads of data they end up saving a ton of money and it’s another example I gave you, right? 1.5PB of replicas down to 45TB—that’s a huge storage savings.

Shimel: Yep.

Phillips: Yeah and bear in mind I’m the marketing guy here, I mean the things that I’ve heard is when you think of these distributed teams who are working in a DevOps environment it really makes them seem like they’re really in one office, right, because it makes that speed seem just as fast over a wide area network across the world as essentially on a local area network in one office.

Shimel: Sure. And, Barry, you’re being facetious when you say you’re just the marketing guy. I happen to know you have two degrees in computer science so let’s not hide behind the marketing title too much. Anyway, gentlemen, we’re—actually, we’re past our time already. We always go past our time and I apologize, but I need to ask one last question which is the question we usually end our DevOps chats with. Though there’s two of ya, I’m gonna ask you just to recommend one book to our audience that they really should read as soon as they can or at least put it on their list and get to it when they can. What book would that be?

Phillips: Yeah, it’s Barry. I really enjoyed reading, “The Big Switch,” from Nicholas Carr and it really was—it was interesting ‘cause it—and I think it applies to DevOps and especially with DevOps in the cloud. I think someone wrote it’s kind of the whole chocolate and peanut butter you know together as a chocolate peanut butter cup and just really gave examples of what happened when power used to be generated from waterwheels and how that moved to the grid and really making that comparison of how things are moving to the internet. So I thought it was a great book and I recommend it for anybody.

Shimel: Great. Rich, you second that one?

Weber: Absolutely. [Laughs]

Shimel: Great. Well Rich Weber, Barry Phillips, Panzura—of Panzura, thank you for joining us on this episode of DevOps Chat. We welcome you to the devopsy.kinsta.cloud community and we hope to see and hear more from you in the near future. Continued success and we’ll see you both soon.

Weber: Thank you.

Phillips: Thanks, Alan.

Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chats. Thank you and we’ll see you again at our next DevOps Chat.

— Alan Shimel

September 19, 2016
To Be Continuous Podcast: Category Creation featuring Martin Casado

In this episode of “To Be Continuous,” Paul and Edith are joined by Martin Casado, General Partner at Andreessen Horowitz. He previously was co-founder and chief technology officer at Nicira, which was acquired by VMware in 2012. While at VMware, Martin served as senior vice president and general manager of the Networking and Security Business Unit.

The group discusses the deeply complicated and difficult process of category creation, with a special focus on technology infrastructure products.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/283115632?secret_token=s-zX7AW” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

Edith Harbaugh: What do you like about continuous delivery?

Martin Casado: I think that there’s a broader movement around continuous delivery that is really interesting, which is, traditionally, infrastructure and operations came from an independent group. My first job out of undergraduate was working on simulations code in a national lab.

I couldn’t control anything about infrastructure. I really didn’t have budget to buy a pencil. You get infrastructure, and you’d have some application to code, and you’d work on that application. We’d fiddle around with our MIG files or whatever, and that was pretty much it.

The cool thing about the broad movement now, and I think CI/CD (continuous improvement/continuous delivery) is just part of this, is more and more applications, application developers, are actually getting responsibility for operations.

This is provisioning, this is delivery, this is deployment. That’s a big huge change in not only what technologies get created but who’s consuming it and why they’re consuming it. I think it’s actually one of the more interesting trends right now.

Edith: This would be a great time for you to introduce yourself.

Martin: My name is Martin Casado, and I’m a general partner at Andreessen Horowitz.

Edith: But you did stuff before you were at Andreessen.

Martin: That’s right. The quick arc, as I mentioned, I used to be a research scientist at Lawrence Livermore National Labs. I spun out of that, did my PhD at Stanford. My research was in networking, so I was part of the team that started software-defined networking.

I was there for four years, spun out of that, started a company called Nicira where we did software-defined networking. I did that for five years. That was acquired by VMware. I ran the networking security business unit at VMware for almost four years, and four months ago I decided to change and become a VC.

Edith: So you basically created a category. What drove you to do that? What made you decide to start something knowing that it was so hard?

Paul Biggar: You’re talking about software-defined networking? For the viewers at home, Martin roughly invented software-defined networking.

Martin: There’s a whole bunch of people contributing, but I think a lot of the original momentum came from my thesis. You know, I’m going to be totally honest. If I had any idea how hard it was, I never would’ve done it.

Edith: Really?

Martin: I think so.

Edith: I think you would’ve.

Martin: Well, maybe. But it would’ve been a lot more daunting. I came out of Stanford pretty darn naive, like, “This is going to be easy!” Now, nine years and tons of gray hair later, I just realized that, man, it was a battle. I don’t think I had one-quarter that was easy. Everything was a battle.

This is the way that I think about it. If you’re an entrepreneur, and you’re going to do category creation, you basically just have two jobs, in addition to product development. And job No. 1 is, there’s going to be some constituency out there you’re selling to, and that constituency, they wake up every morning and they think about all sorts of stuff, but they’re not thinking about your thing, because it hasn’t been created yet.

That object in the mind space, that object doesn’t even exist in their brains yet. The first thing you have to do is create that object. It’s like Leonardo DiCaprio at “Inception.” You go in, you’re planting an idea in somebody’s head. It has to become a thing, something people think about, something people know and integrate.

This is from nothing, and that’s hard. For us, it took five-plus years, and it touches every aspect of thought leadership such as analyst relations and technical conferences and broad marketing.

Paul: So the activities that you’re doing in that category creation are largely marketing and getting people to hear about the activity and learn about it?

Martin: I think so. I think maybe technologists will view marketing as this pretty shallow thing, but I think you’re exactly right. It’s marketing. But it is often very technical marketing, for example, in the guise of open source.

In releasing open-source projects, you’re getting people to use it, you’re going to standards bodies, you’re going to conferences. It’s an incredibly technical thing, but in the end, it’s marketing in the sense that you’re actually creating awareness and a market.

The first thing that you’ve got to do as an entrepreneur is, if you’re doing category creation, nobody’s thinking about your thing. You’ve got to get them to think about your thing, which is a lot of work. In my experience, five to seven years.

Then the second thing that you have to do, which is just as much work, is then you have to attach a value to that thing. And I think we as technologists, there’s this kind of fallacy that we have where, “I’m going to create this new widget.” Let’s say I create the iPhone.

Paul: Everyone will know how amazing it’s going to be.

Martin: Exactly.

Paul: Just build it and they will come.

Martin: Yeah, there’s intrinsic value in my widgets. I take my widget, I put it on a sidewalk and someone picks it up. They’re like, “This is amazing. It’s worth millions of dollars!” And that’s totally not the reality.

The reality is people only see value if they exchange money and they’ve used it.

And if you’re doing category creation, how do people know what that value is? It’s a very difficult thing.

Paul: And when you say attaching value, do you mean monetizing? Or is there more to it than that?

Martin: I meant more the idea. Ultimately, this materializes monetization. Let’s say that you’re my constituency, and I’ve created this new widget. First I need to get you to think that this is actually a real thing. I’m going to call it a new phone. So, you need this new phone. First I need to convince you that you need the new phone.

Then the second thing I need to convince you is it’s worth tens of thousands of dollars to you because you need to mentally actually attach that value to it. And it turns out introducing new concepts don’t necessarily have value if they’re new concepts.

Normally, the value comes from, for example, an actual transaction. There’s a psychology around this. Or at least some experience with it, knowing that it’s going to, I don’t think you can just sit back to a couch experiment and be like, “Oh, I think this is going to save me money, therefore it’s worth something.” It really requires a lot of effort to make value.

Paul: So the category that I see being created, or the one that’s closest to me at least, is this idea of containers and Docker, and more specifically Kubernetes, the idea that there’s this cloud infrastructure over there. The way that I became aware of it is exactly the way you’re talking about it. There’s open source coming out there that you can use and you can hack on yourself. There’s talks up there where people blow your mind.

Martin: I think that actually this point, and certainly for all the listeners, I think this is one of the most salient points of this decade, actually, which is going to be a weird thing to say. At least an infrastructure’s the following.

In the past, how did we create mindshare and customer bases? Well, there’s this whole pmm function and this whole sales function. And if you look at the big enterprise companies, if you look at Cisco and IBM and Oracle, really their power is this function. They own the sales channel.

They have great relationships with the analysts, they’ve got great relationships with the customers, they’ve got certifications and the classes. So anytime they have a new concept, they take that concept and they cram it down the machine.

As a startup, it doesn’t matter how cool your technology is, the hardest thing is to actually penetrate that channel.

But when it comes to this new era of open source, now you actually have this hack that’s never existed before, where the buyer is shifting from an operator to a developer. Developers like open source, and you can actually create these concepts by getting open source out there and getting them to use it.

Paul: We’ve been talking about this sort of thing, just the idea that it’s bottom-up now versus top-down.

Martin: Not only that, it’s a totally different buyer that’s a totally different aesthetic. I don’t think developers care as much about analysts. I don’t think developers care as much about the 42-long sales dude with white teeth and the boat. I don’t think developers care as much.

Paul: They won’t even answer his call.

Martin: Exactly. About the channel, I think they don’t care about complex procurement processes.

Edith: Having sold software for a little bit myself, if you get into a bigger corporation, you still don’t start to run into that.

Paul: You get there, because the developers were first asking for it to exist.

Edith: The longest part of our sale cycle is you get bounced to procurement and legal.

Martin: Absolutely. I think this is the most important nuance of this argument, is exactly what you said. I’ve always maintained that open source and the developer is replacing marketing and pre-sales, not sales.

You get credibility to the account, you can get things to technical close and technical validation, you can get account pull. So it’s almost like filling the pipeline, getting the transaction done, I still believe. For a long time, you need to have a professional, direct sales force that will be in there pushing things for procurement.

Edith: It’s just a lot of work, because you pass the technical evaluation. They’re like, “Okay, go talk to procurement.” And to procurement, you’re a widget.

Martin: Right, but the good news is, now it’s possible. Where in the past, to get that much legitimacy, to get things to technical close, was very difficult. You didn’t have the certification, you didn’t have access to the buyer, you didn’t have the account rep to make the introduction. You didn’t have any of that.

Edith: That’s true.

Martin: And now you do, and now it’s just about actually going through the logistics. And you’re absolutely right, it’s hard, it’s baroque. I’ve called it tribal bloodletting. It’s all of that, but you can do it as a startup.

Paul: The thing that I think is really interesting is the converse of that. It’s that people who work in open source now are becoming actually incredible marketers. They don’t refer to themselves as such, but they have amazing social media presence.They build up tons of channels, whether it’s mailing lists or just Twitter followers.

Edith: It’s like everybody recreates marketing. Everybody’s like, “Oh, we don’t need marketing.” Then you’re like, “Well, what is this thing over here where you have an email list?” Oh, that’s not marketing.

Paul: It’s not marketing because I’m a developer.

Martin: I really think that those that know how to do this are some of the most valuable people in the entire industry because this is the new entree for products into customer bases. I mean, there’s another kind of potential pitfall here, which is, let’s say you’re using open source for marketing.

Now, there’s probably $7 billion have been invested in open-source companies and only about a $1 billion worth of returns. I’m not sure if those numbers are true, but I hear them quoted all of the time. But the reality is, a lot of money’s gone into it and not a lot of money has come back.

The reason is because now, if you’re using open source to do marketing, you’re almost cannibalizing your sales motion. And so for a long time, the only open-source model we knew how to work was the Red Hat model, which is a services company. Only Red Hat’s ever pulled it off. It’s been very difficult.

But another shift has happened in the last few years is people have figured out that actually you can use open source for marketing, but you don’t have to confuse that with your actual product offering.

And with the rise of services, you can actually use open source for customer traction. You can monetize the service, and when it comes to services, no discussion of open source or closed source. So I think that we’re actually starting to unlock viable business models where you use open source for marketing.

Edith: Who do you think does a good job of that?

Martin: I think GitHub is a great example, right? Git isn’t even built by GitHub. It’s the standard in Linux. But if you look at GitHub, it’s a very fast-growing company that’s based on open source, and so everybody knows about it because of Git. So Git is doing the marketing. And this is just one example, I think there are many.

Paul: It’s funny that you cite that as based in open source, because almost none of their stack is actually open source.

Martin: Exactly, it’s a service offering. That’s what I’m saying.

Paul: When you say service, you’re referring to software as a service, not service as in consulting?

Martin: Absolutely. I should’ve been more clear. The long-standing question for us, certainly since 1995, is how do you build an open-source company that has the margins of a closed-source software company? Because you’re open source, basically you become a service and support company.

What has happened in the last decade is exactly what you’re saying: people will realize that you can get account credibility and account traction, account knowledge, through open source.But then you can offer a back-end service offering as a service offering, and monetize that, and it’s often a closed-source stack on the back end of what you’re doing.

But you don’t talk about open source/closed source as much with service offerings. It’s normally if you’re consuming something on-prem that you think about those things.

Paul: How do you feel about this? People who are building, let’s say CircleCI as a good model, but there’s a ton of them. Building something that’s a SaaS product, a hosted SaaS product, but that then sells to people who use it in their own VPC and pseudo on-prem sort of thing.

Edith: Oh gosh.

Martin: I come from this somewhat traditional world of selling enterprise software. In there, there’s this whole discussion, and I was part of this discussion, of is it on-prem or is it off-prem in general? And I think that you framed this question perfectly. I’ve realized that that’s a false dichotomy. It’s actually not the right question to ask. I think as a service, is it actually an operational model and a delivery model? It doesn’t really matter if it’s on-prem or if it’s off-prem.

I think that the days of selling closed-source software to companies is done.

But you can sell them services and you actually can sell them appliances. But if you look at appliances, appliances almost look like services. They’re boxes that have services, and often the upgrade is happening remotely, management is happening remotely.

I do think that the right model for these companies, I think CircleCI’s a great example of this, you have open source that customers use, you have a SaaS offering, but you also have an on-prem delivery offering as long as you don’t change the operating model, as long as it still looks like a SaaS model somehow, whether it’s a managed service or something like that.

I think as soon as it becomes shippable software, where you have to manage a heterogeneous set of environments, you have to manage all the day-two ops. It becomes unwieldy.

Edith: I had a really interesting discussion the other day with the VP of Sales from CircleCI and somebody from Microsoft. CircleCI was basically like, “We love that it’s selling on-prem. It’s helping you.” Microsoft is like, “We’re trying to get off-prem desperately.” So it was not the argument you thought was going to happen.

Paul: I think it’s probably because of how sensitive the IP is. If you’re talking about something like, well, documents are pretty sensitive, but the source code is very sensitive. And so people are not as happy to ship that off-prem as we once thought was going to be the case.

Edith: Microsoft’s reasoning was, and this might be the way Microsoft had done it, is they have 10-year maintenance agreements.

Martin: We have, “If you have a problem, upgrade to the latest version and then we’ll deal with you.” I think that’s kind of what everyone has. There used to be this idea that you’d create a fork and then you’d backport things to that fork or the old version, or something like that.

I don’t know anyone who’s doing this sort of services, the SaaS with a managed to on-prem version that does anything but “the latest version is the version.”

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

— Malia Powers

September 19, 2016
DevOps Experts Unite on Video Podcast Series
To remain competitive in today’s software-driven economy, organizations of all sizes are investing in DevOps to become better at releasing software. Although the ROI is evident in the IT and business performance of organizations that have successfully implemented DevOps practices, the journey still can be challenging.

There are troves of resources available to help companies begin or continuously improve along their DevOps journey. However, oftentimes it’s the practitioners—experts from the community who live and breathe DevOps every single day—who can offer the most insightful tips.

To that end, Electric Cloud hosts a community video podcast series titled, “Continuous Discussions” (#c9d9, for short). Each episode focuses on a different topic and brings together a group of expert panelists to discuss all things DevOps, Agile and continuous delivery (CD).

Why? Because we all understand DevOps is a team sport. It’s all about collaboration: bringing people together and continuously improving through shared learning and experimentation. Community is at the core of any DevOps initiative, and connecting with peers and sharing experiences is the best way to accelerate our mutual success—so we can all get better at delivering software, together.

These casual #c9d9 chats are often funny, entertaining, thought-provoking and—always—educational! These are a great way for the IT community to pinpoint emerging patterns, discuss challenges and highlight tips and best practices for modern software delivery, in topics including continuous improvement (CI), deployment patterns, security, DevOps culture, microservices, containers and more.

Out of the 50 episodes that have aired to date, featuring more than 150 guest speakers, below are 10 of our favorite recent discussions:
1. Continuous Discussions (#c9d9) Podcast: Episode 34 – Microservices and Continuous Delivery
“In the microservices world, individual features might end up being their own services that are completely well understood”

– Daniel Rolnick, Yodle

Microservices are all the rage right now, and the industry is still learning, experimenting and developing patterns, for successfully designing, deploying and managing microservices in the real world. Are you considering jumping on the microservices wagon? Learn from experts at Kik, Yodle and Semaphore, as they share their journey and learnings from decomposing their monolithic application into microservices.
Featured Panelists:

Daniel Rolnick
Daniel is the CTO of Yodle, a SaaS platform for small businesses, where continuous delivery is a way of life.
@YodleTech | www.yodletechblog.com

Darko Fabijan
Darko is co-founder of Semaphore CI, helping teams deliver software faster. He currently is focusing on scaling Semaphore team and architecture.
@darkofabijan | semaphoreci.com/blog/

Usman Ismail
Usman is a server and infrastructure engineer, with experience in building large-scale distributed services on top of various cloud platforms.
@usman_ismail | techtraits.com
1. Continuous Discussions (#c9d9) Podcast: Episode 46 – Deployment Automation 2.0
“When you treat configuration like first-class citizens, only then can you have your deployment product succeed because your product depends on the deployment configuration being right.”

– Juni Mukherjee, author of “Continuous Delivery Pipeline – Where Does It Choke?”

To enable fast, reliable releases, deployment automation is a must. This episode discusses the prerequisites and best practices for automating your deployments and ensuring zero downtime and fast mean time to recovery (MTTR) when deploying large-scale mission-critical apps. We also talked about the key differences between the first-generation of deployment automation and deployment automation 2.0, and riffed on what we have to look forward to for the next iteration of deployment automation 3.0.

Featured Panelists:

Juni Mukherjee
Author of “Continuous Delivery Pipeline – Where Does It Choke?”
@JuniTweets | techbeacon.com/contributors/juni-mukherjee

Martin Cron
Technologist, writer, photographer, teacher, evangelist, diplomat, heretic
@martincron | martin.cron.com/

Robert Firek
Software craftsman at Codurance. Devops engineer. Java programmer. Agile practitioner. He strives to create software according to the rule, “Simplicity is the final achievement.”
@robertfirek | codurance.com/blog/author/robert-firek/

Paul Reed
Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec, and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity and human factors.
@jpaulreed| jpaulreed.com

Taco Bakker
Taco previously worked as a Team Lead for a large international bank, spending most of his time bridging Dev and Ops. Today he’s a LEAN Six Sigma black belt focusing on CD.
@tsbakker65 | www.tsbakker.nl/taco.html
1. Continuous Discussions (#c9d9) Podcast: Episode 43 – DevOps and CD for Non-Web Applications
“Firmware is updatable and I think the whole notion of being responsive to change is ultimately a very powerful characteristic of firmware and one that ultimately, along with the performance you get from it, is going to be an important part of solutions as we go forward.”

– Stephen Hendrick, ESG

If you think that DevOps is only for web apps, think again! Some of the largest organizations in the world focused on hardware manufacturing, embedded systems and IoT are proving the value of DevOps for the delivery of complex physical products that are integrated with software components. Watch the podcast to explore the differences between continuous delivery for webware and firmware, and listen to panelists discuss the challenges and patterns for successfully implementing DevOps for non-web apps.

Featured Panelists:
J. Paul Reed
J. Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec, and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity, and human factors.
@jpaulreed | jpaulreed.com

Juni Mukherjee
Author of “Continuous Delivery Pipeline – Where Does It Choke?”
@JuniTweets | techbeacon.com/contributors/juni-mukherjee

Mark Dalton
Enabling Enterprise Software for Continuous Everything.
@mdalton323 |autodeploy.net/category/blog/

Stephen Hendrick
ESG Industry Analyst covering application development and deployment software.
@sdh_esg | www.esg-global.com/stephen-hendrick
1. Continuous Discussions (#c9d9): Episodes 29 and 45 – Security & Compliance as Part of Your DevOps Processes
“In order for you to audit and trust the system, you need to make sure the system hasn’t changed over a period of time. Have a test that shows whatever you put in, the results that come out are predictable.”

– James DeLuccia, PwC

Listen to expert panelists explain how to bake-in security and compliance to your DevOps processes. Find out how DevOps and automation can help you pass your next audit. Key focus points include what it takes to get everyone on board with DevOps; how automation equals auditing, with some discussion on industry-specific regulations and compliance requirements; and how to enforce security for the code and for your environments and configuration.

Featured Panelists:

James DeLuccia IV
Technologist, author, security evangelist, risk manager, entrepreneur and runner. James is the author of, “IT Compliance and Controls: Best Practices for Implementation” and “How Not To Be Hacked: The Definitive Guide for Regular People”
@JDeLuccia | pcidss.wordpress.com

Jonathan McAllister
Jonathan has been creating automation software since he was a child. Professionally he leverages 10+ years of experience in software development, test and delivery practices. He is an author, automator and business consultant.
@jmcallister80 | www.masteringjenkins.com/

Nikhil Vaze
Staff software engineer at Electric Cloud. He is a full stack engineer and loves to hack on things. Nikhil holds a Master of Science in Security Informatics.
@therealnikhil | http://electric-cloud.com/blog/author/nvaze/

“The safest environment is the one you don’t let humans muck around in.”

– Martin Cron, WiserCare

Featured Panelists:

Andreas Wittig
Cloud Specialist. Author of “Amazon Web Services in Action.” Software engineer, speaker, teacher and consultant.
@andreaswittig | cloudonaut.io

Dave Bechberger
Senior architect and developer with a passion for delivering solutions to challenging problems in difficult domains from concept to delivery.
@bechbd | experoinc.com/author/dave.bechberger/

J. Paul Reed
J. Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity and human factors.
@jpaulreed | jpaulreed.com

Martin Cron
Technologist, writer, photographer, teacher, evangelist, diplomat, heretic
@martincron | martin.cron.com/

Sukhbir Dhillon
When Sukhbir isn’t coding, dreaming of automation or being the founder of Addteq, he is at home playing with his 2-year-old daughter.
@addteqsukhbir | nebula.addteq.com/blog
1. Continuous Discussions (#c9d9): Episode 21 – Implementing a DevOps Culture
“One expectation I like to lead the conversation with is, if you are a non-trivial software business, then guess what? You are in competition with every other software business in the world. So, you have two choices: evolve or die.”

– Aaron Lee, Pythian

This podcast offers tips, best practices and real-world examples of how organizations can navigate the cultural shift to Agile, DevOps and continuous delivery—from the leadership’s perspective, as well as at the teams’ level. Hear expert advice on how to facilitate silo-busting and system-level thinking and how to encourage experimentation, support a blameless culture, constantly practice for game day and more.

Featured Panelists:
Aaron Lee
VP of Transformation Services at Pythian. DevOps practitioner committed to creating successful business outcomes for clients.
@observator | www.pythian.com/blog

Alon Becker
DevOps architect at AOL. Alon is involved in DevOps transformation at several companies, both startups and enterprises.
@alonbecker

Mike Kavis
VP/principaI architect @ CloudTP Analyst at Forbes and The Virtualization Practice. Author of, “Architecting the Cloud.” No hype, just lessons learned.
@madgreek65 | www.cloudtp.com/insights

Randy Bias
Randy Bias, VP Technology, EMC former founder of Cloudscaling (acquired by EMC) and director at the OpenStack Foundation.
@randybias

Robert Kalweit
Certified ScrumMaster with 7 years’ experience and an Agile mindset that helps to execute tasks efficiently, on time and with personal heartiness.
www.kalle-online.net/blog/agile
1. Continuous Discussions (#c9d9) Podcast: Episode 41 – Creating an Internal Dev/Test Cloud
“While there are multiple approaches for implementing an internal Dev/Test cloud, you need to make sure that you pick a solution that is adaptive.”

– Kelly Looney, Skytap

The need to speed up feedback loops, simplify dev/test processes and collaboration and also save on infrastructure costs has led many organizations to create a private Dev/Test cloud to standardize their processes, tooling and environments across teams. This podcast takes a deeper dive into some of the challenges and prerequisites for enabling a self-service shared platform for the software delivery pipeline across dev and test, and some tips and best practices for getting started.

Featured Panelists:

Chris Riley
Helping bringing #DevOps to the enterprise. Analyst @fixateio
@HoardingInfo | devopsy.kinsta.cloud/author/chrisriley/

Himanshu Chhetri
CTO @ Addteq, specializing in DevOps & Atlassian Tools implementation.
@0xhimanshu | nebula.addteq.com/blog

Kelly Looney
Regional consulting manager at Skytap.
@krlooney | www.skytap.com/blog/

Phil Dougherty
Phil has over 10 years of experience building the backbone of the internet, from multi-continent private cloud environments to fully automated public cloud infrastructure powering mobile commerce APIs.
@phildougherty | blog.containership.io
1. Continuous Discussions (#c9d9) Podcast: Episode 36 – ITIL and DevOps
“Take a user-centered design approach to everything you do.”

– Jeff Sussna, DevOps writer and speaker

During this discussion, we uncovered the similarities and differences between ITIL and DevOps, and discussed tips for how to align the two methodologies in an organization.

Featured Panelists:

Jan-Joost Bouwman
Jan-Joost works at ING as ITSM process owner, adapting ITIL to an Agile Way of Work. Previously he worked in various roles in systems development.
@JanJoostBouwman

Jeff Sussna
Consultant | Writer | Speaker. Design Thinking + DevOps. Author of “Designing Delivery: Rethinking IT In the Digital Service Economy.”
@jeffsussna | medium.com/@jeffsussna

Kaimar Karu
Head of ITSM at AXELOS – custodians of ITIL & PRINCE2 / President at #itSMFEstonia / Service Management enthusiast / Beer sommelier / Food writer
@kaimarkaru | www.axelos.com/news/blogs/

Simon Morris
Interested in the mechanics and techniques of highly performing teams, whether in the world of technology or not.
@simo_morris | community.servicenow.com/people/SimonMorris
1. Continuous Discussions (#c9d9) Podcast: Episode 33 – Measuring DevOps
“The way we build software when it’s always releasable is fundamentally different than when we build to a release. The flexibility and agility comes from building it iteratively—where you’re always able to go in and change it. That, I think, is the main advantage of CI and CD.”

– David Bernstein, To Be Agile

Panelists review some of the metrics that matter for the different stakeholders throughout the software delivery pipeline. Learn best practices for some of the metrics that you should be monitoring to track your DevOps efforts, and—equally important—some of the metrics you should abandon.

Featured Panelists:

Chris Riley
Helping Bring #DevOps to the enterprise. Analyst @fixateio
@HoardingInfo | devopsy.kinsta.cloud/author/chrisriley/

David Scott Bernstein
David helps teams adopt practices such as test-first development and refactoring at hundreds of companies around the world. David is also the author of, “Beyond Legacy Code.”
@ToBeAgile | tobeagile.com/blog/

Ketil Jensen
Ketil is a passionate learner and practitioner, always looking for better ways to work. Loves to help organizations continually improve.
@ketilj | ketiljensen.wordpress.com
1. Continuous Discussions (#c9d9) Podcast: Episode 32 – Orchestrating Your Testing Suite
“If you can test it underneath the UI, you probably really should be testing it under the UI”

– Chris Kent, BTI360

Get an in-depth review of best practices for orchestrating enterprise software testing. Panelists discuss some of the challenges and proven patterns used to test critical software quickly and efficiently: What does your test matrix look like? How do you define the pathway through your test cycle? How do you use automation and service virtualization? How do you manage test environments and data? And more.

Featured Panelists:

Alex Cowan
Alex has been an entrepreneur (5x) and intrapreneur (1x). Currently helping create digital innovators @DardenMBA & advising companies. He talks too much.
@cowanSF | alexandercowan.com/blog/

Chris Kent
Chris loves crafting enterprise apps with ATDD, TDD and clean coding. You’ll also find him reading, outdoors or at a local brewery/winery.
@thirstydev | www.bti360.com/author/chris-k/

Hugo Hendriks
Hugo is a freelance integration consultant based in the Netherlands with the focus on Oracle Fusion Middleware, Java, open source and Scrum.
@R3DR0CK | www.redrock-it.nl

Kate Abrosimova
Director of content at Yalantis and tech journalist, who likes to create things, write about technology with a focus on mobile and collaborate with tech teams.
@kateabrosimova | yalantis.com/blog/
1. Continuous Discussions (#c9d9) Podcast: Episode 27 – Architecting for Continuous Delivery
“The pipeline is not so much about ushering code out to production, it’s finding ever opportunity to reject a harmful change prior to letting it get into production. So, the pipeline is an essential part of risk management.”

– Michael Nygard

To get to CD, applications and delivery pipelines must be architected in a way that supports the more frequent pace of smaller, incremental releases. On this episode, we discussed some recommendations for constructing a flexible, versionable, reviewable, test-able, revertable and resilient application architecture and CD pipeline.

Featured Panelists:

Aater Suleman CEO of Flux7, helping companies use AWS infrastructure to improve business agility and continuity. Flux7 deploys web apps across various technology stacks.
@FutureChips | blog.flux7.com

Graham Smith
Dr. Graham Smith is head of software engineering at the UK Hydrographic Office, championing continuous delivery by day and blogging about it at night.
@GrahamDSmith | pleasereleaseme.net

Marcus Rehm
Software engineer and business intelligence developer for Odebrecht Ambiental. Agile and Automation enthusiastic that always is looking for ways to improve products and process.
@marcusrehm | marcusrehm.github.io

Melvin Laguren
QA automation lead at Wrap Media. Melvin has worked at various start up and enterprise companies developing automated tests and working on CI/CD pipelines. He spends his “free” time speaking at meetups/conferences, teaching QA workshops and working on a weekly comic strip, www.melvinisms.com.
@mlaguren | www.laguren.net

Michael Nygard
Michael works for Cognitect. Has written and co-authored several books, including, “97 Things Every Software Architect Should Know,” and “Release It!”
@mtnygard | blog.cognitect.com/

With such great conversations, it’s certainly hard to choose…

Some of our other favorite episodes include our live broadcast from Mobile Delivery Days, DevOps KPIs with Gene Kim, Docker & Containers, CI & CD for legacy applications, Agile in large enterprises, and more.

Continuous Discussions (#c9d9) airs every other Tuesday at 10 a.m. PST. You can watch all previous episodes of the podcast and also subscribe on iTunes here.

About the Author / Anders Wallgren

Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings more than 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.
August 31, 2016
Don’t Make Me Code: Environment Protection

Thanks for listening to “Don’t Make Me Code,” a Heavybit podcast that discusses developer experience design and the unique challenges of building developer-facing products. “Don’t Make Me Code” is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

In this episode, Steve and David are joined by Sean Li, lead product designer at Docker. Sean, Steve and David discuss Docker’s acquisition of Kitematic, the friction of attempting to replace a developer’s existing tool, and the increasingly prominent role of design in developer tools.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/274576622?secret_token=s-QHiyf” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

Steve: We’re calling this episode of “Don’t Make Me Code” “Environment Protection,” and we’re here with Sean Li, lead product designer at Docker and one of the founders of Kitematic.

Sean: Thank you.

Steve: Thanks for being here with us. This is a really exciting conversation for me because we get to talk to a product designer for a company like Docker.

Sean: It’s good to be here.

Steve: Kitematic is a real interesting project for a bunch of reasons. I mean, it caught the interest of Docker. It’s also proven to be a really novel bit of development environment technology. And so we’re curious how it all got started.

Sean: It got started in a university dorm room. I was a student from University of Waterloo in Canada, and the school actually offers a pitch competition. So we had this idea around making development environments easier, and so we pitched the idea and won. That’s how we got enough money to get started.

Steve: Wow, and was it at all tied to Docker at that point?

Sean: Docker was actually what we used for the back end. At the time, Docker was version 0.3. And then we’re on Hacker News, and we’re like, “Oh, this is interesting. It could be super useful technology to do what it wanted to do.” Our idea was essentially like Dropbox for your code.

You get a Dropbox-like icon on your task menu, and then you can put code in it. For example, Django, it would just run it for you. And you can see it on the browser.

Steve: Oh, nice. And so you have your production environment there, compiling for you and ready to go.

Sean: Yeah. Then, when you added the code, it will sync to the cloud environment and then update right away.

Steve: Nice. That’s awesome. It’s like a step beyond GitHub. It’s not just committing the code; all the CI and everything is built into this one workflow.

Sean: That’s like the future plan right at the time, but at first, our MVP was super simple—just syncing code to a remote server and then seeing the changes.

Steve: From the beginning it was implemented as a desktop application, you said like a Dropbox tray application.

Sean: Yeah, because Dropbox was obviously the inspiration.

Steve: And so why a desktop application?

Sean: At the time, we actually didn’t realize the power of desktop application yet. At one point we used to pivot a lot, as startups usually do. And then we’re talking to customers, and they start realizing what we’re using underneath.

We talk to Canadian Tire, the biggest retailer in Canada. They were looking for something like this, and they’re like, “Are you using Docker underneath? We want to use that.”

At the time, the product we have is in the cloud, like an on-prem web browser setup. And then we started thinking of, instead of abstracting away Docker, why don’t we embrace it and then make it easier for the customers? Then we start brainstorming ideas, and it came across that having a desktop application is actually super beneficial.

It’s like the best platform for developers, because they can import their code super easily. They can open a directory instead of having to upload files in a browser. You can also get a lot of access to their desktop, so once your tool gets more powerful, there’s more things that you can do.

It’s also super cool because we use Chrome in an electron shell. And we wrote the UI in React, so that means we only have to worry about how the UI runs in that one browser, instead of having to worry about browser compatibilities across the board.

Steve: So it’s not something React needed, it’s just running in a web view in the electron browser.

Sean: And we make it feel as native as possible.

Steve: All right, nice. So it’s a true desktop app in many ways, but specifically the UI, it’s a web UI.

Sean: A lot of inspiration comes from the Atom Editor by GitHub. They’re using the same technology.

Steve: And so this whole bit was open-sourced from the beginning?

Sean: We were working on it, and then we open-sourced it.

David: I’m curious what made you decide as you’re releasing this tool. Was open-source service a strategic decision, or you figured you could get more users by doing that? Or is it just wanting contributions from the community? Could you talk through a little bit of your inspiration behind that?

Sean: I think the biggest part is if it’s something that touches their code, it’s really important that the developer trust it by seeing what the code is like.

We’re really open about what we do, and also the part on gathering the feedback from the community is super, super helpful. I feel like, in general, open-source projects get more feedback from the community.

Steve: With developer tools it seems like a great way to encourage participation. If you’ve got an open-source project, you’re inviting people to contribute. Obviously, our Opsee product for example, it’s closed, a SaaS application. So we don’t have the level of community support from developers that we would really like in some ways.

Sean: We hired an engineer from Docker because he was a maintainer and he was super passionate about the project. It really helps on that front as well.

Steve: Following from that, you launched this to an open-source community, did you have an idea of the kinds of users you were targeting at that point?

Sean: We sort of did from the original product that we had, the Dropbox-for-code product. We had a signup list. A lot of these users are more leaning towards willing to use UIs and prefer something simpler. The super active ones are actually consultants that work on multiple projects.

Steve: That’s an interesting segment. People there, maintaining a lot of projects, and they’re looking for an easy way to keep track of all that stuff. And Kitematic fit that mold.

Sean: Yeah, and Docker being isolated also provides that value.

Steve: That too. Now, if I’m maintaining multiple projects, I can have a Docker environment for each one. The app makes it very easy to move between those. And so specifically the React UI and the GUI, what was it like having that be part of the open-source project? Did you get contributions for that as well, or was that entirely internal?

Sean: The React UI helped us in a way, because React is, according to a Google trend, almost on the same trajectory as Docker. So there are a lot of people willing to work on something that’s built in React. It was in a way accidental, because when we started, it was a really good technology to use.

Steve: Did you have any designers contributing to the project?

Sean: We do have design-minded people but not professional designers.

Steve: For example, you’re a lead product designer at Docker and you, I assume, identify mostly as an engineer, or your background in coding. But there’s definitely this hybrid world in the developer tool space.

Sean: Definitely. In the beginning we had hackthons. A lot of participants were trying to add features to Kitematic, then make a huge effort on figuring out the right UI right experience to build there. By default, I think what I wanted is sort of like designing an OS.

A UI is very extensible, and you want to figure out the right points where you can extend on it. You actually focus on per component and really set an example of how you extend the current UI. When people contribute, it can follow that pattern. And you only had to make slight adjustments to it.

Steve: That seems true of open-source projects, generally, too. You want build a broad base that people can build on top of and customize.

Sean: Yeah, but the initial effort has to be really strong. Because otherwise you will get swayed by different opinions. And design by committee isn’t always a nice thing.

David: That’s pretty interesting because you oftentimes see open-source projects that are sort of notorious, especially visually, for bad design or design by committee that ends up being a little too weird. I can think of some Linux desktop managers that I won’t name, but Kitematic is actually a beautiful application.

Sean: Thank you.

David: I’m curious how you managed to maintain that, even when you’re doing community-driven design.

Sean: I think a big part of it is keeping focus and actually be willing to cut things. In the beginning, Kitematic actually had build, you can actually build an image and then push it. But to keep focus and make things simple before we figure out the next steps is actually making it run content only.

Essentially the focus of Kitematic was helping users install Docker on their computer. You know, in a visual way, it feels very reliable. We solve a lot of underlying issues with VirtualBox in the beginning. And then after that choose a beautiful catalog where you can click one button and run a container. And then that’s the experience we were aiming for and focused on. So it’s super obvious what to do.

Steve: Did you ever get push-back on those decisions from the community where you had to assert your position strongly there?

Sean: No, I think the community is mainly supportive. What I had to manage was people trying to add too many things that are not focusing on that road map currently.

Steve: I think I remember you saying, on the Software Engineering Daily podcast, that you did end up cutting quite a few things from the product after a bit of time. Can you talk more about that? You were trying to clean it up?

Sean: The one thing that was cut was building images from it. Even though it’s a super important thing, we decided to delay it because we want to do it right. Instead of releasing something super early, and then get sidetracked into different things, we want to keep focus until we figure out this is it.

And then release that as a whole. Talking about cutting more, the next version of Kitematic is sort of Docker for Mac. It really solved the core issues that Kitematic was trying to solve in the beginning, to install Docker reliably on people’s desktops in a way that it almost feels like it’s seamless.

You don’t feel like it is running inside a VM at all, and that’s the goal in the beginning. You install Docker for Mac. When you open the terminal you can type “Docker run,” and it just works.

Steve: Had the Docker for Mac project begun before the Kitematic acquisition?

Sean: It was after the acquisition.

Steve: So you were involved with that from the beginning.

Sean: Yeah, I was the founding member of Docker for Mac.

David: So it’s interesting to think about this this sort of internal debate. I guess with most design questions it’s customizability and configuration versus limited options, and this curated a beautiful experience. I feel like that happens even more with developer tools.

It seems like Kitematic and Docker for Mac, some of these tools, are definitely trending towards the latter there, where you’re removing some of the optionality of Docker to make a better user experience. I think that’s really interesting.

Sean: I think the two tools are, in a way, more complimentary. People usually use Kitematic by having the Kitematic UI side by side with the terminal. So they like the transparency that they’re getting from the Kitematic side, and the sense of it feeling reliable.

“I see things are running. I can check the logs super easy.” On the other end, the terminal is how they’re used to working before, and that was sort of expected in the beginning. And then you go from there. You never want to displace a tool that they’re already using, one they’re so familiar with.

So instead we embraced that but made Kitematic more of a complimentary to the Docker CLI.

Steve: That’s really interesting. I’ve seen similar comparisons made with GitHub and some of their tooling. GitHub has their Mac app and their web UI and stuff like that. And I found myself going to them for things like diffs and comparison, merge states, something where I want to get a lot of text or get some status update.

But for actions, if I want to do merges, everything I’m actually doing with it I’m still doing through the command line. But that’s a really interesting comparison, because it sounds like you’ve made the same distinction. To view things, maybe you go to the UI. But to actually take action?

Sean: GitHub desktop is like a huge inspiration for all these decisions as well.

Steve: I never really heard that distinction made this clearly, that there are certain things that developers are going to continue to want to do through the command line and through terminal. But that we can make the experience better in some ways, like just figuring out whether a container is running or not. That’s really nice to have a UI to see that all the time.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

July 27, 2016