Spaceship Komodor

Video size:

0:09 Miko Pawlikowski

Hello and welcome to Conf42Cast. My name is Miko Pawlikowski and today my absolute pleasure is to host Ben Ofiri, the co-founder and CEO to Komodor. Ben, how you doing?

0:20 Ben Ofiri

Hey, it's a pleasure to be here. Thank you so much.

0:22 Miko Pawlikowski

Thanks for finding time. It wasn't easy with a different time zones. I'm glad it worked out. So first, let's confuse you a little bit. If you could live anywhere in our solar system, where would it be?

0:34 Ben Ofiri

An interesting question to start with. I think that after with all of the COVID-19 situation, definitely want some place away from people. Not sure. So probably Earth is not a good option. Probably Mars not as well, with all of the Bezos and Elon Musk's of the world junk together. So weill probably be maybe on Saturn drinking some cocktail. And then, you know, watching people trying to get to different planets from Earth.

1:01 Miko Pawlikowski

Love it. I appreciate the honesty. All right. So for everybody on Spotify who can't see Ben, he looks very professional. There is a Komodor backgroung and it's hard to miss Komodor. So I'm gonna go and jump straight to that. Ben, you started the company. Why?

1:19 Ben Ofiri

Yeah, it's a fair question. So I actually co-founded Komodor a year and a half ago together with my partner, which is today our CTO. And both of us were developers. So we came from a very technical background, we're backend developers, infrastructure engineers. I think the kind of developers that today will be defined as DevOps or even SRE in some companies. And we had several years of experience working for different companies, I worked for Google for almost six years, and my partner started in a big company like eBay, then he transitioned to work for smaller companies and smaller startups. And actually the pain that we felt personally on our own flesh and blood from our years as developers and DevOps developers, and from the weeks or months that we spent on on-call rotations, those were basically the basis or the motivation for us to start the company. So actually, we were very frustrated for many years from how hard it was and how tedious it was to troubleshoot complex and distributed systems. Today obviously contained from Kubernetes. But a couple of years ago, it might be some Lambda, and VMware's and Serverless and EC2, etc. What both of us failed for many years is that given an alert, given an issue, given an incident, which is just a matter of time, when the company is big enough, right, it's a matter of seconds, minutes, hours, days, the first thing usually you do is like you go say like, 'Wait, like what the heck happened in the system? Five minutes ago, everything was great'. Now I'm getting the Solera, getting a symptom from one of the monitoring systems and trying to understand what changed, I'm trying to gather all the context needed. But this job, this very naive description that just tried to understand what happened is sometimes a very hard task and very, very hard problem for a lot of R&D organizations from the single fact that no one really knows what changed the system. So the systems are originally very distributed and very complex, and they change very rapidly. And basically, you need to be an expert in all of those different tools, right, like Kubernetes, Jenkins, GitHub, maybe your monitoring systems menu, maybe volt console, other configuration systems, maybe in the cloud layer in AWS, or GK, etc. And probably you are not an expert in all of those tools. Because you are developers that like to write code. So it's a very hard task, it requires a lot of expertise, and can be very frustrating for a lot of people. And at some point, we decided that, 'Hey, let's try to think together if we can ease this experience, if we can change our people troubleshooting. And if we can take this very complex and frustrating process to make it something that is very easy, and sometimes even trivial to do'. And with this ambition, or with this goal, we actually started to work on what is today Komodor.

3:55 Miko Pawlikowski

Okay, so would you say that that kind of starting point and the unique selling point from the beginning was tracking all the differences of what goes into, I guess, production in the end and all the other stages, and then kind of grew from there?

4:08 Ben Ofiri

Yeah. So differences is a tricky definition. Because sometimes you have a difference, because someone made a code change or a configuration change, right, from X to Y or something like that. But sometimes the difference is difference in the health of the system, right? Maybe it was healthy, and now it's not healthy, or maybe it's somewhere inbetween. So it's very tricky to exactly define what are the most interesting factors. Or what are the things you need to look for when you have an issue. But it's definitely somewhere between the changes themselves, the statuses of the different components, and maybe most importantly, the relations between the different sub-components, their statuses and what change there. So you basically need to have an understanding of not only what changed, but also how those changes correlate or relate to each other and how together they can affect a status change or a health change or a different symptom in your system.

5:00 Miko Pawlikowski

Right. So to take the example of Kubernetes, which I think is probably going to be the most popular option for everybody listening to this, or most of them. So it's basically like diffing the Yamos plus looking at the events of what actually happened. And when things stop working, and getting all of that together somehow to mash it up into a congruent image?

