From Functions to Full Applications: How Serverless Evolved Beyond AWS Lambda with Nitzan Shapira

Kostas (00:04.184)
Welcome, would you like to give us a quick introduction of yourself? us a little bit about your background.

Nitzan (00:13.424)
Sure, thanks for having me. So I'm Nitzan, I'm originally from Israel. My background quickly is a computer engineering degree, a master's in computer science that I did before I started my IDF service. And then I went to the IDF for about seven years in the intelligence unit. So dealing in the areas of cybersecurity and basically

working in the R &D areas and managing different teams there. After that, I took some time off. I went traveling for about a year, got back, had a chance to work at a cybersecurity startup called the Misto that got acquired later in when that was 2017, I think I was there. So it got acquired by Palo Alto Networks. And in 2018, I started my own company, Epsagon, together with my co -founder.

run, so I was CEO and Epsagon was in the space of observability for cloud applications. We worked with companies using technologies like serverless Kubernetes building distributed applications to help them and specifically their development teams to understand what's going on in their application to troubleshoot production problems and to make their applications better. With Epsagon, we

built the company for about four years. We raised 30 million in total. In 2020, I moved to New York to open the office here. We had about 70 employees in total. And in the end of 2021, Epsagon was acquired by Cisco. And since then, I still work for Cisco. It was two years in a product leadership role. And in the last year, I've been doing a role in the space of investing and working with startups in the AI space.

Kostas (02:07.938)
That's quite a journey. Quick question. You said you worked for a startup in security, right? And after that you started your own company that was in observability. What made you go from security, which obviously I assume was something you knew really well, to moving into the category of observability?

Nitzan (02:32.164)
Yeah, so it was a bit of a different journey than that because the first step was to even want to start a company. That's how we started. And then I found the co -founder run while I was working at the security company. And then we just started spending time together, exploring ideas. And our first idea was actually in the HR tech space.

found a problem that we thought is interesting. We started building something for it and we talked to customers and we did this for a few months. And during this time, we also realized we want to work together full time and both of us actually quit our jobs to become full time on a startup. But right away, we also discovered that we don't really believe in the direction that we had.

And then we started from scratch and that's where we started exploring ideas that are much more technical. We realized these are areas that we will have some advantage in. And we didn't, we actually didn't say, let's do something in security or let's do something in cloud or whatever. Many people actually do say, I want to do cybersecurity, especially if you look, you know, it's been six years since we started or even seven years since we started the journey.

Today, it's very clear to everyone that Israel is a massive cybersecurity hub with so many acquisitions. So many people choose that because I think they believe they just have a very high success for a successful exit, which is probably true, but also there is a lot of competition and at the end of the day, you need to find the right problem to solve. So we just said, let's do something technical and let's try and look at different domains.

And one of the domains we immediately went to was the cloud. And specifically within cloud, my co -founder, was writing skills for Alexa that was done using AWS Lambda serverless technology. And he was familiar with the technology, you know, very broadly. And we started looking at it and as well as some other areas that we explored that we very quickly said, let's go into serverless because it seems that, you know, it's a very new technology.

Nitzan (04:52.068)
the kind of like research and predictions are that it's going to be how new software will be made, which, you know, looking backwards was a bit exaggerated, but it was definitely growing. And even there were a few startups that started to raise some money doing stuff for serverless. So this was the first choice, let's do something for this type of technology. Then, you know, we looked at cybersecurity as an option, but we didn't

see it as the main problem there. It seemed like, you know, there are some challenges, but all in all, it's actually more secure because you don't have access to the server. So you have less, less of an attack surface, plain and simple. So there were actually a few startups trying to do something for, for security for serverless. I think one or two of them got acquired pretty small acquisitions and it turned out it's not really a market later on. But basically we said, let's do something for serverless.

The first idea we explored was in the migration space. So something much more, let's call it heavy or infrastructure -y, like let's take an existing app and try to migrate it to AWS Lambda for the purpose of reducing costs because you're not paying for whatever is not running. We realized quickly that customers don't really want that. mean, nobody's going to take their existing code base and do something that risky to save some money.

But that was an important step because we realized that serverless is actually an interesting place to be. And we started speaking with customers that use serverless. And then we got to the whole troubleshooting challenge. That was a very real challenge. And eventually we decided to go into this because, again, several very large players, real pain points that we could relate to as developers. And even though...

We didn't build a cloud or developer tool company before. also didn't build a cyber security company before. mean, just because you know, stuff in the technical area of cyber, it's very different than building a company that sells a cyber security product. Usually, you know, those are made to monitor something or defend something and it's selling to see. So it's not something we've done before anyway. So actually.

Nitzan (07:14.04)
Actually, developer tool was a much easier way to go for us because you just speak to developers, like people that you know you have access to. You can even use the product yourself. Our engineers use the product. it made everything a bit easier in the beginning.

