Rajesh Razdan, Devtron | KubeCon + CloudNativeCon North America 2023

This is Textron tv. Hey everybody, welcome to Coup Con. This is day three that we're doing live broadcasting, live streaming here from the show floor.

And, uh, we've got another set of great, uh, interviews. You know, it's been really interesting kind of picking up on some themes, and I think we're gonna see that again with our next guest. So I have the pleasure to be joined by, uh, Raan, who is co-founder and go-to-Market, dude, at, at, uh, at def tron, for lack of a better title.

Welcome. Good to be chatting with you. Thank you, Mitch.

Happy to have you. I Good to have you tell us a little bit about Dev tron. For folks that may not have heard it.

Tell us about the open source and the company and kind of what you all do. So, Dev Tron is about three, three and a half years old. Um, we are an open source company and built philosophically as an open source platform for, uh, adopting and helping people migrate to Kubernetes.

Um, Kubernetes is the most stocked word in the last three, four years I've seen in the entire CICD space. And, you know, when we started Dev tron 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, you know, oblivious with what is really happening because they don't want to learn Kubernetes, right? They want something spend All their time, All the time, Kubernetes, right? Yeah.

They, they are best doing, checking the code and pushing out to whatever the repo is and, you know, doing for staging and QA and everything else. And what we were seeing was that Dev tron was essentially built to help this adoption and migration. Like the whole ton of companies are actually moving to microservices architecture and then thinking that, you know, how do we interface with Kubernetes?

So we, 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, uh, which actually adapts with literally everybody via are 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 ex, you know, a little more extended in terms of definition.

So you, we could be talking to folks who are just new to Kubernetes and saying that, Hey, we can give you ready, uh, 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, you know, you know, once you are comfortable with that journey, then you know, 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 sort of sum it up in terms of what Dev Tron 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. Okay.

When you, and when you say interface, you're talking about sort of the visual interface into it or the API interfaces to it, Or both? Yeah, both visual and, and the backend as well. The point is that, you know, at the end of the day, there are a lot of systems that have been built, um, with keeping the backend in in mind and people have gone deeper into that thing.

But you know, when you, so that may suit very good audiences such as platform engineers, sre, uh, DevOps folks, but large users of the systems are developers and they need abstraction out of those complexities Mm-hmm. For them, while some of them, you know, you know, like a very nice low-code visual interface for that and where they can, you know, actually click few things and get s**t done, you know, and very quick few clicks. So we focus 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 thank, you know, and when we thought about building Deron, 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, you know, industry best, um, sort of products like Argo CD and fluxx 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, you know, not as opinionated and opinionated to an extent that it suits pretty much everybody's deploy and build style or, 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, um, we've been, we've been lucky to get a lot of fan following and, and sort of, you know, 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, we are seeing a lot of people talk about it. And, uh, I think this is the right, or at least, uh, one of the decent ways to build, uh, you know, a complete platform layer.

Good Go to market. Um, so what's the name of the open source project? Is that Dev Tron or Something else?

It's Dev tron. We, we deliberately Deron d yes, dev Tron. And we haven't really done it a different differently, and we said that, you know, open source in our definition is truly open source, but it's not, it's not.

I mean, we are A-C-N-C-F 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 and 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? Uh, and we take, 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, um, thought and people use Dev tron 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, you know, if we just focus on the user first, rather than, uh, what comes out as something in the magic quadrant for people, something is, is a buzzword.

Let's, let's go beyond the buzzwords and let's see where the problems residing in this whole process of Devon Ops. Mm-Hmm. And our approach was looking and going very myopic in those processes and put their, put a layer on top of it.

0 product in building that. So it's our take to build that. It's not CICD plain.

CICD was, 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, uh, with, as an interface layer. So there's a lot of focus on these interfaces and, and on user experience. And user could be the DevOps folks, which, which build and who are actually the, 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. Okay. Let, let's unpack a couple things.

Um, it sounds like you built it for developers by developers kind of thing, which of course helps with adoption, you know, as a target audience. Um, we're in the process when developers somewhere in writing codes, setting up environments, starting to realize I want to use Kubernetes. Let me set it up.

Well, maybe I don't want to go through all of that myself. We're in the kinda lifecycle of creating your maybe first or your next, uh, cloud native microservices based application that they say, you know what, there's this great project called Deron, right? Tron tron VI should go check that out.

What's the best time to kind of introduce it? Or when do people typically introduce it? So as, as soon as you build your code and you try and check it in, and that is where you interface with dev tron.

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, uh, in totally. And, and, and prop the DevOps process.

Uh, 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. Like 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, you're using some form of containerizations already, of course we have templates to get you containerized as well.

Okay. 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, you know, sort of 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, um, you know, and it is obviously Tron is GitHub's based, so you, as long as you are, you know, you have something on Git, whatever, wherever you are your repositories, we can pull and we have direct interfaces from there.

So a developer interfaces with Dev Tron along the CICD path all along. And then, um, we, we say that a lot to also folks that, you know, 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 dev drop.

And if you choose to, for example, deploy through helm, for example, there's a helm package manager as well, which sort of 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, you know, as 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 you, how a developer should unravel, uh, the area of Kubernetes.