5:23 Ben Ofiri

Yes. So if we think for example, once again, about Kubernetes. So my analogy for Kubernetes for Dummies, right? Not particularly technical people, is that it's very similar to an analogue watch. So you know, in most of the time, it just works. And it's like a magic, right? Like it can read the hour, you know, it's 6pm. You don't need to think about how behind the scene, this thing walks, you don't care. But when your watch stops working. And if I have an analog watch, you hope that it's the battery, right? Maybe you can replace the batteries, great. But if not, you know, you probably need to go to some expert or some technicians, because he will never be able to grasp the complexity behind all of the different sub-components there. So Kubernetes is pretty similar, much more complex, much more distributed, much harder to grasp. But the analogy is very similar. So in most of the time, it just works. But when it doesn't, it's not only a matter of doing some diff between some files, because there can be hundreds of thousands of files that all of them changed in the last hour. So what are the things that you're trying to match? What are the things you're trying to find? What are the questions you're trying to ask yourself? So maybe we'll find the answers by diffining some files. Those are, in my experience, in my opinion, those are the complex issues, this is the real problem. They're like getting the context of how those different components work together. Like for example, you know, an obvious example is that you have a pod that is doing restarts, right? It's like it's in the crash loopback of mode is there, this pod is doing restarts, you get an alert, you know, you have a file that is not loading. Okay, you can check, you know, the pod, the file, you will see nothing, maybe. And maybe then you need to understand, wait, is this, the only pod that is doing restarts? Or maybe then all of the ports that are on the same node are doing restart, so it might be something in the node. Okay, it's all of the pods, okay, so it's a problem in the node, let's go check the node. And then you say, okay, what's the problem in the node? The node looks healthy, but you might be able to understand that, you know, it is a provision issue. So you might need to increase the CPU or the memory. So basically, you need to know which questions you want to ask before you actually go to doing any diffs or to like checking in any information. And from our experience, usually the developers, the on-call developers, etc, just don't even know which questions they need to ask. And then they don't have the tools to really answer those. And this is, I will say, the biggest problem we're trying to tackle or the biggest pain we're trying to solve.

5:29 Miko Pawlikowski

Right. And that reminds me, first time I was playing with Kubernetes auditing logs. The first thing I noticed is that it's not actually that easy to get any meaningful information out of that, if you just log, even if you just look things about pods, just to separate the automated stuff, that's just, it's happening in the background, and supposed to be happening in the background from the actual changes that you make, it was already pretty tricky to get to that stage. So I can see definitely why the...

7:38 Ben Ofiri

I think we spent five years of, you know, one engineers, only two separate automated stuff, like HPA and auto scaling, or LT and Phaedra, from manual stuff. And we call it expected and unexpected. We thought it's like one week project, you know, hey, let's take the expected like, you know, we're increasing the number of replicas, right? Because there was an auto scaling. So obviously, it's okay that we have only 50 replicas not 60, because we're in the middle of increasing it, right? It's natural. This is how Kubernetes works. Versus, we need to have 60 replicas for some bad reason, we have only 50 replicas available. This is a bug, it's affecting production, like you're bleeding money. And we thought, hey, it's a nice project to differentiate between those two scenarios. And it ended up with one of the biggest obstacles and challenges we had in the company, which I'm proud to say that we overcome, but definitely it was not that easy to do.

8:59 Miko Pawlikowski

Speaking of overcoming challenges, so I'm wondering for this kind of project, getting it off the ground, and you started during COVID. So I'm going to come back to that in a minute. Because I'm very curious how that actually affected you. But what would you say were the biggest challenges to overcome to get it off the ground?

9:15 Ben Ofiri

So obviously, our solution, you know, it's pretty sensitive, right? Because we need to install some agent within the Kubernetes of our customers, into VPs of our customers. Whether it's on pram, or it's managing one of the cloud providers. And you know, when we started, it was only a year ago or a year in two months ago, you know, we didn't have any LinkedIn page. We didn't have any website, we were completely in stealth mode. And even if we were having a website, you know, it didn't contain anything interesting. And basically, you know, we knocked on the doors of the head of DevOps of, you know, great companies in Israel in Europe and the USA. And basically, we offer them to install some agent that can read all of their changes, right? They metadata changes and the code changes and it digests everything and provides insight. And we thought that they will say, 'Yeah, sure, go ahead'. No, it was not that.