Nitay Joffe (07:31.898)
What was, you mentioned kind of you saw a lot of pain points. What did you find in those early days in terms of people trying to adopt serverless or the people doing it right versus not? What did you see in the market?

Nitzan (07:43.706)
So we just said, let's talk to people using serverless and specifically AWS Lambda was by far the leading technology. We started talking to them and then we realized that there is a spectrum between, I have a few Lambdas for automation, which was very popular, to I'm building an actual app using AWS Lambda, or I'm building it almost exclusively using Lambda, which is actually what we did a couple of ago.

across the spectrum, the more you get to the latter, people were struggling more and more. So I think for many people, there was no pain point if they didn't adopt it seriously. But for people who did, they were like really struggling and they were mainly using logs from AWS to try and figure out. But like when you know, when you have, let's call it 500 components in your app or different functions, and you just look at their logs individually, it's almost impossible to understand.

you know, what happened in the system. that was like the, that was the essence of the pain point. using a, sorry, using a single item in the system and looking at its metrics or logs when you try to understand the full system is not a good approach. And it breaks quickly when you have more and more complex systems and high scale. And that's when we,

more like intuitively thought about this idea of distributed tracing and why don't we actually be able to trace the request across dozens or even hundreds of components and then we realize it's not just the Lambda function, it's all the third parties because when you have an app that is so embedded in the cloud environment and it uses all those services and triggers, like you save a file, it triggers another piece of code, you push a message to a queue, it triggers another Lambda. So this is actually the app,

the mix of pieces of code that are yours and services of the cloud provider. And then we realized like, this is what we want to help figure out, like to trace it, to visualize it, and then to drill down and see specific requests in your system. That was like the essence of what Epsagon did.

Kostas (09:58.454)
Nitzan, you mentioned that people were using lambdas for different things. Can you help us understand what were the main use cases that you were seeing like people using AWS lambda for? What kind of applications they were building?

Nitzan (10:21.968)
Sorry, I had a quick break. I'm sure it was just on my end. So I heard the question. I can just, you're gonna need to edit it, but yeah. So the use cases, so I mentioned automations and one let's call it less interesting use case or less complicated. There was one use case, which is just using it as a,

like as a backend for a web app or a mobile app. So just like building an API, using stuff like API gateway. That was, think, that was a pretty popular use case that AWS was publishing a lot and explaining a lot about. But I think it had more potential for problems maybe because of the latency issues or stuff like that. And

I think, know, but again, that's like a very popular use case. And second one is more like data processing. So there is like constant data coming and triggers a series of Lambda for processing. that's a very good use case, in my opinion, for Lambda, because you can break it down very easily and decide what you want every piece to do. And probably there are a few more. There are like step functions, which is a, and sort of like a state machine.

with Lambda functions that some people would use. But really, eventually people just used it as part of a bigger system. So that's when eventually we expanded apps are going to not do just Lambdas, but do anything that is like distributed microservices. So you can't just say, I'm doing it, you know, I'm doing just Lambda because then you are targeting a very narrow subset of the market. The business case is like, I'm using what the cloud has to offer me.

to build apps that are modern and I will spend less time on the DevOps and more time on the logic. And maybe I will be more efficient with money, even though eventually, know, Lantus can be very expensive too. So you really need to be smart about them. So it's really a mix of Kubernetes and servers and serverless, but really using a lot of the cloud resources. So...

Nitzan (12:49.892)
Yeah, anyway.

Nitay Joffe (12:51.61)
And I'm curious, you mentioned kind of you have to be smart about how you use them. I'm curious, was there cases where, you know, some customers looking to use Epsagon and, know, they're, ready to do all the, should be tracing and get all the observability and either they realize, or maybe with you guys helping or something along the way that like, Hey, you guys have architected this wrong. Like you guys are kind of not using the patterns the way they should be. Was there any like anti -use cases or anti -patterns that people had to kind of unlearn or relearn to do differently when you said be smart, basically, what does that mean?

Nitzan (13:22.233)
Well, I think...

Well, it depends. mean, some, people just chose to use Lambda because they thought it's cool or whatever. Some people really understood the concepts and you really need to know how to architect the system properly. It's just more, more architecture work and less DevOps or infrastructure work, but it doesn't mean it's going to be less work. So, and maybe much more difficult to debug or understand. So yeah, of course some, some

Simple examples were heavy computations. Lambda had some limitations when it comes to memory and all that stuff, or CPU, and people just didn't think about those things and constantly got out of memory, and Epsagon actually helped to realize that. then you need to start and increase the memory and more and more and more. And at some point, it doesn't work anymore. So you need to break it. So some things, it just doesn't make sense to do it in Lambda. Things that are just...

so much easier to do in a regular piece of code. Or maybe people that were like, they said, I'm gonna have zero servers. I'm gonna have like 100 % Lambda. And even when it wasn't the right choice, they were like, how do you say, stubborn about it or, and ended up with architectures that make sense or very expensive. We also started to do cost monitoring and stuff like,

