Screaming in the Cloud - Episode 24: Serverless Observability via the bill is terrible

Episode Date: August 22, 2018

What is serverless? What do people want it to be? Serverless is when you write your software, deploy it to a Cloud vendor that will scale and run it, and you receive a pay-for-use bill. It’s not necessarily a function of a service, but a concept. Today, we’re talking to Nitzan Shapira, co-founder and CEO of Epsagon, which brings observability to serverless Cloud applications by using distributed tracing and artificial intelligence (AI) technologies. He is a software engineer with experience in software development, cyber security, reverse engineering, and machine learning. Some of the highlights of the show include: Modern renaissance of “functions as a service” compared to past history; is as abstracted as it can be, which means almost no constraints If you write your own software, ship it, and deploy it - it counts as serverless Some treat serverless as event-driven architecture where code swings into action When being strategic to make it more efficient, plan and develop an application with specific and complicated functioning Epsagon is a global observer for what the industry is doing and how it is implementing serverless as it evolves Trends and use cases include focusing on serverless first instead of the Cloud Economic Argument: Less expensive than running things all the time and offers ability to trace capital flow; but be cautious about unpredictable cost    Use bill to determine how much performance and flow time has been spent Companies seem to be trying to support every vendor’s serverless offering; when it comes to serverless, AWS Lambda appears to be used most often Not easy to move from one provider to another; on-premise misses the point People starting with AWS Lambda need familiarity with other services, which can be a reasonable but difficult barrier that’s worth the effort Managing serverless applications may have to be done through a third party Systemic view of how applications work focuses on overall health of a system, not individual function Epsagon is headquartered in Israel, along with other emerging serverless startups; Israeli culture fuels innovation Links: Epsagon Email Nitzan Shapira Nitzan Shapira on Twitter Heroku Google App Engine AWS Elastic Beanstalk Lambda Amazon CloudWatch AWS X-Ray Simon Wardley Charity Majors Start-Up Nation Digital Ocean .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as a managed service at

varying degrees of maturity. Others bias for, hey, we heard there's some money to be made in the cloud space. Can you give us some of it? DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they're using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access and IP addresses. DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote, albeit with profanity about other providers taken out. DigitalOcean also offers fixed price offerings. You always know what you're going to wind up paying this month,

so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It's click button or make an API call and you receive a cloud resource. They also include very understandable monitoring and alerting. And lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co slash screaming, and they'll give you a free $100 credit to try it out.

That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Hello and welcome to Screaming in the Cloud. I'm joined this week by Nitzan Shapira of Epsilon. Before he co-founded Epsilon and became their CEO, he was an engineering manager in the IDF. Before that, he was a developer at Intel. Welcome to the show. Hey, thanks for having me. No, thanks for taking the time to speak with me.

It's always nice to get a chance to talk with someone doing interesting things in this space. So let's start at the very beginning. What is serverless? So that's a good question. Well, I don't think it matters a lot what the definition of serverless is, but it's more about what people want it to be. So basically people want to write software without managing infrastructure because this is not what they want to do.

They want to focus on their business logic. So serverless means you can just write your software, deploy it probably to the cloud vendor, and the cloud vendor will run it for you, will take care of the scale, you will be billed as pay-per-use, and so on. So this is how I and also our colleagues see serverless not necessarily as a function, as a service. It's more of a concept. So you can just ship your code and someone else will take care of you for running it.

So there have been a lot of talks about what that potentially could be. Originally we started seeing things like this in the form of Heroku or Google App Engine, or if we were particularly unfortunate, AWS's Elastic Beanstalk. How does this modern renaissance

of functions as a service tend to differ from what came before? In my opinion, the main difference is that function as a service is as abstracted as it can be, which means that you don't have almost any constraints. You can write any code that you like. It will run as it would run on your own computer. So basically you have an operating system, you have a container, you have a Linux, your code is just running there and it can do basically anything. So you're not inside any platform like Heroku that kind of forces you to do things in a certain way. And you can do it basically however you want

