devopsy.kinsta.cloud

Tag: ci-cd

  • DevOps Chat: The CD Foundation, with CloudBees’ Kohsuke Kawaguchi and Tracy Miranda

    DevOps Chat: The CD Foundation, with CloudBees’ Kohsuke Kawaguchi and Tracy Miranda

    A new foundation, the CD Foundation, has been formed under the auspices of the Linux Foundation to serve as the home base for a vendor-neutral movement committed to making it easier to build and reuse DevOps pipelines across multiple continuous integration/continuous delivery (CI/CD) platforms.

    The first projects to be hosted under the auspices of CD Foundation includes Jenkins, the open source CI/CD system, and Jenkins X, an open source CI/CD solution on Kubernetes. Both were developed by CloudBees. Netflix and Google, meanwhile, are contributing Spinnaker, an open source multi-cloud CD solution. Google is also adding Tekton, an open source project and specification for creating CI/CD components.

    Founding members of the CD Foundation include Alauda, Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    In this DevOps Chat we speak with Kohsuke Kawaguchi (aka KK), founder of Jenkins and CTO of Cloudbees, and Tracy Miranda, open source community director for CloudBees. They give us the insight behind the CD Foundation and what the future may be for Jenkins, JenkinsX and CloudBees.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation. Enjoy!

    Transcript

    Alan Shimel: Hello everyone. It’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is about some big news that came out in the DevOps continuous integration/continuous deployment world, CI/CD. That is the founding of the CD Foundation and it’s part of the Linux Foundation. It was announced just this afternoon. I’m happy to be joined by a couple of folks from one of the founding members—really one of the pivotal founding members of the CD Foundation, CloudBees. From CloudBees, joining us, joining us today is Tracy Miranda, who is director of open source community at CloudBees, and none other than KK himself, founder of the Jenkins Project and community as well as founder and CTO of Cloudbees. Kohsuke, Tracy, welcome to DevOps Chat.

    Kohsuke Kawaguchi: Thanks for having us again.

    Shimel: Kohsuke, it’s always a pleasure to have you. Tracy, I know you’re new to this, but thank you for joining with us.

    Tracy Miranda: Yeah, [inaudible].

    Shimel: Guys, big news today. Linux Foundation starts the CD Foundation. CloudBees is one of the founding companies, and if I’m not mistaken, a board member of CD Foundation as well. Is that correct?

    Kawaguchi: Yeah, exactly. We are part of what – I think 20.

    Miranda: Yeah, I think we’re up to 23 members now.

    Shimel: I think it might have been 25.

    Miranda: Wow [chuckle] I think it’s continuously growing.

    Shimel: It’s funny. I spoke to a few companies today after the announcement. They mentioned that they’d like to join in it. That’s for them. I’d like to understand and maybe, KK, this is a question for you. What was the motivation to turn Jenkins and Jenkins X – we’re talking about two significant projects – over to this new foundation and to the Linux Foundation?

    Kawaguchi: From the Jenkins – I have multiple hats to wear in this, but from the Jenkins project perspective, a key part of it is we wanted to create this level playing field that creates – that accelerates the innovation in Jenkins family. The Jenkins family as you know, it’s been benefiting pretty much everyone in every organization, and there are a lot of companies with an eye on Jenkins. We want to drive them more into the project. We move the project forward together. In that way, I think we can do it faster. In case of Jenkins X, it’s been critically designed on a number of projects that’s coming out of the CNCF, which is a sister foundation that is also under the Linux Foundation. It made a lot of sense we’d be bringing these projects closer so that we can again collaborate faster. So those are, I think, very convincing obvious benefits for two projects.

    Now the CTO of CloudBees, CloudBees has been the biggest contributor of behind the Jenkins project. This move made a lot of sense for us as well, because one, our customers rely on a lot of open source projects and ecosystem. When those foundational resource projects that’s driving is strong, then obviously that benefits CloudBees and our customers. I think that’s a fairly obvious move for us as well. Also importantly, we – well, I, talk to a lot of people in the – our customer and prospect organizations and those technical people understand the need and the benefits that the objectivity really brings. I often see them struggling while the rest of the organization around them. Here, I talk about things like money, people, and time to invest in these efforts. It make the necessary business impact.

    I feel like a part of the role that I’m really looking forward for the CDF to play is to advocate the practice of continuously, elevate it beyond the technology practice. Again, like the CNCF for cloud-native, thereby we can make a bigger impact in the world. That’s the kind of thing a single vendor cannot very easily do because people automatically assume the intention behind these things, or a pitch behind them. Open Source foundation, there’s multiple vendors, and also the end user companies like _____ and _____ adds a lot of credibility and authenticity to that message. For all of these reasons, I think it’s kind of a no brainer, a win win win across the board. That’s how I think about it.

    Shimel: I think that’s a great way of looking at it. Tracy, let me ask you, you’re the liaison to the open source community. In this case, we’re really talking about the Jenkins community and Jenkins X. How is this announcement – it’s kind of new still, but what’s been the feedback from the community on this?

    Miranda: Yes, it’s been really, really positive. We’ve been talking to the Jenkins community, well, the Jenkins board members, Tyler and Kohsuke, the kickoff conversations over a year ago. Since I’ve come in as well, we’ve been keen to get everybody involved with how this would shape up. We’re hearing lots of exciting things. Some things we hadn’t even predicted at the beginning. So for example, Jenkins has a very emerging and very strong and enthusiastic Chinese community. They are super excited about using CDF as a way to really expand in China. I think we can look to that for new areas we want to expand into. So yeah, on the whole, very positive. Lots of enthusiasm which is fantastic.

    Shimel: Absolutely. As a matter of fact, I’m somewhat familiar with the Jenkins community in China. One of our partners held the Beijing Jenkins Day while I was out there last year. So I had a chance to meet a lot of those folks firsthand. It was a very enthusiastic group. They’re doing great things there in DevOps and CD as well. I’m sure it’s been used as well as Jenkins X. Actually, one of the founders of the Jenkins X project was presenting there that day. He was in from Australia. It was very, very well received. Back to this, both for Tracy and KK, one of the things I think people really admired about CloudBees was it wasn’t the usual vendor open source project manager relationship.

    So many of these open source projects that are managed by a single vendor tend to be run for the sole benefit of that vendor whether it be OpenCore or Razor-Razorblades kind of thing. Decisions are made for the benefit of the commercial vendor, oftentimes at the expense of the community. CloudBees was always above that. All these years there was an independent board. There was independent steering and governance of the Open Source community and project. With that already in place, KK, does that negate some of the reasons why you would need a separate foundation, or that just accelerates it?

    Kawaguchi: Yeah, so thanks for the nice words. We’re already proud of the way we participate in Jenkins project. I think there are two factors to that. One is number of people who founded CloudBees. They all come from open source background, the _____ folks, RedHat folks. We share a lot of – it’s like a common body. And that really played a critical part in recognizing, understanding how open source community works. The other important part to call out is Jenkins project is not owned by CloudBees. It is an independent project with its own decision-making process. This project, mind you, it came out of the drama with – well, a certain company. I won’t name names.

    Miranda: [laughter]

    Kawaguchi: So I think the people in the community felt really strongly about their independence. So we discussed it. So, in moving to CDF, many – well people are outside CloudBees, they also continue their _____ CloudBees. They’re also very anonymous desire and preference to come over to CDF because they see it as the next step of the governance to ensure this level playing field, which I touched on a little earlier. Then I think that’s been – that was seen as very valuable characteristic. I think the CloudBees has done good things over the past year _____ the project. I think it’s time to also codify and turn it into something more stable and fundamental. I think that’s what this move to CDF signifies.

    Shimel: I think that’s true. I think there’s another element too, KK. When we look at the history of Jenkins, when something is so successful, you don’t see many contenders. That was true with Jenkins. When Jenkins burst on the scene – we don’t have to go into the history of it, but Jenkins burst on the scene, and it quickly became the dominant CI and then CD tool of choice, not only for the DevOps community, but for the software developing and ops communities. Everyone used Jenkins. Recently, in the last year or two, three years, we’ve seen other contenders coming up, many of them commercial.

    Some of them have an open source, open core, kind of program business plan, but nevertheless, people had this, “Well, Jenkins is older, or it’s yesterday. This is tomorrow.” I think by putting it in a foundation like this, it guarantees a tomorrow. It’s the old, “So many eyes on the code, it has to be better” story. With so many hands in the pot, it has – it’ll accelerate faster. So that’s a good thing. I feel like we’re neglectful though. We should mention beyond Jenkins and Jenkins X, there was some other great software programs that were contributed to the CD foundation today, correct?

    Miranda: Yes, that’s right. Would you like to hear a little bit more about those?

    Shimel: Yeah, please.

    Miranda: We’re super excited. One of the other projects is Spinnaker, is what Netflix originally put together for continuous delivery. That is a well-known, a well-loved project in this space. We were really excited they bought into the vision and wanted to be part of it. Then the other project, last year Google announced the Knative serverless platform. As part of that project, there’s a build and pipeline side of it which has been renamed to Tekton. Tekton is the pipeline and build part of – behind Knative. What’s really exciting about this project is that we’re looking as part of the vision of CDF to really focus on integration and sharing concepts and making tools work together. Tekton will be the pipeline engine, set the definitions for which Jenkins X are going to evolve to. Spinnaker are going to look at it too, and for Jenkins’ next generation pipeline, there’s lots of exciting things in the work. Just really excited about all the possibilities coming up.

    Shimel: Sure. We should mention both Spinnaker and Tekton were contributed by Google.

    Miranda: Google and Netflix for –

    Shimel: And Netflix yes, for Spinnaker. But that’s not all. Once a technical oversight committee is formerly introduced, there may be other projects that are – come under the CDF management as well, correct?

    Miranda: Yes. Absolutely. I think one of the things we outlined in the charter is we want to focus on the entire software delivery life cycle. We want to have a whole set of complimentary projects. So we’re  looking – there’s some really exciting projects in the world of mobile and other areas as well. It’s not just cloud. So lots and lots of exciting projects out there. We look forward to welcoming and onboarding those as we develop, and as we get up and running properly.

    Shimel: We should also – I just wanted to mention that some of the other companies involved as founding members of this CDF are Alibaba, Autodesk, Capital One, CircleCI, CloudBees, obviously, DeployHub, GET Lab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP. These are household names out there. This really is a heavyweight list of contributors, and I think guys, that that really talks to just how important CI/CD has become in the modern software factory.

    Kawaguchi: Like I said, it’s kind of on the cusp from growing from just the technology things to more bigger business impact. It took CloudBees all along, and so I’m really excited that this mission, this sense of passion is all shared by so many more companies. I think it makes the message a whole lot more critical.

    Shimel: Here’s another flip side. As this frees up CloudBees to really focus in on the commercial side of things. Though you weren’t – CloudBees didn’t manage Jenkins. The community and the Jenkins community managed itself. CloudBees played a – obviously it was a big role helping – making sure – KK, you’re wearing two hats with that. Now that CloudBees is freed from that, what do you think we’ll start seeing from CloudBees going forward?

    Kawaguchi: Actually, we are doing more than ever in open source. A number of key folks behind Nginx is at CloudBees _____. So just to make sure that this isn’t all a move by _____, trying to wash our hands away from it. In fact, it’s the opposite. At the last time also, CloudBees is getting bigger. We are working on a number of the products and services. So I don’t really see those things as mutually exclusive. I think everyone at CloudBees understands that those are both important parts of our business.

    Miranda: Yeah, and if I add to that, well, this one specific example, the DevOptics project, which focuses a lot on analytics, and these key measures you’re doing your software delivery. That’s one area where CloudBees is going to do a lot more and you’re going to see a lot more, and it’s pretty exciting going up to that next level.

    Shimel: Excellent. I would imagine you would. Tracy, if you don’t mind, this is going to be a change for you and how you deal with the open source community, or you think not really, not too much?

    Miranda: No, absolutely. I think it’s going to be quite different. We’ve got lots of different people working together. I think that’s what makes it really exciting, just having the different perspectives, the different ideas. I always say like with open source, what I’m most excited about is the unexpected things that you don’t really know what they are until they happen, the innovation, or the two people getting together and saying, “Hey, let’s take things in this direction.” It’s so full of possibilities that it’s really exciting.

    Shimel: I think it will be, and I think it’s going to be for sure. You know what, I haven’t read – who particularly from CloudBees is going to hold the board seat in the CD foundation? Has that been announced or decided?

    Miranda: So I’ll be representing CloudBees at Board of Directors, but also Kohsuke is heading up the technical oversight committee, which means he will also be at the board level. We’ve modelled a lot of the charter and foundation rules off the CNCF where it made sense.

    Shimel: Fantastic. That is really good. What about some of the other folks who are on the board of the Jenkins community board? People like Tyler and some of the other folks? Will they be – what will be their involvement going forward, if you know?

    Kawaguchi:  I think the charter will define the structure. It’s just got launched and we will, I think, in the coming days we will have people’s names and so on. I just don’t want to give the wrong information, but Tyler, for example, he’s been pretty instrumental in making this happen. So I expect him to stay involved in this going forward in some shape or form.

    Shimel: Absolutely. I realize it’s only announced today. You don’t have all the answers, but I thought I’d ask. So final question because we’re running low on time here is one of the – you called the CNCF a sister foundation, it would be hard to argue that hasn’t been a really successful effort by the Linus Foundation, and not just Kubernetes. Kubernetes seems to be the star pupil, or star favored child. There’s a lot of projects within CNCF that are really, really doing well. CNCFCon along with KubeCon is – to me, it was the most exciting event I’d been to certainly within the last six months, certainly since Jenkins World. Will there be a similar type of event now for CD Foundation? Or maybe you pitch one grand tent with CNCF for one big conference? Any ideas on that?

    Miranda: Well, first thing we have in place is that we are going to hold our very first continuous delivery summit. We’re going to co-locate that with the new KubeCon which is in Barcelona.

    Shimel: In May.

    Miranda: That’s right. Yeah, getting going quick. That will be our first opportunity to bring a lot of contributors together, a lot of the end user community as well. We just love the projects in CNCF. We want to continue collaborating closely with those folks. I think this will be a great first event. We did just hear today that there’s something like 12,000 people expected at that event in Barcelona. Big, big fans of CDCF.

    Shimel: Yes. I will be there – we’ll be there doing videos. Hopefully, we’ll get to, Tracy, meet in person, maybe do some video interviews there in person.

    Miranda: Yeah, that would be awesome.

    Shimel: Yeah, that would be great. Then, we’ll – I forgot when the next one. Well, after that, the Shanghai in July, and then in the fall is KubeCon back in North America. Will this be an ongoing collaboration or is that – after that, you might do your own?

    Kawaguchi: We don’t know that yet, I think.

    Shimel: Still to be decided. All right, well guys, congratulations first of all, on all of the new today. This sounds just so god darned exciting. It’s good stuff. Kohsuke, what can I say, man? You just keep doing it. Congratulations. Keep it up. Tracy, congratulations. I guess we’ll be hearing a lot more about the CD Foundation in the months and year ahead.

    Miranda: Yes, absolutely. Thanks so much, Alan. This has been wonderful.

    Shimel: You know what? I sound like Colombo. One last question. You’re probably too young to remember that, but anyway, why not CI/CD Foundation? Is CI becoming passé, out of style, we don’t refer to it? Or we’re just so focused on CD? Any thoughts on that?

    Kawaguchi: The practice that surround the continuous integration is still very much there. I just think of it as frontier moving on, and so therefore the concept is encompassing more and more. When we say continuous _____, so the _____ includes all of the things we talked about as CI. It just expanded into something bigger is how I think about it.

    Shimel: Yeah, all right, fair enough. Guys, again, thanks so much, Tracy, KK. Kohsuke from CloudBees on the announcement of the Linux Foundation setting up the CD Foundation and Jenkins, Jenkins X part of it. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to a minute of DevOps Chat.

    — Alan Shimel

  • DevOps Chat: JFrog Acquires Shippable

    DevOps Chat: JFrog Acquires Shippable

    The big news in DevOps today was the acquisition of Shippable by JFrog. This adds a CI/CD solution to the JFrog Enterprise+ platform and further expands JFrog’s end-to-end DevOps offering beyond Artifactory and more.

    In this DevOps Chat, we speak with Shippable CEO Avi Cavale, JFrog CEO Shlomi Ben Haim and JFrog VP of Marketing Ayally Goldschmidt about the thinking behind this acquisition and JFrog’s plans going forward.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, you’re listening to another DevOps Chat. Today’s DevOps Chat has some breaking news. It was just announced this morning—JFrog has acquired or merged with Shippable in a rather, you know, this is big news within the DevOps world, and we’re very, very happy to be joined by the CEOs of both Shippable and JFrog. From Shippable, we have Avi Cavale, and from JFrog, of course, our friend, Shlomi Ben Haim. And joining us from JFrog is Ayalla Goldschmidt, who really runs marketing at JFrog. I’m not sure of your exact title, Yes, Ayalla?

    Ayalla Goldschmidt: VP of Marketing, thank you, Alan.

    Shimel: VP of Marketing—thank you for joining us. So, first of all, to all three of you, congratulations, Mazel Tov as they say in Seattle. [Laughter]

    Goldschmidt: Thank you, thank you.

    Shlomi Ben Haim: [Laughter] Thank you, Alan.

    Shimel: Thank you. And so, you know, Avi, let’s turn it over to you first. I think a lot of our audience is familiar with JFrog, and most of our audience have heard of Shippable, but let’s just lay that right out there. What’s Shippable about?

    Avi Cavale: Shippable is about a modern CI and CD platform. So, our focus is to streamline the delivery—packaging and delivery of software, and that’s kind of where we are focused on.

    Shimel: Fantastic. So, Shlomi, I think I already know the answer, but I’m gonna ask you—why Shippable for JFrog?

    Ben Haim: That’s a great opening question. Actually, Alan, you know JFrog very well. You know that everything starts with the culture, and when we met Avi and the team, it looked like we’d found the brother Frogs in a different company. So, for us, it was just to make sure that the technology and the strategy are aligned. And when we looked at the technology and the next generation of CI/CD that was built by the Shippable team with Avi’s leadership, it was a no-brainer for us.

    Shimel: Absolutely. But the other thing I think we should mention is, you know, JFrog, many people know JFrog from Artifactory, maybe Xray, you know, point solutions that we can call up. Artifactory is a whole platform in and of itself.

    But, really, the big move for JFrog—and if I’m wrong, correct me; Ayalla, you’re the Marketing person—the big move for JFrog was, you know, this JFrog enterprise platform. And, to me, if you’re gonna have an enterprise platform in the DevOps space, you need that CI/CD pipeline kinda delivery capability.

    So, to me, you know, this really kinda helps fulfill that vision of the JFrog platform. Yeah, no, wrong?

    Goldschmidt: Yeah, that is exactly right, Alan. That’s the vision that we have for it. Obviously, we’ll be doing a lot of work here in the coming weeks to clarify the roadmap and the timeline, but you hit the nail on the head. That’s the value that we’re seeing for our customers and what they’re looking to, what they’re asking us for as far as, you know, we love JFrog, we have very happy customers, they love what we do, and they’re looking to take it to the next level.

    Shimel: Excellent. So, let me ask my next question to Avi and Shlomi, and that is, you know, I guess it’s part of the maturation of the DevOps market where all—you know, there are now, everybody wants to offer the whole enchilada. Do you know what I mean?

    Ben Haim: [Laughter]

    Shimel: People aren’t content any more just offering a piece of it, we wanna offer it all, that whole SDLC, we’re gonna help you throughout that life cycle. It seems everyone is pointing towards that, and the money—look, JFrog, it’s no secret, raised $165 million. Some of your competitors have raised also eight figures. That’s where the smart money’s going, towards companies that are building out this end-to-end DevOps framework.

    Avi, is that what you saw at Shippable, and is that what attracted you guys to want to do this deal with JFrog?

    Cavale: Yeah, I think what we are seeing is that there is one thing which is very critical for customers. It’s like—yes, they want the whole enchilada as a single platform, but at the same point in time, they also want a platform that is open, and they want to make sure that they can plug in the tools that they like in certain places.

    So, of course, they want to see the native capability end to end, but extensibility is also super important. And so, what we kind of saw with what JFrog was doing and what we were doing also was that we were being open to everything. I mean, yes, we want to have a standard of how we think about an end to end platform, but we want to be open and make sure we embrace all the practices that developers want to do and extend the platform to DevOps capabilities.

    Shimel: Absolutely. So, Shlomi, Avi makes a very good point here, and that also goes to the heart of JFrog. One of the things about JFrog is that they play nice with everyone, basically, right? You could pick whatever CI/CD platform you wanna work with or whatever—you know, whether it’s Puppet or Chef or the Red Hat software, you know, JFrog works with everyone, so to speak.

    But now, you have an in-house CI/CD solution, so how do you balance that in your go to market?

    Ben Haim: That’s a great question, Alan. I think that what we’ve started to see in the market for more than 12 months now is that DevOps is maturing and the organization and enterprises are looking to get an end to end solution, yet the driving force of DevOps production is still in the hands of the developers, which, obviously, would love to see the freedom of choice and the best of breed options kind of open to them.

    So, you are right. Our universal approach is something that always led us. We always provided our users with the power of choosing their tools pack, and it will still be the case.

    However, on the JFrog platform, what we call the enterprise class, we want to make sure that we take artifacts seriously, from the moment you build it from code all the way to production. And, together with Shippable automation power, together with the integration and the visibility that technology like Shippable can provide to the platform, I think we will be able to combine the two, to allow a better universal approach. So, you can still use your Jenkins, your CircleCI, your other DevOps tool sets. But you will also have a JFrog end to end solution that takes you all the way from code to production.

    Shimel: Excellent. So, Avi, you know, how do you—I’ll reverse, mirror that question back to you, right? How do you see the Shippable team, the Shippable product fitting into that JFrog Enterprise Plus, you know, the Artifactory platform, all of the different tools that JFrog and services that JFrog is putting together—how do you make sure you fit in there?

    Cavale: So, as Shlomi mentioned, right, what is happening is—so, the artifact is something that is immutable, and that’s something that you build and you want to kind of take it through your entire value chain of how you deliver software to your end customers or end devices or whatever they might be.

    The issue is that, if you don’t have the pipes to kind of control that in a high fidelity fashion, you lose a lot of information as you go from stage to stage. Because you’re leaving it up to the customer to make sure all the data is being persisted and you’re keeping all the hooks so that eventually what you’re really trying to do is, you want to be able to go to something that’s running on the end device and be able to track, if there are problems, what are all the pieces that went into actually building that piece of software that is running there?

    So, losing that ability to connect that entire life cycle, all the way from code to the point where it’s running on a device is a very critical piece of DevOps. And what we see is, that kind of, now, our marriage to the whole Artifactory plus Xray and plus distribution, all of those pieces now can be connected through a common pipeline and we’re making sure that we have high fidelity information exchange as things move through this work flow end to end. And I think that’s kind of the critical thing that we are adding to the product.

    Shimel: Excellent. Ayalla, a question for you—you look at, all of a sudden, you’re embarrassed by the riches of JFrog in terms of their product, right, in terms of the product that you have to work with, the products that you can bring to market. But at the same time, at some level, it’s a double-edged sword from a marketing perspective, right? You have so much now, too, that you need to market, that you need—how do you make sort of a holistic message for market that includes all of these pieces and how they fit together and how, if you don’t want to use all the pieces, you don’t have to, either?

    Goldschmidt: You know what, I feel like the luckiest marketing person on the planet. And, you know, Shlomi promised me when I joined this company a little over a year ago that there will be no shortage of news, and he has delivered.

    Shimel: [Laughter]

    Goldschmidt: So, since I’ve joined, the acquisitions, our Series D announcement, and of course, all of the new technologies that we’ve supported along the way, and the most recent exciting edition of support for Go and Go Center, we love all of these audiences and we do actually put in a big effort in tailoring our message to make sure that we’re communicating with a developer first mindset, and that seems to be working for us.

    So, you know, until today at JFrog, everything we’ve built has been through an inbound marketing funnel with an inside sales team. We haven’t had field people knocking on doors, and that seems to be working great for us, and now we’re ready to take it to the next level. But we’ll always remain developer first.

    Shimel: Excellent. Let me—Avi, let me ask you some sort of typical M&A kind of questions. So, is your whole team staying on as part of this acquisition?

    Cavale: Absolutely, and we’re all joining the JFrog family, and so there is really no change to the business and how we are running it. And I usually tell my team that I have a new boss, that’s all—nothing else is changing, and we’re gonna keep marching towards the vision, and all we have is an opportunity to broaden that vision that JFrog brings to the table and we are part of a much bigger family than what we were before.

    Shimel: Excellent. And so, Avi, what do you see particularly as your role going forward, here?

    Cavale: Sorry, was that for me?

    Shimel: Yes, specifically you—what’s your role going forward? Is it just heading up Shippable? I mean, I’ve been in your role, to tell you the truth. I’ve had my company acquired more than once. And, while you still want to maintain your team and run the team, you also need to integrate now, right? You’re part of an executive team at JFrog that has—I will tell you, I think one of the best cultures in the DevOps world or in the tech world, period.

    You know, how do you see yourself? How do you see this changing your role? It’s more than just having a new boss.

    Cavale: I think the way—I’m actually in Israel right now, and we have already started collaborating. So, one of the things that I actually see is that the team is like, it’s all about brainstorming, quick integration. So, my role is to make sure that I’m delivering the products that JFrog’s customers love as well as most importantly the trust that it actually runs the way it needs to be running. And we’ve focused on the CI/CD aspect of it; nothing is changing from that perspective.

    But what I have now is more brains who are kind of helping me think through what we need to actually do so that we are focused on the enterprise and driving towards that, so that’s kind of how I see myself, as part of the team.

    Shimel: Excellent. So, Shlomi, let me ask you, now—what’s next? What worlds are left to conquer? What pieces of the puzzle are missing? What’s next?

    Ben Haim: You know, Alan, I’m sitting here and listening to Ayalla and Avi and this is great. And from people from outside JFrog, they might think that JFrog is trying to complete the pipeline with all kinds of pieces.

    But the one great feedback that I’m getting from the community is that there is no question mark. People understand what are we doing, it all makes sense. Every tier, every brick that we put on the DevOps wall sounds like the right, next logical step.

    But we are the binaries people, and we will stay the binaries people. We will just make sure that this pipe is completed, and when we speak about the liquid software vision, when we speak about continuous update and solving the pain for the DevOps world, we are taking it seriously, and, as you see, we are super determined to complete our mission.

    What next? We have to stay focused, we have to be a great solution to our customers and users as a community. We are very active in the community, providing them with more tools and more capabilities. It is now our responsibility to make sure that Shippable is fully integrated and the user experience is smooth and fun to use, and as Ayalla mentioned, thinking of the developer first and not the full platform story, but the user experience and the fun and simple-to-use solution.

    Shimel: Excellent, excellent. Alright. Guys, we’re about out of time, I think. We’re probably over time. But again, Avi, congratulations. Welcome to the JFrog family.

    Cavale: Thank you.

    Shimel: It’s an amazing culture, and I’m sure you probably already know that, but you’ll continue to find out. Shlomi, my friend, congratulations to you. Keep up the great work. I can’t wait to see you.

    Ben Haim: Alan, thank you.

    Shimel: Thank you.

    Ben Haim: Thank you so much, partner. Thank you so much.

    Shimel: Alright. And Ayalla, always a pleasure.

    Goldschmidt: [Cross talk]

    Shimel: You, my friend, have work ahead of you now. [Laughter]

    Goldschmidt: [Laughter] Yes, I do. The work is just beginning.

    Shimel: Good for you.

    Goldschmidt: Thanks for having us on.

    Shimel: Alright. So, big news today—JFrog acquires Shippable, and another brick in the wall, as Shlomi mentioned. I tend to think of it as more of a Pink Floyd song than any political thing, but it certainly is continuing this DevOps maturation.

    Guys, congratulations. We’ll see you all soon. And for now, that’s a wrap on this DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: CI/CD with the Semaphore Platform

    DevOps Chat: CI/CD with the Semaphore Platform

    As the old saying goes, “speed kills.” When it comes to development, a lack of speed can kill, too. Marko Anastasov and the Semaphore team have strived to make Semaphore the fastest continuous integration tool in the market. With version 2.0 of Semaphore, they believe it truly is.

    With his background in development, Marko brings a unique perspective in leading the Semaphore team. He knows what he and his colleagues like, and that is the road map for Semaphore. Have a listen to Marko tell us in his own words.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. In today’s DevOps Chat, we’re gonna talk about a company called Semaphore. Their website is semaphoreci.com. And I’m happy to be joined today by one of their cofounders, Marko – and I’m not gonna pronounce his last name well, so I’m gonna let him pronounce it himself. Marko, your last name?

    Marko Anastasov: Anastasov.

    Shimel: Anastasov. Correct?

    Anastasov: Yes, that’s correct. Hi, Alan, and thanks for having me. It’s a pleasure.

    Shimel: Thank you for joining us. So, Marko, before we jump into Semaphore, let’s give our listeners a little bit of background on your – who is Marko Anastasov? How did you get here today?

    Anastasov: Yeah. Yeah. Sure. So my core is, you know, I’m a programmer. Big fan of making – I’m a product-guy-slash-programmer. Maybe that’s kind of the intersection where I’m at, so I like making software products. Been doing that kind of almost since I was a kid.

    Shimel: Mm-hmm.

    Anastasov: And the kind of when I started being, let’s say, a professional is when things were going fast on rails, like Ruby on Rails, you know, Web development. And so I got into that, despite being kind of C++ nerd myself, originally.

    Shimel: All right.

    Anastasov: And I just kinda fell in love with ease at which you can kind of make something, put it online, create something useful for other people. I did a couple of kinda noncommercial projects and started a small consultancy, with my cofounder Darko, who is also a cofounder of Semaphore now. And, you know, we’re both also big fans of clean code, doing things – you know, software craftsmanship, all that kind of stuff. And, as we kind of grew ourselves professionally in that whole area, it wasn’t long till we, of course, realized the benefits of processes like, you know – it wasn’t called, really, “DevOps” at that time, ten years ago or something, but we identified, “Okay, continuous integration is obviously a process that any kind of – if you wanna keep moving fast, as you kinda work on a project, this is what you gotta do.”

    And so, through kind of adoption of these practices in our own company and kinda having an eye on an ambition to create a tool that other kind of developers will also find useful, we started prototyping and eventually launched Semaphore in 2012. And, from that point, it’s kind of all we do and it’s been a great ride so far, you know, leading all the way to today’s interview with you.

    Shimel: Sure. Hey, man, thank you. You know what? It’s funny; it’s not easy, but, when you ask people to tell them about themselves, you don’t wanna blow your own horn too much, but you wanna tell people what’s going. And I think you did a good job with it. So let me – before we jump into Semaphore, you mentioned something that I’ve heard from a lot of other developers, people in the DevOps space, whether they be vendors, practitioners, what have you, and that is they were doing what’s called a “DevOps-like things” before we called it “DevOps.” You know what I mean? And so were you into Agile? Was that something that kinda went with that?

    Anastasov: Yeah, I would say yes. Although I never – it was always – Agile itself has always been a bit of a vague concept for me. The first maybe introduction to that kind of thought space, for me, was the “Extreme Programming Explained,” the book by Kent Beck, which –

    Shimel: Sure.

    Anastasov: So it was more like a practitioner’s path for me, so, as you’re in development, working in small iterations, you know, you’re breaking things down, being ready to adapt to change, kind of not being married to some kind of roadmap, and so on. So it was definitely something that we identified as a good way to operate, but even before maybe the Agile backslash – I don’t know. I didn’t use the word “Agile” myself that much, but –

    Shimel: Well, you weren’t doing Scrum or taking Scrum classes and stuff.

    Anastasov: Not really.

    Shimel: But, certainly, sort of the Agile way of doing software development, right, before we called it “DevOps” or anything else, was kinda ingrained in you, if you will. So then I always – and this is something, Marko, I’ve asked other people about – so one of the unique things about DevOps is we sort of build on that Agile, we build on Lean, but, certainly, ops gets involved.

    Anastasov: Yeah.

    Shimel: When did you kinda make that jump, as sort of a programmer/developer, to say, “Hey, it’s really important we get the ops folks, the ops functionality, kinda built in there”?

    Anastasov: So –

    Shimel: And I don’t wanna put words in your mouth.

    Anastasov: Yeah, sure. So, for me, it was about – so I come from a kinda small company environment and that was kinda my beginning. And so, in that kind of setup, if you’re kind of being responsible for a product, means that you’re also responsible for the operational stuff or that there is maybe a shared responsibility among developers to some degree, but there’s always somebody who kinda specializes, at least for a specific project, for doing the operations. And there is – I think it’s very healthy, kind of, for a programmer to kinda be exposed to these things because you – as you kind of experience this firsthand, you kind of  – let’s say you’re ready to – you’re not maybe – you don’t have patience that much for things that kinda get in your way of getting the job done.

    So, if you kind of practice not repeating yourself in writing code, you wanna kind of practice the – try to practice the same thing, when you kinda deal with infrastructure. So I think that’s kind of the line of thought that brought us the kind of infrastructure-as-code, you know, kind of EDU and the movement and the tools force.

    And, once you maybe grow out of that kinda maybe very small team kinda environment, I think what you see then is you see maybe the bigger picture of, if you think of continuous delivery as a broader objective of being able to deploy anything that you’re working on at any point in time, as the ideal state that you wanna be in, then being really good at ops means that, for example, if you’re doing microservices, you’re not really that even Agile in the ’90s, maybe, way, if it takes two weeks for somebody to provision you the resources so you can just get started and write the first lines of code in your microservice. So if that can be reduced to five minutes or an hour or something, that’s really great, so.

    Shimel: Yeah.

    Anastasov: Yeah.

    Shimel: So this is something, Marko, again, back when I first started devopsy.kinsta.cloud, four, five years ago, there was this big debate over “Is DevOps different at a small company versus at an enterprise?” And, of course, there’s differences between working at a small company versus an enterprise, right? In small companies, you do wear multiple hats. You don’t have the luxury of having a full ops team and a full separate dev team and QA and business architects and all that kind of – you know, you don’t have that. Everyone pitches in and does what they gotta do, where, in large enterprises, you sometimes do have that stuff.

    And so, obviously, there’s a difference between them, but, at the end of the day, DevOps is DevOps, right? It’s about doing continuous integration, continuous delivery, and so forth. So I think that’s a – you know, what you’ve described is very not out of the ordinary. I think that’s sort of the path, the track that these things follow.

    Anastasov: eah. Yeah. I think it’s about – whether you’re coming from a small or you’re working at a big organization, ultimately, it’s all about “How do we move fast so that we just kinda of – ” the ideal state is when we’re all kind of in creation mode, all the time or as much as possible.

    Shimel: Sure.

    Anastasov: And it can happen in a small team as much as, I think, in a large team, that things can get stuck, if you maybe – I don’t know – pick the toolset that’s maybe not fit for your needs, where you kind of want to reinvent the wheel or – so I think that, regardless of maybe the team size or the technology stack, the decisions should always be kind of “Okay, what will enable us to kinda stay focused on creating value, versus kinda being maybe, in some ways, slaves to the toolchain?”

    Shimel: Got it. All right. So let’s jump in a little bit – you know, we got off on a bit of a tangent, but let’s talk about Semaphore.

    Anastasov: Sure.

    Shimel: What is it? How did that – I mean, I think you’ve given us a little background on how it came about. Talk to us what’s Semaphore about.

    Anastasov: So Semaphore is – generally, our mission is to enable teams to build great products at high velocity. And we do that by making it as easy as possible to enable continuous integration and continuous delivery processes in their organization. We’ve started way back in – about six years ago, when we launched Semaphore initially, it was like we were looking at the tools available and, from our perspective, services like GitHub or, you know – on GitHub, you do a few clicks and you get your repository; you’re ready to collaborate with other people. We looked at, for example, there were already platforms-as-a-service, like Heroku, for example, where, again, in a couple of commands, you kinda have your entire application up and running and you’re ready to kind of iterate and get something to customers very quickly.

    Shimel: Mm-hmm.

    Anastasov: But, in the area of, for example, just having a scalable continuous integration process, basically, at that point, Jenkins was the only tool that’s available. And kind of this was initially like “scratch your own itch” kind of thing, but, for a lot of people, maintaining and scaling and learning how to do all that, the infrastructure for building and testing their code isn’t really their core business purpose or where they kind of create value. So our initial goal was like, “Okay, can we create something which is as easy to use as, for example, GitHub, but for continuous integration?” so that you just kinda click to connect your GitHub account, select your repository, and we, in many cases, automatically infer what the CI build should be and kind of you’re just off the ground. You have the full continuous integration process automated and running in the cloud.

    And so, pretty soon after that, of course, listening to our customers, we implemented some features that enable continuous deployment so that customers or open-source users can keep track of releases and manage different environments. And so what’ve – throughout the years, we’ve kind of evolved from – so, traditionally, it was mostly about when people think about this space as “hosted CI,” so it’s kinda like there’s some – but, at this point, there’re a couple of options, of course, other companies doing the same function. And I think the perspective’s like, “Okay, it’s very – ” but, at this point, 2018, it’s pretty straightforward to kind of automate the testing, using some kind of a cloud service.

    But that’s not – if we go back to kind of what we also discussed in the beginning, if the goal is to accelerate kinda the entire engineering organization, there’s more to just running tests, you know? So every tech leader wants to – I mean, their objective is to deliver bug-free products to customers as quickly as possible. So we’re talking not just about testing but also configuration and delivery processes that often involve multiple technology stacks, which, of course, evolve over time. Now we have container technology, for example, which we didn’t have –

    Shimel: Changed the game.

    Anastasov: Completely changed the game. So the way to do this is to basically implement continuous delivery so that, step one, you automate all the processes and step two is to kind of optimize them, but using Semaphore for automating all continuous delivery processes has so far been – it wasn’t able to support, let’s say, every process that’s needed, so this is why, this November, we’re excited to present the brand new version of Semaphore, which is —

    Shimel: That’s Semaphore 2.0, right?

    Anastasov: Exactly. Yeah.

    Shimel: Mm-hmm. So, Marko, let me ask you this. I think you guys are pretty proud; on your website, you mention your bootstrap. You know, it’s interesting and, when you look at the CI/CD space, there’s a lot of great open-source, free tools, right? Jenkins, obviously, is the obvious one, but CloudBees, of course, has the commercial version, if you wanna call it. CircleCI, Travis – what’s the other one? – City – I forget the name of it. You and I both know there’s several pretty popular CI/CD tools, ARAs and all of this stuff. What do you think the special sauce is for Semaphore, if we’re talking – and our audience is developer-heavy, DevOps-heavy – why Semaphore versus maybe some of these others?

    Anastasov: Sure. We’ve always been focused a lot on speed, so “How can we not just provide a tool that automates something for people, but can we give them something preferably out-of-the-box, so that they just save time, comparing to whatever else they were using previously?” So one of the kind of foundational things, when you use Semaphore, is that basically we kind of periodically keep measuring this and it always stays true, is that Semaphore is twice as fast, comparing to all other competitors in the cloud space, in terms of just pure performance.

    So this alone can kinda save hours of engineering time to any team. Of course, it depends on the size of the projects and the team, but, if you kinda think back, kind of the fully-service hourly rate of developer in US is about $150.00. So, if you can do something to optimize that, we think it’s a huge win. Over time, we’ve kind of made steps forward, in terms of –

    [Phone ringing]

    Is this somebody from Jenkins calling to – [chuckles]

    Shimel: Yeah, it could be. [Laughs] That was pretty timely, but, no, I think it was something else. Go ahead.

    Anastasov: Yeah. So we provide tools that, for example, automatically paralyze the CI builds for projects, so people – which is, you know, large projects, for medium or bigger-sized teams with 100 or more developers, they typically have CI builds that run for hours. And the feedback loop – the kind of feedback loop in which you find yourself working, as a developer in such a project, it’s a pretty miserable experience. So you kind of become defensive. You work in wandering branches; you don’t merge off and – you know, you have flaky tests and so on. So, essentially, what we’ve seen, when people adopt Semaphore is, if they start using our automatic paralyzation feature, they go from, in some cases, from over 2 hours to something like 15-minute CI build. And it’s literally like they just needed to drag a slider and it worked. So we try to do things that really kind of improve the productivity of the teams.

    And so far, on the market also, it hasn’t been – in Semaphore 2.0, we’ve kinda took a lot of kinda learning that we picked up along the way and from our customers, especially the bigger customers, and, first of all, we made it really easy to create complex pipelines for companies that need to model the continuous delivery processes. On the other hand, what we think is pretty important is that, so far, this kind of cloud-based CI and CD tools – and Semaphore was part of this. In fact, we kind of initiated this idea of kind of charging per worker or per concurrent some kind of a machine that’s executing your stuff, your jobs.

    So, with Semaphore 2.0, we made the decision to kind of provide a service which is, let’s say, truly cloud, so it scales automatically to your needs, so you only pay what you use and you never really have any waiting time, which is a huge bottleneck we see in many organizations. They would maybe purchase some resources on a monthly or annual basis from Semaphore or Circle or some other product, and it’s like, if they are, let’s say, really busy in a certain period of a day or week, their CI just doesn’t process what they need. So we think that, with auto-scaling, developers will always be able to kind of get their work done quickly and stay in the zone as much as possible.

    Shimel: Got it. Hey, Marko, man, I would love to talk to you for another hour about maybe state of developers. And I do think you’re right – while speed is really important, as a benefit or an advantage to Semaphore, I think we’re in a world where developers are the top alpha predator, right? The most difficult kind of shoes to fill, the hardest jobs to get. Giving them an environment that keeps them happy, that keeps them working, if you will, in a good way, is a huge bonus than, frankly, making them work with crappy tools. I’m not calling anybody’s tool “crappy,” but I’m just saying, given the choice, I think developers would – they’d wanna work with tools that make their life easier and make it a better experience for them. But we’re at a half-hour and this was way more than 15 minutes, man, so we’re gonna need to end this. Maybe we can pick it up a second – in another chat in a couple weeks or whatever.

    Anastasov: I’d love to.

    Shimel: But, for now, we’ll call a wrap on this episode of DevOps Chat. Interesting conversation with Marko Anastasov. Close?

    Anastasov: That’s correct. Yeah.

    Shimel: All right. Cofounder of Semaphore. The new Semaphore 2.0’s coming out; check it out – great tool for CI. Until next time, this is Alan Shimel for devopsy.kinsta.cloud and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: CI/CD with CircleCI’s Rob Zuber

    DevOps Chat: CI/CD with CircleCI’s Rob Zuber

    Microsoft’s recent acquisition of GitHub has spurred a lot of conversations regarding which company is the next big acquisition target, and here on DevOps Chat is no exception. In this episode of DevOps Chat, I speak with Rob Zuber, CTO of CircleCI about the CI/CD space, the future of the market and, yes, M&A activity in the DevOps space.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Rob Zuber, CTO, CircleCI. Rob, welcome to DevOps Chat.

    Rob Zuber: Thanks. Good morning.

    Shimel: Good morning.

    Zuber: It’s a pleasure to be here.

    Shimel: Or afternoon, in my case, or evening. Who knows when people are listening to this? But, Rob, thanks for being our guest. I think this is the first time we’ve had anyone from CircleCI on a DevOps Chat here. So, you know, you are a mold-breaker and thanks very much.

    Zuber: I’m excited.

    Shimel: All right. So, Rob, our audience tends to be pretty DevOps-y, and so I’m assuming they know of CircleCI or at least have heard of CircleCI, but maybe they haven’t. So, in case they haven’t, Rob, give us a little background, just a real quick elevator, on CircleCI.

    Zuber: Yeah. So we’re a big part of the delivery pipeline for many software organizations. We offer continuous integration and continuous deployment, both as a cloud offering so that you don’t have to manage any of it yourself, but, if you’re interested in doing that, we also have a server-hosted version. And, you know, our objective is to help people focus on their business and get their software into market faster, taking out of the way the overhead of managing a lot of the tooling around doing that.

    Shimel: Yep. And, Rob, just in way of history and background and setting the table here, CircleCI really is – it was kind of a cloud-native CI/CD solution originally and it’s only relatively recently that you started having sort of an on-prem solution as well, offered as an option. So it’s kind of opposite of the usual SaaS migration, if you will, right, where people turn on-prem stuff into SaaS solutions. You were kind of a SssS solution and now offer an on-prem option.

    Zuber: Yeah, that’s exactly right. And that’s probably partly a function of when the company was started, so CircleCI launched in 2012. At that point, people were pretty comfortable with cloud offerings. GitHub had been around for a little while, so people were used to having the source code in someone else’s servers, and so we were able to leverage that a little bit. And we were able to grow quite effectively off of that base, but we did reach a point where there were very large customers with very specific needs, where it made a little more sense for them to run the software themselves and be able to have a little bit more opportunity to customize the environment in which it was being run, etc.

    One thing that’s interesting about that – and you talk about the difference in which way you go across that transition – because we built a multi-tenant platform from the beginning and really focused on our ability to operate that on behalf of other people, we find that, even in an on-prem solution, especially for very large organizations, we have a lot of the capability around that management at scale and centralized management that doesn’t – that still gives freedom to the individual developers to do their work. So it is actually quite interesting, how the genesis of the product affects how it operates in those multiple environments long-term.

    Shimel: Absolutely. Rob, another area – and I didn’t really talk to you off mic about this, but another area I wanted to explore was, historically, was CircleCI originally just CI or was it always CI/CD?

    Zuber: I think you could kind of look at that two ways. I mean, there was CD pretty early in the product, at least for some particular cases, but, if you look at the evolution of the software industry, many more people were doing CI in 2012 than CD. I mean, it was sort of this slow transition of people getting to, you know, “First, we’re gonna figure out Agile process and just how we do our actual software development. And then we’re gonna add CI on top of that. And then we’re gonna add CD.”

    So we always had some CD capabilities, but the number of our customers or the percentage or breakdown of our customers using CD has grown pretty significantly over that time, and I think that’s partly an effect of the kinds of tooling we’re offering, partly a shift in what CD even means, and then partly just growth in the market and comfort level of people doing that, right? Of – especially – and CD, of course, is always challenging ’cause some people are talking about continuous delivery and some about continuous deployment, but, in particular, on the continuous deployment side, other things had to come into play – you know, feature flagging, canaries, just better control of what it meant to actually put something in production. And so the comfort level and increase in that has led to more people using our platform for CD as well.

    Shimel: Absolutely. You know, as an observer of the space, sort of the market, I’d seen it come – when I first launched devopsy.kinsta.cloud, four years ago, Rob, there was this clear sort of distinction between “We’re not CD. CD is something else. We’re CI,” or reversed – “Those folks are just CI. They’re not CD.” And it kinda just seemed like an artificial wall had been built, right? Not to get all political.

    But – and so I, for one, am happy to see sort of that wall being torn down and the natural flow of the software development life cycle, of the modern software factory, if you will, taking place, where CI kinda naturally flows into CD. And I think the next thing we’re seeing is this natural connection to what Gartner and some of the others call “ARA.” Right? Which I don’t even know what the difference between that and CD is, but I don’t know. What do you think?

    Zuber: Well, I think that, overall, this evolution, as I was saying, it always takes a long time for people to get – or, let’s say, for everyone to get comfortable with each of these stages of the evolution. And we’re always looking to the next frontier, right? So, at one end of the spectrum, you have those early adopters, who, in 2012, were doing CD or before that. I’m trying to think of the original sort of posts around CD that I think came out of, I wanna say, Etsy, but I don’t know if that’s actually true or me projecting kind of them as a pillar of this type of thinking. But, you know – and we’re still at a point where some people are just getting comfortable with and adopting it, so the spectrum is really broad, from early adopters to sort of overall mass adoption.

    And the early adopters have moved on to, probably, things that I haven’t even thought about, and so we’re always seeing that and it’s nice to have people try those things and, in some cases, fail, and, in some cases, discover really new and interesting ways of approaching stuff. And it takes – it definitely takes a little bit of a mindset of “I’m just willing to try this. I’m willing to take some risk and do new things,” and the people that do those create opportunities for the rest of us to learn from, the things that go well and the things that go horribly wrong.

    And so it’s one of the reasons that I just love being in the space in general, is just the constant kind of desire to do things better and find new opportunities, of course, with a good balance towards actually focusing on getting stuff done, but there’s just such a creativity and desire around improving, in any way we can, this process and how we get stuff out and how we build it reliably and work efficiently.

    Shimel: Absolutely. So, Rob, let’s turn a little bit to – we’ve done a nice history. Let’s look a little bit to the future now, though.

    Zuber: Mm-hmm.

    Shimel: Talk to me – what did – how – you’re the CTO. You kinda have a lot of the vision for CircleCI. Where do you see CircleCI and the market in general going?

    Zuber: Yeah. Well, that’s a great question. I think a lot of people’s perspectives of this market was changed a little bit in the last week or so, with news around Microsoft and GitHub and just the value that people are starting to recognize in developers, the happiness of developers, the efficiency, the value that they place on the tools that they use. So, for the market overall, I think we’re just a really exciting time, where we talked about this – or I talked about this creativity and passion to do things better, but we’re at a sort of inflection point where there’s a really, really high-level recognition of the value of that.

    I would say there’s been a significant shift in the mentality of many companies. And we talk a lot about how every company is becoming a software company, in that, even if you’re an airline, your biggest issue, when you ground your planes for a day, is that you have some software glitch somewhere, right? You know, multinational trading markets are shutting down on software issues. So the impact and value of software is becoming really, really visible and, as a result, there’s a shift in mentality about how we build software, from “This is a cost center that I just have to manage down,” to, “This is the core of my business and I need to be really investing and doing this in the best possible way.”

    And so that’s obviously exciting for us. And one of the things that’s really interesting for us, as we look forward, is that we – we’ve had the fortune of some success and growing and, to the best of our knowledge, run the largest or one of the largest build platforms on the planet. As a result, we know a lot about how people are building software, and so we’re investing a lot of our time and energy in figuring out how to use that to then help those people, meaning, if you’re building on CircleCI, you don’t just get an understanding of your particular code change that you just made, but you can get an understanding of how your team is doing, how your whole process is doing, how effective you are, relative to other teams out there.

    And I think that’s a place where we have a lot of opportunity to really add additional value for our customers, in not just, again, direct feedback on this one thing that you did today, but really helping understand your process, maybe where things aren’t working well, maybe where you have some opportunities to improve. We’re all in this, trying to be better every day. And if we can help customers at that at a higher level, that’s really exciting for us.

    Shimel: Yep. You know, it’s interesting you brought up the GitHub thing and to justify all this. And so I have some views on it. What a surprise. But, you know, Rob, couple things. No. 1, when you look at GitHub and the price Microsoft paid, it obviously is a ridiculous multiple to revenue. I saw a chart earlier today. I forgot if they said it was 21 or 24 times revenue, which is wow. Right? That’s why people do software companies.

    But another way of looking at it is, look, Microsoft has always coveted the developer community. And, over the last – I mean, for as long as I’m in technology, 25, 30 years, they’ve done not a crappy job of working with the developer community. Yeah, there are haters and Linux folks and the open source, when Ballmer was there, you know, but they’ve always gone after the developer community hard. And so they had an opportunity to buy a company that has, some estimates say, 28 million people or potential developers, right, in that community that GitHub has. So, when you look at 28 million and what they paid – don’t get me wrong; it’s still a lot of money, but it’s a little bit – you could see where they saw the value, okay?

    Zuber: Mm-hmm.

    Shimel: No. 2, having been in the tech, software infrastructure business a long time, I learned a lesson from my friend Brad Feld, who I sold my first company to and he financed or was one of the key VCs behind many of the companies I’ve been involved in, and that is, look, first mover or first – not the first mover, first acquisition in the space always gets the lion’s share and the best multiple. The second one does okay. The third one does a little worse. If you’re not in the top three, don’t bother. Right? That was something Brad always preached to us.

    So, when you look at Git – or GitHub, excuse me, being the first kind of acquisition in that space, getting this kind of multiple, they deserve it. Right? They were first. They were the first ones bought; they’re gonna get the lion’s share. I think the message to other folks in the GitHub space, specifically, is “Hurry up and get bought ’cause you don’t wanna be number four or five.” Right? You don’t wanna be left in the musical chairs game when the music stops.

    Part and parcel of that, though, Rob, is that companies like Microsoft, like IBM – we used to say “like HP, Cisco,” you know, big, big public entities – it’s very hard for them to be innovative. It’s very hard for them to do their own R&D. It’s very hard for them to build these communities themselves. And so what they would spend in R&D or community actually goes into their M&A budget and they buy those things.

    Zuber: Mm-hmm.

    Shimel: So, when we look at a GitHub, we look at a CircleCI, we look at any – a Chef, a Puppet, any of the – even the Jenkins or CloudBees, any of the players in this DevOps space that is so hot right now – GitLab, another one – they all are gonna be very attractive to companies of a Microsoft kind of girth. Right? Because the big guys can’t – they can’t do what you’re doing, Rob. They don’t –

    Zuber: Yeah.

    Shimel: You know.

    Zuber: Yeah. I mean, I think this is classic innovator’s dilemma, right?

    Shimel: Yeah.

    Zuber: Did I get that right? So it’s difficult. I mean, if you look at the first five year – I mean, we all talk about these overnight successes, right, and they always – they’ve been around for 10 years. And the first five years many of those companies is extremely painful, it’s a grind, and the incremental increase, the amount of revenue you’re driving or whatever, would be so insignificant on any one of these companies’ radar that they just – they won’t put the time and energy into it, right?

    Whereas you’ve got a company like ours or anybody in the space, honestly – I’ve done a bunch of different startups in different spaces – you’re living and breathing it, right? And you’re so tuned into what’s happening that you can see it. And that kind of incremental growth, to you, is everything and it’s super exciting and you get this passion behind it that allows you to build a very focused and, honestly, a great product. And I think GitHub is a great product. And then, suddenly, you have 28 million users – I’m quoting your number so I’ll assume you’re right –

    Shimel: _____ I’ve seen.

    Zuber: And a massive community. You know, and then, going back, as you were talking about the time and tech, I mean, I got into tech with the quarterly mailing of MSDN CDs and, honestly –

    Shimel: Exactly. Yeah.

    Zuber: – my favorite IDE – I’m a Mac and Linux user, almost exclusively, but I used Visual J++ in the late ’90s, when I started doing Java development. It’s still the best IDE I ever used. So Microsoft has been good, very, very good, with developers, but the kind of developer community has started to drift away from where they were going. And so this is – I wouldn’t call it a course correction because they still have all of their community, from a .NET and sort of Windows world, but this is an opportunity to be less about Windows, you know? And we’ve seen Microsoft shifting away from –

    Shimel: Oh, yeah. Satya Nadella’s Microsoft, Rob –

    Zuber: – just pure kinda _____ –

    Shimel: Not to step on you, but Nadella’s Microsoft is a very, very different place than when Steve Ballmer was there. Right?

    Zuber: Yes.

    Shimel: And they are moving to Azure and though Azure does Windows well, it does containers well, it does Linux, it does – you know, there’s very little it doesn’t do.

    Zuber: Right.

    Shimel: You know? And I will tell ya – I’ve told people this – I think, one day, Microsoft buys Docker. That’s my personal opinion. I think it’s another kind of – not to get into it or badmouth or anything like that, I just think someone’s gonna buy Docker ’cause the revenue has to justify the valuation, and so – and Microsoft’s a great candidate to do so. But, anyway, you heard it here first. But, Rob, that’s all fine and dandy. GitHub plays in sort of a different segment of this DevOps market than you guys do, certainly.

    Zuber: Mm-hmm.

    Shimel: And we really haven’t seen the consolidation yet, that I think we will in the CI/CD and, if you wanna call it, ARA space, but it’s coming. I’m sure.

    Zuber: Yeah, we’ve seen movement in the market, but most of it has been off the bottom end, if you will, meaning sort of the smaller people we would consider to be our competitors but didn’t quite reach critical mass and then got pulled in by other companies, for the people or because the product was going to be useful to them internally, that sort of thing. Not a roll up and now we’re taking this and getting it scales or _____ –

    Shimel: So we used to say, when I worked with Brad, those are companies that really were a feature, not a product.

    Zuber: Mm-hmm.

    Shimel: But, with that being said, Rob, we went off on a little bit of tangent here. We’ve used up way more time than we were supposed to. But maybe we could have you back on and – ’cause I wanted to really get into a little nuts and bolts around continuous integration, delivery, what it means for developers, what it means for ops folks, but why don’t we do this? We’ll call it a day on this 25-minute DevOps Chat and we’ll have you back on maybe next month. And let’s get into what it means for developers and ops folks in even testing, in this new world of CI/CD.

    Zuber: That sounds great. I’m always happy to talk about that as well. There’s so much happening in this industry, in this space right now, that it’s hard to keep it short. [Chuckles]

    Shimel: You know what? Hey, man, it keeps my kids going to college, Rob. [Laughs] Anyway, hey, Rob, Zuber, CTO, CircleCI, this episode’s guest on DevOps Chat. Thanks for joining us. This is Alan Shimel. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

    DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

    In this DevOps Chat we speak with GitLab CEO Sid Sijbrandij. Sid has guided GitLab as a co-founder to the heights of the DevOps market. Joining Sid and me is Ashish Kuthiala, who recently joined GitLab. I have always been impressed with the completeness of GitLabs’ vision of the DevOps toolchain and what the company wants to offer. Sid’s vision for this is something he calls Concurrent DevOps. You will hear more about Concurrent DevOps in our chat, as well as in the months to come.

    Another thing about GitLab is is an open source-based company, which allows for a lot of transparency. With hundreds of thousands of organizations using GitLab and thousands of paying customers, GitLab is a great example of a DevOps success story.

    As usual, the audio of our conversation is immediately below, followed by a transcript of our conversation.

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 120255″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Sid Sijbrandij
    Sid saw the first ruby code in 2007 and loved it so much he learned to program and made this his profession. Before that he was engaged in various businesses, from selling programmable infrared receivers to starting a recreational submarine company. He is always looking to publicly document an answer or to make a process more efficient. He was never good at sports but tries to make it up in quantity by hiking, sailing, skiing, snowboarding, speed skating, dancing Zouk, squashing, and running. In love participating in conversations on Hacker News, and reading Marc Andreessen’s tweets (now that Marc stopped this greatly increased his productivity).[/su_pullquote]    Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Our DevOps Chat episode today is gonna be all about GitLab, and we’re joined by two GitLab folks. First joining us is the co-founder and CEO of GitLab, Sid Sijbrandij, and I hope I did that justice. Sid, welcome to DevOps Chat.

    Sid Sijbrandij: Thanks for having me.

    Shimel: Thank you. And joining Sid and I is a friend of mine, recently joined the GitLab team, Ashish Kuthiala. Ashish, I didn’t mess that up too bad, did I?

    Ashish Kuthiala: No, you didn’t. No, that was perfect.

    Shimel: Alright! Well, one of the nice things about tech is, I get a lot of experience. Not a lot of Smiths in the group. [Laughter] And as I said, this is Alan Shimel, and we’re here with DevOps Chat.

    So, guys—GitLab. You know, first of all, Sid, I’m sure you’ve probably heard this before, but I’m sure there are people in our audience who still have to ask themselves, “GitHub, GitLab,” right? And as silly as it sounds, they may confuse them sometimes.

    So, let’s set it straight in terms of GitLab. Sid, you co-founded it. What exactly is GitLab and how does it differ, let’s say, from GitHub, and we’ll go from there.

    Sijbrandij: Yeah, so GitLab started off as an open source alternative to GitHub, where you could have Git repositories, do version control, do some issue management, and it’s now grown a lot as a company and as a project. We now do the whole DevOps life cycle. So, anything from planning to rolling out what you’ve made—CI/CD, packaging, monitoring—all in a single application.

    Shimel: Great. And I think you’re being modest, actually. GitHub is certainly—when you say branched out, it’s branched out, I mean, from what I know, and I’m no expert, obviously, the breadth of the vision is pretty dynamic. So, congratulations with that.

    Sijbrandij: Thank you.

    Shimel: Ashish, you were—thank you. Ashish, you recently joined GitLab, and why don’t you give us out, what’s your position there?

    Kuthiala: So, Alan, I think you and I have known each other for a while, and I am very passionate about the promise of DevOps, especially at large scale enterprises, right? Not smaller teams or not those who had the luxury of building out their infrastructure and teams to adopt DevOps and realize the promises of that.

    We still a lot of the larger enterprises struggle with adopting and realizing the promise of DevOps as it is. I mean, a lot of them are achieving results, but a lot of them are still in the journey and trying to figure out how to get there.

    So, and I had heard about GitLab, I knew that they were building out a solution for this, but I think it was in the last DevOps Enterprise Summit, you, I, and Haydn ran into each other. And I started talking to Haydn and I learned more about the company, and I think it’s just the right product at the right time. Because if you look at all the challenges that exist in the big enterprise, there’s massive transformation needed, and there’s several things that prevent this from moving forward at the speed that everybody would like, whether this is different organizations within the large organizations to get them to collaborate together, whether this is stitching together the different toolset chains to kind of make this seamless.

    And I think GitLab has really built something from ground up that addresses this problem. And the good news is that the velocity at which we are adding functionality, we are adding the needs that need to be addressed. Because we are an open source company, we are completely open and transparent, right? We gather input from everybody, a road map is opened. We take the input, we take contributions, and we build the right thing for solving today’s problems. And as needs change, I see this model as something that can really adopt to that, right?

    Because the world of DevOps is changing very rapidly, and often there’s a fear of getting locked in with a vendor, too. With our solution, I think the openness of it and the direction it can go to solve problems as they change is a great promise, and we’re already solving a lot of problems. So, that was a big thing for me, you know, that I considered in joining GitLab.

    And the other thing is the culture and open transparency that Sid and the company have built in the company. It’s just phenomenal for me, right? I mean, that was just an eye opening model of how everything we do is open to the world. It’s open within the employees. Anybody can contribute, anybody can look at everything we do and how we move forward to help our customers.

    So, these two are the main things for me that really inspired me to join GitLab.

    Shimel: Great. So, Sid, I’d like to come back to you. Certainly, we can all have vision, but execution is what kinda separates winners from losers in the market. And I’d like to ask you, as the CEO, what’s the secret, if you want to share it with us, right? How do you translate this vision that attracts someone of Ashish’s quality and character and then translate that into an execution that actually translates to success in the market?

    Sijbrandij: Yeah, I’d love to talk about that. We’re biting off a lot, so I think we’re now—GitLab offers a great solution for 10 different product categories. So, that’s massive. There’s a lot of engineering effort. For example, we have a CI/CD team that is just 10 people, and that they have to compete with people that are 100 times bigger. So, how do they do that? First, they’re just selected. GitLab CI is the leader in this space. There’s GitLab CI on the top right and then whole lot of nothing.

    Shimel: Mm-hmm.

    Sijbrandij: So, how do you do that with 10 people? Well, there’s a couple of secrets. The first one is—you don’t do that with 10 people, you do that with 1,800 people. So, we’ve got over 100,000 organizations using GitLab, and over 1,800 people contributed to the product. So, in the release that will go out in a week from now, there’s not just 1 contribution, there’s not 10, there’s 93 features that people contributed that aren’t paid by GitLab.

    So, we see it as, instead of having a tool chain where you have to make the integrations yourself—and that’s not just a few, we identified over 24 integrations you have to make in a standard DevOps tool chain. Instead of making them all yourself with your DevOps tooling team, you work together with 100,000 organizations and 1,800 people to do that.

    So, that’s the big secret. It’s open source. We work together. Then there’s some small secrets, and one of them is iteration. Iteration is one of our six values, and it’s something that everyone is super excited about when they join, but they all kind of don’t understand how painful it is, because it’s very, very painful to do the minimal thing. We’re now in a call with Ashish that Ashish will probably not like that we’re gonna probably change the header on our home page today, because we thought of something better. He’s probably gonna say no, but give me a month, I can think of something even better. And I will be like, “That’s great, Ashish. Think of something even better and then change it again.”

    Shimel: Yep.

    Sijbrandij: It’s very, very painful, and we do that throughout the company, and in product, it’s a very painful thing. My previous call was with Martin, and they’re working on a cloud native chart for GitLab, and we have a thing with uploads and we probably are gonna ship a chart with an NFS server as a part of that. A very clumsy thing, but it unlocks everybody else, and we can keep shipping. And one of our other subvalues is boring solutions, and I love that, because it’s so obvious. You say “boring solution” and people understand what you mean. We don’t go for the shiny toy. Our mission is, everyone can contribute, and people can only contribute if there’s a stable environment to do that, if they understand what you’re doing.

    So, when I saw the GitLab code base a year after Dmitri created it, I expected to see a hobby project. Someone super passionate, but doing this outside of work, like, putting some new development paradigms in it and having something that is hard to comprehend, especially since 300 people already contributed in that first year.

    And instead, I opened up the code base, and I saw a pristine Ruby on Rails application. Totally idiomatic, like, exactly how it should be, and we kept that. We don’t allow anyone to do anything that isn’t boring, and that enables everyone to contribute. That enables us to make forward progress, and we adopt the best of what’s out there. We embrace Kubernetes, we embrace Prometheus—really great, rock solid open source solutions that we can build for later on, and that’s been a big success.

    Shimel: Absolutely. You know, Sid, that was a mouthful in more ways than one, right? So, let’s hit on a couple things. First of all, harnessing the power of open source, right? Right out of The Cathedral and the Bazaar, you know, the book, and what’s gone on is, I mean, the false multiplier there is amazing. Of course, there’s a certain amount of a herding cats element to it, right, in getting everyone moving the same way. But if you can, harnessing that power is just—you know, it’s amazing.

    No. 2, you know, you spoke about iterations and sort of feedback loops and constant change, right? This is core to DevOps, right? This is DevOps 101 kinda stuff.

    Sijbrandij: It really is. This is exactly what we deliver to customers.

    Shimel: Yeah.

    Sijbrandij: Organizations adopt GitLab because we can make their DevOps life cycle three times faster, but you still have to work between the tools. They had these handles between the tools, they had these integrations that weren’t transparent, that weren’t seamless.

    With GitLab, they can work concurrently. As soon as you push your change, QA is gonna run, security tests run, production is gonna have the first review up out there. There’s not a sequence to it. It is, you paralyze the whole process and you gain tremendous speed and you reduce your time to value, and you allow to get feedback and to improve based on that. That’s the value we bring as a product and of course, we try to practice that ourselves.

    Shimel: Yeah. Well, so, but you more than practice it yourself. I think, you know, Sid, I’m a little different. You’re the CEO of this great company, GitLab. I’m an observer, I’m a fly on the wall of many DevOps companies, of many DevOps transformations, and I will tell you, the DevOps tools providers who do it best are those who eat their own dog food, who are practicing DevOps themselves. If you can’t do DevOps internally, don’t try to tell other people how they should do it or, you know, what they should be doing.

    It’s not a case of “do as I say, not as I do.” You have to live that, you have to talk the talk, walk the walk in order for you to truly understand it well enough to get other people to buy into it and be successful. So, kudos to GitLab for doing that.

    You guys recently announced an acquisition in the securities space. We’re kinda running low on time, but I wanted to just touch on that. Sid, your take on it?

    Sijbrandij: Yeah, we acquired a company called Gemnasium, and I think they’ve done the best job of any company of assessing all the different libraries, all the dependencies that are out there and saying which ones are vulnerable, which ones contain a problem. And that is functionality that’s gonna, that’s part of the DevOps life cycle, so we want them to be right in the product.

    So, we’re really happy to join their team, and I’m super proud of them for embracing our values, because they joined us, and within three weeks, all the Gemnasium functionality ended up in GitLab, so.

    Shimel: That’s cool.

    Sijbrandij: We know we hired the right people, they’re amazing, so congrats to Philippe and his team.

    Shimel: Yep. Congratulations to them. And look, we see it here, you know, this whole DevSecOps thing, if you will, if you want to call it that, is probably, along with testing, two of the hottest areas within the larger DevOps community.

    Ashish, we’re almost out of time. Let me come back to you, though. So, you joined this fantastic organization. We’ve heard from Sid a little bit of a peek into what’s making this engine roar, this rocket lift off. What are you gonna bring to the table? What are we gonna see from you, Ashish?

    Kuthiala: I think we need to take this message out to the marketplace, like, you know, a couple of things you talked about when people hear GitLab, they sometimes confuse it with the Git community and other Git offerings like GitHub, for example. So, we really need to tell the world what we are doing, and we are much more than just a repository engine, right? We do a lot more.

    And now that, you know, we are out there trying to help other customers with their DevOps challenges, it’s actually a little bit more than what Sid mentioned here; he is being humble. So,  not only are we practicing our own DevOps methodology to develop and roll out our application, but we actually use DevOps in every single aspect of running the company, right? Right from the hiring process when I joined to everything that I do in the company adopts a pipeline—you know, you create an issue and you run it through the pipeline and you merge that issue and it goes to production. If something is wrong, you know, it comes back.

    Amazingly, everything, between signing for benefits to updating the webpages to running our tracking of issues of what we do, it’s all run through pipelines. And I think I see that as a future. You know, DevOps is not just to be applied to delivering IT value, but you know, it is a methodology that can be applied across running your company for all functions.

    So, I think the version of GitLab is much bigger than just helping companies deliver efficient software really fast out there with feedback on the DevOps methodology. It’s almost to pivot and change the way we think about delivering value to our customers, in every aspect of running the company that we do. And I want to be part of that. I think it’s really exciting. I can’t wait to kind of start talking about this to everybody and, you know, seeing how we go down this journey.

    Shimel: Great. Sid, we’re over time, but I want to give you the last word, so I’m gonna ask one last question for you. What can we expect to see next from GitLab?

    Sijbrandij: We detail a really ambitious vision, and the vision is called Complete DevOps. And we said we’re gonna realize that this year, and we’re executing on that. We’re really proud, we integrated a complete web IDE in GitLab, so VS code running in GitLab. No need to check out this autocode base, you can just edit right there and then.

    But it consists of a lot of parts. We’re gonna have real time editing of issue and merge request descriptions. We’re gonna add logging to GitLab. You can already do monitoring, but we’re gonna add something for your logs, we’re gonna add application performance monitoring. Lots of other things that we think are needed to have a complete solution.

    So, if you started a startup, the only things you have to do is incorporate it, get a Kubernetes cluster, and install GitLab on it—job solved. Like, you’re up and running, you don’t need any other tools, and the only thing you have to do is, you push your code and already today, GitLab detects what language is it, it builds your code, it tests your code, it tests for all the security issues that might be there, it tests your code quality. It gives you all that. It gives you a review app to work with, kind of a staging app. That already works in GitLab today and we’re expanding on that, and I’m super excited to deliver that to the market this year.

    Shimel: DevOps complete. Thank you. Ashish, Sid—thanks so much for being our guests on this episode of DevOps Chat. Continued success with GitLab. We’ll be checking in—actually, I’ll see some of the GitLab folks at IBM Think in a few weeks, and we’ll get an update there, but Sid, you’re always welcome to be a guest here, don’t be a stranger, and congratulations.

    Sijbrandij: Thanks so much. Thanks for having us. I enjoyed this. Looking forward to coming back.

    Shimel: Alright, Ashish—

    Kuthiala: Thank you, Alan, for having us.

    Shimel: – good luck, my friend. Be well. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat, and we’ll see you soon on another DevOps Chat, everyone.

    — Alan Shimel

  • DevOps Chat: Harness.io, Continuous Delivery as a Service w/ Steve Burton

    DevOps Chat: Harness.io, Continuous Delivery as a Service w/ Steve Burton

    Today marks the launch of Harness.io, continuous delivery as a service. The company is founded by some of the original team at AppDynamics. They want to take the same kind of approach AppDynamics brought to APM, to the CI/CD market. We caught up with Steve Burton, VP of product marketing at Harness to get the scoop on this exciting new company.

    As usual immediately below is the audio of our discussion and the transcript of our discussion follows after that.

     Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118147″ width=”300″ height=”300″]Steve Burton

    Steve is VP of Product Marketing at Harness, a new Continuous Delivery-As A-Service Platform. Prior to Harness, Steve ran Product Marketing at AppDynamics, Moogsoft and Glassdoor. Steve also started his career as a Java developer back in 2004 at Sapient. When he’s not playing around with technology he’s normally watching Formula 1 or researching cars on the internet. Twitter: @BurtonSays[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel, with another DevOps Chat here on devopsy.kinsta.cloud. Today’s chat is with Steve Burton, VP of products at an exciting new company – just launched today – called “Harness.” Steve, welcome.

    Steve Burton: Thanks, Alan. Great to be here.

    Shimel: Great to have you here and, hey, it’s a great day to launch a company, Steve.

    Burton: Yes. Sure.

    Shimel: Of course, you know, I’m reminded of what someone told me when I sold the first company I started, and they said, “Companies are like boats – the best two days are the day you buy ’em and the day you sell them.” So this is one of the good – this is one of the big days for ya. And speaking of that, though, Steve, before we get into what Harness is about and markets and stuff, you actually – you’re one of the founding team there, and the team’s really kind of a get-together of a lot of the guys who helped found AppDynamics, I guess, back in the day. Correct?

    Burton: Yeah, for sure, with a few AppDynamics guys here. We’ve also got people from Apple and Google as well, so there’s a nice mix. But, yeah, for sure. There’s Jyoti, there’s myself, Greg Howard, and Randy Boysen, so there’s – yeah, that’s what we love to do, is build start-ups.

    Shimel: Yeah. Getting the band back together. So, Steve, though, with Harness, though, you guys have taken an interesting kind of approach here in that, you know, you see a tremendous opportunity within the CICD market. Correct?

    Burton: Yeah. Yes. I mean, Harness has primarily kind of been built for continuous delivery as a service, so the kind of CD part of CICD, and we think there’s a big opportunity there. There’s a lot of excitement, there’s a lot of projects and customers, and there’s a lot of complexity to solve, and so, yeah, that’s what we’ve kind of founded the company to kinda help customers with.

    Shimel: Sure. And, Steve, I mean, here at devopsy.kinsta.cloud, we obviously follow the CD space pretty closely, and there’s certainly no lack of companies that have thrown their hat in the ring here, right, without naming names, from well-funded start-ups to big, traditional 800-pound gorillas, but the fact that no one has really captured a dominant market share probably indicates it’s because no one’s really come up with the killer CD app, if you will, or the – and if it’s not the app, maybe it’s the delivery means and everything else. Is that part of what drove you guys to, you know, go this route with Harness?

    Burton: Yeah, I mean, for sure. I mean, if you speak to Jyoti, one of the key reasons he founded the company was when he was, obviously, CEO and founder of AppDynamics, he met with a lot of enterprises and big customers, and they were telling him, “Hey, look, we have hundreds of DevOps engineers, but a lot of them are spending their time scripting and building automation platforms. And so there’s no real solution to help us kind of be like a Facebook or a Google, where we can do continuous delivery.” And so that was really the impetus for Jyoti to kind of take a step back and think, “This problem really isn’t solved yet.”

    Shimel: Yeah. No, I think you hit on something there ’cause there’s been some – not backlash, but there’s some talk on some of the DevOps channels that, “You know what? DevOps hasn’t been as successful as we thought it was going to be and a lot of organizations aren’t experiencing the success they hoped with DevOps.” And, frankly, a lot of it is subjective, not objective, and maybe some of it also has to do with hyped-up expectations that can never be met anyway.

    But, that being said, you hit on something there that I think is important, that, a lot of times, when we talk about DevOps teams and implementing DevOps, it’s time spent figuring out automation, right, and scripting automation. And, whether it be automated testing or automated integration or configuration or what have you, it’s kind of like groundwork, rather than actually doing the work. And you probably need to do the groundwork first, right, Steve? I mean, no one’s – I’m not saying that, but, with a SAS solution like Harness here, you can kinda not cheat, but you can get a head start on that.

    Burton: Yeah, for sure, and I think one thing we’ve tried to do is simplify continuous delivery, and so a lot of the scripting and automation that you might require teams of DevOps engineers to do, we feel we can give those teams a solid platform that they can build on top of, to do continuous delivery. And so I actually sympathize because, if you look at the complexity and the work involved to make continuous delivery work, it’s more than just provisioning infrastructure and configuration management. I mean, today, you’ve got release strategies, you’ve got canary deployments, you got blue-green. You think it’ll verify how those deployments succeed in production. You’ve got rollback, so, if things fail, how quickly can you roll back?

    And I think as well, from speaking to customers, one thing we hear a lot of is just the compliance and security around DevOps, and so DevOps is ultimately about empowering teams and giving freedom to developers and operations, but, at the same time, these companies need to control and audit and make sure that things are done correctly. So a lot of the boring stuff, like the credentials and secrets management and kind of visibility and reporting, that’s as much of the puzzle as a lot of the cool stuff.

    Shimel: Yeah, you’re talking my language, Steve. Certainly, security and compliance, and I tend to think compliance is the caboose on the security engine. You know, just doing compliance doesn’t make you secure. But, that being said, security and compliance are major – they could be your best friend or your worst enemy, in the continuous delivery game, right? If you do it right, you could automate a lot of that and shift it left. It could really help speed up a successful CD process, a successful experience. But if you don’t pay attention to it and you run afoul of your security and compliance, I mean, it’s like going back to “Go,” don’t collect the 200 bucks, and you’re starting from scratch. So it’s an important piece of the puzzle, for sure.

    Steve, give us a little background, though, in – you know, so Harness sees this and the team sees this opportunity with CD. It’s a SAS-based solution. What more can you tell our audience about what you guys are doing?

    Burton: Yeah. So, primarily, it’s SAS and we also offer on-premise software as well, so you can deploy either model. I think what we’re trying to do is three things, is one is automate the actual deployment aspects, and so, instead of needing kinda scripting or coding a lot of the configuration and wiring together all of your ecosystem, and so you kind of use CI in your repository tools, like Jenkins, Bamboo, JFrog, CircleCI; and then making those kind of work in sync with kind of Amazon cloud platforms, Kubernetes, Docker; and then, finally, all the configurations. So what we’ve tried to do is build reusable connectors and templates for all of the technologies in the ecosystem so that you can literally plug them together and build CD pipelines in minutes.

    And that sounds totally alien and kinda sounds too good to be true. We’ve managed to do it, but it’s been a lot of work and it’s been working with a lot of customers. And so, in the last 3, 4 months, we’ve literally had, I think, 270 kind of validation meetings with customers. We’ve got over 20 betas in deployment. And so it’s been understanding that complexity of how we can simplify the CD pipelines today. So, yeah, it’s still a lot of work to do, but I think we’re on the right path.

    Shimel: Excellent. And, of course, Steve, you mentioned something that I wanted to bring that out too, is that, you know, it’s sort of this “It takes a village” with CD, right? There’s no one tool that, soup to nuts, is going to do everything for you, and, as you mentioned, Harness already has integrations with a number of the most common tools that are out there, like a Jenkins and so forth.

    Burton: Yeah. Yeah, and I think, if you look at a lot of the solutions on the market, they require you to rewrite your CD process and change the way you do deployments and potentially replace tools you already have, and kinda that never really works because most customers have invested a lot of time and money and resources in those tools, in those processes. And so what we do is we can fit around your existing ecosystem and tools, as well as your processes, and so a lot of the customers who’ve gone through our beta program, within the first three or four hours, they’ve actually been able to get a CD pipeline up and running and reuse the Jenkins or reuse all of the cloud technologies and platforms, in addition to the monitoring tools as well.

    Shimel: Excellent. So, you know, though today’s launch day, Steve, you guys have actually put in months and months, if not year, already of work on this, but where do you think it goes next?

    Burton: Yeah. Yeah, so, in the intro, I talked about us building the building blocks for the automation and getting the CD pipelines built. We’ve also architected Harness to do continuous verification. What that means is, once you’ve deployed code or artifacts in production, we’re actually gonna use machine learning to understand whether that deployment had a positive or negative impact on the business. And so we’re gonna verify things like performance, response times, errors, throughputs, in addition to looking at application logs to see if there’s any regressions or anything that’s been introduced as part of the deployment.

    And so that’s what we’re excited about. That really, we believe, is unique to Harness – the ability to validate a production deployment. And if we see failures or we see anomalies, we can automatically roll back to the last working version for the customer, with no interruption to their business. So, for me, the future, it needs to be more than just deployment. If you don’t know the business impact of your deployment in production, then you could say there’s been a lot of work and time and effort for, potentially, nothing.

    And I remember, when I was a developer, I worked on projects for months and our success was hitting the go-live day. And once we hit the go-live day, it was operations’ responsibility to deploy it and we never really knew whether we had a positive impact or a negative impact. And I think, in today’s world, with kind of continuous delivery and DevOps and going from an idea to money as quickly as you can, you’ve really gotta know the business impact of every change. And if you don’t, you’re letting your company down.

    Shimel: Agreed. Agreed. So, Steve, it sounds – you know, this is something that I’ve always wondered about with DevOps, which is we put so much effort into automation and doing it better, you know, getting better code, automating all of the stuff, automating CI, automating CD to the point where we actually deploy, and then, all of a sudden, post-deployment, we’re on to the next thing or we’re looking for our feedback loops so we can develop the next iteration of it. And I guess sort of APM sort of filled that next post-deployment monitoring and so forth, but it sounds here like Harness wants to fill that gap in there. Is that fair to say?

    Burton: Yeah. Definitely. I think we wanna automate how customers verify their deployments, and so the APM market is like $5-billion market right now because, literally, every company’s building software and their software keeps breaking. One stat for you is 30 percent of application deployments fail. This was an article that Wired.com wrote – I think it was a few months ago – but that’s a staggering amount of failure. And the reactive way to deal with failure is to go and buy an APM product to help you kind of troubleshoot in production, when you do a deployment.

    The smarter way to do it today is to start and do canary deployments in production, where you roll out the application to a small amount of nodes or users and then verify it before you then roll it out across the rest of your application environment. And so you can kind of think of Harness as a safety net – we’re gonna let you deploy in production, we’ll help you with canary deployments, and, if we see something that’s wrong or we spot an anomaly, you can roll it backward with virtually no business impact

    Shimel: Got it. Got it. Well, Steve, believe it or not, we’re probably a little over time here already, but, hey, we tried. Steve, before we wrap up, though, for people who wanna find out more about Harness, where can they go?

    Burton: Yeah, they can go to harness.io, is our Web address, and we’ve got lots of videos and will be a free trial coming shortly. And you can actually subscribe for the early adopter program as well, if you wanna show your interest there.

    Shimel: Oh, that’s excellent. Excellent. And I’m sure there’s plenty of stuff on the website where people can find out more information of all of these things. Steve, congratulations to you, Jyoti, and the rest of the team. It sounds like you guys are on to your next great adventure and I’m sure it’s gonna be an amazing journey. We hope to have you back here soon and we’ll be watching Harness closely and seeing what it brings to the market. Congratulations.

    Burton: Yeah. Appreciate it. Thanks, Alan.

    Shimel: All right. Steve Burton, VP product at Harness, at harness.io, if you’re interested. Exciting new entry in the DevOps space. Best of luck, Steve, and we’ll see you soon. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: How DeployHub and OpenMake Software Help CI/CD w/ Tracy Ragan

    DevOps Chat: How DeployHub and OpenMake Software Help CI/CD w/ Tracy Ragan

    This DevOps Chat features OpenMake CEO Tracy Ragan. OpenMake are the producers of DeployHub and DeployHub Pro, which help DevOps with CI/CD. OpenMake is a company that was helping developers long before people spoke about DevOps. Using an open-source business model with DeployHub has transformed the company. We speak with CEO Tracy Ragan to find out how.

    As usual, the streaming audio is below with the transcript immediately following.

    Audio

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, DevOps Chat, and, in this episode of the chat, we’re joined by Tracy Ragan, CEO OpenMake Software. Tracy, welcome to DevOps Chat.

    Tracy Ragan: Thank you, Alan. Thank you so much for inviting me. It’s my pleasure.

    Shimel: Okay. So, Tracy, the last time I think you and I caught up, we were over at Jenkins World, out in San Francisco, a couple of weeks ago. And, you know, that was quite an event and it really kind of spoke to how big the CD space is becoming—you know, the CD market and the kinds of companies that are utilizing different CD solutions. Of course, OpenMake, you know, plays in that market arena, Tracy, but, for those of our listeners who maybe aren’t familiar with OpenMake, can you give us a little background?

    Ragan: Absolutely. So OpenMake Software has been playing in this continuous delivery space long before it was in fashion. Our initial product, our Meister product, was created about 20 years ago, and it was created to accelerate the process of compiling code once it was checked into a version control tool. So you check in and you build—we were doing that close to 20 years ago. Now we were just doing builds off of a trigger; we weren’t doing continuous integration. What we were doing was the hardcore build automation, and what I mean by that—the automatic generation of the compile and link scripts, the acceleration of the compile process, and the dependency management so you could do just-in-time builds, to speed up the process of moving code forward.

    So we were really early on in understanding the need for faster delivery of code and the ability to create what we call a “release candidate” at any point in what used to be call the “life cycle” and now what we’re calling the “pipeline.” So this is an area that we have heavy expertise in and a lot of heart for.

    Shimel: Absolutely. You know, Tracy, one of the things that I always find interesting, and somewhat sad, is that, when we talk CD, right, some people—I think most people still refer to continuous delivery, but others, you know, talk about continuous deployment, and then, unfortunately, I think there’s a Venn diagram kind of subset that think that somehow continuous delivery and continuous deployment are one and the same. And—

    Ragan: Yes.

    Shimel: – why don’t we start with destroying that myth? Right? What’s the difference? Is there a difference—I think there is—between continuous delivery, continuous deployment?

    Ragan: So if we look at the continuous integration process—and I think that’s where we have to start, to understand continuous delivery and then, of course, continuous build and continuous tests and continuous deployment underneath that— so continuous integration itself, I don’t wanna say it doesn’t do anything, but, in itself, it’s an orchestrator. It itself doesn’t compile code, it doesn’t test code, and it doesn’t deploy code. What does those steps are the unsung heroes who oftentimes write scripts or automation tools that sits underneath that process.

    Continuous delivery is the ability to have a release candidate ready to go at any point in time across what’s now called the “pipeline,” so, if you have a continuous integration at the dev state, you might also have one at a test state—now this sounds very waterfall, which is why I don’t like to describe it this way—but, in essence, what you’re doing is saying, “The development teams are ready and they have a release candidate they wanna push off to testing. Testing should automatically test it and then push it off to production.” Now what’s core, what’s the lowest common denominator between those simple three states, is the ability to get it out to end targets so you can actually run a test at dev or run a test at test or execute it at prod. That’s what continuous deployment does.

    I prefer to call it “continuous deployment.” We often hear it referred to as “application release automation,” or ARA, and that sometimes feels a little heavy and waterfall-like, but, in essence, that’s what those tools are doing, is they’re doing continuous deployment, in the same way as test automation tool does continuous test and in the same way, you could say, Maven or a product like our Meister is doing continuous build, all driven through a CI/CD workflow.

    Shimel: Excellent. Excellent. And, you know, you hit on something else there—ARA. And that, again, we’ve seen several vendors kind of stake—they’ll put a flag in the ground around ARA. So now that we’ve got some basic definitions done, Trace, let’s talk about how do we move right—in this case, it’s almost shifting right, right?—how do we move rightwards down this deployment—delivery, deployment, management—you know, timeline? And—

    Ragan: So I think what we have to do is we have to talk about DevOps, right? So we have this other big term that’s being thrown around, and that’s “DevOps.” Everybody I speak to has a different opinion of what DevOps is, so I’ll just share with you mine. DevOps is the process in which the development teams start taking over more of the operational tasks. And the operation teams’ role is mainly one of auditing or having some level of control. My guess is that, as DevOps is pushed left, so developers are doing more of the work, we’re going to see operation teams become smaller.

    And that’s really—if you really look at what companies are doing, they have large operation teams because they’re doing their own thing when it comes to doing software releases. They’re not part of the CI/CD process, in many of these cases. But, in reality, what happens is is that the developers are the ones who have to do the hand-holding at production, so the more we can get developers to declare their definitions around their software deployments, what their environment looks like, the easier it becomes for the data centers to become leaner. And that’s really what Agile, DevOps is all about, is getting, in the hands of the developers, tools that can automate these operational tasks to a point that the testing teams and the production teams can consume them and have some transparency and some level of control around them.

    Shimel: Got it.

    Ragan: So that’s what continuous deployment, application release automation, is achieving, is that ability for developers to dig in at the dev level, not with scripts because scripts can’t adapt across the pipeline, but to do that in a model-driven way that could adapt across a pipeline, so that the work – all the declarations are done down at dev, and the users of that are testing and production. Even down to a configuration change, if need be, at a Cisco router level. We’re talking low-level definitions.

    Shimel: Sure. Sure. So, you know, Tracy, it’s funny; you guys over at OpenMake have been involved in this space, as you said, 20 years, right? Way before we start using—throwing around the terms “DevOps” and “continuous” this and “continuous” that. And kind of living in the DevOps bubble, if you will, we think, “Oh, everyone’s doing this kind of stuff and this is the way it should be done and this is the way it is being done.” But, really, when you look at it—and you probably have a better view than most, Tracy—how far along are we on market adoption, around this, you know, more—I think it’s a more holistic approach to DevOps and continuous delivery and deployment, as well as ARA?

    Ragan: That’s a hard one to answer. I can give you my best guess and give you some numbers I hear from the analyst. If we talk about ARA, the analyst tell us about 20 percent of the companies have adopted ARA. Now, but, that being said, when I hear—yeah?

    Shimel: Yeah, I was gonna say that sounds high to me.

    Ragan: It does, but let me tell you why it sounds high. It sounds high because, when companies adopt an ARA solution, they’re often talking about a legacy product that somebody on the operations side of the house decided to purchase. And, oftentimes, they’re legacy because they have the requirement of in-target agents, so the decision to put an agent on every single production end point, including cloud or even define them to a micro-service, has to be done way right. That doesn’t mean that we’re doing continuous deployment; it means that their operations side of the house decided on a tool that may or may not be adopted by the left side of the house.

    You know, when I talk to companies, most of them will talk about that they’re adopting DevOps, but if you ask them if they’re able to solve a build in less than 10 minutes or if production can repeat the deployment that developers defined, the answer will be “No.” So the reason why it’s hard to answer that question, to get clear metrics on it, is because everybody’s definition of what that is is so drastically different.

    Shimel: Yeah.

    Ragan: In my mind, I’ve only met a few companies that have really established a real Agile, DevOps practice, and it’s not for the entire organization—it’s for a few teams—so we’re babies, when it comes to this. I believe we have a long way to go to really understand how to make that shift left so that this Agile concept of where testing and production are not separate states in life cycle and separate silos, but part of a circular process that is included everybody on the same team. So waterfall still persist, and to be quite honest, in continuous integration, if you look at what drives the CI process, we are still using the same waterfall scripts that we did, you know, five or 10 years ago, depending on how far you are in CI. Much of the stuff, they consider automated because a script executes it, but that’s not automation. It’s automation in the waterfall world, but it’s not automation in an Agile, DevOp practice.

    Yeah, these steps really have to truly be automated so that it’s transparent, there’s reporting, there’s clean metrics, there’s a continuous feedback loop, because that’s the best way to go fast. The best way to go fast in anything you do is control, right? The more control, the more speed. The problem with control, on the ARA side, is it costs too darn much, which is why we decided to do an open-source solution. It’s like developers, in order to achieve this, in order to really achieve this and really move as fast as possible and increase these release cycles, you have to have developers being able to get their hands on a product that will do the deployments without having to babysit a script for every state in the life cycle.

    Shimel: Agreed.

    Ragan: So we have a ways to go.

    Shimel: I agree 100 percent. But I’m gonna tell you—you know, and this, again, it’s not my original thought, but it’s something I’ve heard and I fully agree with, and that is I don’t think it’s the mission of DevOps or CD or ARA, you know, that we’re gonna totally eliminate waterfall. I think there are, you know, situations where waterfall—excuse me—where waterfall may, in fact, be the right solution to the problem. I think—[coughs] excuse me, Tracy—I think there are other areas where some sort of combination of waterfall and Agile, waterfall and DevOps, you know, some continuous kind of stuff, you know—it’s like that—you know, General MacArthur said, “Old soldiers never die; they just fade away,” or something like that. I think old development styles and techniques never die either, so I don’t necessarily believe in throwing out the baby with the bathwater. What do you think about that?

    Ragan: I think technology will change that. When you’re talking about monolithic applications that have been around for a while and they have some sort of a cadence that they’ve been going through, where they have developers developing and testers testing and production teams managing the production releases, you’re probably right. It’s gonna be some sort of a water-Scrum-fall or what we’re calling “bimodal” approach.

    But, with the introduction of microservices, that is going to change the way—if it’s not a monolithic application, as we move into microservices, even though it solves—microservice solves some problems, it’s going to complicate the landscape of the production environment, which means that the need to have these production operation types and these testing types working hand in hand, on the development team, will be critical. So, as we see microservices become more prevalent, we’re going to see waterfall slowly die.

    Shimel: Okay.

    Ragan: It’s just the nature of micro-services. Now it becomes—microservices becomes code as well. Everything has become code, which means that the productions teams are not gonna be able to track and manage that level of detail in the production environment. It’s gonna go beyond just a collection of DLLs or a WAR JAR file that’s going out to an end location. It’s gonna complicate matters and it’s gonna change the way we—it’s gonna change waterfall drastically.

    Shimel: Yep. And so it’s gonna change it drastically and maybe it does evolve, if you will, but I think that’s what technologies—I think—you know, one of the things I’ve learned over too long, being in this business, is we don’t see revolutions as much as we see evolutions. And then, when we look back over a five-, seven-, 10-year span, it seems like, “Oh, my God, that was revolutionary.” But, from the day to day, it’s rather evolutionary.

    Ragan: I would agree. When it comes to—you know, we have—if you look at the macro and the micro, when it comes to the micro level, we have changed—you know, software developer bank doesn’t evolve anymore; it’s revolutionized. And that is due to Agile. What happens is is that, in some of these enterprises, the fear of doing frequent releases has slowed down the adoption of lean practices at the production state. That, we have to fix because there should be a revolution. If an end user needs a fix, it needs to get out there. It shouldn’t evolve over a six-month period.

    Now, if we look at the macro, we take a—you know, we soar up a few miles up—when it comes to major shifts in the way the community at large does business, it is a evolution. Everybody—I mean, I was at the Gartner data center show last December, and very few of those enterprises had even completed the adoption of cloud. They still had big, you know, warehouses of servers, so you’re right. From the perspective, I would say, the data center adoption, it does evolve, but, at a micro level, I think that we see a revolution in the way developers want to develop software and are driving software, and that’s where the microservices is gonna change a lot of how we do things. And I think, as more developers push for that, I think it’s gonna happen faster than we think.

    Shimel: I don’t—I—so that, along with the evolution versus revolution thing, I think the speed of—you know, this internet time speed warps, you know, the world we live in. It just—I mean, it’s crazy. So it’s no doubt about that one. Tracy, we’re actually—I didn’t realize—we’re kind of over our time, but it’s okay. These things often run over. Let me just quickly bring it back to OpenMake. What are you guys—anything new? Announcements feature-wise? Or what’s happening over there that you may wanna share with our audience?

    Ragan: Well, we have our DeployHub product that you can become part of the open-source community and participate in freely-available continuous deployment at deployhub.org. We are also—we’ll be getting a press release out very shortly here, regarding a SAS version of our continuous deployment solution, which it will be both a supported version of the open-source, as well as the pro version which includes release management capabilities, all from a SAS model, so you don’t have to download anything. We can do that because we’re agentless. Makes it real easy to support people in a cloud model.

    Shimel: Excellent. Tracy Ragan, CEO of OpenMake Software. Thanks for being our guest on DevOps Chat. Hope to have you on soon—have you on again soon and you can keep us posted.

    Ragan: Okay. Thank you, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Have a great day, everyone, and we’ll see you soon on the next chat.

    — Alan Shimel