10:00 Miko Pawlikowski

'Okay, pinky promise, won't steal the data'.

10:02 Ben Ofiri

Yeah, so you know, obviously as some of the listeners can hear we have some accent, we're Israelis. So there's like culture issues there are time differences there is language barriers. So it was not that easy to convince, you know, head of DevOps or director officer in, you know, some of the biggest and most successful companies in Europe and the USA to actually allow us to install our solution in their production system without any, you know, security certification back then, and without any evidence that it actually works. So we worked pretty hard on that. Basically, we had sandbox environment. And you know, we did a POC with our first design partners and customers. We are working very, very with a definition of Kubernetes, with all of the Arabica configurations, etc. So users can actually see via the Kubernetes manifest, which resources we consume, and how. So we tried to really work, you know, together with our customers in order to get this first trust. But I think now, after, you know, successful onboarding of dozens of customers, we're finally there, like we find that getting customers from references, and customers that have heard about us from different companies. And you know, this barrier is obviously much lower today, is a bit more mature company than it was when we just started.

11:08 Miko Pawlikowski

Yeah, and you only started early last year, right? I guess out of the stealth mode really. So let's talk about COVID and pandemic. How was it to build the whole thing, basically, during one of the weirdest times in living memory?

11:24 Ben Ofiri

I will give the disclaimer that they don't have anything to compare it to. So it's the first time I founded the company, it's the first time I thougth of founding the company, and it happens to be in the weirdest time ever, but I really can't compare it, you know, to five years ago or anything like that. So I can tell you how it was for us. Both of us had this, you know, great goal and motivation that I mentioned earlier to change how people are troubleshooting and to change how developers are operating Kubernetes. And it was so exciting for us that we decided to leave a very convenient day job. So I was a product manager in Google and Google duplex, which was back then one of the coolest projects I think Google did for a couple of years. And my partner was the first employee in other startup that is doing DevTools named Draw Card, when you know, he was very happy in his job. And you know, we decided to quit our day jobs to fulfill our dream. But this was in February, last year. And it was before the pandemic was, you know, a global pandemic, it was something that you read on the news, you know, in the end of the news about something that, you know, is happening in China. And after a few weeks when we started to do validation. And we actually, you know, decided that we want to raise money to really start the company. It was somewhere I think, between March and April, it was the exact time where Donald Trump decided that, you know, he's locking down America, the national sport stopped, like, you know, the NBA in the NFL. And I told my partner, look, if in the USA, they don't play sport anymore, we're doomed. It's not going to work. And to help us Sequoia just released an open letter that called 2020 the "black swan of investment", and basically, they recommended all over the VCs not to invest in new companies, but rather save the funds to their existing portfolio. So obviously, it was very nerve-racking experience. Both of us left our the jobs, you know, we have families to support, we need to do something, right? And we said to ourselves that we have, you know, a lot of motivation, we have a strong team, we're going to do it anyway. And we went and we raised the seed round, which was back then not that easy to do. You know, today, companies are raising money in a very high rate. But a year and a half ago, there was like a few months of almost a complete halt. But we raised the seed round from great VCs and engine investors, we hired the first employees and we just went full blown to start working on the first MVP. And fortunately for other things, you know, things worked out both for us and I think for the entire investment, economic and you know, we also raised the errand shortly six or seven months after, so things worked out fine, eventually.

14:01 Miko Pawlikowski

They surely do seem so. So, do you want to talk about the latest funding round?

14:06 Ben Ofiri

Sure, I can share the things. Yeah. So um, so the seed round was, as I mentioned, like, something like a year and two months ago, and originally the money should be sufficient for us for at least two years. But shortly after, you know, we started working on the MVP when having first design partners and first customers, it seemed, at least from my perspective, that you know, something changed on how VCs and maybe how, you know, other people grasp what Kubernetes is, and what it's doing to the role. So when we raise the seed round, not a lot of the VCs really understand the cultural changes, you know, the real effect, the permanent effect that Kubernetes brings to organizations. But something happened there in those six, seven, eight months after we raised the seed round. And all of a sudden doing something with Kubernetes that is helping developer and DevOps became trivial, right? Like yeah, obviously and it needs to do troubleshooting for Kubernetes, obviously, you need to secure Kubernetes better, obviously you need to read Kubernetes and allowed to ship Kubernetes faster, etc, etc, etc. So basically what happened is that once we got the early traction for first customers, we had all of the, I would call them top tier VCs in, you know, European in the USA, knocking on our doors, and those are the same VCs that probably would not answer our phone calls like just six months ago, asking, 'Hey, how can we never met? How can we're not talking about the errand?' And I was like, you know, 'Wait a bit, we're still trying to get the first traction, we're still building the product'. But there was a very large appetite from the VCs. And eventually, basically, we got preempted by several VCs. And we're fortunate enough to be able to choose the partner that we want to work with. And we chose Excel, which are amazing partner to work with. I don't need to say good things about Excel, obviously, their brand is amazing. And it was a love at first sight. And I'm very, very happy that we teamed up with them. And they're helping us since then. So we're working almost six months together already. And I'm really happy that that we found each other.

