Ori Shoshan, co-founder of Otterize, geeks out with Adriana Villela, as he discusses the challenges of authorization in cloud-native environments. Ori shares insights into the inspiration behind Otterize and how it aims to make access control easier and more streamlined. He also dives into the importance of considering the people who will interact with your code and shares valuable words of wisdom for developers. Plus, learn about how the magic of open source contributions brought OpenTelemetry into Otterize's open source Network Mapper tool, and the company's future plans for OpenTelemetry integration.
About our guest:
Ori Shoshan is the Co-Founder and CTO of Otterize, where he spearheads a leading Workload Identity and Access Management platform that automates and simplifies access control for cloud-native environments. By offering a declarative and zero-trust approach to access management, Otterize empowers organizations to streamline network policy management while ensuring maximum security.
Drawing from a remarkable 15-year career as a seasoned platform engineer, Ori's expertise is underpinned by his leadership roles in both technology and personnel at esteemed institutions. Notably, he made significant contributions at the IDF cybersecurity unit 8200 and served pivotal roles in cybersecurity and developer tooling startups, such as Guardicore (now part of Akamai) and Rookout (now a part of Dynatrace).
Find our guest on:
Find us on:
Show Links:
Additional Links:
Transcript:
ADRIANA: Hey, y'all! Welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela, coming to you from Toronto, Canada.
And geeking out with me today is Ori Shoshan of Otterize. Welcome, Ori.
ORI: Hi, thank you for having me.
ADRIANA: Super excited to have you here today. Where are you calling in from today?
ORI: So I'm actually in Berlin, but normally I am in the periphery of Tel Aviv, Israel.
ADRIANA: Cool. Well, let's let's get started with our lightning round questions. Are you ready? Okay, first of all, are you left-handed or right-handed?
ORI: It's a complicated answer. I know you said the lightning round was going to be easy.
ADRIANA: It's all good.
ORI: I'm left-handed on the computer, but I write with my right hand. You can thank my school for that. They basically made me use my right hand, so I guess I'm ambidextrous.
But I tend to write...like, I basically just sign stuff with my right hand at this point in life because everything else is on the phone or typed, so yay.
ADRIANA: Oh, yeah, it so you were probably born a lefty, but turned into a righty.
ORI: Yeah, but I like my left-handed mouse.
ADRIANA: That's interesting. I'm left-handed and I never got the left handed mouse thing, I think because the first time that someone presented a mouse to me was, like, a right-handed mouse, so I never even thought of holding it with my left.
ORI: Yeah, that's a big problem. I always have to like when I buy a new mouse, sometimes I feel like as the years go on, it gets harder and harder to find, like a symmetric mouse that isn't specifically for right handed people.
ADRIANA: True. That's true. Actually, you just made me think of, like do you remember? I think it was like the Microsoft mouse that was like it was shaped for right-handed people, and I remember thinking, oh, my God, if you're left-handed, you're screwed.
ORI: Exactly. Yeah. So I make do with the smaller mice. But it's nice. It's an excuse to buy a gamer mice sometimes. Yeah, but it must be hard to find a cool mouse that will either be ambidextrous or tailored for left-handed mousers. Yeah, but it's a once in a few years thing. I just wish it was more like headphones, where you can basically buy the same pair again and again when they go bad.
ADRIANA: Yeah, that's true.
ORI: As long as they don't discontinue it.
ADRIANA: Yeah.
ORI: With the mice every time, I'm like, I want to buy this mouse again and they don't make it anymore, so I have to find the closest one.
ADRIANA: Yeah. I feel you. I feel you. Okay, next question. iPhone or Android?
ORI: Android,
ADRIANA: All right. Mac, Linux or Windows?
ORI: Honestly, Windows, even though I use Mac daily because I've given up because everybody else at the company wanted Macs, so I didn't want to be the odd one out, but I'm a Windows guy, through and through.
ADRIANA: Interesting, interesting. I grew up on Windows, and then the first time I used a Mac, I hated it so much, and now I'm a full Mac convert. But I remember when Windows came out, I was like, this is the greatest thing ever.
ORI: I think the thing that gets me is like, I've been in software development a lot of years by now and so on Windows, I really know how things work, like, beneath the outer shell, and when something doesn't work in the system, I know how to debug it. But with MacOS, my understanding only goes so far. So it's like if you see the famous beach ball spinning and something stuck on Windows, I would know how to figure out what is doing that. But on Mac, I feel useless. I'm just like, okay, better force close it and try again. Pray that it fixes itself.
ADRIANA: I find that the funniest thing on Mac that ever happened to me is when I got, like, the Mac's equivalent of the blue screen of death, but it was so polite, and I'm like, oh, shoot, when this happens, I know I'm in trouble. I think I only got it once, but I was like, Damn, I should have taken, like, a picture of it. I don't even know what it looks like.
ORI: I think I've had a few the last couple of weeks because I opened my laptop into, oh, everything's closed, and by the way, we've crashed. So you want to send an error report? Maybe, but I didn't get to see the actual crash screen.
ADRIANA: I got to find a picture to include in the show notes. I'm sure someone's taken a picture of it.
ORI: It's hard to see. They don't let you see it.
ADRIANA: Yeah, that's right. It's like a Yeti sighting.
ORI: Yeah, exactly.
ADRIANA: Okay, next question. What's your favorite programming language?
ORI: It changes along the years. Right now it's Golang definitely. I like to say it's a language for stupid people, and I'm one of those stupid people because it's really prescriptive about how you should do things. Generally, most of the time, there's only one way to do something, and I find that really valuable. I think it's insane that I can look at our own code base, like the back end and our open source code base and the Kubernetes code base, and they look pretty similar. And other languages not so much. I think Rust code bases will look very different. Don't get me started with C++, where the language basically it's worse than JavaScript. The language reinvents itself every couple of years. And there was so much sorcery to know. I probably couldn't read C++ code by now, even though like six years ago it was what I was doing all day...
ADRIANA: Oh, wow.
ORI: ...and before that it was Python.bPython will always have a dear place in mybheart, but it got complicated in Python free whenbthey added async await, it got kind of fragmented.
ADRIANA: Yeah, fair enough, fair enough. Yeah, I do agree with you. Python...I have much love for Python. I started out in Java, and Java...I don't know, it's like coding in spaghetti. It's, like, such a verbose language, and most of my career was Java, but I'm like, nah, Java, I'm over you. I do like go. It's like, generally succinct except with error-handling. It's kind of weird.
ORI: Yeah, it is weird. And it's a common refrain. I feel like a macro could help there, but I actually like the concept of like no, this is how you do things. And there are clear downsides to using Panics. You could use them theoretically as exceptions, as you would use exceptions in Python.
ADRIANA: Yeah.
ORI: But I like that they say this is how you do things, just do it this way. Shut up.
ADRIANA: I do like, prescriptive things in that manner. I think we can do with more prescriptive languages, to be honest.
ORI: It's just so opinionated. And at the same time, they leave some stuff out. Like it's not so batteries included that you don't have to do anything, which is a strange combination, but I feel it works well.
ADRIANA: Yeah, definitely. All right, next question. Dev or Ops?
ORI: So can I say both? I feel like probably a lot of people said it.
ADRIANA: Yeah, a couple of people have said DevOps, so I'm like, yeah...but it's okay to have a preference of one over the other or, like, both. It's totally cool. Like I said, no wrong answers.
ORI: Yeah, I guess both, you know, nowadays it's the popular thing to DevOps. And if you talk to people who work at, like, I think at Apple, they still separate dev and SRES a lot. And I talked to people who said they basically just throw stuff over the wall, over to Ops and they get to deploy it. And I really enjoy looking at the entire stack. So DevOps is for my spirit. I like seeing things happen end-to-end and like understanding, you know, like I said about Mac, that I can only debug so far. So I like that about DevOps, that I know what the code is and where it runs and when something strange happens, I can understand the system as a whole. That's really appealing to me.
ADRIANA: Yeah, I can totally relate to that. Awesome. Okay, next question. JSON or YAML?
ORI: JSON yeah, the spaces. The spaces. It's also like that spaces or tabs being part of syntax.
ADRIANA: Yeah, that should be a question I could ask: spaces or tabs?
ORI: Another thing I hate about Python is just there are so many discussions about that, like should we use this or that in Python too? And it's like it's meaningless and so many stupid bugs just by missing one space. No, definitely JSON even though it's annoying too. But I don't think that there is an ideal choice.
ADRIANA: Yeah, fair enough. Fair enough. I did have one person say HCL, which I'm kind of down for because I feel like if JSON was, like, a little more pared down with some of the love from YAML
Yeah, HCL is like a bit closer to INI files, right? INI files.
ADRIANA: Yeah, true.
ORI: Yeah. It is simpler to parse. I feel like I got to use them in the Windows part of my career.
ADRIANA: Yeah, nice. All right, two more questions left. All right, so do you prefer to consume content through video or text?
ORI: Definitely text
ADRIANA: That seems to be the winner so far. I've had some where it's like it depends, but it's mostly text. Word I feel like it's a little bit of a cultural thing, like in the front-end community. It seems that even JavaScript in general, I feel like videos are much more common, but growing up in the C++, no one will tell you anything. Just read man pages and like, MSDN documentation. I have a hard time when I can't scroll past stuff. So video is like the antithesis for that.
ADRIANA: I know, right? Yeah, that's my biggest issue also, is, like, I need to be able to skim and search easily, and video just makes it a little bit harder. I use video out of desperation. It's like I have no other options, and all Google is giving me is a bunch of videos. I'm like, crap.
ORI: It yeah, exactly. But for some things, it can be useful. And I get why it's more popular with front-end, because you want to see stuff in many cases.
ADRIANA: Yeah, totally. Yeah, I definitely agree. I definitely agree.
ORI: So yeah, I can understand it.
ADRIANA: All right, final question. What is your superpower?
ORI: Yeah. So can I say my wife? Can it be not something about me, I
ADRIANA: That's probably our most creative answer so far.
ORI: Because I guess, like, at Otterize, we're not even two years old now. And being a founder is very demanding in terms of time and stress, and even the stress is showing up here and here [points to hairline], I like to say. So my wife has been really supportive this entire time. And just beyond not just being supportive or understanding, she talks to me about stuff, and it really helps me think things through, which can be important.
And honestly, I think I would probably do a much worse job if not for her, because she really helps me process things, which is really important in such a stressful environment where you can if you're too stressed out, you can reach for knee-jerk reactions. And that's the opposite of what you want to do since you want to manage and not react. So she kind of helps center things for you.
ADRIANA: That's awesome.
ORI: Yeah, it's honestly, it I think that the biggest thing that has had an influence on how I do things. She gives a lot of space and support.
ADRIANA: That's great. I really love to hear that. And I think this is actually a perfect segue for our topic of conversation because, as you mentioned, you are a founder of Otterize. So why don't you tell us a little bit about what Otterize is all about, how the idea came about, and what it's like to be a founder because you hear stories of the stress.
ORI: Yeah, I think okay, let me start with Otterize. I was going to start with the end. So, Otterize...what we do... The name is a funny joke that alludes to what we do. So we do authorization for your back end. So it's called Otterize, because if you're Israeli and you say "otterize". Authorize and otters...they're cute animals. So it's a win-win. It's a pun.
ADRIANA: Totally. Totally.
ORI: So what we do is we make declarative zero-trust easy. We have released open source tooling that lets you map your Kubernetes clusters. And using that map, you can then auto-generate what we call Client Intents. So each backend service in your cluster declares its intentions, which is what it needs to access. So say I have a service that needs to access a database, an AWS IAM resource, another service. So my intent would say, I need to access this thing, and it does this in a high level Kubernetes resource called Client Intent. And then Otterize figures out how to configure your infrastructure to make it work, whether that means something like Kubernetes Network Policies or AWS IAM Policies or Kafka ACL Rules. Whatever infrastructure you have and we do that all open source with a Kubernetes operator.
And I guess in one sentence it would be to make access control not a nightmare because there are so many different kinds. And as a developer, what do you want to do is I just want to call this freaking API and have it work, but then all of a sudden you've got configure IAM policies and that other service that's in a different cluster, so they have a different way that you need to authenticate and authorize.
So as an aside to all that, I still get to do quite a bit of hands-on work, which is fun, and it's thanks to my awesome team that is very independent and awesome.
ADRIANA: It that sounds super cool. And I think as our software is only getting more and more complex, and IAM is, I think, the bane of our existence in this space, and to be able to make it accessible, easier, less nightmarish, is awesome. And definitely very much needed in this space. And to be able to also codify in a standardized way, who'd have thought? I think that's a very awesome use case. So yay. Nice to see a tool like that in the space.
ORI: It you know, as a developer, you want to say, I need to connect to that thing. You don't care if it happens with IAM and you need like a thousand different permissions, so we want to take all that away. The security team cares, you don't care, so you shouldn't care. High level.
ADRIANA: Is the intent that you work like...developers work with the security team to kind of determine what those policies are supposed to be, but then the developers can, I guess, self provision that access? Is that how it works?
ORI: Yeah, essentially, because what we've learned is that in most cases, security teams don't actually care to approve the policy except in very sensitive cases. Like if the ledger service for a bank has an API that transfers money so that one might be approved on a case by case basis, but in a lot of other cases, they just want to know that the access is intentional, that it's not an attacker.
Just like they want to know that the code that gets deployed to production has been reviewed and approved, but they don't want to review the code themselves. And developers also don't want to talk to the security team. So both sides don't want to talk. They just want to get access and for it to be intentional.
ADRIANA: Yeah. That's so great. I love that use case. Going back to we understand what Otterize does. Tell us a little bit about starting up this company. How has that been, and have you guys been around?
ORI: We've been around since January 2022 and, well, it's been a crazy journey, as I guess any startup founder would say that.
ADRIANA: Yeah, I would imagine.
ORI: I think the biggest surprise for me would be I came into this as the CTO, and the CTO at a small size manages the dev team in the early stages. So I thought like, hey, this is going to be similar to managing a small team of developers, which I've done many times before. But what it turned out to be is I found out that when you start a new company, it's not just about managing the team because in an existing culture, an existing company, a lot of decisions have been made already.
When you go to make a new decision, like, should we use this language or this library? Like the smallest decisions within an existing culture. A lot of decisions around that serve effectively as guardrails and in a new company. Even though everyone we hired were people we knew personally and worked with and have even worked together sometimes, some of them when we all joined, like day one, everybody has been to different companies. Like the previous company was different. So they all come with slightly different expectations for culture, for technical choices.
So the challenge is less about how do you make...Bigger companies, the challenge is about how do you move quickly and how do you keep quality and all that. And for a new startup, I feel like the challenge is how do you end up with the right culture and do it quickly while everyone gets a chance to express themselves and feels included, while taking into account that everybody has different expectations day one, and that all happens really quickly. Like at a big company, when you start a new team, people might trickle in, but you start day one with four new people. So now you're four developers and the founders, and you're like, oh my God, so all of this has to happen at once. And everybody also really wants to work quickly.
ADRIANA: Right, right.
ORI: And beyond that, it just teaches you a lot about how a business works, like any business, the technical stuff, how does payroll work, all kinds of regulation. You learn a ton of stuff, which is really interesting and useful.
In my day-to-day, I just got a mortgage, and I understand how banks see lawyers and people and companies and how to navigate that, which has been really useful now that I'm super busy.
ADRIANA: Yeah. Um, so how did it all get started?
ORI: I guess I didn't answer that. So as founders, we have experienced the pain of solving for authorization and authentication at every company repeatedly. And this is like authorization is one of those things that people just sort of accept for what it is. You start a new project or you need access to something else on IAM, so you accept that it's like this. But it doesn't have to be that way because you know, Android apps, when you build an Android app or an iOS app, you know that if you specify, "I need to open the microphone," you don't have to say which specific API it is or it's very high-level. And you know that if the user and the user sees all the permissions that they're going to need, and if they approve that, then your app is going to work.
And you don't have the same level of confidence and simplicity in Cloud Native. You have to say on AWS IAM, if you're using a service that is writing to like, say, if you use Cloud Watch, it's writing to S3 buckets. And you got to make sure you also have access to write to the S3 buckets that is going to access beneath it all, which is insane. You're just a developer. You're doing one simple thing, and you have to think so deep, which, I mean, I love, but I think it slows it down if you have 500 engineers and everybody needs to understand this to make progress. And different teams use different tech stacks. We've seen people struggle with it. We've struggled with it and we see how it can be better in the mobile world. So like, why not for Cloud Native? Shouldn't accept it.
ADRIANA: I think that's such a great idea. I think we see this recurring theme, too, in our space, which is, like, we keep solving the same problems over and over and over. Right? And you get to the point where, like, let me just package it into a damn tool already. Right? Because it's starting to get annoying. Like, why do we need to keep reinventing the wheel? We got better things to do.
So I think that makes a lot of sense. Now, you mentioned AWS with Otterize. Does it work with other cloud providers as well?
ORI: Yeah, it will.
ADRIANA: Okay, cool. Nice. You got to start somewhere, right?
ORI: Yeah. I think the reason no one has done this before, even though for mobile apps, it seemed kind of obvious, so both Google and Apple did it is because there are so many different kinds for other kinds of software that it's hard to even put them together. I mean, I don't think a lot of people would put network policies and AWS im policies, even though they both have the same word in their name in the same category, they would think of them as different things. It's an architectural problem, right? And you can't just imagine it all together. It's exactly the kind of problem that you would start a company for if you need to work on it for a while with a team.
ADRIANA: Yeah, absolutely. Now, switching gears a bit, because I think this is the thing that got us connected initially. You all are doing some cool stuff around OpenTelemetry at Otterize, so why don't you share some of that with our audience?
ORI: Yeah, sure. So we have built the authorized network mapper, which prior to OpenTelemetry, the way it worked is you set it up on your cluster, it's zero config, it's all open source and it captures DNS traffic and uses that DNS traffic to create a map of your cluster. Now, with OpenTelemetry, I've actually had a chance to work with OpenTelemetry relatively recently, but alsoa while back at my previous employer when parts of it were still called open tracing. And it can be a bit of an involved deployment to get your first few bits of data because you need to integrate SDKs and all that.
So the Network mapper being an infrastructure level component that you deploy in your cluster, if it was able to export OpenTelemetry metrics, then it could make the first step to OpenTelemetry adoption a lot easier. Because I think the first step when you add instrumentation is to ask yourselves, what do I want to instrument? And if you don't know what you have, which in a large enough organization as the platform team, which might be keen on implementing OpenTelemetry, that can be where you are, that you don't even know what are the different components, which is connecting to whom, what are the dependencies that I care about.
And the Network Mapper had that info and the awesome team at Lightstep/ServiceNow saw the Network Mapper and contributed an awesome pull request that exports OpenTelemetry metrics from the Network Mapper. And it was really a no-brainer for us to accept the contribution and support you guys because, you know, we think of the Network Mapper as there are a bunch of cybersecurity products with simple similar capabilities for network mapping, but we really wanted the network mapper to be a standalone thing that you could use independent of the rest of Otterize.
So it's really like seeing what was possible to do with Grafana Tempo so easily with the same data that the Network Mapper has. We saw how it could make people's lives easier and really, that's what the network mapper is trying to do. To be a simple tool. You can just "helm install" on your cluster with zero configuration and get as much value as you can in a complete open source fashion.
And that really works well with OpenTelemetry. So far, the Otterize Network Mapper had a CLI that was using Graphviz to create a visual map of the traffic. And you could also hook it up to Otterize Cloud to get an interactive map. But now with OpenTelemetry, you can hook it up to your Grafana instance and get an interactive map, which then helps you see, okay, I'm interested in this service and it's communicating to these three other services and that's where I want to start with OpenTelemetry.
ADRIANA: Right.
ORI: Yeah, it's pretty powerful...the combination, I think.
ADRIANA: Yeah. And it's so cool to I think it's nice to see more and more vendors, including OpenTelemetry as part of their products, because, first of all, I think it shows the staying power of OpenTelemetry, but secondly, like, the recognition that, "Hey, this could help our customers, too." Right?
ORI: Exactly. And mission number one is to make people successful in what they do.
ADRIANA: Yes.
ORI: And we really want Intents and Otterize and easy network mapping to be something that everybody in the Cloud Native community has access to. So we have aspirations to turn Client Intents into the way that you do authorization, even independent of Otterize, contributing to upstream.
So that really falls in line with that. How do we make the network mapper more useful? Like a no brainer.
ADRIANA: Yeah, absolutely. So have you seen internal and external benefits as a result of the work around the network mapper, like, with OpenTelemetry?
ORI: Um, so it's still quite early.
ADRIANA: Fair enough.
ORI: I think it's just been out for about a week or so and we are I believe we're going to publish a blog post together that will help it get noticed.
ADRIANA: Yeah, definitely.
ORI: So right now, I think it's depending on people organically discovering it, which, I mean, it can happen and the Network Mapper gets organic traffic, but people who are specifically looking for OpenTelemetry and using it with Grafana Tempo are going to be best served by content that points to that. We want to add a tutorial for that too,
ADRIANA: Cool. And do you have any future plans around continuing OpenTelemetry integrations?
ORI: So we still need to explore that. Off the top of my mind, I'm not well versed enough to say what, but definitely I think even now there's more data that the Network Mapper has access to. Like, if you have Istio or Kafka, then it can tap into resource-level or topic-level information which can probably be reflected in OpenTelemetry as well in the same infrastructure way. And once we add more capabilities to the Network Mapper, we want to add cross-cluster discovery and the ability to discover infrastructure outside of Kubernetes from within Kubernetes. So that could also be interesting to add to the OpenTelemetry support.
ADRIANA: Right. Awesome. And can you speak to how OpenTelemetry is being set up or are you guys running like a Collector as part of your internal infrastructure or...what does the landscape look like?
ORI: So we're we're pretty new in terms of the internal deployment. I mean, I've had the opportunity to use OpenTelemetry before, but at other eyes we really only got into it with you guys saying, "Hey, remember Grafana Tempo?" Which we knew about before, but then we were like, "Of course." So as part of dog-fooding yeah, we started with setting up a Collector and a Grafana instance, but it's also really fresh at Otterize. We make it a point to use everything we put out, including contributions, so we know how it works for users. So we're pretty early there. But yeah...
ADRIANA: Yeah, amazing how's the learning curve been for you and within the company in general for OpenTelemetry.
ORI: I think there are some pretty cool tutorials and guides for we've looked particularly at Grafana Tempo which we said, videos and text.
ADRIANA: Yeah, I always appreciate the tutorials with the screenshots.
ORI: So Grafana Tempo has tutorials with screenshots, so getting like the initial setup has been pretty easy. But we did like I think if we built the integration completely ourselves then we would have had a slightly steeper learning curve because Clay at Lightstep did the research for us of what the metric should look like and how to configure it. So it was pretty straightforward. But I think also for a user that's trying to use it now, it would also be pretty straightforward because it was just one configuration value that we needed to pass to the network mapper after all is said and done. But I think it's interesting now to explore what else can we get from it now that we have the base layer of information there is.
ADRIANA: Yeah. As a follow up, do you envision at some point adding Open Telemetry traces to your core product, for example?
ORI: You mean like our back-end infrastructure or like the product itself?
ADRIANA: For your application code.
ORI: Yeah, because we use some level of Datadog APM to debug. So there's like a natural hook point that we would go into and hook up to OpenTelemetry now that we have it set up.
ADRIANA: Right.
ORI: Datadog was like we set it up just because it's the natural thing we reached for from previous experience. But we're just one step away from OpenTelemetry now. From places in OpenTelemetry.
ADRIANA: You've got your foot in the door now with OpenTelemetry.
ORI: Yeah, it's like all the infrastructure is there, the traceability of the code is there. Like we have contexts and everything in Go so that it's easy to pass traces. So I think we're a middleware away, which is a tiny step.
ADRIANA: Awesome. That's so great. That's very exciting. And I think it's, you know, the other thing that that's super important to underscore here too is the fact that you had somebody making an outside contribution to your code base and it speaks to the power of open source, really, to be able to have your...your code's out in the wild. And someone saw this and they're like, "Hey, I got a cool use case."
ORI: Yeah, absolutely. First of all, it was a pretty major contribution, which was cool. It's actually the first major contribution that we've had. We've had contributions before but they were of a bit smaller scale so it was exciting on that front as well. But yeah, the cool thing is that we were actually aware of Grafana Tempo but we didn't think to do that if we had thought about it, I think we would have built it ourselves before. But it's cool that somebody saw it, saw the potential, and just wrote the code, and now it's out there, and it's open source, and anyone can use it, and you guys contributed to it.
And there's actually one other company, Komodor.io, which has incorporated the Network Mapper into their own product and their own open source, which is cool.
ADRIANA: Oh, cool.
ORI: It's cool to see people use it in ways we haven't thought of. That really. It's like you said, it's the power of open source that we don't need to think about every use case because someone else can think about it and add it, and all we need to do is to support and go like, yeah.
ADRIANA: Yeah, totally. I mean, basically you've provided the seed and then people are just like, "Hey, what can we do with this now?"
ORI: Right. And it's kind of like the pitch for Google Fiber in the United States was, we don't know what people will do with one gigabit of data, but we will build it and see what they do. So the Network Mapper is really that it's just it's raw data of your network, and it does the collection bit, and then you can just add more and more exporters, which just this is like an OpenTelemetry exporter. So there's so much you can do with a map of your network. I think every developer product and every cybersecurity product has a map of your network, so it's the most valuable and flexible kind of data for a development teammate.
ADRIANA: Yeah, absolutely. And I'm just spitballing here, but I think a really interesting I wonder if there could be like...a really interesting use case with...I don't know if you're aware of the Open Telemetry demo.
ORI: Which one exactly? I guess not.
ADRIANA: So there's a repo called Open Telemetry Demo and it's based on the Hipster Shop app, which I believe originated with Google and they've turned it into like a telescope shop now, but it basically showcases instrumentation with OpenTelemetry. So it's this multi-microservices app written in different languages and so it shows different instrumentation in different languages with OpenTelemetry. And it started last year, just before KubeCon, and it's turned into this massively complex, but very cool showcase of OpenTelemetry's capabilities.
And it made me think of something where...so recently there's this company called Tracetest. So they're part of this company called Kubeshop. Tracetest is the product and they offer trace-based testing. And so basically the idea is, like, you're already emitting traces. Why don't we take those traces and create test case pieces out of these? And so they recently integrated trace-based testing into the OpenTelemetry Demo to showcase hey, like we can leverage this to basically run automated integration tests.
So then I'm thinking, hey, wouldn't it be kind of cool to have Otterize, especially the Network Mapper, integrated into this demo, showcasing, again, OpenTelemetry, the Network Mapper emitting metrics. So anyway...
ORI: Yeah, it it a it's a great idea. I wasn't aware of it, but we definitely should do that. And it's funny because most of our tutorials are based on the Google Microservices demo. It's the we still have the stock shop. It's not a telescope shop, but yeah, I guess that app is everywhere. I've seen it on Calico too, and Istio for sure that's a good way to help people discover that the Network Mapper can emit OpenTelemetry metrics. I'm sure it will be useful to a lot of people.
ADRIANA: Exactly. And especially it's an open source tool working with another open source tool.
ORI: The way God intended.
ADRIANA: Yeah, that's exactly. By the way, so we will be releasing this episode during the week of KubeCon. So by the time everyone's listening watching this episode will be out on the Tuesday. Will you be a KubeCon look for the Otterize?
ORI: Yes, definitely will be in the main area. Damn. I don't know what our booth number is, but...
ADRIANA: Look for the otters.
ORI: maybe I can check and you can...yeah...Look for the otters. Maybe I can check and you can edit that in.
ADRIANA: Yeah, you know what? I can add it to the show notes once you find the booth name or in booth number, I should say. Do you guys have, like, really cool swag that you're giving out?
ORI: You guys, we're going to have the booth other plushies and T shirts, of course. Of course. Oh, my God, the otters are so cute. They have, like, this little key. I wish I had one to show you now.
ADRIANA: Damn it. That means you have to go to the booth.
ORI: It's like it's been...yeah... You're going to be there too?
ADRIANA: Yes. I'm going to be a KubeCon. I'm going to be giving a couple of talks there. There one on platform engineering, actually, and self-service tooling.
ORI: Yeah? I'll come see.
ADRIANA: So I feel like it's, like, very on topic.
ORI: Yeah, I'll be in the crowd. I'll go, "Woo! Yeah!"
ADRIANA: I'm going to now make sure that I visit the booth because I definitely want to score one of those otter plushies.
ORI: And socks. Will we have socks? Actually don't know. Last time we had socks, they were a huge hit. The first time we had plushies and socks, I was kind of worried, like, would the platform engineers that come to the booth be happy to get those. Maybe it's a bit like, what do grown-ups do with plushies? But then I was like, no, it's actually a hit. And grown-ups have kids too, so not only are they interested in one plushie for themselves, they need also one for every kid so nobody gets there jealous.
ADRIANA: Yes, that's right. Because if you bring a plushie home and one of them is not for your kid, you are in trouble. It is the law. I do find the socks are quite popular because I find, like, for me, T-shirts usually are very hit and miss because I'm very petite, and so if it's not very small and fitted, I swim in the T-shirt. So the socks end up working very well because you can't go wrong with socks. They generally fit.
ORI: Yeah, and startup socks tend to be like happy socks, very colorful and...
ADRIANA: Yes, exactly.
ORI: ... maybe you don't want to walk around every day branded, but the socks are like your little secrets.
ADRIANA: Yes, exactly. They're perfect. They're perfect. Well, we are just coming up on time, but before we wrap up, are there any parting words of wisdom or hot takes that you would like to share with our audience?
ORI: I guess...I'll go for words of wisdom. I'll try, I'm not good on the spot without my...
ADRIANA: All right.
ORI: ...without my wife, but I guess the thing that I would keep in mind as a developer is to always think about the people that will encounter your code and read your code. A lot of times we think about the design, the performance, does it look good? Does it work well? But I think the most important thing to pay attention to is about the people. And sometimes the people includes you. I'm sure a lot of people watching have come up on a piece of code they wrote and think like, what the hell, what is this? And then find out it's them a couple of years ago.
ADRIANA: Oh, my God. It's so true. What the hell was I thinking?
ORI: It yeah, and it like, it really goes a long way because, you know, it's the, it's the feeling you get when you use a product and you expect something to be there or you expect to be able to do something, or even the unboxing experience seems like they thought about the person who's opening the product. If you come upon a confusing bit of code that does something nontrivial and you find a comment that says why it's this way and what you should do if you want to change it, like, oh, someone has thought about me.
And in some languages, like Go, you can go a bit further and use the compiler to do some of that. I think if you have a function that is doing I/O and it can block, then it's good hygiene to accept a context as a parameter and allow it to be canceled. Because you're not just allowing cancellation, you're communicating, hey, this thing is going to do something that you may want to cancel, it may block. And the cool thing is the compiler then forces the caller to actually make a choice. Like they have to decide which context are they passing in, which is a bit like returning errors. You're saying with a function signature, this thing can fail, which you can't not in every language.
You can do that using exceptions, Java, you can say throws and like an endless list of exceptions. But there's nothing fun, more fun than in C getting an unexpected exception.
And you're like, what is even going on? How did this get here? And it's like a leaky abstraction. So, yeah, my parting words are think of the people when you write code, not about the machines, because the machines, they're going to be fine. We're going to throw a bit more CPU and memory at it. The people are more important.
ADRIANA: I really love that. That those are really great words of wisdom. Well, thank you so much, Ori for geeking out with me today. And y'all do not forget to subscribe. And be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time...
ORI: Peace out, and geek out.
ADRIANA: Geeking out is hosted and produced by me, Adriana Vilella. I also compose and perform the theme music on my trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the Socials by going to bento.me/geekingout.
ADRIANA: Hey, y'all! Welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela, coming to you from Toronto, Canada.
And geeking out with me today is Ori Shoshan of Otterize. Welcome, Ori.
ORI: Hi, thank you for having me.
ADRIANA: Super excited to have you here today. Where are you calling in from today?
ORI: So I'm actually in Berlin, but normally I am in the periphery of Tel Aviv, Israel.
ADRIANA: Cool. Well, let's let's get started with our lightning round questions. Are you ready? Okay, first of all, are you left-handed or right-handed?
ORI: It's a complicated answer. I know you said the lightning round was going to be easy.
ADRIANA: It's all good.
ORI: I'm left-handed on the computer, but I write with my right hand. You can thank my school for that. They basically made me use my right hand, so I guess I'm ambidextrous.
But I tend to write...like, I basically just sign stuff with my right hand at this point in life because everything else is on the phone or typed, so yay.
ADRIANA: Oh, yeah, it so you were probably born a lefty, but turned into a righty.
ORI: Yeah, but I like my left-handed mouse.
ADRIANA: That's interesting. I'm left-handed and I never got the left handed mouse thing, I think because the first time that someone presented a mouse to me was, like, a right-handed mouse, so I never even thought of holding it with my left.
ORI: Yeah, that's a big problem. I always have to like when I buy a new mouse, sometimes I feel like as the years go on, it gets harder and harder to find, like a symmetric mouse that isn't specifically for right handed people.
ADRIANA: True. That's true. Actually, you just made me think of, like do you remember? I think it was like the Microsoft mouse that was like it was shaped for right-handed people, and I remember thinking, oh, my God, if you're left-handed, you're screwed.
ORI: Exactly. Yeah. So I make do with the smaller mice. But it's nice. It's an excuse to buy a gamer mice sometimes. Yeah, but it must be hard to find a cool mouse that will either be ambidextrous or tailored for left-handed mousers. Yeah, but it's a once in a few years thing. I just wish it was more like headphones, where you can basically buy the same pair again and again when they go bad.
ADRIANA: Yeah, that's true.
ORI: As long as they don't discontinue it.
ADRIANA: Yeah.
ORI: With the mice every time, I'm like, I want to buy this mouse again and they don't make it anymore, so I have to find the closest one.
ADRIANA: Yeah. I feel you. I feel you. Okay, next question. iPhone or Android?
ORI: Android,
ADRIANA: All right. Mac, Linux or Windows?
ORI: Honestly, Windows, even though I use Mac daily because I've given up because everybody else at the company wanted Macs, so I didn't want to be the odd one out, but I'm a Windows guy, through and through.
ADRIANA: Interesting, interesting. I grew up on Windows, and then the first time I used a Mac, I hated it so much, and now I'm a full Mac convert. But I remember when Windows came out, I was like, this is the greatest thing ever.
ORI: I think the thing that gets me is like, I've been in software development a lot of years by now and so on Windows, I really know how things work, like, beneath the outer shell, and when something doesn't work in the system, I know how to debug it. But with MacOS, my understanding only goes so far. So it's like if you see the famous beach ball spinning and something stuck on Windows, I would know how to figure out what is doing that. But on Mac, I feel useless. I'm just like, okay, better force close it and try again. Pray that it fixes itself.
ADRIANA: I find that the funniest thing on Mac that ever happened to me is when I got, like, the Mac's equivalent of the blue screen of death, but it was so polite, and I'm like, oh, shoot, when this happens, I know I'm in trouble. I think I only got it once, but I was like, Damn, I should have taken, like, a picture of it. I don't even know what it looks like.
ORI: I think I've had a few the last couple of weeks because I opened my laptop into, oh, everything's closed, and by the way, we've crashed. So you want to send an error report? Maybe, but I didn't get to see the actual crash screen.
ADRIANA: I got to find a picture to include in the show notes. I'm sure someone's taken a picture of it.
ORI: It's hard to see. They don't let you see it.
ADRIANA: Yeah, that's right. It's like a Yeti sighting.
ORI: Yeah, exactly.
ADRIANA: Okay, next question. What's your favorite programming language?
ORI: It changes along the years. Right now it's Golang definitely. I like to say it's a language for stupid people, and I'm one of those stupid people because it's really prescriptive about how you should do things. Generally, most of the time, there's only one way to do something, and I find that really valuable. I think it's insane that I can look at our own code base, like the back end and our open source code base and the Kubernetes code base, and they look pretty similar. And other languages not so much. I think Rust code bases will look very different. Don't get me started with C++, where the language basically it's worse than JavaScript. The language reinvents itself every couple of years. And there was so much sorcery to know. I probably couldn't read C++ code by now, even though like six years ago it was what I was doing all day...
ADRIANA: Oh, wow.
ORI: ...and before that it was Python.bPython will always have a dear place in mybheart, but it got complicated in Python free whenbthey added async await, it got kind of fragmented.
ADRIANA: Yeah, fair enough, fair enough. Yeah, I do agree with you. Python...I have much love for Python. I started out in Java, and Java...I don't know, it's like coding in spaghetti. It's, like, such a verbose language, and most of my career was Java, but I'm like, nah, Java, I'm over you. I do like go. It's like, generally succinct except with error-handling. It's kind of weird.
ORI: Yeah, it is weird. And it's a common refrain. I feel like a macro could help there, but I actually like the concept of like no, this is how you do things. And there are clear downsides to using Panics. You could use them theoretically as exceptions, as you would use exceptions in Python.
ADRIANA: Yeah.
ORI: But I like that they say this is how you do things, just do it this way. Shut up.
ADRIANA: I do like, prescriptive things in that manner. I think we can do with more prescriptive languages, to be honest.
ORI: It's just so opinionated. And at the same time, they leave some stuff out. Like it's not so batteries included that you don't have to do anything, which is a strange combination, but I feel it works well.
ADRIANA: Yeah, definitely. All right, next question. Dev or Ops?
ORI: So can I say both? I feel like probably a lot of people said it.
ADRIANA: Yeah, a couple of people have said DevOps, so I'm like, yeah...but it's okay to have a preference of one over the other or, like, both. It's totally cool. Like I said, no wrong answers.
ORI: Yeah, I guess both, you know, nowadays it's the popular thing to DevOps. And if you talk to people who work at, like, I think at Apple, they still separate dev and SRES a lot. And I talked to people who said they basically just throw stuff over the wall, over to Ops and they get to deploy it. And I really enjoy looking at the entire stack. So DevOps is for my spirit. I like seeing things happen end-to-end and like understanding, you know, like I said about Mac, that I can only debug so far. So I like that about DevOps, that I know what the code is and where it runs and when something strange happens, I can understand the system as a whole. That's really appealing to me.
ADRIANA: Yeah, I can totally relate to that. Awesome. Okay, next question. JSON or YAML?
ORI: JSON yeah, the spaces. The spaces. It's also like that spaces or tabs being part of syntax.
ADRIANA: Yeah, that should be a question I could ask: spaces or tabs?
ORI: Another thing I hate about Python is just there are so many discussions about that, like should we use this or that in Python too? And it's like it's meaningless and so many stupid bugs just by missing one space. No, definitely JSON even though it's annoying too. But I don't think that there is an ideal choice.
ADRIANA: Yeah, fair enough. Fair enough. I did have one person say HCL, which I'm kind of down for because I feel like if JSON was, like, a little more pared down with some of the love from YAML
Yeah, HCL is like a bit closer to INI files, right? INI files.
ADRIANA: Yeah, true.
ORI: Yeah. It is simpler to parse. I feel like I got to use them in the Windows part of my career.
ADRIANA: Yeah, nice. All right, two more questions left. All right, so do you prefer to consume content through video or text?
ORI: Definitely text
ADRIANA: That seems to be the winner so far. I've had some where it's like it depends, but it's mostly text. Word I feel like it's a little bit of a cultural thing, like in the front-end community. It seems that even JavaScript in general, I feel like videos are much more common, but growing up in the C++, no one will tell you anything. Just read man pages and like, MSDN documentation. I have a hard time when I can't scroll past stuff. So video is like the antithesis for that.
ADRIANA: I know, right? Yeah, that's my biggest issue also, is, like, I need to be able to skim and search easily, and video just makes it a little bit harder. I use video out of desperation. It's like I have no other options, and all Google is giving me is a bunch of videos. I'm like, crap.
ORI: It yeah, exactly. But for some things, it can be useful. And I get why it's more popular with front-end, because you want to see stuff in many cases.
ADRIANA: Yeah, totally. Yeah, I definitely agree. I definitely agree.
ORI: So yeah, I can understand it.
ADRIANA: All right, final question. What is your superpower?
ORI: Yeah. So can I say my wife? Can it be not something about me, I
ADRIANA: That's probably our most creative answer so far.
ORI: Because I guess, like, at Otterize, we're not even two years old now. And being a founder is very demanding in terms of time and stress, and even the stress is showing up here and here [points to hairline], I like to say. So my wife has been really supportive this entire time. And just beyond not just being supportive or understanding, she talks to me about stuff, and it really helps me think things through, which can be important.
And honestly, I think I would probably do a much worse job if not for her, because she really helps me process things, which is really important in such a stressful environment where you can if you're too stressed out, you can reach for knee-jerk reactions. And that's the opposite of what you want to do since you want to manage and not react. So she kind of helps center things for you.
ADRIANA: That's awesome.
ORI: Yeah, it's honestly, it I think that the biggest thing that has had an influence on how I do things. She gives a lot of space and support.
ADRIANA: That's great. I really love to hear that. And I think this is actually a perfect segue for our topic of conversation because, as you mentioned, you are a founder of Otterize. So why don't you tell us a little bit about what Otterize is all about, how the idea came about, and what it's like to be a founder because you hear stories of the stress.
ORI: Yeah, I think okay, let me start with Otterize. I was going to start with the end. So, Otterize...what we do... The name is a funny joke that alludes to what we do. So we do authorization for your back end. So it's called Otterize, because if you're Israeli and you say "otterize". Authorize and otters...they're cute animals. So it's a win-win. It's a pun.
ADRIANA: Totally. Totally.
ORI: So what we do is we make declarative zero-trust easy. We have released open source tooling that lets you map your Kubernetes clusters. And using that map, you can then auto-generate what we call Client Intents. So each backend service in your cluster declares its intentions, which is what it needs to access. So say I have a service that needs to access a database, an AWS IAM resource, another service. So my intent would say, I need to access this thing, and it does this in a high level Kubernetes resource called Client Intent. And then Otterize figures out how to configure your infrastructure to make it work, whether that means something like Kubernetes Network Policies or AWS IAM Policies or Kafka ACL Rules. Whatever infrastructure you have and we do that all open source with a Kubernetes operator.
And I guess in one sentence it would be to make access control not a nightmare because there are so many different kinds. And as a developer, what do you want to do is I just want to call this freaking API and have it work, but then all of a sudden you've got configure IAM policies and that other service that's in a different cluster, so they have a different way that you need to authenticate and authorize.
So as an aside to all that, I still get to do quite a bit of hands-on work, which is fun, and it's thanks to my awesome team that is very independent and awesome.
ADRIANA: It that sounds super cool. And I think as our software is only getting more and more complex, and IAM is, I think, the bane of our existence in this space, and to be able to make it accessible, easier, less nightmarish, is awesome. And definitely very much needed in this space. And to be able to also codify in a standardized way, who'd have thought? I think that's a very awesome use case. So yay. Nice to see a tool like that in the space.
ORI: It you know, as a developer, you want to say, I need to connect to that thing. You don't care if it happens with IAM and you need like a thousand different permissions, so we want to take all that away. The security team cares, you don't care, so you shouldn't care. High level.
ADRIANA: Is the intent that you work like...developers work with the security team to kind of determine what those policies are supposed to be, but then the developers can, I guess, self provision that access? Is that how it works?
ORI: Yeah, essentially, because what we've learned is that in most cases, security teams don't actually care to approve the policy except in very sensitive cases. Like if the ledger service for a bank has an API that transfers money so that one might be approved on a case by case basis, but in a lot of other cases, they just want to know that the access is intentional, that it's not an attacker.
Just like they want to know that the code that gets deployed to production has been reviewed and approved, but they don't want to review the code themselves. And developers also don't want to talk to the security team. So both sides don't want to talk. They just want to get access and for it to be intentional.
ADRIANA: Yeah. That's so great. I love that use case. Going back to we understand what Otterize does. Tell us a little bit about starting up this company. How has that been, and have you guys been around?
ORI: We've been around since January 2022 and, well, it's been a crazy journey, as I guess any startup founder would say that.
ADRIANA: Yeah, I would imagine.
ORI: I think the biggest surprise for me would be I came into this as the CTO, and the CTO at a small size manages the dev team in the early stages. So I thought like, hey, this is going to be similar to managing a small team of developers, which I've done many times before. But what it turned out to be is I found out that when you start a new company, it's not just about managing the team because in an existing culture, an existing company, a lot of decisions have been made already.
When you go to make a new decision, like, should we use this language or this library? Like the smallest decisions within an existing culture. A lot of decisions around that serve effectively as guardrails and in a new company. Even though everyone we hired were people we knew personally and worked with and have even worked together sometimes, some of them when we all joined, like day one, everybody has been to different companies. Like the previous company was different. So they all come with slightly different expectations for culture, for technical choices.
So the challenge is less about how do you make...Bigger companies, the challenge is about how do you move quickly and how do you keep quality and all that. And for a new startup, I feel like the challenge is how do you end up with the right culture and do it quickly while everyone gets a chance to express themselves and feels included, while taking into account that everybody has different expectations day one, and that all happens really quickly. Like at a big company, when you start a new team, people might trickle in, but you start day one with four new people. So now you're four developers and the founders, and you're like, oh my God, so all of this has to happen at once. And everybody also really wants to work quickly.
ADRIANA: Right, right.
ORI: And beyond that, it just teaches you a lot about how a business works, like any business, the technical stuff, how does payroll work, all kinds of regulation. You learn a ton of stuff, which is really interesting and useful.
In my day-to-day, I just got a mortgage, and I understand how banks see lawyers and people and companies and how to navigate that, which has been really useful now that I'm super busy.
ADRIANA: Yeah. Um, so how did it all get started?
ORI: I guess I didn't answer that. So as founders, we have experienced the pain of solving for authorization and authentication at every company repeatedly. And this is like authorization is one of those things that people just sort of accept for what it is. You start a new project or you need access to something else on IAM, so you accept that it's like this. But it doesn't have to be that way because you know, Android apps, when you build an Android app or an iOS app, you know that if you specify, "I need to open the microphone," you don't have to say which specific API it is or it's very high-level. And you know that if the user and the user sees all the permissions that they're going to need, and if they approve that, then your app is going to work.
And you don't have the same level of confidence and simplicity in Cloud Native. You have to say on AWS IAM, if you're using a service that is writing to like, say, if you use Cloud Watch, it's writing to S3 buckets. And you got to make sure you also have access to write to the S3 buckets that is going to access beneath it all, which is insane. You're just a developer. You're doing one simple thing, and you have to think so deep, which, I mean, I love, but I think it slows it down if you have 500 engineers and everybody needs to understand this to make progress. And different teams use different tech stacks. We've seen people struggle with it. We've struggled with it and we see how it can be better in the mobile world. So like, why not for Cloud Native? Shouldn't accept it.
ADRIANA: I think that's such a great idea. I think we see this recurring theme, too, in our space, which is, like, we keep solving the same problems over and over and over. Right? And you get to the point where, like, let me just package it into a damn tool already. Right? Because it's starting to get annoying. Like, why do we need to keep reinventing the wheel? We got better things to do.
So I think that makes a lot of sense. Now, you mentioned AWS with Otterize. Does it work with other cloud providers as well?
ORI: Yeah, it will.
ADRIANA: Okay, cool. Nice. You got to start somewhere, right?
ORI: Yeah. I think the reason no one has done this before, even though for mobile apps, it seemed kind of obvious, so both Google and Apple did it is because there are so many different kinds for other kinds of software that it's hard to even put them together. I mean, I don't think a lot of people would put network policies and AWS im policies, even though they both have the same word in their name in the same category, they would think of them as different things. It's an architectural problem, right? And you can't just imagine it all together. It's exactly the kind of problem that you would start a company for if you need to work on it for a while with a team.
ADRIANA: Yeah, absolutely. Now, switching gears a bit, because I think this is the thing that got us connected initially. You all are doing some cool stuff around OpenTelemetry at Otterize, so why don't you share some of that with our audience?
ORI: Yeah, sure. So we have built the authorized network mapper, which prior to OpenTelemetry, the way it worked is you set it up on your cluster, it's zero config, it's all open source and it captures DNS traffic and uses that DNS traffic to create a map of your cluster. Now, with OpenTelemetry, I've actually had a chance to work with OpenTelemetry relatively recently, but alsoa while back at my previous employer when parts of it were still called open tracing. And it can be a bit of an involved deployment to get your first few bits of data because you need to integrate SDKs and all that.
So the Network mapper being an infrastructure level component that you deploy in your cluster, if it was able to export OpenTelemetry metrics, then it could make the first step to OpenTelemetry adoption a lot easier. Because I think the first step when you add instrumentation is to ask yourselves, what do I want to instrument? And if you don't know what you have, which in a large enough organization as the platform team, which might be keen on implementing OpenTelemetry, that can be where you are, that you don't even know what are the different components, which is connecting to whom, what are the dependencies that I care about.
And the Network Mapper had that info and the awesome team at Lightstep/ServiceNow saw the Network Mapper and contributed an awesome pull request that exports OpenTelemetry metrics from the Network Mapper. And it was really a no-brainer for us to accept the contribution and support you guys because, you know, we think of the Network Mapper as there are a bunch of cybersecurity products with simple similar capabilities for network mapping, but we really wanted the network mapper to be a standalone thing that you could use independent of the rest of Otterize.
So it's really like seeing what was possible to do with Grafana Tempo so easily with the same data that the Network Mapper has. We saw how it could make people's lives easier and really, that's what the network mapper is trying to do. To be a simple tool. You can just "helm install" on your cluster with zero configuration and get as much value as you can in a complete open source fashion.
And that really works well with OpenTelemetry. So far, the Otterize Network Mapper had a CLI that was using Graphviz to create a visual map of the traffic. And you could also hook it up to Otterize Cloud to get an interactive map. But now with OpenTelemetry, you can hook it up to your Grafana instance and get an interactive map, which then helps you see, okay, I'm interested in this service and it's communicating to these three other services and that's where I want to start with OpenTelemetry.
ADRIANA: Right.
ORI: Yeah, it's pretty powerful...the combination, I think.
ADRIANA: Yeah. And it's so cool to I think it's nice to see more and more vendors, including OpenTelemetry as part of their products, because, first of all, I think it shows the staying power of OpenTelemetry, but secondly, like, the recognition that, "Hey, this could help our customers, too." Right?
ORI: Exactly. And mission number one is to make people successful in what they do.
ADRIANA: Yes.
ORI: And we really want Intents and Otterize and easy network mapping to be something that everybody in the Cloud Native community has access to. So we have aspirations to turn Client Intents into the way that you do authorization, even independent of Otterize, contributing to upstream.
So that really falls in line with that. How do we make the network mapper more useful? Like a no brainer.
ADRIANA: Yeah, absolutely. So have you seen internal and external benefits as a result of the work around the network mapper, like, with OpenTelemetry?
ORI: Um, so it's still quite early.
ADRIANA: Fair enough.
ORI: I think it's just been out for about a week or so and we are I believe we're going to publish a blog post together that will help it get noticed.
ADRIANA: Yeah, definitely.
ORI: So right now, I think it's depending on people organically discovering it, which, I mean, it can happen and the Network Mapper gets organic traffic, but people who are specifically looking for OpenTelemetry and using it with Grafana Tempo are going to be best served by content that points to that. We want to add a tutorial for that too,
ADRIANA: Cool. And do you have any future plans around continuing OpenTelemetry integrations?
ORI: So we still need to explore that. Off the top of my mind, I'm not well versed enough to say what, but definitely I think even now there's more data that the Network Mapper has access to. Like, if you have Istio or Kafka, then it can tap into resource-level or topic-level information which can probably be reflected in OpenTelemetry as well in the same infrastructure way. And once we add more capabilities to the Network Mapper, we want to add cross-cluster discovery and the ability to discover infrastructure outside of Kubernetes from within Kubernetes. So that could also be interesting to add to the OpenTelemetry support.
ADRIANA: Right. Awesome. And can you speak to how OpenTelemetry is being set up or are you guys running like a Collector as part of your internal infrastructure or...what does the landscape look like?
ORI: So we're we're pretty new in terms of the internal deployment. I mean, I've had the opportunity to use OpenTelemetry before, but at other eyes we really only got into it with you guys saying, "Hey, remember Grafana Tempo?" Which we knew about before, but then we were like, "Of course." So as part of dog-fooding yeah, we started with setting up a Collector and a Grafana instance, but it's also really fresh at Otterize. We make it a point to use everything we put out, including contributions, so we know how it works for users. So we're pretty early there. But yeah...
ADRIANA: Yeah, amazing how's the learning curve been for you and within the company in general for OpenTelemetry.
ORI: I think there are some pretty cool tutorials and guides for we've looked particularly at Grafana Tempo which we said, videos and text.
ADRIANA: Yeah, I always appreciate the tutorials with the screenshots.
ORI: So Grafana Tempo has tutorials with screenshots, so getting like the initial setup has been pretty easy. But we did like I think if we built the integration completely ourselves then we would have had a slightly steeper learning curve because Clay at Lightstep did the research for us of what the metric should look like and how to configure it. So it was pretty straightforward. But I think also for a user that's trying to use it now, it would also be pretty straightforward because it was just one configuration value that we needed to pass to the network mapper after all is said and done. But I think it's interesting now to explore what else can we get from it now that we have the base layer of information there is.
ADRIANA: Yeah. As a follow up, do you envision at some point adding Open Telemetry traces to your core product, for example?
ORI: You mean like our back-end infrastructure or like the product itself?
ADRIANA: For your application code.
ORI: Yeah, because we use some level of Datadog APM to debug. So there's like a natural hook point that we would go into and hook up to OpenTelemetry now that we have it set up.
ADRIANA: Right.
ORI: Datadog was like we set it up just because it's the natural thing we reached for from previous experience. But we're just one step away from OpenTelemetry now. From places in OpenTelemetry.
ADRIANA: You've got your foot in the door now with OpenTelemetry.
ORI: Yeah, it's like all the infrastructure is there, the traceability of the code is there. Like we have contexts and everything in Go so that it's easy to pass traces. So I think we're a middleware away, which is a tiny step.
ADRIANA: Awesome. That's so great. That's very exciting. And I think it's, you know, the other thing that that's super important to underscore here too is the fact that you had somebody making an outside contribution to your code base and it speaks to the power of open source, really, to be able to have your...your code's out in the wild. And someone saw this and they're like, "Hey, I got a cool use case."
ORI: Yeah, absolutely. First of all, it was a pretty major contribution, which was cool. It's actually the first major contribution that we've had. We've had contributions before but they were of a bit smaller scale so it was exciting on that front as well. But yeah, the cool thing is that we were actually aware of Grafana Tempo but we didn't think to do that if we had thought about it, I think we would have built it ourselves before. But it's cool that somebody saw it, saw the potential, and just wrote the code, and now it's out there, and it's open source, and anyone can use it, and you guys contributed to it.
And there's actually one other company, Komodor.io, which has incorporated the Network Mapper into their own product and their own open source, which is cool.
ADRIANA: Oh, cool.
ORI: It's cool to see people use it in ways we haven't thought of. That really. It's like you said, it's the power of open source that we don't need to think about every use case because someone else can think about it and add it, and all we need to do is to support and go like, yeah.
ADRIANA: Yeah, totally. I mean, basically you've provided the seed and then people are just like, "Hey, what can we do with this now?"
ORI: Right. And it's kind of like the pitch for Google Fiber in the United States was, we don't know what people will do with one gigabit of data, but we will build it and see what they do. So the Network Mapper is really that it's just it's raw data of your network, and it does the collection bit, and then you can just add more and more exporters, which just this is like an OpenTelemetry exporter. So there's so much you can do with a map of your network. I think every developer product and every cybersecurity product has a map of your network, so it's the most valuable and flexible kind of data for a development teammate.
ADRIANA: Yeah, absolutely. And I'm just spitballing here, but I think a really interesting I wonder if there could be like...a really interesting use case with...I don't know if you're aware of the Open Telemetry demo.
ORI: Which one exactly? I guess not.
ADRIANA: So there's a repo called Open Telemetry Demo and it's based on the Hipster Shop app, which I believe originated with Google and they've turned it into like a telescope shop now, but it basically showcases instrumentation with OpenTelemetry. So it's this multi-microservices app written in different languages and so it shows different instrumentation in different languages with OpenTelemetry. And it started last year, just before KubeCon, and it's turned into this massively complex, but very cool showcase of OpenTelemetry's capabilities.
And it made me think of something where...so recently there's this company called Tracetest. So they're part of this company called Kubeshop. Tracetest is the product and they offer trace-based testing. And so basically the idea is, like, you're already emitting traces. Why don't we take those traces and create test case pieces out of these? And so they recently integrated trace-based testing into the OpenTelemetry Demo to showcase hey, like we can leverage this to basically run automated integration tests.
So then I'm thinking, hey, wouldn't it be kind of cool to have Otterize, especially the Network Mapper, integrated into this demo, showcasing, again, OpenTelemetry, the Network Mapper emitting metrics. So anyway...
ORI: Yeah, it it a it's a great idea. I wasn't aware of it, but we definitely should do that. And it's funny because most of our tutorials are based on the Google Microservices demo. It's the we still have the stock shop. It's not a telescope shop, but yeah, I guess that app is everywhere. I've seen it on Calico too, and Istio for sure that's a good way to help people discover that the Network Mapper can emit OpenTelemetry metrics. I'm sure it will be useful to a lot of people.
ADRIANA: Exactly. And especially it's an open source tool working with another open source tool.
ORI: The way God intended.
ADRIANA: Yeah, that's exactly. By the way, so we will be releasing this episode during the week of KubeCon. So by the time everyone's listening watching this episode will be out on the Tuesday. Will you be a KubeCon look for the Otterize?
ORI: Yes, definitely will be in the main area. Damn. I don't know what our booth number is, but...
ADRIANA: Look for the otters.
ORI: maybe I can check and you can...yeah...Look for the otters. Maybe I can check and you can edit that in.
ADRIANA: Yeah, you know what? I can add it to the show notes once you find the booth name or in booth number, I should say. Do you guys have, like, really cool swag that you're giving out?
ORI: You guys, we're going to have the booth other plushies and T shirts, of course. Of course. Oh, my God, the otters are so cute. They have, like, this little key. I wish I had one to show you now.
ADRIANA: Damn it. That means you have to go to the booth.
ORI: It's like it's been...yeah... You're going to be there too?
ADRIANA: Yes. I'm going to be a KubeCon. I'm going to be giving a couple of talks there. There one on platform engineering, actually, and self-service tooling.
ORI: Yeah? I'll come see.
ADRIANA: So I feel like it's, like, very on topic.
ORI: Yeah, I'll be in the crowd. I'll go, "Woo! Yeah!"
ADRIANA: I'm going to now make sure that I visit the booth because I definitely want to score one of those otter plushies.
ORI: And socks. Will we have socks? Actually don't know. Last time we had socks, they were a huge hit. The first time we had plushies and socks, I was kind of worried, like, would the platform engineers that come to the booth be happy to get those. Maybe it's a bit like, what do grown-ups do with plushies? But then I was like, no, it's actually a hit. And grown-ups have kids too, so not only are they interested in one plushie for themselves, they need also one for every kid so nobody gets there jealous.
ADRIANA: Yes, that's right. Because if you bring a plushie home and one of them is not for your kid, you are in trouble. It is the law. I do find the socks are quite popular because I find, like, for me, T-shirts usually are very hit and miss because I'm very petite, and so if it's not very small and fitted, I swim in the T-shirt. So the socks end up working very well because you can't go wrong with socks. They generally fit.
ORI: Yeah, and startup socks tend to be like happy socks, very colorful and...
ADRIANA: Yes, exactly.
ORI: ... maybe you don't want to walk around every day branded, but the socks are like your little secrets.
ADRIANA: Yes, exactly. They're perfect. They're perfect. Well, we are just coming up on time, but before we wrap up, are there any parting words of wisdom or hot takes that you would like to share with our audience?
ORI: I guess...I'll go for words of wisdom. I'll try, I'm not good on the spot without my...
ADRIANA: All right.
ORI: ...without my wife, but I guess the thing that I would keep in mind as a developer is to always think about the people that will encounter your code and read your code. A lot of times we think about the design, the performance, does it look good? Does it work well? But I think the most important thing to pay attention to is about the people. And sometimes the people includes you. I'm sure a lot of people watching have come up on a piece of code they wrote and think like, what the hell, what is this? And then find out it's them a couple of years ago.
ADRIANA: Oh, my God. It's so true. What the hell was I thinking?
ORI: It yeah, and it like, it really goes a long way because, you know, it's the, it's the feeling you get when you use a product and you expect something to be there or you expect to be able to do something, or even the unboxing experience seems like they thought about the person who's opening the product. If you come upon a confusing bit of code that does something nontrivial and you find a comment that says why it's this way and what you should do if you want to change it, like, oh, someone has thought about me.
And in some languages, like Go, you can go a bit further and use the compiler to do some of that. I think if you have a function that is doing I/O and it can block, then it's good hygiene to accept a context as a parameter and allow it to be canceled. Because you're not just allowing cancellation, you're communicating, hey, this thing is going to do something that you may want to cancel, it may block. And the cool thing is the compiler then forces the caller to actually make a choice. Like they have to decide which context are they passing in, which is a bit like returning errors. You're saying with a function signature, this thing can fail, which you can't not in every language.
You can do that using exceptions, Java, you can say throws and like an endless list of exceptions. But there's nothing fun, more fun than in C getting an unexpected exception.
And you're like, what is even going on? How did this get here? And it's like a leaky abstraction. So, yeah, my parting words are think of the people when you write code, not about the machines, because the machines, they're going to be fine. We're going to throw a bit more CPU and memory at it. The people are more important.
ADRIANA: I really love that. That those are really great words of wisdom. Well, thank you so much, Ori for geeking out with me today. And y'all do not forget to subscribe. And be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time...
ORI: Peace out, and geek out.
ADRIANA: Geeking out is hosted and produced by me, Adriana Vilella. I also compose and perform the theme music on my trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the Socials by going to bento.me/geekingout.