there is a bug in the code that could lead to a loop or something and then the Lambda can be very expensive and stuff like that that is like, like you need to be much more aware of what's going on and be able to put the right things in place. But yeah, I think we realized after some time that, you know, this is not like the future of

Nitzan (15:28.336)
This is just like a very interesting approach that can be utilized in many ways. But the future is whatever people want the future to be. People will use whatever technology is the right fit for them. And I think the future is also just having many choices. You can use the cloud service. You can use a third party service. You can host it yourself. You have many ways to do different things. And there were also open source frameworks for serverless.

I don't think any of them really kind of like missing the point, but that's also an option if you're into it. So, you I think it's about choice.

Nitay Joffe (16:08.816)
Yeah, I think the ability of like, this is, as they say, this is the difference between, you know, junior first timer versus kind of very senior person going and using a tool. It's the difference of using it as a hammer and applying every single problem to it versus knowing where to apply it or not. And so I think that's very, very relevant here. And you mentioned you guys were kind of going much deeper than just the serverless, you know, Lambda or whatever.

Nitzan (16:20.496)
Yeah.

Nitay Joffe (16:33.278)
you were doing. I assume that underlying technologies you were using like DAPR or open telemetry, cetera, a lot of those kind of existed and predated Epsagon to some degree, but also never really fully took off in terms of like massive adoption, right? Like they're very cool capabilities and technologies, but at the same time, at least from what I've seen in the market, a lot of folks either stumbled to use it or never really get how to get value out of it.

Is that something you guys found as well or like what did you find in terms of the distributed tracing world?

Nitzan (17:05.488)
Yeah, so when we started and I'm like end of 2017, there wasn't much adoption when it comes to distributed tracing. So open telemetry was existent, but very early and not so useful. And there were almost no players that offered actual distributed tracing that is not like do it yourself, which really misses the point. Like, why do I want it?

implemented myself. It's just like ton of work. So we actually, that's why we started in a very naive approach, which is like, I don't know what's out there. I mean, I know there is open telemetry, but I'm not going to bet on this framework as, you know, the reason for the success of the tool of our tool. I mean, we built our own libraries, we made them open source. They were at first, maybe the first year or two even.

they were actually not compatible with open telemetry because who cares? Like you come to Epsagon, we give you a five minutes installation. do everything ourselves. We instrument your code. don't have to, technically you don't even have to write a line of code in many cases, especially if you use Lambda, you just inject our library and you see the result. Just like you install a data dog or a new relic agent on the host. You don't care.

what is the code of the agent? It's not even open source. So that was our approach. We want to focus on the end user. We want to focus on the user experience and not on how it's working and explain to the user how it's working. We made it open source to generate trust because it's a piece of code that goes into their code. But we didn't have to do that. Like when you start an agent on the host, it instruments the code in the same way and you don't really have access to what it's doing.

Later, we started to see companies talking about open telemetry. By the way, until today, it's still like the adoption rate is not so high. But I mean, relative to the number of companies that should adopt it in theory. But we said, OK, let's make it open telemetry compatible. So we made it according to the standard, which means if you send open telemetry traces to Epsagon, we will be able to digest them and connect them to the rest of the traces.

Nitzan (19:32.248)
And if you already have open telemetry, that was honestly, that's not what drove customers to us. Customers liked Epsagon because it was like a one -click installment. That's what they liked. As opposed to, we had, for example, another company in the space called LightStep that took a very different approach. said, you must implement open telemetry in your code. We're going to explain why we're going to help you do that. They were targeting much bigger enterprises and tried to close

And I think they succeeded in some extent to close bigger deals. But their service was much more a white glove, long implementation. And we didn't like this approach. We felt like most people would prefer something that works out of the box. So, know, all in all, the open telemetry became the standard. But I think most people still prefer easy adoption versus, you know, write it in the code.

on their own.

Kostas (20:34.038)
Yeah, that makes sense. What do you think is the future of observability? It keeps coming back. There's kind of a circular situation with it. You see, you know, iterations of companies coming, trying to disrupt the observability space. After a while, more of them. VCs apparently are always happy to fund observability.

companies but you've seen, let's say like the how things progress and how the market also matures. What do you think is the future for that? What is changing based on compared to how it was when you started a few years ago, right?

Nitzan (21:25.932)
yeah. So on one hand, not much has changed. And, know, the basics are still the basics, metrics, logs, dashboards, alerts. They are like the fundamentals and everyone uses them. you know, there weren't many new observability companies that was founded or even at all, like significant ones. If I look at, know, when we started Datadog just became

I think they would just raise their first big round and Grafana was also starting to grow. Now they are definitely very big, but other than that, there isn't like any company that is big in observability. And I'm not talking like about all the logging companies that are like generic logging for observability security. Logging is like, there is always like another logging company, whatever. But I think...