16:06 Miko Pawlikowski

Well how the tides turn, right?

16:10 Ben Ofiri

That's crazy.

16:11 Miko Pawlikowski

One of the unique points of view, unique experiences that you had, was that you've kind of been on the both sides in terms of Kubernetes. You've seen Borg, you worked there, and you basically watched Kubernetes become what it was becoming, you know, from the fence of Google. I wonder if you could talk a little bit about how it differs from Borg, as much as you can talk about that, and your personal opinion on whether Kubernetes is here to stay and why is everybody throwing money at it?

16:44 Ben Ofiri

Yeah, definitely. So I will share a bit about my experience at Google. So obviously, as you probably know, you and the audience, Kubernetes started as an internal project within Google named Borg to basically become, I would say, like the cloud operation or the engine for all of the internal Google Cloud infrastructure. And there are a few nuances, differences between Borg and Kubernetes. Kubernetes basically provides another layer of abstraction that we had in Borg in order to support different cloud providers and different environments, and different components that in Google, we have only one of each, right? Probably you heard about, Google developed all of their monitoring infrastructure and tooling internally. So we have one logging solution, we have one monitoring solution, and we have one orchestration solution record for Borg. So obviously, when they released Kubernetes, as an open source, a lot of changes needed to happen to be much more flexible, and to add more abstruction. So it can work better with different components, different cloud provides their OnPrem, Hybrid, etc. The basis is very similar, I would say that the biggest building blocks are almost identical. And obviously, the processes needed and the expertise needed to operate the Borg and Kubernetes is almost overlapping. But again, like, besides the another layers of abstruction added to the external version.

18:07 Miko Pawlikowski

So going to the second part of my question, so that's all cool. That's all great. But what happened? Why did it explode like this when it became Kubernetes? And why is everybody and their pet dog investing in it now?

18:21 Ben Ofiri

Yeah, so obviously, you know, it's a good question and you can only answer in retrospect, right? Because no one you do years ago that this is going to be the situation. So I think there are a few reasons. One of them is I think it's obvious today that first of all, containers are the go to way of building modern apps, right? I don't think anyone will say, 'No, containers suck. You should not use containers'. So you know, it's a big chunk of why I think Kubernetes became so trivial, because a container is already the gold way of building modern apps, right? Then Kubernetes ecosystem was rapidly, not only maturing, but also adopted, right? So first of all, companies like Google and Netflix, you know, announced that this is how they work. And obviously, those are the companies that you look after, when you try to understand what's the newest, what's the hardest, what's the thing you need to adopt. And later on, because it was open source project, a lot of companies started to adopt it. And it was like a snowball that fed itself that eventually became the most common open source project for the cloud native community. So it's also something that, you know, helped it to grow exponentially, then I think, you know, the security folks jumped on this train and started to secure Kubernetes. So now, you know, there are tons of companies doing great job on securing Kubernetes. So it's definitely enterprise-ready in terms of security and compliance for organizations to use. And I think that with the digital transformation, it's very obvious that if you won't move fast, you will die. And one of the ways to move fast is to, you know, have more microservices and have more developers the ownership end-to-end to their production, right? This whole DevOps methodology is based on the fact that the developers and your ops guy can work together, can move fast together and can operate as one team. And I think Kubernetes allows companies to do exactly that. Now, it also has downsides, right? It's not perfect, but it definitely allows companies to move much, much faster and to adapt to this digital transformation. So I think all of them combined to the fact that Kubernetes now became de facto standard for what I say, is the operating system for cloud operations today.

20:25 Miko Pawlikowski

All right. And do you think that means that with all this investment, even when you know, the next best thing ever comes along, we're still going to be using Kubernetes, you know, a decade from now?

20:36 Ben Ofiri