as long as you live with the limitation of the environment, mostly around the running time and the memory and the CPU. So this is what, for me, is function as a service. It's basically a way to run compute really with certain limitations and being billed as pay-per-use. But also, in my opinion, serverless can be a container. So you can ship a container to something like ECS Fargate and basically, again, you don't have to manage the infrastructure. So it's still not pay-per-use, but for you, you get kind of the same experience.

As long as you can write your own stuff in your own way and then ship it and deploy it, for me, this counts as serverless. I've tended to go a little bit down into the weeds with functions as a service recently. And I agree with everything you just said until I started using it. And for me, I guess the eye-opening, the revelation that really tended to make it all start to click to me was the idea of treating this as event-driven architecture. An event happens. Maybe it's the passing of time.

Maybe a file gets uploaded. Maybe another function triggers something. Maybe some web service hits a webhook. And then all of the code and questions swings into action. That, for me, to some extent, was a more revelatory moment than, oh, I just write my code and hand it to them and they run it for me. Is that

abnormal, or is that more or less one of the things that other people just took for granted and I wound up not seeing because I'm, let's be honest here, an absolutely terrible developer? No, I think, well, first of all, when people get into function as a service or, let's say, Lambda, for example,

so they just try to write one Lambda, they run it, they get the input, the output, everyone is happy, and it works, it's fine, and then they run another Lambda and so on. So this is usually how people start with serverless or what they think serverless is, which is something like AWS Lambda. But at some point when a company or an individual have a decision

to go serverless because the company doesn't want to manage servers anymore as a strategy, it wants to be more efficient, then you need to think ahead and start planning. So now you want to develop this application with certain logic. And it's not just one function. It's a whole bunch of functions.

It's not just functions. It's all the services in between. So you have the message queue, the databases, the storage, all the external APIs to use, if it's any REST API or Twilio or authentication. And all of it has to be combined together into, like you said, event-driven architecture, which will usually end up being very distributed. So the fact is that once you pass a certain point,

the application you're going to end up with is quite complicated, or in many cases, very complicated. And this is, in my opinion, the real essence of serverless applications. The highly distributed manner, the event-driven, and all those elements, not just functions, but also everything else other than the functions, that can actually have a great impact on the performance, on the costs, on everything that's going on.

It's all together, your code and the managed services. So this is how I see it anyway. Epsilon tends to provide observability into the serverless space. That's the entire premise that your company is founded on. So you're in a somewhat privileged position, almost by default, where it's not just the serverless applications that you write and the people that you're interacting with on a daily basis are writing, but it's also you're approaching the position of being a global observer for what the industry is doing and

seeing how people implement this as they continue to evolve their own understanding of serverless. Is it too soon to draw conclusions based upon the trends you're seeing? Or are you starting to see the industry moving toward a certain, I guess, shared understandings or shared best practices? I mean, what trends are on the horizon? Yeah, so I mean, that's a great question. And everyone keeps asking me, and not just me, I mean, all the leaders in the industry, all the companies that are playing around in the industry are being asked, so is it like,

what is serverless suitable for? Is it just for small things? Is it just glue? Is it, you know, is it cron jobs? Can I really build production, complicated application on top of these things? Because traditionally, this is what people were doing with Lambda. And what we are seeing today, so we started about a year ago,

and we actually got into this space with no particular experience in serverless. So my partner ran the CTO, He did some Alexa skill development for Amazon. So he even got some rewards from Amazon for his top performing skills. So he knew what Lambda is. But we came from a cybersecurity background, reverse engineering, infrastructure technology, these kind of things. And then we just came into service and we saw, okay, so what does it look like? So obviously people were doing different things.

But even a year ago, we could see very interesting use cases, even presented in conferences and in blog posts. And once we started speaking with companies using service, we found out that many of them are actually running very important production applications on top of these things. And they don't do it just because it's fun and easy. They do it because they want their organization to be fully serverless in five years. For example, this is one of the things we've heard. Or every new application is going to be serverless from now on. People say in the past we were cloud first, now we are serverless first.