there wasn't like a big technology that required a new observability tool. So there were some stuff for like observability for AI, which is not exactly observability. Some call it like it's more on the monitoring side, like make sure it's working properly. But also I don't think that's on its own is a big enough category. And I think that the biggest paradigm now is the whole

AI and how to apply it to observability, especially when it comes to code generation, because you can, in theory, start and think about generating the bug fixes yourself or dealing with the incident automatically, not just, you know, reporting on it or doing a bunch of things that you predefined, but actually writing code to fix the problem.

or even going to your cloud environment and fixing something over there, like anything that the DevOps person or the SRE or even the developer will do, you know, maybe the AI can do. And this can, you can be seen also in cybersecurity in the stock space. So a bunch of companies started there and raised a lot of money. And that makes sense to me, but I think it's potentially more doable than doing it for the

Nitzan (23:46.192)
to replace the developers because a developer is like the most sophisticated person in the, I don't know, in the engineering tree, I would say, where if you compare it in security, the security analyst is basically following some sort of playbooks to handle problems. Of course they have to think and they have to do things, but to my knowledge, they don't write code to replace.

and existing code in a product. They do stuff that can be done based on standard interfaces where replacing code is just one step beyond. But you know, if you look at the pace of innovation for AI and what it can do when it comes to really anything, but especially around the text and code generation, I don't see why not, you know, in a year or two, we will start seeing actual companies implementing it and

Maybe the big players like Datadog or whatnot or the other big players will start and offer some stuff over there. And then the question is how will customers like it? Will it be like, OK, that's nice. It's a nice feature, but it's only 85 % working. So I literally can't use it. I can't have 15 % of the cases where the code fixes

wrong, you know, it has to be like very, close to 100%. So developers will rely on it. So I think there is still a way to go. And that's probably the same reason why the Gen. AI adoption is still taking time. Maybe more than people thought in the enterprise. But that's my, that's my like intuition. I don't know, maybe there will be a good reason for a new observability approach that I can think about.

Kostas (25:38.296)
Yeah, and as a person who has been an engineer, built companies, doing products, do you think that the solution is a technology problem right now? Do we have to wait for the models, let's say, to get to the point where they are closer to 100 % accuracy in what they're doing? Or it's more of us as engineers and builders?

figuring out new ways to build products around them and deliver this to the users.

Nitzan (26:17.2)
Ehhmmm...

I don't think we will ever get to 100%, especially when you can't explain the model. So how can you prove that it's 100 % right? I think it's even mathematically impossible. So you always have the risk of hallucination or anything, something that can go wrong. So it's more about the users, in my opinion, to start adopting. And you can see it in code generation, I think.

A year ago, many people were skeptical, including me. Not skeptical that it's not going to work, but it's going to be faster for me to do it the way I'm used to. But today, think, I mean, I don't know the stats, but I would be surprised if not most engineers rely on Gen .AI in some way to help them. It's just faster in some ways. And then you have those tools that...

actually write the app for you and deploy it for you. And I think it's a natural progress. And yes, people will, because at the end of the day, okay, even if it's 99 % accurate, the human also has an error rate, right? Like when you push a code fix and it goes through all the tests, the test might miss something. So it's never 100%. This is the difference between a...

software engineering and mathematics, like you need to develop something that just works good enough and efficiently. And just, makes sense to use those technologies for that. So yeah, I think people will evolve and they have been evolving very fast already, I think. And one of the things I think is really exciting for new startups that just start is, or even existing ones is to think about creative ways to utilize those technologies to their advantage, you know, in a non -trivial way.

Nitzan (28:15.472)
not just in engineering also in go to market, but like to start and do stuff actually 10 X where the competition might struggle to use those tools yet because they're not good enough, but you're going to make it good enough for you. So that's how I see it.

Nitay Joffe (28:34.13)
And tying that back to something you said earlier about, sounds like at Epsagon you really focus on this super easy install, sometimes not even requiring a line of code. And here we're talking about the AI, we're kind of getting to 100 % quality is something that's kind of table stakes necessary. What is, like I'm curious anymore detail from your Epsagon days of how did you guys think about like, how do we make developers fall in love with this?

What is it beyond the install? How do you build that community that kind of bottoms up product growth? All that kind of stuff that people kind of talk about. sounds like you guys hit on a lot of those cords.

Nitzan (29:12.792)
Yeah, honestly, it's very difficult to create a product that developers love because developers is one of the more difficult users you can have. They are smart. They think they are smart. Sometimes they are smart, but they think they are more than the other user. And also they have very high standards and they

like to find everything that doesn't work. So, you know, it's a difficult audience. And of course we had users who would complain about stuff and so on. But I really think it's less about like the way the product was built. I think the product was built well, the UI was good. We were using it ourselves, as I mentioned, as our main observability tool in -house. But I think it's really about the customer service more than anything. And it was done not by like

