Speaker 1: This is Techstrong TV.

Mitch Ashley: Hey everybody, welcome to KubeCon. This is day three that we’re doing live broadcasting, live streaming here from the show floor and we’ve got another set of great interviews. It’s been really interesting kind of picking up on some themes, and I think we’re going to see that again with our next guest. So I have the pleasure to be joined by Rej Razdan, who is co-founder and go-to-market dude at Devtron, for lack of a better title. Welcome. Good to be chatting with you.

Rejesh Razdan: Thank you, Mitch. Happy to have be here.

Mitch Ashley: Good to have you. Tell us a little bit about Devtron for folks that may not have heard it. Tell us about the open source and the company and kind of what you all do.

Rejesh Razdan: So Devtron is about three, three and a half years old. We are an open source company and built philosophically as an open source platform for adopting and helping people migrate to Kubernetes. Kubernetes is the most talked word in the last three, four years I’ve seen in the entire CICD space. And when we started Devtron with my other two co-founders, we thought this is the best way. This is the most challenge that we saw was people are talking about building platforms from their own unique ways. So for example, a platform engineering is seeing the Kubernetes world in a very specific way with him or her being the user. Then developers are oblivious with what is really happening because they don’t want to learn Kubernetes, right? They want something…

Mitch Ashley: They spend all their time.

Rejesh Razdan: All the time.

Mitch Ashley: Working on Kubernetes, right?

Rejesh Razdan: Yeah. They are best doing, checking the code and pushing out to whatever the repo is and doing for staging and QA and everything else. What we were seeing was that Devtron was essentially built to help this adoption and migration. The whole ton of companies are actually moving to microservices architecture and then thinking that how do we interface with Kubernetes? So we laid a lot of emphasis on interfaces and interfacing with different platform tools that are already available in the market, both open source and closed source.

So we thought, why don’t we build an interfacing layer which actually adapts with literally everybody via hooks and APIs and interfaces, and then build a system which actually helps you migrate to Kubernetes first, adopt Kubernetes, and then help you unravel the complexities of Kubernetes in few clicks. So there are, if I go a little more extended in terms of definition, so we could be talking to folks who are just new to Kubernetes and saying that, hey, we can give you ready containerized application, some templates with few clicks you can just go and first of all, onboard.

So that is day zero. So once you are comfortable with that journey, then day two operations, how do you manage those kind of workflows? Then we give you templates, then give you policies and governance. Then we view all the hooks, which makes the manageability super easy. And I think the best part, which I would like to sum it up in terms of what Devtron does and bring value is we cater to both the audiences because the whole Dev team consists of various users here. And our philosophy to build this was to make sure everybody focuses on an interface and this interface is common. So you less worry about the tooling and more look at the interface with a common pane of glass for build, operate, and manage and debug. So I think this is a long answer to exactly what we do.

Mitch Ashley: And when you say interface, you’re talking about sort of the visual interface into it or the API interfaces to it, or both?

Rejesh Razdan: Both visual and the backend as well. The point is that at the end of the day, there are a lot of systems that have been built with keeping the backend in mind and people have gone deeper into that thing. But when you, so that may suit very good audiences such as platform engineers, SREs, DevOps folks, but large users of the systems are developers and they need abstraction out of those complexities. For them, while some of them like a very nice low-code visual interface for that and where they can actually click few things and get shit done in very quick few clicks. So we focused on those aspects of things and we went actually deeper because we come from the same background. We’ve been platform engineers for a while. We were facing the same problems, and when we thought about building Devtron, we said, let’s first solve it for ourselves.

And this is a problem that has been going on because we have been using industry bread industry best products like Argo CD and Flux CD and everything else. We said that we don’t have to reinvent the wheel there. Let’s build an abstraction layer on top of it, take the best practices out of it, build our own unique layer. Which is not as opinionated and opinionated to an extent that it suits pretty much everybody’s deploy and build style or platform interface style and then tell folks that, hey, you can come and build all of this through this platform integration layer. And with a single promise that Kubernetes for sure will not be a complex animal for you, we will solve it very, very easily. So that was the promise that we started on and we continue to do it.

