Solving Application Networking Challenges with Idit Levine
This conversation covers:
Idit’s role at Solo.io, and what she typically does on a daily basis. Idit also talks about how her job duties have changed over the last two years, and the impact that COVID-19 had on the company.
The common business reasons why customers come to Solo.io — and where they typically are in terms of cloud-native maturity.
Some things that Idit has learned about customers over the last two years. In addition, Idit talks about her own journey at Solo.io and what she’s had to learn along the way.
How Idit’s customers typically benefit from using distributed systems — and some of the top misconceptions that they tend to have about using them.
Idit’s thoughts on the market for cloud-native technologies.
Links
Transcript
Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.
Emily: Welcome to the Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Idit Levine of Solo.io. Idit, I want to start out, first of all, by thanking you for joining me.
Idit: Oh, thanks so much for having me.
Emily: And then, second of all, I wanted you to just start off by introducing yourself: what you do, what your company does, and also a little bit about how that translates into what you do every day, like, what activities you spend your day doing.
Idit: Oh, for sure. Okay, so as you said, my name is Idit Levine. And I’m, right now, the founder and the CEO of Solo.io. I started Solo two years ago, and when I started it, my focus was try to solve our [00:01:24 unintelligible] application networking problem that we know that will come up.
So, what does it mean? As you guys all know, there was a huge shift in the market between monolithic to microservices and, kind of like, moving from technology of monolithic to microservice stack mean that now we also moved to a distributed application. And it was clear to me that now everything is basically will go on the wire; any communication, small communication, between those two microservices basically will have to go to the network. And I thought that would become a big problem because stuff that we didn't need to take care of when everything was the same binary, now we need to actually figure out how to solve. And basically, I was really passionate, thought that that will be a huge problem in the ecosystem and I was very passionate to actually try to solve that. So, the idea was, how to connect, right? How to connect the application, how to connect everything related to your, eventually, application to the user.
Emily: And then tell me a little bit, what do you do every day? When you start, what does an average day actually consist of?
Idit: Oh, wow. So, it's really interesting, that I think it's a huge difference between now and what I was doing a year ago. Right now, basically, it's pretty simple. Corona came by and it was influence a lot of companies. I was assume that it will influence also my company, and therefore I basically freeze hiring, freeze everything, and try to do the best I can with the resources that we had.
What happened is that actually, not only that we didn't was influenced, we actually over doubled our revenue every quarter. That's basically forced me to immediately grow the team to be able to actually serve all those customers. Right now, basically, the main thing that I'm focusing on is—besides the technology, of course, in the strategic of the company—is basically on growing the team. So, it's hiring, it's interviewing, it's looking for the right people, it's building. You know, basically try to grow the team as much as I can in order to basically, yeah, serve well, the customer that are asking for us to—you know, for our products. That's a lot of my focus this day.
Emily: And what do you find are the business reasons? What's the business problems that cause somebody to come to you?
Idit: So, as I said, once people basically is moving from monolithic to microservices, there is a lot of simple stuff that before that just natively happened inside of the organization; right now, it's a little bit more complex. So, first of all, they needed to find something to run it on, and this is what Kubernetes so great in this ecosystem is the ability to install, upgrade, and basically orchestrate their microservices. But then, as I said, simple stuff that before that people were baking into the microservices created a lot of issues, like small stuff, like how do two microservices communicate with each other? How do you make sure that they're doing it safely right now? Because as right now, it's all on the wire, so potentially, there's always a third party that could, you know, join the party.
So, you really need to be safe and make sure that there is a very secure line between those microservices. And then the last thing is that because there is so many because the idea of microservices was to allow you to scale, the question is how do where the request is actually routed? So, in the [00:04:52 unintelligible], request is coming, and there is a lot of replication of the same microservices, and you have no idea basically where it's coming and where it's landing. And then it will go to the next level of the microservices, and again, not know which instance of it is basically being hit.
So, now the question is, how do you get visibility to something like that? How do you know what's going on in your cluster? How do what to look for the logs when now it's distributed all over the place. So, that's a lot of problem that the organization basically started to have. As well as with this—if—before that, there was a technology called [00:05:26 api-get] that was relatively popular, but people somehow—it wasn't a must.
Right now, when microservices was adopted specific in environment like Kubernetes, when everything is very cloud-wise, you know, stuff is coming up and coming down, you really wanted to make sure that you have a place that you can actually control the policy, control the [00:05:50 unintelligible], the [00:05:51 unintelligible]. And that's basically where API can help. So, that is basically—how do you manage all this networking, basically, of all these systems and applications, as an edge gateway? It's something that going inside your cluster, as well as what's going on inside the cluster after it. And that's basically, yeah, the main problem that you're solving.
So, every traffic to your infrastructure, node to start, we're basically taking care of exactly of everything that you then have traffic between what called East and West, inside your cluster. And that's basically the stuff that we are targeting. So, customers that calling us is mainly usually aware of more like, API gateway and service mesh, and they are basically looking for the one that is the most innovative one, the one that can solve them the problem in a very Kubernetes-native way. And this is where we actually very attractive.
Emily: And how do you usually position yourself on the cloud-native maturity journey? When somebody comes to you, how far are they, usually, on that maturity journey.
Idit: So, that's very interesting. When I started the company, it was clear to me that service mesh would be a very big thing that everybody will adopt, but I also knew that it will take quite a while until the market will get there. And I also knew that every company that will come with me will be, as you said, in a different level of maturity. So, what's always very focusing on, is basically, is the journey. So, you have customer that's just have monolithic application, don't even using something like Kubernetes yet, and just interesting of basically moving. So, we will have those guys.
And then once they actually adopted, they will need some API gateway that is natively running on Kubernetes and will help them with. And then when they will decided that they have more and more microservices, they probably want to adopt something like service mesh. So, we have that, the second pillar of the company that basically focusing on service mesh, and then once they do this, we even going the next level, and basically help them extend those measures. And that’s, you know what, basically imagine that because of this technology, it's allowing us to basically attack more use cases. So, that's the next level that we are in.
So, the idea is that we're getting customers from all over the [laugh] the spectrum: people that just starting, people that wanted to do already adopt and looking for the next thing, people that adopted and looking for more innovation stuff. So, it's really, kind of like, a journey that you're taking with us, and it doesn't matter where you are in this journey, we usually have a way to help you getting even more innovative.
Emily: And then what do you find about when somebody is going to be happy with say, a pure open source solution to something versus when they need an enterprise version? Like, when they need to pay for something? What are the different characteristics of someone that's going to be happy with pure open source versus not?
Idit: So, specifically now [00:08:47 unintelligible] is very depends in— what is the feature that you're looking for? [00:08:53 unintelligible], we have a lot of people that are using open source are not paying us a dime, and this is totally fine, and we excited about having them as a user. The way we, kind of like, differentiate our model is the thing that we are putting on top of service mesh, it’s what people usually are paying for us. So, stuff that related to security. So, if you really care about security, you want something like web application firewall, you want something like data loss prevention, that's usually when you will basically want to come to us and basically ask for help.
The other thing that is very important is support. So, we have a very, very active open source community. And we are helping as much as we can, and I think we are very, as I said, not only that we are helping right now, our community is helping, which is a beautiful thing to see. But if you are a huge organization, like Vonage, or at a company like ADP is that basically running in production, most likely wanting 24/7 immediately getting support. And that's basically what will be on offer as [00:09:57 unintelligible]. So, it's mainly very related to this.
In terms of the people, I will say that there is a lot of company that just come and gets a set and taking the open source usually is people—as I said, even people that are less familiar with that, we are doing a lot on the [00:10:11 unintelligible], so we can help them to get where they want. I would say that the only thing is basically mainly is this support and some security feature that we're putting on top of it that is not available to open source.
Emily: What have you learned about your customers over the past two years? Do you think there was anything that—like any misconceptions that you have that you’ve discovered that were not correct?
Idit: Yeah, my gosh. Yeah. See, I mean, first of all, [00:10:40 unintelligible] is a little bit interesting. We actually, all the work that we're doing, customers coming to us, it's all inbound leads. So, we are not going to any customer, they are coming to us.
I think that the majority of the thing that I learned that is extremely important is that if customer is committing, and actually starting a POC, you learn so much about these environment, what does it mean for him to run? What does it mean for him to upgrade? Because in the [00:11:06 unintelligible], when you using open source specifically, when there is such a different variety of customers, I don't think you getting enough exposure to the people that running in more big organization because usually those people is not going to use open source; they will look some provider to help them adopt that. And therefore, you're not exposed to their environment, you don't know what their limitation, you don't understand how they—you know, the politics in their organization, you don't understand how the security division is working together with architecture, and so on. And I think just learning this is teaching you a lot because it's explain you what is the limitation in your product that you just, to be honest, didn't even envision that exist.
So, why people is not just taking the new version of my product? This is the best, which is put a lot of a work on this, and why people is not upgrading. Then you learn stuff, like for instance, what does it mean to upgrade in organization, in big organization like this? And you discover that it's a really, really big deal, and it's very hard. And their probably doing it over six months to a year testing before they actually putting into production.
Just to upgrade, it's not something that is extremely simple. And I think all this stuff, if you're looking at the open source community, I think that's what they're missing, all this exposure for different environment, different organization, how does it work? What is the limitation? And then of course, if they don't know, it's very hard to try to solve it. So, I think that that's what make up for the exposure that we have with the customer.
That's what make the products better. And I think that in open source community, it's not always the case. Specifically, not when it's young, relatively. I'm not talking somthing like Kubernetes, that has Red Hat and all those guys involved, and therefore they're basically bringing the information there. I'm talking about open source that basically people start using, usually, they're missing all this input from the customer, which is extremely important.
Emily: And how have your job duties changed over the past two years? One of the things you mentioned was like, “Oh, gosh, what I'm doing now is really different from what I was doing a year ago.” So, what were you doing a year ago? What were you doing two years ago?
Idit: Yeah. So, I think that in the beginning, when we started the company, the focus was more on the product in the open source. My job was basically understand why do I think that—basically to find a market fit. That was basically my focus. I was doing a lot of product stuff, I was trying to understand—of course, we grow the team, and but not in that based because we didn't have customers back then, of course, so was less interesting to me.
Marketing was totally different, with the idea was to create an awareness versus right now we already have awareness, so the marketing is changing more to target leads. So, a lot of stuff in the company changed, totally. How do you manage, right? When we had before, and we were very young, and we have—I don't know—10 engineers, it's totally a different skill to manage when you are 50 engineers. So, a lot of stuff change, and of course, every phase of the company is different.
I think that, as I said, what as the big kind of like, push back and forward was once we started to acquire a lot of customers, and the knowledge base that they gave us; that was extremely useful. That, I think, when you need to start suddenly thinking about stuff that you didn't in the beginning, how do you support that? How do you make sure that they have a 24/7 support to it? How do you help them to actually go to the production? The skill are different.
It's not enough—not necessarily, the engineers are the one who will need to do this. I mean, someone can write the best code in the world, but maybe it's not the best solution architect that exists. So, just attacking different groups. Suddenly, instead of just hiring an engineer, now I needed to hire a solution architect, the field engineers. So, the focus of the company doesn't change; you want people to run into production, want to make sure that we are—you know, it's not only about creating a community, it's not only about open source, it's more about how we’re actually making our product the most usable for the real use cases in the world. And not just people, maybe just for fun trying it in the open source.
Emily: What do you think are the top three things that you've had to learn?
Idit: Yeah, a few things. So, first of all, I’d start with the fact that before I started Solo, I worked in a very big company, EMC. When I started Solo I—one of the perception that was changed for me is that, when you're working in a small company, it's way harder for you to get a lot of stuff that you assume that would be—that was extremely easy when you work in a big company. Like when I was in EMC in the beginning, everybody wanted to interview me. Everything that I did, any announcement that I make, created such a huge noise.
Versus then, when I moved to—started Solo and we were a very small company, and no one know us, everything that I tried to do was [laugh] way harder to get, right? Attention to the market, attention from the industry, attention for reporters, everything was it will be harder to do. So, that's one thing. Totally different. And that's true for everything.
I mean, if Google will go and put some open source project out there, no matter how good it is, it will get a lot of eyes on it and people will be extremely excited. I can put an amazing project to, and the same equivalent project in the open source, most likely, I'm not going to get the same coverage. So, that's number one that basically are saying, “Huh, that's different.”
The second thing that I learned is that I think that a lot of us, not only me, has this perception of, we're going to put a very good project out there, and that's it; that's all we need: good technology out there, people will see it, they will understand how amazing it is, and we will become the best—the next—I don’t know—HashiCorp. That's really not how it works. Also, it's not enough to put the project, and then hope that the community will come and build it with you. As I said, that's maybe true when you are Google; that's really not true when you are Solo.
When you putting a project, doesn't matter how good it is, there’s one of two things that will happen: either people will come, and then just expect you to continue building it, but it will be on you to build it, which is totally fine, and that that's what I think it should be; Or even worse, other people will come and copy the project from you. And you saw that in the open source. So, I think that a lot of the perception about open source, I was pretty naive about how these things work. And I think that was something that I definitely needed to learn.
And I think that the last thing, and as I said, is the most important is exactly understand that in the [00:17:37 unintelligible], I need to get a real customers; people that has skin in the game. They pay you money, and because they pay you money, they will put a team, and they will work, and they will stress it, and they will make sure that it will run perfectly, and they will make the product better by giving you an input. And I think again, in the beginning it, I was relatively naive when I came, and said, “Oh, we’ll put a project. It will be cool. We are smart. We can figure out what to do.”
But actually, it's not working like this because no matter how smart you, if you don't have the data, you can’t make the right decision. I think that that's the third thing that, basically, it was a huge change in the company once we start to get a real customer running it in production. I think it's totally changed the company, and the product, and the view. Everything was extremely different.
Emily: Yeah, that makes total sense. What would you say is the top symptom that a company would experience, that you can help with?
Idit: So, as I said, for us, it's a little bit different. They are coming to us. And then, as I said, they are very different in the level of knowledge. There is customer that coming, and most of the work they're doing by themselves, they already fluent in Kubernetes, they understand even the concept of service mesh. Sometimes they even going in, already installed the open source by themself and start working on this, and then just coming to get fine-tuning of it.
When there's customer that comes in that doesn't know anything. They just know that they have—they wanted to change. They just know that Kubernetes is probably something that they will be interested in, and therefore they will need other stuff. But that's basically where it's done; they don't know much more. And for those people, a lot of the support that we are giving them is not even related to our product, it's basically, just teach them how to use something like Kubernetes.
So, I think that this is a very, very different. In the [00:19:23 unintelligible], as I said, as a customer—as a company what we own is basically application network layer. Everything, as I said, North to South, East to West, and I think that this is something that we extremely solid at this. We’re running Envoy in production for the last two years. We’re running a huge organization in a big scale. We writing our own filter to Envoy, we basically—we doing a lot of upstream code, so you know, it’s putting us as really understanding that piece of the low-level application networking. So, I think that's really helpful.
Emily: Why do you find that your customers summers want to use distributed systems in the first place?
Idit: I’d say it's good question. I think that mainly the reason is usually for scale, and I think that another reason—and I will not say that this is a distributed system—but the ecosystem of building a beautiful thing called Kubernetes—and it's really beautiful. It's really, really, very well thought off, and it's solving a lot of problem, and it's just making stuff extremely more easy—so if you look before that, and you needed to do stuff, like for instance, make sure that what's happening if your application is down, handling all your VMs and stuff, that is relatively way more a hard. Right now, basically, we’re abstracting to make it extremely simple. And with the managed solution in the Cloud like a AKS, GKE, and so on, it's become very, very simple.
So, I think that the main reason, to be honest, it's just, first of all, it's make you go faster, it's way more scalable, and the tooling is great. It’s just makes it so much simpler to do this and to do the other thing. So, that I think a lot of that reason, it's why you probably want to go to distributed, to use microservice [00:21:13 unintelligible] and monolithic application. And again, it's something you [00:21:16 unintelligible] problem. Like for instance, you can cut your organization into a small groups that basically can own a service, and it will be very seamlessly, kind of like, connected to each other, it's mean that each of them can write in a different language, they can write in—basically, own their own schedule for the versioning, and they don't really need to, per se, be basically consumed by the fact that they were working all on one big, giant source code.
I think all of this is very helpful. And then on top of it, with the fact that the tooling is very useful and make it very, very easy to work with, and your velocity of the team is going dramatically up. So, I say, I think that that's probably will be one of the reason for microservices and distributed application.
Emily: What do you think, among your customers, are some misconceptions that they have about distributed systems, about cloud-native in general?
Idit: I think, to be honest, I don't think that they have a lot of them. And the reason is because this ecosystem—don't forget that, I don't know, Kubernetes is relatively mature, Docker was a very long time ago. It's not that new anymore, so I think that there was so much marketing from all the big organization that I think that it's well understood of. I don't think that there is people who doesn't understand what microservices is. I don't think that there is any misconception there.
The only thing that I will say is that there is this notion of microservices is the best, and sometimes to be honest, microservices also a little bit more complex. I mean, it's way simpler to build it in one binary, and it's probably even quicker. I think that when you move into microservices, mainly, the thing that you need to think about is, if you just wanted to build a very simple application, probably monolithic will go faster and be simpler. If you’re using microservices, yes, you're getting a lot of benefit of the scale and so on, but it's also mean that you will need to handling as a distributed application, and therefore they care about different system for logging, and different system for how to communicate between these microservices, and a lot of other stuff that I think, yeah, it's a steep, curving, curving learn. So.
Emily: So, I wanted to ask if you wanted to add anything about, sort of, what you've observed about the market for cloud-native technologies, what end users are looking for, and then also what you've learned about running a company in this space?
Idit: Yeah, no. So, I mean, if you're looking at the market itself, I feel that as everything, as I said, is a journey. In the beginning, people were very excited about Docker, and then they move to the next level, we're all very excited about Kubernetes. And I think now that the buzzword we say is service mesh, and how to connect those microservices together. And I think there will be more and more stuff coming up.
So, I think that that's a—it's basically the evolution. We're always striving to be better. So, I think that's what I see in the market. As I said to you, we see a lot of type of customers in a lot of states on this journey, but in the [00:24:19 unintelligible], they all have the same journey? They're all interested in microservices. They're all very driven to get a lot of observability and security, and the ability to run between service—and microservice. This is why they will adopt service mesh, and we'll see what will come next after it.
Emily: Yeah. Just a couple more questions, which is—the next one, what is a tool, an engineering tool that you can't do your job without?
Idit: Huh. It's a good question. Yeah, I mean, right now, it's basically will be we're using a lot of [00:24:55 unintelligible]. Of course, behind the scenes, we’re using stuff like Docker and so on. I’m using a lot of command line. Like this is [laugh] the thing that I'm using a lot. Yeah, I'm using Visual Studio Code. That's something that is also extremely helpful for me.
Emily: Right. And then how can people connect with you or follow you?
Idit: So, they can connect me to Twitter, and my Tweet account is open, which is @idit_levine. You can also join our Slack. We have a huge community in the Slack. And so itself and all of us there. So, we are extremely active in answering any question from every reason. That could be another way to connect me. And the last one is to go to the website of the company and just send a message. That would be the last one.
Emily: Fabulous. Well, thank you so much for joining me, Idit.
Idit: Thank you so much for having me. It was a lot of fun.
Emily: Thanks for listening. I hope you’ve learned just a little bit more about The Business of Cloud Native. If you’d like to connect with me or learn more about my positioning services, look me up onLinkedIn: I’m Emily Omier—that’s O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.
Announcer: This has been a HumblePod production. Stay humble.