Read and watch part 1, part 2, and part 3 of our latest Serverless Show featuring Ran Ribenzaft, CTO, Epsagon. In the final installment, our experts discuss their favorite tweets. Hillel choose a topical tweet. “It’s a cartoon that talks about multi-clouds, so I think it fits right in.”

“I know that all of our customers are at least interested in understanding how they can have a roadmap to multi-cloud and how they can support multiple platforms, etc. I think there is some truth to, ‘Hey, why don’t we just optimize and figure out how to do the best possible job you’re doing on the current platform you’re doing before you start worrying about how you can be multi-cloud?’ But, obviously, it’s a question people come up with.”

Ran replied, “Yeah. I think it’s at the point where everyone wants to be this multi-cloud because everyone is talking about cloud and observability, so everyone wants to be there, but actually this meme, although it’s humorous, it’s true. Most of the companies went to the place that they’re utilizing the single cloud to the right performance or the right architecture. ‘Let’s do another one. Let’s do another one because everyone is talking about it.’ I think that the right attitude will be first to do whatever you can do best at the cloud that you’re running. I don’t care about vendor lock-in. Let’s do the best that we need to do with where we’re at, and if, for example, I don’t know, Google is counted as one of the best machine learning services. You can move part of your services that’s running, for example, in AWS to Google Cloud to have better machine learning services and resources. But don’t try to mess all over the area and try to do all of the clouds, but trying to win them all, but honestly lose them all.”


Ran’s favorite for the week was his own story. “It actually was published a week ago, and I’m really excited about it because I really love benchmarks and stats about the services that we use. Every time there is a benchmark about Lambda, I know that there was at least a couple in the last year, 2018, and I really wanted to have something, another one, so the picture that I selected was how popular each and every runtime is. For some people, it might sound interesting that Node is the leading one. But for me, I work with lots of serverless customers, so I know that Node is the leading one. But Node and Python all together are the vast majority of everything. I mean both together it’s almost 90% out of the function as a service, the Lambda service. You only find barely Java and Go or .NET, obviously. I’m curious why it happens. Why Java hasn’t won the serverless competition or Go hasn’t won it. Why Node and Python are so popular. Do you have any gut feeling about it?”

Hillel stated, “I can tell you from what we saw it feels like Node and Python seem to be the ‘modern way to go.’ People feel like, ‘If I’m going to do something the way the young and cool kids do it, I’m going to do it that way.’ Java and C# tend to be, ‘I’ve got a team that knows how to build software. I’m in the insurance business or banking or something, and they’ve been writing Java for a hundred years, and now they’re going to write Java on serverless functions.’ I think they start there. I think that Java particularly, probably because of the cold start, will get penalties early on. I think people moved away from it. I think there’s probably more production Java in percentage last year, I would guess, than there is this year because I think there’s a lot of penalty there. But yeah, why Go hasn’t picked up, why Python 3.7 hasn’t picked up yet, we’ll see, but I agree with you. We see the same thing. We see Node and Python dominating most of the charts.”

Timeouts – Pick a Random Duration and Hope?

Ran stated, “Python 3.7 I understand why because it’s fairly new. Go is also counted as the cool kids go-to language, but seems that it isn’t really taking off on Lambda functions. The second one, it’s not presented here, but it’s also part of the post, is about timeouts. Timeouts is a phenomenon that everyone knows. You pick a random timeout or duration when you set up the Lambda and hopefully that never reaches to that point. Most of the developers think that it’s not reaching to that point. But from our review that we got, more than 100K functions is that 12% of them experience timeouts sometime in their lifespan. It means that 1 out of 10 functions or even 1 out of 8 functions experience timeout in their environment. If you’ve got 100 of them, it’s a little function that you need to make sure that they’re not getting timeout and need flow, why they’re getting timeout. This is part of this observability that we’re talking about. Tons of resources, what’s going on, are they working okay or not? That was really interesting for me. I thought that the number might be much smaller like, I don’t know, less than a percent, but you find out that many functions do experience this phenomenon.”

Hillel said, “I loved your comment on the fact that it feels as though developers are almost picking a random number when they pick duration.”

Ran replied, “Yeah, who knows? I mean when I used to develop monolith applications, I haven’t needed to consider how long will it run? I was okay if it was running a second or 30 seconds and now I need to know how long it runs.”

Hillel stated, “Yeah, absolutely. We do a little bit of focus on that as well because, from a security perspective, our goal would be for you to set your timeouts to be as short as possible without hitting those timeouts, and then if there’s an occasional timeout, is that a security problem or is that a functionality problem or is that just once in a while your function needs to run longer? But ideally functions should run as short as possible. What we find is developers are either opting for the maximum or the default in most cases, or as you point out, some other random number in the middle.”

Hillel concluded, “I hope the people who maybe didn’t get exposure to the Epsagon platform will now, because it’s a fantastic platform. It’s almost a prerequisite for building anything complicated in a serverless application. If you’re not using it, guys, go out and try it. I don’t know how you’ve done anything without it.”

Share This Article
Share on facebook
Share on linkedin
Share on twitter
Share on email

Join industry experts as they discuss all things serverless including industry news and best practice tips.