customer support reps. mean, at the end we did have a few of them, by the CTO, he would go on a call with the customer and help them on the customer support. We would ship features really fast back to the customer. That's what developers care about, not about all the marketing stuff or even the product stuff. They care about getting what they want quickly from smart people.

We also spoke a lot in like the conferences in the community. I went to speak, Ron went to speak all the time. And we just, I think we were just approachable to developers more than the average company. But yeah, I don't know. I also don't like have some sort of stats about how, how much developers liked us or not. I just have a feeling about it. So maybe they didn't like it as much as I think. It's hard to say.

Nitay Joffe (31:12.102)
Yeah, it makes sense. How do you, how has that changed? If you see like tying tying it to kind of all the AI tools that people have now, what do you think in terms of like for anybody going out and trying to build the dev tools or observability, et cetera, kind of company today, how has that landscape shifted over time?

Nitzan (31:33.808)
I think one main shift is just that the big companies are really good and innovative and there are a few companies like, of course there are the big players that have been around like Updynamics and Eurelix or Dynatrace and they are still serving customers and building more stuff and then you have those

newer companies, mean, Datadog is not small anymore, but it's definitely newer than the others and Grafana Labs. they are just covering so much of the needs of developers. So many, many things I see in observability today is in areas that are, let's call it horizontal, which make it sometimes more difficult, like reducing costs.

How do I reduce your data though costs? Personally, I don't find it very interesting. think cost reduction tools are very limited in how much value they can give. Or let me make sense of all the different data that you have in your different tools and use AI to do that or whatever. And that's also something that is also, I mean, it's like another layer on top, but it's hard for me to say why it's

not a nice to have, like why is this a must have thing? So that's what I've seen in observability when it comes to innovation, I would say. And again, like there was no strong why now, that's probably why. mean, when we started Epsagon, the why now was like applications are becoming much more distributed, like orders of magnitude. So that was, in my opinion, a strong why now. But today,

I don't know. Okay. Applications are becoming more complicated. Okay. So the existing tools can cover that. I don't know, like more programming languages, more clouds. don't see a case, you know, and maybe just when so much code will be auto -generated by AI, I actually think it's going to be better code. So why do you need something else for that? I just, there needs to be a strong one now, which I don't see right now.

Nitzan (33:58.254)
No pun intended.

Kostas (34:04.502)
Okay, I have a question about something that you said at the beginning about serverless. So you were looking about the opportunities, trying to find opportunities and serverless got you excited back then. It was part of the why now, I guess. What, so two questions. One is what was so exciting back then about serverless? And second,

I have a feeling that maybe how you think about serverless has changed since then, how things have changed regarding serverless.

Nitzan (34:40.986)
how things change regarding serverless specifically.

Kostas (34:44.47)
Yeah.

Nitzan (34:49.294)
Honestly, I haven't seen something that was like a very big change. I think that technology just became more solid, more production ready. mean, people are using it, but I actually think the popularity trend has gone down. it's, I think I'm pretty positive about it. think Kubernetes actually became more and more popular and many people select it as their go -to and they just

know how to do it and they prefer to do that. You know, I don't hear AWS talk so much about AWS Lambda anymore, nor the other cloud providers. Now they all talk about AI. But yeah, I honestly don't know. think like, but on the other hand, there are really a big wave now of no code and low code tools that are actually good. Like you can build web apps, you can build mobile apps.

and not just like a simple one, but a full app and some of them are fully customizable. You can download the code, can go through everything, but the code generation capabilities are so good and the platforms are so easy to use that that's some of it is serverless in a way, like you don't have access to the server. You don't care about scale. It handles everything for you, just like you had Netlify. So like the next gen of that. And some of them are now like, I'm sure it's very early, but

That's like the future, like describe to me in text what the app is supposed to do and I will generate everything for you and then you have access to modify stuff. That's like, I don't know if that's the next gen, but I think no code or like very low code is definitely the future. I can't justify, you know, of course for special cases, you always need like, you know,

infrastructure engineers and all that stuff. But I'm talking about like SaaS applications, mobile apps. I don't see any reason that anyone will have to start from scratch or even write something that is not like their business logic and how it should look. So that's really, that's like the future of serverless is like a full serverless app, not just like a serverless function. you know, serverless is just like a word, but the point is fully managed.

Nitzan (37:13.696)
app and even and potentially no code if it's possible. So I think just evolve to do that instead of just like small pieces of functions.

Kostas (37:25.622)
Yeah, that makes sense. Do you think...

Kostas (37:30.456)
I'll share with you how I think of the difference between what serverless functions in something like AWS is and this new breed of serverless platforms and I'd love to hear from you like if this is something that resonates to you but...

I think of several less functions like AWS lambdas as a very horizontal platform, right? Which is what AWS also does extremely well. It's something that gives you the primitives to go and build a lot, but it's not attached to a specific use case or specific, let's say part of the life cycle of software. Well, we see these new companies