The second point that I want to talk about is, and this is a cross section of, you know, about 4,000 open source installations that we have. And about 20, 30, uh, global customers that we have, uh, folks are, you know, they're, they're trying to wonder how do we best utilize these templates, et cetera. Those are all available within, within the dev tron, uh, framework.

You can choose one of many of those, uh, templates and start using them. And so that, you know, so that adoption journey is very, very easy. And what, 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, I mean, we lay out a golden path for them to sort of 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, you know, robust production set up without breaking things. And of course, if you do work to roll back, do we offer all kinds of rollbacks and, and the diffs and wire and do we offer enough and more on the, um, 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.

Mm-Hmm. And of course there is, needless to say, there is deep amount of SecOps built in as well. So you don't worry about, um, you know, unsecure builds and all of those kind of things.

It interfaces with all the other interface, you know, security systems and scans, et cetera as well. It's interesting 'cause you are catering to targeting kind of multiple personas, if you will. You know, developers sort of abstracting away Kubernetes the whole build process, DevOps tool chain, workflow pipeline.

And then of course deployment management sounds like a Kubernetes once you're in production, correct? Yeah, yeah. So could be a developer, could, could be a platform engineer, SRE ops, whatever person, which has much different requirements.

Right? Um, 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? So, a there are, um, so okay, people who are already matured on Kubernetes.

So b give them, and you know, I think we take away, we sort of add another few layers on top of it to set, you know, 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 like say, what are the templates? You know, how can you roll back? What are the deployment types?

Can you do cannery, bluegreen, um, uh, rolling, et cetera. And we are also looking at what are the best ways this entire, like, disparate systems are the learnings from how you deploy and what are the best ways to deploy in a fairly matured environment. Uh, we are working on something called as ephemeral environments or temporary environments, which are basically, if you're not using any sort of, uh, clusters during any of your deploys, it brings them down and which automatically takes care of the costs and everything else.

So it sort of, it containerizes or it contains it in a certain temporary setup and does not let you take, uh, enough memory and, 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.

I worried about cost, you know, 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 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, in the tech stack.

So that is the, the, the path for platform engineers and DevOps, of course, the, the whole transition from, uh, either a legacy network or your Kubernetes from less mature to more mature, that journey is for the developers. So it's, you know, equally distributed for both of these folks. But largely we have tried to rather focus a lot on how do we make this system, uh, DevOps persons or, uh, or, or, uh, you know, 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, you know, finger pointing, et cetera. You did not do this and I did not do that.

Why? Because everybody's not on the same plane. 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 hand and saying that, how do we optimally work between these two groups? There is very little that fell, you know, that falls through the cracks and we are able to sort of at least find an answer. At least TRON is an attempt to solve that.

How much, so you mentioned you're being get ops based. Um, how much do you find on the repository to have everything in that, to be able to drive what Tron does? Or do you help people get, maybe they don't have everything, all their config files or scripts or whatever they're using now?

I mean, you would think a lot of that's gonna be in there, but it may not necessarily be in a well organized or structured way. 'cause those things tend to evolve over time. How do you help people get to a point where Tron can take advantage of it and start using that concept?

So Our open source is literally everything on the, in the repository that we have. And we actually help folks, uh, for all our commercial, uh, products. There are some of the, so what we've sent, you know, as I said initially is from an adoption point of view and a migration point of view, everything is given out in open source.

You know, um, role-based access controls, very fine grained. Actually you people were a little worried about that. I may not be able to give controls or accesses to sort of 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 brained that, 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 and living.

So that's one point. So all of, so our backs, SSOs, single sign-ons, everything has been bundled in into the open source. So because we don't want any guardrails in terms of adoption of Kubernetes, that's the first promise.

And once you are ready and comfortable to move things into production, that is when, when we come with, you know, 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 you know, 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 for, 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, and, and the open source repo, and also get some of those controls and planes when we actually help people onboard them faster there. We have a very vibrant, uh, discord community folks, uh, sort of interface with us on Slack as well. So I think our idea is that, you know, we are leaving no stone unturned in, in order for people to sort of adopt Kubernetes via they're drawn.

Our vision would be, uh, and all of us think about that when people think about migrating or adopting Kubernetes, the first name that should come is de tron. And, you know, that's the way we wanna build. Great, well congratulations on your success so far and your growth in the US North America market and enterprises.

What's the best place folks to check this out? Go check out your GitHub repository. Go website, tron website, tron AI website.

We have folks all over us, uh, our US headquarters data out of Silicon Valley. So hopefully, uh, we are available. Literally, I mean, come check us out and uh, I'm sure you'll, you'll like it, right?

Join the Slack channel, do the thing Standard. Yeah. There's Discord.

Yeah. And they can join it. So There's a lot of great help and support.

Absolutely. Communications happening there. Absolutely.

Well, good look forward to, um, more great progress and, uh, your, your, your timing is great. 'cause you know, adoption and management of Kubernetes is, thank you. A massive theme right now for where we are in the adoption cycle.

So Raj, who is a co-founder in go to market with, uh, dev Tron. Dev Tron, do ea, right? Yes.

Okay, good. Make sure I got that. Thank you very Much, Mitch.

Thanks for Having me. Yeah, thanks for joining us. Thank you.

Come back and talk to us again. Absolutely. Look forward.

Thank you very much. We'll be right back with more great interviews, so hang tight. We'll be right back.