So we are seeing this trend that, at least in the mindset, people really like the idea of not managing infrastructure. It makes a lot of sense for the organization. For the developers, the developer velocity is increased, the go-toto market is shorter. So everything just makes a whole lot of sense. So this is how, let's say, organizations think about it. Some of them, anyway. And now if you talk about the practice that we see, so we see all different things. We see the big companies that are taking more time

and they have applications here and there, different projects. And you see a ton of startups that are fully serverless from day one, like we are and a lot of others. And then you see these companies in between that are still quite large, but they also have almost

100% serverless backend. So some of them were actually talking in serverless conf in San Francisco two weeks ago. And so you can see definitely that the applications can vary a lot, but you can definitely say that there are interesting use cases today already. And I mean, if I would guess, I think that two years from today, serverless is going to be the default way to develop cloud applications.

So this means that every new application, people will think first, can I do it serverless? And only if not, then they will go to other options. Today, obviously, it's very mixed, but it's very fun to be on the state of the art and speak with customers that they just tried the new service from AWS, or they are using Step Function in a very massive way. And you don't even see these examples online and suddenly you get to see something that is live in production in very high scale. And so I think it's a very interesting time

to be in this technology space. And I mean, I really do think that it's the future. I mean, we are serverless and it's not because we have to. It really does make sense for us as well. And of course there are also downsides, but this is what AWS and Azure and Google and all the others are working on to make the platform much, much better.

So I'm not worried about that. So right now, one of the big arguments people are making about serverless distills down to the economic argument where it's less expensive than running things all the time. And that's part of the value I see from an economic perspective. But I also see what Simon Wardley was talking about as far as being able to trace the capital flow through an application when certain functions take longer than others, there's a defined cost affiliated

with that. How are you seeing the economic story of serverless start to play out? Yeah, so I think that's actually one of the more interesting things around serverless. So, you know, people think pay-per-use is a good thing because, I mean, why wouldn't it be? You just pay for what you use, right?

But sometimes you don't know how much you are going to use. So think about a company that has some budgets. Now, how can they know that the budget is going to be enough? How can a startup company know that it's not going to get a 100K bill at the end of the month because the Lambda functions were running too much. So the concept is very nice. And if you do the math, yeah, you can, you know, after 60 or 70% utilization of a server, it's cheaper to run a server or the other way around. But that's not the point. The cost is something that you just have to be very, very cautious about.

And you have to be on top of all the time. And as long as you do that, you can enjoy the major benefits of serverless, which is the lack of managing infrastructure and scaling and so on. So to me, the cost is more of a disadvantage because suddenly it becomes very, very unpredictable. And we spoke with companies that paid $50,000 because of a bug in the code. Even we had a case that we identified it before,

but using our own system, we found out that one of our functions is going to be $20,000 at the end of the month. But we knew about it before, so we were able to stop it. But generally, these things are very hard to predict, and it's not just your own code. So you have your own system and your own code,

your own functions, everything is okay. But suddenly you're using an API to some external service, and maybe this API has some issues, has some problems with its own backend. And suddenly, instead of taking 50 milliseconds, it's taking 50 seconds every time. So think about an application that is running 1 billion times every month. This can actually be a very, very expensive problem that you have,

and you will have a very difficult time finding out about it because it's not even in your own code. How realistic is that type of failure mode? In other words, is this something that you've seen in the real world, or is this more of a theoretical concern for most folks right now? No, I mean, it's definitely something we see all the time. I mean, we have an application, we use a bunch of APIs. Some of them take five milliseconds, some of them take 500 milliseconds.

So obviously, there you go, you have a very big difference. And just think about any application that uses all the APIs. So you have all the APIs of AWS, for example, if it's Kinesis or DynamoDB or S3 and so on. And now you have OZero and Twilio and all those other APIs in the cloud. So your application is using, I don't know, 30 different APIs. What are the chances that none of application is using, I don't know, 30 different APIs.