So I'm not sure if it's going to be the same Kubernetes that we know today. But I definitely think that if not, it's going to be something that is built on top of Kubernetes. For example, you've probably heard about the Knative or other solutions that are providing other layers of abstractions and other capabilities upon Kubernetes. So I don't want to give my forecast if it's going to be Kubernetes 5.6, or something that is built on top Kubernetes. But I definitely think that it's here to last and everything, it's going to serve us many years to come.

21:08 Miko Pawlikowski

So going back to Komodor. How does one get started? Where do they go? What did they do to get a taste of what Komodor is like?

21:17 Ben Ofiri

So fortunately for us, we have a free trial for everyone. So basically, the only thing they need to do is, first of all, they need to think that they have an issue or they have a problem, right? Do they want to understand better what's happening? Do they have a lot of features in Kubernetes? Do they want to understand why they have specific issues or even that they have specific issues in your system? Then the only thing they need to do is go to komodor.com, apply for the free trial. And from there, one of our solution engineers will basically reach out and start a free trial and it takes 30 minutes to deploy a solution on our customers' environment, we are very, very, very low touch, we're going to release a self-serve version very soon. But until then, you know, we're setting up a meeting, we're opening an account, and basically installing our agent on your environment, it takes roughly a few minutes. And then you can see all of Komodor's value on your system, you can play with it, you can examine it, you can ask to add more things. We really like to work very closely with our customers to receive feedback, to receive feature request, to receive bugs complaints as well. And that's it, so super straightforward process.

22:22 Miko Pawlikowski

Alright, and the bonus question then. Why is it called Komodor?

22:26 Ben Ofiri

Yeah, this is the elephant. Okay, so as you probably know, all of the Kubernetes theme is around shapes, waters, sea, Kubernetes, Helm, etc. And we were looking for a name that will represent some leader in this space, right? My dream was to have some name that will basically reflect that we help developers and DevOps to handle the storm of complexity when you're using Kubernetes, right? It's like a ship in a very high water, and you want to be the captain of the ship. Unfortunately, captain was already occupied, no matter how you spell it with the C with the K with the Q. And the second best thing we found was Komodor, which is another Navy rank, almost like a captain. And we obviously spend it with a K for Komodor. And this was the first reason why we chose Komodor. Now, later on some other employees or some other investors thought differently about the origin of the name. So we have a few explanations. But if you ask me, this is the real explanation behind the name.

23:29 Miko Pawlikowski

Right, thank you so much. This has really been good. But before I let you go, I want to speculate a little bit with you and squeeze a little nugget of information for everybody listening. So if you were to go into speculation and make a bet on the word technology, or language, methodology, whatever a skill is going to become more and more important, let's say within the next six to twelve months, so it's worth investing time in, what would be your personal choice?

24:00 Ben Ofiri

So maybe I'll surprise a bit with my answer. I don't think it's a matter of a specific programming language, for example, we stopped having a minimum requirement or criteria for a specific programming language, meaning we don't care. If you know, Java, C++, Python, Node.js, React, we don't care. What we're really looking for in modern developers is the ability to become a real full stack developers. And when I'm saying a "full stack", I'm not only saying you know, frontend versus backend or something like that. But I want to have people that really understand your system, that can really understand from the deployment, when it goes to production, when you need to troubleshoot it when you need to debug it. I want someone that can take it end-to-end. This is the only way I think organizations can really fulfill the DevOps movement or the DevOps idea. I really don't believe that what you need to have is a bunch of developers and bunch of infrastructure developers and bunch of IT or SRE and you know, someone to manage all of them. I think this is the recipe for organization that won't be able to move fast enough. So what we're looking for when we interview and when we hire developers is the ability to really understand end-to-end, the entire lifecycle of software development, from designing, to writing code, to test it, to ship it to production, and to debug it and troubleshoot it when there are issues. Because there will always be issues when you want to move that fast.

25:21 Miko Pawlikowski

Absolutely. With a disclaimer, past performance is no indication of future returns. All right, thank you so much. This has been a real pleasure. Ben Ofiri everybody, the co-founder and CEO at Komodor. What's the best way to find you?

25:38 Ben Ofiri

So you can find us at komodor.com or just email me personally, if you want at ben@komodor.com.

25:44 Miko Pawlikowski

There you go, a direct email to the CEO. Thank you so much for that, all the best with Komodor and we'll see you next time.

25:50 Ben Ofiri

Thank you so much. It was really, really fun. I appreciate it.

25:53 Miko Pawlikowski

Likewise, thanks.