For example, Versel, right? They call themselves serverless, Modal, serverless, fly .io, serverless, Neon, serverless databases. So they feel to me a little bit more, let's say vertical in a way, like they take one very specific thing and they try to abstract it as much as possible, starting from...

the servers, right? Like the infrastructure itself, but actually going much, higher. Inverse Shell is a good example where, as you said about the low codes, when AI came out, they started releasing these features and frameworks where you can build UI, kind of auto -generated using prompts and stuff like that. Does it make sense? Is this what you see? Like is this

what you were describing about how you see the future of serverless.

Nitzan (39:19.696)
Yeah, I think similar to what I said, that's it's the future and yeah, like first of all, one good example. Maybe they just stop calling it serverless, that's the future. like, you know, it's also a word that is very hard to pronounce, so better if people stop using it. Yeah, but...

I'm excited to see more companies using those platforms to ship stuff because there is really no good reason not to. mean, the main one is the vendor lock, but some of them let you get out of there if you want. So that makes it not a big problem.

Nitay Joffe (40:12.626)
What about on the, you mentioned before, you know, the early days of when you guys were starting Epsagon serverless would have limits, right? Like memory limits and lambdas and runtime limits and so forth. And even today there still are many of those limits. How have those been changing or rather what would you like to see change there and what sort of...

things are, you know, just technical limits that you think over time will overcome versus what things are like inherently like you just shouldn't do that in serverless or serverless will never be for that use case.

Nitzan (40:46.8)
yeah, I don't think you will be able to escape all the limitations because just fundamentally of how it's working and how they build you, it's just, it's not meant to be for long run long running tasks. You're supposed to break your application into components, et cetera. So, no, I think it is what it is for now and they will continue improving it, but the basics can remain what it is. And, and you have so many other.

You know, think just the future is just write less code and use third parties to do a lot of it for you. And those third parties can also use AI. So you actually can remove big chunks of your code by replacing it with the right service that will just do it for you even without any code and we'll do it better and more creatively or whatever, depending what you need. So I think the future is just to focus on business logic and maybe

like AI will make serverless like even a non not so interesting technology to use because you will just focus on the very specific business logic that you need. So you will effectively have much less code to manage anyway. And you will worry less about scaling and more about like the architecture and selecting the pieces and prompt engineering and costs and all those kinds of things. Just a different, different

development world that we have now.

Nitay Joffe (42:23.896)
Yeah, whole different kind of developer workflow. that makes sense. Going back to shifting topics slightly, I'm curious, you mentioned earlier early on, you guys were exploring different ideas. You knew you wanted to do something technical and then you kind of fell into this observability space. As you were kind of kicking off the company and doing kind of exploring the early products, was there any moments where you were like,

maybe we shouldn't go this route, maybe we shouldn't go this observability serverless, or any like, you know, as they call them near death moments for the company. A lot of our audiences are, you know, either at startups or looking to start companies. I think they'll enjoy hearing those stories.

Nitzan (43:05.274)
some near -death moments because they went to use serverless.

Nitay Joffe (43:09.552)
No, for you as a company, as Epsagon.

Nitzan (43:11.708)
okay. I think we were lucky not to have near death moments because we weren't close to running out of money, which is really the main reason startups are dying. But that's really because we were able to fundraise at specific point in time. I think one point which was probably the most...

The most stressful one maybe is when we had our first large customer. So I'm talking about like a six figure customer, pretty big company. And it was one of our first significant users. So they used the platform across, let's say, 100 users, very high scale, like billions of requests. But the product was still early. mean, it was, you know, we had Python and Node .js libraries only. You know, later on we had like six programming languages.

And in terms of testing, in terms of everything, it was still early. So we had a bug in the library, which is like the most sensitive area to have a bug because this is embedded in the customer's code and it can actually crush their code. It will if there is a problem there. So we had a bug there basically in one of the Python libraries and this customer was in the...

let's call it a consumer app. So it has many users in the US, New York. And then one time this bug happened and they reported to us that because of our tool, their entire system in the East US region went down for like five hours. And this cost them more than they pay the Epsagon, which maybe, I don't know.

However, you know, they are engineers and they understand that code may have bugs and we fixed the bug quickly. We, we did like a full report. We explained what happened to them and they continued using the tool and they even doubled their contract later on. So at the time it was very scary or like, okay, what is this? mean, maybe it's too risky to put code in, in customer's code. It can cross their environment, but then we just realized that, you know,

Nitzan (45:34.4)
every problems can happen and if you show value and customers will still want to use. It happened to us a few more times but not at this scale. As far as we know, we didn't crush a production environment of a customer for several hours besides this instance. So that was one item. Other than that, just like the general...

difficulties of a startup when it comes to go to market, getting enough customers, making them use the product. mean, one of the things we realized, I think, is that developer tool or such a technical type of sale that requires the customer to go in their code and to change stuff at the end of the day is not ideal. Like you have many hops in the way that can go wrong and many...