What are the chances that none of them is going to have any issues ever? So probably pretty low. So at some point, you may get this thing. And so you are constantly in a risk of paying more because of these services. And the thing is that you never know. Sometimes AWS is having a bad day on one of the regions and sometimes you misconfigured a service. So this is why it's very slow, but it's kind of hard to notice until you get the bill and you find out that you paid 80% of the cost on waiting for this service over time.

Oh, you're absolutely right. Even before the serverless advent, every time I want to understand what's going on in a new client's AWS account, I mostly ignore everything they say and everything that the console shows me. I start with the bill because that starts to point at what's actually being charged,

what's going on as far as resource usages go. I think serverless starts surfacing this at a much better level than historically just, oh, knowing you have a bunch of instances running. But you're absolutely right. A lot of, I guess, day-after-Monday-morning quarterbacking style of observability historically has all come down to what the bill says. We also think that this is a great way

to look at an application. And in serverless, the nice thing is that you can actually take the bill and you have a simple equation that tells you exactly how much performance time is being spent. And vice versa. Which doesn't exist in EC2

because of the spatial pricing model. And this way we can actually take an application with, I don't know, like 100 Lambda functions and all those services in between, all the AWS services, all the APIs, and actually show a picture of everything, how it's connected, and put dollars on every point. So you know how much money your Lambda function costs you over the month and how much money you paid waiting for this API in the last month and so on. And then you have a much

better understanding of your spend. And another thing that is really cool to do is to start to look at flows. So you have business flows in the application. So a user can register to your system, a user can pay in your system and so on. And now you can see how much money every flow costs you over the month. And then you can say, okay, I'm spending 80% of my money on this user flow, which is daily backup. But it doesn't generate any revenue to me. And the other money that I'm spending is on the much more important flows. And I'm paying so much money for my cloud bill, so maybe something is wrong.

Maybe I shouldn't be paying so much money for a business process that doesn't generate so much revenue. So these things are much more difficult to comprehend in a serverless, highly distributed architecture. So I think it's very interesting to look and to visualize these things. Right now, it feels a little bit like companies are falling all over themselves in the vendor space to support

every serverless vendor's offerings. In other words, oh, because you're going to want to run your application on top of AWS and GCP and Azure and Oracle, if they have such a thing. And we're going to run OpenFAS and Kubernetes, and, and, and. Is that something that anyone other than the vendors

is actively caring about today? As I look around, and I understand that I'm biased in this, it looks like it's AWS Lambda plus a scattering of also RANS in the serverless space right now. Is that just a byproduct of my living in San Francisco inside of a bubble? Or is that what's going on in a broader context, industry-wide?

Well, I can say that we live in Israel currently and we are speaking with companies from all over the world. And we do see that AWS Lambda is being more than 90%, definitely. Although researchers say that numbers are different, but just that what we see is that AWS Lambda in serverless anyway is very, very significant compared to the others. Although I know that Azure and GCP are very dominant in cloud in general, if I take serverless out of the equation.

So I do believe that their function services will evolve very quickly. And we can see in the next year or two, much more reasonable ratio between the vendors. But today, definitely, when you say serverless, people think about AWS Lambda, even though I do not think it's all about it. But

yeah, it's definitely the most used one by far. I would agree. It feels to me, at least, when I was starting down this path, the serverless provider I went with was the one that was already integrated with whatever else I had going on. And talking to my clients, they see sort of the same thing. They start with a task that was either run by a cron job or had to be built into a monolith that

they could break out relatively easily. And, oh, every time we upload this file to S3, let's go ahead and have this action. Or every time a instance is tagged, well, why don't we go ahead and propagate that tag to secondary or tertiary resources? And it was very natural to wind up using the provider that already supported that event model. Having to bring in something else, such as OpenWhisk, to wind up doing something like that never occurred to most of us. So I think that may be part of the driver behind it. There's also something to be said for not just the first mover in this space, but also the maturity of offering. So yeah, definitely.