And last but not the least, I think what we did was we said that what is the best way for us to give it out to folks without any worry of a huge commercial thing before they feel comfortable going into fully commercializing it, just make it open source. And I think we’ve been lucky to get a lot of fan following and a lot of users on the open source and we’ve seen a huge adoption worldwide towards, and it’s still new in this part of the world, but we still are seeing a lot of people talk about it. And I think this is the right, or at least one of the decent ways to build a complete platform layer.

Mitch Ashley: Good to go to market. So what’s the name of the open source project? Is that Devtron or something else?

Rejesh Razdan: It’s Devtron.

Mitch Ashley: Devtron V?

Rejesh Razdan: Yes, Devtron. And we haven’t really done it differently. And we said that open source in our definition is truly open source, but it’s not. I mean, we are a CNCF member for example. It’s not kind of donated to CNCF, et cetera, but because our philosophy was we’ll keep it open source to the fact to make sure that people adopt it. It’s not about, and how do we get quick adoption and how do we see, let’s say if I’m talking to 20 users, when I talk to 20 users, they give us a lot of inputs. How do we make sure those inputs get templatized for the next 20 and to 30? We obviously are very clued in on what’s cooking at the CNCF level. So take all of those benchmarks and best practices and the new projects and make sure all the learnings have been bred into the platform.

Many times when people thought and people use Devtron and they said, one of the comments that we hear a lot is that you are a combination of multiple things. Where I see that that’s very interesting way to put it as well because that was the whole idea that individually people have been talking about so many platforms. Like there’s backstage and there is so many else now people moving to platform engineering. But they haven’t been able to solve the problems, and that’s what we are hearing from folks. So we have seen that if we just focus on the user first rather than what comes out as something in the magic quadrant for people, something is a buzzword. Let’s go beyond the buzzwords and let’s see where the problems residing in this whole process of Devon Ops and our approach was looking and going very myopic in those processes and put a layer on top of it.

Now you can call us and platform engineering 1.0 product in building that. So it’s our take to build that. It’s not CICD. Plain CICD has been talked about vanilla for so many years, but this is that journey of adopting Kubernetes and whatever comes with it comes with it as an interface layer. So there’s a lot of focus on these interfaces and on user experience. And user could be the DevOps folks which build and who are actually the principles of this guardrail and of course the enormity of the users that actually make it work, which seems like a simple system and one system where everybody works in unison.

Mitch Ashley: Okay. Let’s unpack a couple things. It sounds like you built it for developers by developers kind of thing, which of course helps with adoption as a target audience. We’re in the process when the developers, somewhere in writing codes, setting up environments, starting to realize I want to use Kubernetes. Let me set it up. Whoa, maybe I don’t want to go through all of that myself. Where in the lifecycle of creating your maybe first or your next cloud native microservices based application that they say, you know what? There’s this great project called Devtron, Devtron V, I should go check that out. What’s the best time to introduce it? Or when do people typically introduce it?

Rejesh Razdan: So as soon as you build your code and you try and check it in, and that is where you interface with Devtron. So underneath you can literally, we can take care of the entire build process, which is the complete CI. We can take care of the CD in totally and prop the DevOps process. We say this, we can interface with your CI and just use CD. You don’t have to rip and replace whatever you are using. We can actually pull workloads out of Jenkins or interface with Jenkins jobs, for example. So you can use your existing systems.

What we have tried to also put a lot of emphasis here is the friction from what you’re currently doing. If you are assuming your microservices already using some form of containerizations already. Of course we have templates to get you containerized as well. But let’s say if you’re already in that journey, then we have put all these interfaces to make sure that we work in constant communion with what you’re using rather than asking you, hey, just rip and replace and use this.

So I think that reduces the friction from, let’s say if you’re building from a Jenkins and we can adopt you or you are using a certain other type of, and it is obviously Devtron is GitHubs based, so as long as you are, you have something on Git, wherever you are, your repositories is, we can pull and we have direct interfaces from there. So a developer interfaces with Devtron along the CICD path all along. And then we say that a lot to also folks that before the production, which is kind of a territory of a DevOps person, pre-production, whether it’s staging in QA and then you do a lot of iterative work, you can literally do all of that in Devtron. And if you choose to, for example, deploy through helm, for example, there’s a helm package manager as well, which gives you a very visually appealing interface to do a bunch of builds from there.