people that need to do things to make it happen. So even if you speak with a buyer that really wants it, and then they need someone, some developer to go and change the code, this can take a long time to happen and they don't really wanna do it. And just realize that if you can avoid this kind of dynamics, it could be much easier thinking about like, know, starting a startup from scratch, et cetera.

But I guess other than that, we had the usual stuff that startup goes to, customers churning, letting employees go, all that stuff that I think we dealt with relatively OK.

Nitay Joffe (47:08.763)
I love it because it's very realistic. You have your own crowdfunding story basically.

Nitzan (47:13.976)
Yeah, right. I so you see what happens when it happens to CrowdStrike, which is actually much worse because I don't think people even think about this potential scenario when they install CrowdStrike, where if you speak to developers putting a library in their code, at least they understand the implications. But when you just install CrowdStrike, it's like, so yeah, that's, luckily we had it with just one customer and we weren't a public company.

Nitay Joffe (47:43.739)
And I think the analysis you did there is super interesting around, know, okay, we have this whole shit moment, customer screaming, should we remove the whole library component? And the result of the analysis is actually like, no, there's so much value we get out of that. Yes, it's unfortunate there was this incident and we're going to take it seriously and we're going to prevent it in the future, but there's just so much sheer value we get out of being that low level in the system that we can't take it out. And I think...

many, many companies, think, especially in the dev tooling and security and observability, et cetera, spaces run into that same sort of thing. You mentioned a little bit about kind of the go -to -market piece, right? Which is not something we've actually talked a lot on this podcast. I'd love to hear maybe more there in terms of you were saying the gap between the buyer and the developer finally making a change. What did you guys do from a go -to -market perspective? How did you kind of approach that problem? What were the things you experimented with?

Nitzan (48:39.824)
So it really varied between type of customers. So on the more technology type of customers, like let's call it boring the cloud companies or startup or large startup, they were usually pretty easy to work with. Like you would be right away speaking with the right person that can, you know, implement it, et cetera. And so they were used to those kinds of things. You know, the challenge is bigger the enterprise like

We had a customer that was an insurance company, one of the largest in the US, and they bought the product. They paid like six figures for it. But then we are basically chasing them month over month to implement it. And we are scheduling another training session, another session. We can't get the right people on board. And I think that's common in those kind of big customers, like the implementation side is so difficult. So we always try to...

address it in a few ways. So for example, one is when we before the deal actually closed, and we had we talked about a POC. So when we do a POC, we always try to make sure they are actually getting into production, which is not what the customer always wanted. They sometimes want to just do it on a test environment. It had a few advantages for us. First of all, we could know their scale so we can give them an offer that is based on their actual

numbers and not just guesswork. So that way, you know, we could potentially increase the deal size. But also when they have something running on production, it's like it's a barrier they have to cross. And then it's very easy for them to deploy in additional applications or more places. If we never ran on production, it's very hard to know how long it's going to take because of, you know, just internal processes and regulations and

compliance or whatnot. we tried to do that. In many cases, it worked and the customer did put us on production because for them it's like, why not? I mean, I'm getting it. I'm not paying yet. It's a POC and I can see real data. So as long as there is no internal reason, they might do it. And then for us, it's it's better. So, you know, and then just the best practices in general of customer success and having like the session scheduled ahead of time.

Nitzan (51:04.824)
So the customer knows they have to show up and they have to do certain things after the deal closes. It's not just, you know, they can't ignore you after someone is buying the product. But yeah, it's always a challenge.

Kostas (51:19.82)
Yeah, it's on safety gears a little bit here and focusing more on the present. You mentioned you are at Cisco right now and you are working on things around the Gen .AI ecosystem. Can you tell us a little bit more about that? Like what you are doing and most importantly, what you see in this ecosystem and that really excites you today.

Nitzan (51:44.1)
Yeah, sure. So my view at Cisco is called Outshift. It's essentially a business unit under the Chief Strategy Officer at Cisco that is about building new business lines for Cisco, especially in software. So, know, Cisco has a lot of business in networking as well as in security. And we are trying to do things that are related to what Cisco is doing.

new things. So we launched a product in the cloud security space called Panoptica and it's live. And then the second product that we launched is in the Gen .ai space, essentially a Gen .ai gateway and it helps organizations use it more securely. And it's called Motific and we announced it a few months ago.

And then now we are looking at the agent orchestration space and some other areas when it comes to AI. So it's a big group of people, a few hundreds of people, especially engineering and product people. And yeah, my role is really to help our BU when it comes to everything that's out there, especially the startup ecosystem and VC ecosystem and other areas where we wanna.

used to accelerate our roadmap.

Sorry, I'm hearing nothing. It's in the apartment below me. Someone is drilling anyway. And yeah, I think the whole AI space right now is very interesting because on the one hand, you know, a ton of money poured into many, many startups. Some would say disproportionately like companies that raise hundreds of millions without, you know, having revenue and stuff like that.