Serverless is not just the functions, but it's also the triggers, the events. So if you really want to design a proper serverless architecture, you need events of different kinds. You need triggers of different kinds. So if all you have is an HTTP event, you didn't really solve the problem. You really need a way to have queues and storage and database streams and so on.

So AWS has a very rich ecosystem. And also, I think it's just much more stable nowadays than the others. But I'm sure it's going to change. I'm sure all the vendors will be in a very high quality very, very soon because everyone is working on it. And regarding things like the open source platform that you can install, obviously the main advantage is that you avoid the cloud lock to vendor lock.

So you can technically, I would say, move it from one cloud vendor to the other without much trouble. But although in the reality, it's not so easy, since it's not just the code, it's all the other services that trigger the code as well. So I got to say, I'm not a big believer in serverless on-premise at all, because it kind of misses the point. But I do understand why many organizations are going to go this path.

For me, serverless is cloud, cloud first. And yeah, if you have to commit to a cloud vendor, you might as well do that. I mean, people are usually committed anyway. It's not like they are jumping between cloud vendors, but every organization has its own strategy. We are a startup, so we are happy running on AWS. It also helps us understand our customers much better because we are also using the same tools,

the same services that they are using, and so on. This isn't to say that everything is rosy or happy in AWS's serverless environment. I still think they're suffering increasingly from a problem that's only going to get worse, where in order to effectively and intelligently just get started from day one with AWS Lambda, here are the 12 to 15 other additional services you need to have

at least some passing familiarity with in order to do anything halfway intelligent. That feels like a terrific problem for people who have not been immersed in this cloud world for decades. I don't see that getting much better right now. Conversely, you'll see other vendors who have a very streamlined onboarding experience to this where you can know nothing much about computers, let alone their other service offerings. And there's a direct on-ramp to getting started with this. Is that something that you've noticed? Is that something that I'm alone in seeing as a

potential weakness? Well, I do think that it can take some experience to get started and some learning. But I don't think that things should be super easy. It's okay to do some learning, to do some onboarding, some experimentation, until you feel comfortable with everything. Software and programming is still something that you need to know. It's okay that things take a bit more time.

And I got to say, there are different tools today that really can help you with deploying applications into production. Obviously, everyone knows serverless framework and other tools. So the code management is a bit easier. Deployment of the services around the Lambda functions or around your own code are easier. There's also stuff like Terraform and so on. So I don't see it as a huge barrier,

especially when you start with a small application, you experiment a little. And also, I think it's kind of... I mean, if you can do it so easily, so maybe you are using a lot of templates, but when you start to do something more complicated, then it's going to break. So it's always good to know the basics when you go into a new platform.

And the basic is writing a piece of code and having a trigger and seeing how it works together and then combining more of these elements to create an actual application. So, well, I think it's reasonable. I wouldn't say it's easy. It's definitely not easy. All of our team, all of our engineers

came from cybersecurity background. We didn't know serverless from day one, but we learned and now we are know serverless from day one, but we learned and now we are developing serverless, deploying multiple times a day. We are very comfortable with AWS console. It's not the worst thing, let's say, like this. And once you get comfortable with it, it is very powerful. So I think in general, it's worth the effort. I would agree with you wholeheartedly. Again, what I'm about to say is in no way, shape, or form your position, either personally or as a company. This is coming purely from me.

But Epsilon's entire product positioning in the market is based around serverless observability, understanding what your functions are doing. And it's my opinion on this, that this entire space wouldn't exist other than the fact that CloudWatch is freaking terrible. Whether we're talking about CloudWatch logs, whether we're talking about the metrics coming out of it, whether we're grabbing into X-ray to figure out

how code is working through our serverless applications. All of that is terrible to the point of it can be equated to straining raw sewage through our teeth. And the only way I've ever found to manage my serverless applications intelligently has been to use a third-party service. So from a perspective of, I guess, looking into the future, if one day someone in the CloudWatch team wakes up from a 30-year nap and realizes, oh, wow, there's a revolution going on here, and the product starts to get better, what is the value proposition of something like Epsilon or one of its competitors in the market space