So there is a whole lot of options available to you because we said that in the journey of what is being available as a product, we let you come from various sources. We are not really binding you from how a developer should unravel the area of Kubernetes. The second point that I want to talk about is, and this is a cross section of about 4,000 open source installations that we have, and about 20, 30 global customers that we have, folks are, they’re trying to wonder how do we best utilize these templates, et cetera. Those are all available within the Devtron framework. You can choose one of many of those templates and start using them. And so that adoption journey is very, very easy. And what happens is that many a times, if you don’t have a platform like this, there is too much of a tribal knowledge available there.

So we want that tribal knowledge to go completely out of the window. So developers want to do, we lay out a golden path for them to do a lot of self-serve without having to know anything of those. So that is the developer promise side of things. Of course, DevOps promise is to move things into production, having a more robust production setup without breaking things. And of course, if you do work to roll back, do we offer all kinds of rollbacks and the diffs and wire and do we offer enough and more on the debug ability side of things as well. So I think different users have been given various interfaces to see what is the best way they can embrace it. And of course there is, needless to say, there is deep amount of SecOps built in as well. So you don’t worry about unsecure builds and all of those kinds of things. It interfaces with all the other security systems and scans, et cetera as well.

Mitch Ashley: It’s interesting, because you are catering to targeting multiple personas, if you will. Developers sort of abstracting away Kubernetes the whole build process, DevOps tool chain, workflow pipeline, and then of course, deployment and management sounds like a Kubernetes once you’re in production, correct?

Rejesh Razdan: Yeah.

Mitch Ashley: So could be a developer, could be a platform engineer, SE ops, whatever person, which has much different requirements. How much for the people that deploy it put it into production, how much do you take away the kind of Kubernetes complexity details? How much do you abstract it from them or is that all still there? You just have a better way to manage it.

Rejesh Razdan: So A there are, okay, people who are already matured on Kubernetes, so we give them, and I think we take away, we sort of add another few layers on top of it to set what are the, and so there is this Kubernetes maturity and then there is the non Kubernetes maturity in a total dev environment. So what we also see is that they have seen, I mean they’re very comfortable with the non Kubernetes maturity as well.

What we bring is since we are very hyper-focused on Kubernetes, we are Kubernetes native as we call ourselves, we try and get you the same amount of maturity on Kubernetes. So what are the templates, how can you roll back, what are the deployment types? Can you do cannery, bluegreen, rolling, et cetera. And we are also looking at what are the best ways this entire disparate systems are the learnings from how you deploy and what are the best ways to deploy in a fairly matured environment. We are working on something called ephemeral environments or temporary environments, which are basically, if you’re not using any sort of clusters during any of your deploys, it brings them down, which automatically takes care of the costs and everything else. So it containerizes, but it contains it in a certain temporary setup and does not let you take enough memory and compute, et cetera, et cetera.

So these are best practices built in order to build efficiencies, not from total cost of operations, but how you actually allocate resources. So everybody’s talking about finops and cost savings.

Mitch Ashley: Worried about cost.

Rejesh Razdan: You must have heard that a lot here. So I think we are saying that we don’t have a separate vertical per se, but the things that we do alongside the process actually helps very optimally build the systems, including the ones in production as well. So all those bells and whistles that have been built A takes care of a platform engineers persona of maturing Kubernetes, or these are the best practices from how a mature Kubernetes infrastructure look like almost at par with your other mature systems in the tech stack. So that is the path for platform engineers and DevOps, of course, the whole transition from either a legacy network or your Kubernetes from less mature to more mature, that journey is for the developers.