Nitzan (53:44.624)
companies like OpenAI or Anthropic that are valued in crazy numbers but are actually potentially delivering on it and are really successful. But I think the big question mark is the enterprise adoption because everyone is talking about it. Everyone says in the Gartner research that this is the main priority. But at end of the day,

You know, there are so many businesses that started to help enterprises use GEN .AI if it comes to building the model, testing it, scaling it, securing it, you know, everything you need to do to make it happen. And I think that adoption is still early and people and it's not in line with how much those startups have raised. So that's like a question like, okay, does this mean it

it's going to go slower than expected. Does this mean the market is quote unquote not happening or it's just happening in a different place that we thought and we need to be ready and maybe a year or two from now it's going to be full speed? So that's just a big question mark in a market that is just in terms of the amount of money that went into it is very, very large numbers.

But on the other hand, know, from the user perspective, like personally, I feel like it's real. I mean, the things it can do are amazing. We already talked about stuff like text and code generation. Everybody knows, everybody has seen stuff like image and video generation and how it's been evolving so quickly. And now you have tools on the go to market space and other things. So

It's just like a bit of a chaos, but in a good way, like chaos of many, many different things. And it needs to stabilize into what are like the top use cases that enterprises really need. And then I think from there, will stabilize. But from the technology standpoint, it's fascinating. mean, I'm using playing around with stuff like Chirgpt and Claude and whatnot. And I'm always amazed by how like

Nitzan (56:08.4)
I would say smart it is like things that are, you you can write, you can write something and ask it to rewrite it for you. And it tells it in a better way than I, I want to say it for the same things that were in my head. It's just like unbelievable value. There is real value generated. So, yeah, I would say like this today, if I was like an investor, like a VC, I mean, and I see a company

in the AI space, I would ask a bunch of questions to make sure it's not like a hype story and it's real. But I think the market is real and it's going to be very significant.

Kostas (56:51.706)
All right, so if you could time travel, right, and go back when you started your company and you could take with you Cloud and Charsypt and all these models, how would you use them back then with the knowledge that you have today, right? Obviously,

around building the company, building the product, selling and all that stuff. Where you would first use the technology would be like on the engineering and product side or more in the go -to market side.

Nitzan (57:24.048)
Well, I don't know. I'm actually thinking about those things nowadays a little bit. I think I would split it into the engineering side and to the go -to market side. And engineering side, would say, like, I can't force anyone to use anything, but I think, like, let's make sure everyone is aware of the tools that are available there and get training on them.

and have like AI assisted engineers in the company. Every engineer should be able to use those tools just to be more effective and maybe even do some projects like how can we use AI in certain areas engineering to make it better. that's like, you know, it's complicated but I think it's worth doing for almost any company today. On the go -to market, I think it's a bit more interesting because

There are many tools like automated SDR and automated salesperson or whatnot. And I think there, there is a big opportunity to somehow figure out how to use those tools to your advantage and to actually get 10X pipeline by better targeting, by web scraping, by...

actually doing the reach outs, but not in a trivial way, not just like take the tool and spam people, but do it in a smart way. And so I'm pretty interested to think about how to apply that. And then lastly, in the product itself, like, yes, I think in many things, mean, Episagon, for example, to be honest, the AI component was not.

something we relied on. mean, we didn't need AI. We did correlations of data that is like 100 % correlation. It's not based on some estimations, like what's called the strong identifiers, but maybe we could do other things that will, for example, one thing customers struggled with is, or we struggle with is like the amount of data we had to save because we would basically take a snapshot of every transaction in the system.

Nitzan (59:43.18)
and all the payloads that went. It sounds like a ton amount of data and it was, so we had to keep it for like a week. So just from the top of my head, maybe we could use AI to in a smart way keep less data, but actually only the interesting parts of the data. Like, you know, maybe you had the same transaction exactly a million times and you could find out those kinds of patterns in your systems.

or tell me the most popular flows in my system. What are users actually doing? And take it one step above observability to the business analytics side of things. So based on the payloads, tell me what they're doing with my system. And these are things we thought about, but were very difficult to. I mean, it's like big engineering product to develop, and we didn't get to it. But maybe with AI, you can.

build an MVP pretty quickly. just like, just like try to be creative with it, throw stuff at it, see what it can do. And if it works well, maybe you want to bring like an AI engineer and fine tune your own model. But I think there is a lot to do, but also you need to be careful not to, you know, spread around and start doing things that are not necessarily bringing value to customers.

Kostas (01:01:07.372)
That makes total sense. So we're at the end here. So, Nitzan, thank you so much. It was an amazing conversation. We learned a lot from the past, but also had some very interesting things about the future. And we are looking forward to have you again. And hopefully, at that point, we'll be able to...

a little bit more of a clear idea of what is going to happen with AI out there and discuss more about that.

Nitzan (01:01:38.554)
Sounds good, thanks for having me. Yeah, it was fun.