when it comes to understanding what's going on in our applications? Yeah, that's a great question. We hear it a lot. First of all, our value proposition is not how your functions are doing, but more than how your system is doing. So we are actually going to have a new launch soon, a new website, and also some new messaging. But generally what I say is serverless is more than just functions.

Serverless is functions, it's API, it's services, it's a highly distributed system, which means that you need more than just functions to really know what's going on. And this is our core value proposition. And it was built from the ground up as a distributed tracing solution and technology. And on top of that, there is different things like AI and predictions and helping you troubleshoot and so on.

But generally, I think if you compare it to stuff like CloudWatch or X-Ray. So I don't think it exists because CloudWatch is not perfect or X-Ray is not enough. It's because products, third-party solutions, are always going to be ahead when you talk about what Amazon usually offers. Because Amazon is an amazing company and it's an infrastructure company on the basis of it. And there are several hundred people on Lambda today. And what they are working on is making Lambda faster, making the performance better, reducing the cold starts.

All of these things are what they are taking care of. And they will take care of it. And also the same goes for Microsoft, Google. This is their job. This is the thing that they care the most, to enable Lambda for more and more people, for more and more use cases. Because today it's not suitable for every use case.

So this is why we don't care about monitoring the infrastructure, the CPU, the memory, all of these things, the call starts. This is Amazon's job, and I'm sure they will do a very good job. And then CloudWatch is essential. They have to give you something to understand what's going on. So they give you the basics. X-Ray is very, very cool. It actually lets you understand what's going on inside your code, not just the logs. But then when you talk about really complicated things like really distributed applications, event-driven, in a very high scale, like thousands of functions,

hundreds of functions, these things are quite complicated. And the technology needed for these things, in my opinion, is not something AWS would like to spend the resources on. I mean, the great thing about Amazon is that they don't try to hide anything in the way that they say, okay, we want to make our customers happy.

We want to provide them with the best solutions for whatever they need. So sometimes we develop something ourselves. Sometimes we can offer them something, some other product to help them. But we want them to be happy. So now their customers are worried about cost, about performance. It's a much more basic problem than distributed tracing across the application,

which is something that is very related to the business logic of the specific application for the user and so on. So in my opinion, Amazon will continue to improve the services like CloudWatch, like X-Ray, CloudTrail, everything around that. But I don't think that it would make sense to put as much resources as we put as a company that is solely focused on distributed tracing, on visualization, on AI.

So everyone has the best use cases. And I feel that Amazon will continue to be a very good provider for infrastructure and for all the technologies that enable people to actually run software. And on top of that, there will be different solutions for code management, for monitoring, for security. I don't think all the companies are going to disappear because

Amazon will provide new services. There is always this interesting connection between Amazon and other companies. So I think it's a good dynamics and everything is evolving. And hopefully, I mean, we are actually using some of the data from CloudWatch to enrich our platform. So it all, I mean, in a way, it all makes sense. Absolutely. And I think that your systemic view of how these applications work are one of the key differentiating points from most of the other serverless observability players. It's not about individual functions, it's about overall health of the system,

not just the pieces that I even control or have visibility into. As you mentioned, third-party APIs are probably my single biggest pain point right now. Yeah, definitely. I think that software today is... Some people like charity majors and other people say that, first of all, if you can use something that's already out there, use it. And don't write things that you don't have to write. So using APIs just makes a whole lot of sense.

And when you're in serverless, your functions are very, very small. So you actually cannot do many of the things. So if you want to do machine learning, maybe you would use an API for that. And if you want to do any kind of thing, there is an API for that. So I think that as time goes, the amount of APIs is going to be more and more substantial.

And also the risks with these APIs working poorly or misfunctioning is going to be bigger. And not to mention your distributed manner that one service triggers another one and so on. And when you talk about a chain of events, this can be very, very complicated to troubleshoot and understand. So I do think that this is the core essence