So it’s equally distributed for both of these folks. But largely we have tried to rather focus a lot on how do we make this system DevOps persons or SREs or platform engineers, best friend. Looking at the problems that they’ve been facing over years. And it’s not the tooling problem, it’s also the operational problem of how information flows between this user group and the developer user group. There’s always a lot of finger pointing, et cetera. You did not do this and I did not do that. Why? Because everybody’s not on the same plain. That’s why I keep emphasizing on building a common interface so that this friction also gets reduced. And as an organization, if you wearing a CEO’s hat and saying that, how do we optimally work between these two groups? There is very little that falls through the cracks and we are able to at least find an answer. At least Devtron is an attempt to solve that.

Mitch Ashley: So you mentioned you’re being Gitops based. How much do you find on the repository to have everything in that to be able to drive what Devtron does? Or do you help people get, maybe they don’t have everything, all their config files or scripts or whatever they’re using. I mean, you would think a lot of that’s going to be in there, but it may not necessarily be in a well organized or structured way because those things tend to evolve over time. How do you help people get to a point where Devtron can take advantage of it and start using that concept?

Rejesh Razdan: So our open source is literally everything in the repository that we have, and we actually help folks. For all our commercial products there are some of the, so what we’ve sent, as I said initially, is from an adoption point of view and a migration point of view, everything is given out in open source role-based access controls, very fine grained. Actually people were a little worried about that I may not be able to give controls or accesses to junior folks who are very new in the system out if they may break anything, et cetera. We are saying that, don’t worry about it. The access controls are so fine grained that they’re so nuanced that you are actually, don’t worry about breaking anything up. The system takes care of it, but at least give them the access so that everybody’s familiar with what environment they’re building and living.

So that’s one point. So our backs, SSOs, single sign-ons, everything has been bundled into the open source because we don’t want any guardrails in terms of adoption of Kubernetes. That’s the first promise. And once you’re ready and comfortable to move things into production, that is when we come with slightly other more nuanced enterprise-y features like policy controls and other things. You’re saying now you’re comfortable, now I can go straight into production. And we have moved people into production in seven to eight weeks. That’s one sort of metric that I can share. And we have moved people from zero Kubernetes to almost like 30, 50, or 7,000 microservices literally in three to four months or about 12 weeks. In my view from whatever experience that we have from collectively over many, many years, that’s a very fast jump into moving your entire workloads into Kubernetes.

This wouldn’t have been possible without us to actually go into the collective feedback that we get from the open source things, put all of that in the Git repository and the open source repo, and also get some of those controls and planes when we actually help people onboard them faster. We have a very vibrant Discord community, folks interface with us on Slack as well. So I think our idea is that we are leaving no stone unturned in order for people to adopt Kubernetes via they’re drawn. Our vision would be, and all of us think about that. When people think about migrating or adopting Kubernetes, the first name that should come is Devtron. And that’s the way we want to build.

Mitch Ashley: Great. Well, congratulations on your success so far and your growth in the US North America market and enterprises. What’s the best place for folks to check this out? Go check out your GitHub repository.

Rejesh Razdan: Go to website, Devtron website, devtron.ai Website. We have folks all over US, our US headquarters data out of Silicon Valley. So hopefully we are available. Literally, I mean come check us out and I’m sure you’ll like it.

Mitch Ashley: Great. Join the Slack channel, do the thing.

Rejesh Razdan: There’s Discord. Yeah. And they can join it.

Mitch Ashley: There’s a lot of great help and support, communications happening.

Rejesh Razdan: Absolutely.

Mitch Ashley: Well good. Look forward to more great progress and your timing is great because adoption and management of Kubernetes is…

Rejesh Razdan: Thank you.

Mitch Ashley: Massive theme right now for where we are in the adoption cycle. So Rej, who is a co-founder in Go-to-Market with Devtron, devtron.ai, right?

Rejesh Razdan: Yes.

Mitch Ashley: Okay, good. Make sure I got that.

Rejesh Razdan: Thank you very much, Mitch. Thanks for having me.

Mitch Ashley: Thanks for joining us.

Rejesh Razdan: Thank you.

Mitch Ashley: Come back and talk to us again.

Rejesh Razdan: Absolutely. Look forward. Thank you very much.

Mitch Ashley: We’ll be right back with more great interviews, so hang tight. We’ll be right back.