of what is a serverless architecture. So right now, there's an awful lot of buzz in the serverless space. And it all seems to lead back to Tel Aviv in one way or another. There are a number of companies that have been launching out of that region. It's been something of a renaissance for an area that's always been very technically involved. There have been a tremendous number of startups, and there was a book called Startup Nation that was written about eight or nine years ago that came out talking about Israeli culture fueling innovation. But for some reason, it seems that

serverless is the one area that the entire Israeli tech industry is jumping into, far beyond that of anywhere else up to and possibly even including San Francisco. Why is that? Well, yeah, that's actually a funny thing. I mean, traditionally, Israeli companies have been very good in deep technology infrastructure. I think it's because of the military. So many people in Israel had a lot of experience in cybersecurity and in mostly like really core infrastructure stuff from the army. So this is our natural thing to do, to focus on these things. And serverless infrastructure, cybersecurity, it's all kind of related. It's not like developing a mobile game. I mean, we are not very good at these things, obviously.

So this is one thing. Another thing is that it's a very small place. I mean, if you think about it, like Tel Aviv is a super small city and everyone kind of knows everyone. So when somebody says, oh, serverless, I heard it's very good. Oh, I know these investors. They think it's good.

Oh, so everyone talks to each other and suddenly there is this kind of belief that serverless is a good thing to do. And then I guess at some point, probably about a year or a year and a half ago, multiple teams started to work on serverless stuff. Once because it's technology and highly technological and so on. And the second is because everyone talked about it. And then when you see how things ended up today,

is that you have five, six or more companies, funded companies in serverless space from Israel. And I think it's a bit coincidental, but it's quite funny. In serverless San Francisco, there were more Israeli companies than any others. I find it more amusing

than I can draw any conclusion out of it. But yeah, it's a fun space. Hopefully we have some advantage in these kind of things. I don't know, maybe. I'm one of the program committee members for DevOps Days Tel Aviv. And every year when I go out there, it's just a different caliber of conversation that I have with technologists working on interesting things. I attend a lot of DevOps Days events, but there's always been something unique about, I guess, the perspective that I get whenever I'm out there visiting. I don't even know what that ties back to.

It just turns into a series of conversations I don't really get to have anywhere else. Yeah, I mean, actually, I haven't been yet in the conference, and I'm definitely going to be there this year. We look forward to receiving your submission for a talk. I think we already submitted a few talks, but

you will get them soon. Yeah, Israel is a mix of I think we already submitted a few talks, but you will get them soon. Yeah. Israel is like, it's a mix of, you know, people that just really like technology, a very good, like very small community of investors, including American investors, like, you know, top tier investors have their offices in Israel. And everyone, you know, I have friends, like good friends of mine work in like VCs and in startups. And everyone, I have friends, good friends of mine work in VCs and in startups. Everyone knows each other.

So you just know, I think, about the revolution comes here very quickly. So maybe even at the same time as it comes to San Francisco, it comes to Tel Aviv as well. And this is why probably you see things change so quickly here. I mean, I think it's a cool place to be.

Absolutely. If people want to learn more about Epsilon, where can they go? Yeah, so first of all, anyone can definitely reach out to me. My email is nitsan at epsilon.com and I will respond, I promise. And our blog has some pretty cool blog posts. So we did some really neat stuff like reverse engineering of the Lambda function and things that we believe are more interesting

to the community. It's not just writing general stuff, but we try to do things that nobody did before. So our blog is a good place to go. We had some open source projects that you can take a look at on GitHub. And of course we are in the conferences like ServerlessCon, ServerlessDays, and probably some other more to come. And yeah, we are pretty easy to reach out to.

So just talk to us. Absolutely. Thank you so much for taking the time to speak with me. This has been Nitzan Shapira. I'm Corey Quinn, and this is Screaming in the Cloud. That of Tov. This has been this week's episode of Screaming in the Cloud.

You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.