Ashish Rajan: [00:00:00] Hey, welcome, Ron.


Ran Ribenzaft: Very great. How are you doing? Good.


Ashish Rajan: Good. Thanks for coming in, man.


For people who may not know a bit about you. Love to know. I know a bit about you I’ve been researching it for some time. I’ve been having a conversation with you as well.


So for people who may not know you man what’s your background as to how you got to where you are today, like co-founding company and everything.


So what was your way into technology and serverless?


Ran Ribenzaft: Yeah. So probably it’s the same spiel as everyone is doing. , from the early days they liked computers. I build and disassemble them. I love video games. I love them, hacking stuff. So really starting with the early days, but then the professional career started somewhere along.


, the IDF, by the way, let me introduce myself before saying what’s my professional career. I’m run I’m based out of Tel Aviv Israel. So right now for me, it’s 8:00 AM in the morning. So really great time for , catching up coffee or tea. Yeah. And as everybody in Israel I recruited to the army and there I did focus mainly on cybersecurity.


So my background actually comes from security parts. Anywhere, , from development to , through designing, to living themes, to leading projects a really long [00:01:00] time , serving their really cool stuff, whatever you hear on the news where it happens. It’s like it’s very interesting that when I got, when I got out, it was relatively obvious for me that I want to build something.


And, , when you’re looking at my background, it’s mostly R and D low levels, cyber security cloud infrastructure. And it made a lot of sense to me to focus on,, the things that we as developers dev ops, engineers are experiencing on the day-to-day. So it was clear to me that I need to look for the new technology in the playground.


Lots of people are speaking about. And I’ll start, , the Alexis get what brought me into serverless afterwards, but that’s kind of the long story short today after three and a half years of episode, , jumping to the end of the serverless story, our company got acquired by Cisco for lots of money.


So that’s a great accomplishment. And now we’re building full stack observability within Cisco, like thebroadest offering the biggest offering, but that’s, , this kind of what I’m starting with.


Ashish Rajan: Yeah. Perfect. And it’s really interesting. So Alexa got you into thermal. It that’s an interesting one.


There definitely something exploring it in a little bit, but [00:02:00] so I feel like serverless is one of those topics where a lot of people feel because they have a couple of worker functions running. Hey, I’m serverless , like, , but a lot of companies now they have represented themselves as less con from not other places.


They’re building products in serverless, right? Like the large scale. I’m curious from your side as to what do you see as some of the common use cases where people use serverless considering, I guess you’re in that serverless land now. For people who may not have heard, I mean, they’ve heard of serverless, but they don’t know what many people use them for.


What are some of the examples that people use it.


Ran Ribenzaft: Yeah. So the most straightforward example and the easiest to start is a Cron job. Something that starts every minute, hour, day, , whatever makes sense to you, to do some. Housekeeping staff, , like renew certificates shutting down instances that are unused and all, all these common use cases where you need to do them, or even processing , batch processing, like every day wake up and process all of the remaining files on my objects.


This is kind of the first way to start with several lists. I wouldn’t call it production serverless. I [00:03:00] would just say, , this is the easiest and most straightforward case. And then you starting with more advanced use cases, more native, several issues cases. When you’re thinking of serverless, it’s mostly event driven architecture.


You don’t want to have something that trans on a wild through, or a web framework that just, , always on you want to react into some event, whether it’s a message, a change somewhere, an HTTP call, a web socket, whatever that makes sense to you. So then, , moving to the Mo more advanced use cases probably a VEC and APS.


Would be a really great example, , something that gets an HTTP call, from any type of API gateway or a load balance or any other service, processes, and returns the response. We can think of more sophisticated things like data pipelines. So I’m having a new message coming in from, , my Kafka, my queuing system, my topics.


So I want to process them and do something, , start them on the database called third-party API. And then basically from that point, anything that you want to build, it can be as complex as needed in [00:04:00] our, , our infrastructure. We got thousands of Lambdas, Lambda functions running in production.


So we can get this complex as you can think of. But they would say these are the most common use cases. And, , there are cases like IOT Alexa, which we mentioned. And basically any other thing,


Ashish Rajan: right. And so, because quite a few use cases that are already sounds like it’s in the wild, and I’m sure that comes through different kinds of maturity as well.


And now kind of. Coming from a building perspective. And we’re talking about so many use cases that are probably available already. What are some of the challenges that you see people have when trying to build an event-based architecture driven serverless, and maybe touching on what is event based as well?


Cause a lot of people won’t even know what that is.


Ran Ribenzaft: Yeah. So, , program ethically, you fall step back, , maybe 15 or 20. There’s been the people that, or the engineers that knew what the vendor is. But the programming that we did was more simple , in a, in an essence of a wild true, or like a framework that already is doing for us, whatever we need.


We didn’t thought about messaging about a synchronous [00:05:00] handling. It was more simple and it was good, but then, , software evolved and we needed something that can for. Process your data, but wouldn’t stale. You like , let’s say I’m uploading profile pictures and I need to analyze them to, , to detect your face and your eyes and whatever needs to happen.


I don’t want to block you while you’re uploading your new profile page. Until everything is being processed. So I’ll get your profile picture. I’ll tell someone, someone, Hey, go ahead and handle this new profile picture, understand where the eyes understand the phase, understand, , for the reasons that we needed and reply immediately to Ashish your profile has been updated success.


Go ahead and continue. Whatever. We’ll take care of for the rest of the things in the backend. So that’s part, that’s the part where you sending a message and somebody needs to receive it. This is exactly the event driven architecture. I’m a service that I’m responsible to react whenever there is a new event, , and there are lots of ways to pass synchronous and asynchronous event events.


The rates CDP through GRPC, through sockets, through messages message queues or topics. And that’s what starts a event driven [00:06:00] architect. And then the the complexity of it is to start and think this way, because we used to, , pack all of the logic into one component. There’s no events necessarily just, one function calls the others like real code function, not a functional service, and it’s not really event driven.


And then you need to break it up. And how do you start the transmitter? How do you make sure they’re reliable? How do you make sure what’s the performance from end to end? It starts to introduce, , when you’re, when you’re a software at Jones from one piece into, , hundreds of pieces, it just creates more complexities and more challenges in general.


Ashish Rajan: Oh, is that where people turn? They say, oh, when you start doing serverless, you land on the whole a there’s so many Lambdas. Like, no, they talk about like thousands of Lambdas. I think I was talking to a company once and they said on an average their record. They have at least a million Lambdas running just like wildly that they have no control over, or at least that’s , what they’ve felt or at least from the outside.


So what you’re touching on something really interesting, it’s an event driven architecture, which has kind of helps you scale based on say an action, which could be an upload of a picture, but that could have a [00:07:00] lot of things running in the parallel or maybe at different scale. So what do you see as some of the challenges that at such a scale brings in for building serverless applications?


Ran Ribenzaft: So what you mentioned, we’ve, , thousands or tens of thousands of functions. The first issue is just understanding what happens like would say the most basic resource management or inventory management, which function do I have, what they’re responsible for, what’s their triggers. How many times are they running?


What’s their cost, , functioning as a service introduces new building. How much does it cost? Can I block it if it costs too much? So just understanding, mapping all of the functions and the resources, this probably the first the first and foremost challenge any happens, just because it’s so easy to spin up new resources.


, we have all the infrastructure as a code, and now that we’ve serverless you, you don’t need to ask, , the it department, can you buy me a new Dell or IBM server? It just like, , I’m clicking a button or I’m just typing a command and I have a new server. So this is probably the first and foremost challenge.


Ashish Rajan: Interesting. So, all right. I’ve built an architecture. I don’t know if my [00:08:00] mentoree I’m kind of scared at that point. Fair enough. And so are there security challenges for successful? Let, go and come to your mind at that point. I mean, clearly billing, if you lose billing, you cant blocked stuff. Sounds like there’s a few security challenges as well.


Ran Ribenzaft: Yeah. So it’s saying the easiest, like the most straightforward challenges of security with, with several SES, one. Understanding what resources do we have and what their exes that they’re having. Unfortunately, or luckily it’s really easy to set up a new service, but then unfortunately, if you misconfigure it with the incorrect permissions, you’re ending up with maybe I know a thousand functions that can do anything for your no SQL database.


It’s not, it’s not something that probably would like to happen. So this kind of a trivial mapping of. This is what, it’s allowed. And this is what it isn’t allowed to make sure you don’t have like a, , a wildcards permission. It’s something important. And then just understand the entry vectors, , as a security person, you need to understand where you can come in and out.


And it used to be one single point where you could come in. So you would install, walk and, , run time security [00:09:00] and things like that. But now you have. Thousands of ways in each one is different because this one is from a message. This one is from an HTTP call. This one is GRPC. This one is a web socket.


This one is a Cron job. You have so many inputs, so many differences. It’s so big. It’s, it’s really like, , where do I even start?


Ashish Rajan: Right. So that’s a good question. Right? Where do you start? So w where do we with all these talk with the serverless? Is it inventory the first step?


Ran Ribenzaft: I think so in general, both for security, for monitoring, for observability, for anything, I would start with first understanding what assets do we have?


How are they configured? What’s their KPIs? Like how many vocations, how many permissions they have. So just start with the basic mapping. This is probably the first


Ashish Rajan: Right. Okay. And it’s really easier said than done as well, because clearly, as you mentioned, if there’s only so many trigger points for how many Lambda functions may or maybe serverless function in general would be running, but to your point , is there, like, I think, are there different types to this?


Cause I feel like there’s like an internet facing one entrance, [00:10:00] private ones, public ones that I’m sure that adds even more complexity to the spinal space as well.


Ran Ribenzaft: Yeah. So also just as regular self-aware there you have, what’s your kind of outer layer, which communicates back and forth to the world.


It can be like H it could be end points. It can be arrests graph, QL and points, et cetera. And then you have the internal things and they should communicate somehow through a VPC through some other configuration. And that’s another thing both on the security side and on the monitoring side to understand.


How pieces are communicating together from the outer place, all the way to the inner core business.


Ashish Rajan: Oh, and to your point, the inner core also has its challenges where you can pick any language you want. these days, you can do python node JS. You can go anywhere. It’s another complexity.


Ran Ribenzaft: We’re seeing customers using literally three or four languages on their lambda functions or functions.


Just similar as a code. , they’re have some go, they have some Python actually ask. We have, I think, two or three languages programming languages on our several dysfunctions. So. Because it’s so easy and , you can decouple the teams from one each other[00:11:00] if one team chooses, no, because they know no better.


Why should the other team do so if , their strength is Python, go ahead and do Python. The interconnectivity is what matters. Like the how services are communicating to one another and not what the service is doing. Solely


Ashish Rajan: gee, that’s interesting. How do people, I mean, I’m sure if you’re seeing this as a customer as well, and I see the challenges , in the security space quite often, where it across the organization in general, this is pre serverless.


You’re not even talking just it just server less, there’s people are using different languages, right? Getting ahead around. Yeah. We have a team that uses node JS, another team that uses Java and another team that uses dotnet. And he was like, , how do people normally start even addressing that?


Is that like, cause I normally feel like people normally reaction would be, I’m going to have a standard. We only work with node JS and.net. Nothing else is that how people deal with.


Ran Ribenzaft: So I don’t think having different programming languages is the problem per se. It’s more about how do you standardize, what you’re doing with it, because you have some security tools that may be, native to some programming languages and, , you might have.


One [00:12:00] vendor to monitor or Python and the other vendor to monitor go because they don’t do this. And then you end up with, I’m using , solution X and Y for monitoring solution a and B for security. And they’re not communicating to one another. So I’ll have another solution for logging, , like elastic or Splunk.


And on top of that, they’ll have another Grafana or Cuban, or you end up with a suite of tools that not necessarily correlate to one another. And that’s, that’s another challenge when. When your infrastructure is not unified, it might imply that your, , your second level, your solutions on top of it will not be unified.


Luckily, today I think there were there’s, , we’ve evolved. You have cross solutions that speaks all languages, all infrastructures. So it’s, it becomes a bit easier, but again, I don’t think having different languages is the problem per se. It’s more about how do unify, what the outcome.


Ashish Rajan: Actually, that’s an interesting point because what about interconnectivity between services?


If there’s a team providing services, I’m going to use the example that I gave earlier, upload photo. And the other service is just to save the photo on their [00:13:00] profile. It doesn’t really matter , what the language is, as long as they can communicate that over API, it shouldn’t really matter. Like, I think the complexity may come in from one perspective, I guess, in terms of hiring skillset and all that.


That’s secondary to the port, right?


Ran Ribenzaft: Yeah, it’s, it’s definitely more on the hiring challenge. And in general, , hiring becomes really hard, nowadays, but it’s more of a hiring challenge. Let’s say you have, I don’t know, dot net and it’s not probably easy to get developers. It’s easy to get to node developers and it’s a problem.


It’s more problems than, , dealing and developing with.


Ashish Rajan: Yeah. I have my own stories about dotnet, which I’ll hold off for the moment, but , we didspeak about monitoring as well. So I’m curious. Now we kind of spoke about challenges where we started to build an event driven architecture, have a lot of these serverless applications are running now from a monitoring and performance perspective.


It sounds like there’s already quite a few challenges with different languages. Asset inventory is probably another one is. How do you normally see companies do monitoring and performance? I’m assuming this kind of like there’s a minimum viable product to do monitoring versus [00:14:00] like super advanced level monitoring.


So what does that morning performance look like in a serverless


Ran Ribenzaft: land? Yeah, so the easiest thing to start with, and that’s the basic type of monitoring that everybody gets is Everybody are used to logs, , ship your logs to whatever your cloud offers or some general general solution like elastics plan or any kind of form, out of it.


And just monitor logs. You can set start to set up metrics. You can start set alerts when , something bad happens and you’ll get to the logs and that’s relatively the easiest solution to start with. It requires some, , maintenance and overhead. And now you obviously. Let’s say we’re picking elastic.


It’s open source. People think it’s free. Okay. Then there is the hosting of philosophy and the maintenance and somebody should know elastic in order to set up elastic. It’s not like a click and okay. We got the elastic, we’ve got monitoring. And then the second part, which is more hard. Is actually to ship interesting logs because you don’t want to have roll logs, like a, , a line of log that you need to parse out.


Like, , I broke or something like that. You want to have a Jason with context and metadata and the [00:15:00] payload and the details and everything comes in and out, and then you need to create middle wars in Europe. For everything basically that you do for every API call for every incoming call, for every message.


So generating the logs, it’s probably the hardest parts and not just, , clicking on some button to spin a new elastic search.


Ashish Rajan: So it’s logging readily available and serverless functions. I mean, I’m not, I know there are different types of it. Like how good is the logging, which is out of the box from serverless


Ran Ribenzaft: functions.


It’s the most basic thing , I’ll take, for example, AWS, we have AWS to get. Decent metrics. , how many in vocations, how many errors? What’s the average like what’s the duration, , average percentile. And you get the most basic form of floaters, like start and start and start, and then you can print your own loads.


But again, if you’re just printing logs, if they’re not structured well, it’s hard to make sense out of them. There, there are lots of other problems that I’ll address soon, but, Yeah, you need to create your own logs. Nobody will create the logs that you need. And then, what the nightmare part is, , we’re having a problem.


Oh, , we didn’t print the log before that [00:16:00] line. So we now need to, , add this load line, push it to get up redeploy, wait for the problem to happen again. And it’s like, , the log is not there. You can troubleshoot it. If you don’t have.


Ashish Rajan: No. And to your point,is trouble shooting . I’ve always heard this and keen to know your thoughts on this as well.


It’s troubleshooting quite hard in a serverless land because how sometimes people say, oh, like the compliance requirement sometimes it’s, Hey, you should have, I don’t know, some kind of an agent running or antivirus or whatever, but that kind of concept doesn’t exist in solace. And another thing.


Well, that’s the security side, the other side to running as a computer engine. Is that logging and troubleshooting for? Cause there is a certain time period that the function runs for. If you don’t have logging, you have no idea what happened until you keep running it again and again. So how do people deal with that kind of thing?


Ran Ribenzaft: Yeah. So basically we’ve been that nature. It’s not like a, an instance that you can connect and gather some more information it’s you don’t have any instance or SSH to do so. So it becomes harder, definitely harder to to talk hill, but the main problem, I think with serverless. When you had just one component, it was easy to investigate [00:17:00] because that’s kind of a star architecture diagram.


You have the centralized base, you can see from there all the communications to where it communicates and we’ve serverless. If it’s, , if it’s a built, correct. You don’t have a star. It’s more of a pipeline. Lots of pipelines services are communicating to one another. So not necessarily if these slum the fails, it doesn’t mean that this is the problematic Lambda.


Maybe the Lambda, before that, which pushed a message, pushed an incorrect message with cost caused this function to fail. So understanding the context of a flow in such an environment, this is really the problem. And this is really where logs are not addressing the problems because you’ll have these slow.


Sorry, you’ll have this and that logs, but they’re, they’re not printed all together. They’re not printed like inline one after the other it’s you have this one, you have these ones, you need to correlate them somehow and say, okay, this is the message that correlates with this message. And this is the problem.


And it doesn’t come this way. You have like three different streams, , STD outs to two different outputs, and now you need to match them because , it’s, the problem is not when you were having [00:18:00] just a single message when you were having a thousand messages. Sorry, thousands of messages per second here.


And the same here, you wouldn’t be able to, , to match these logs here.


Ashish Rajan: Wow. Okay. So sounds like it’s sort of easy, clearly building applications in serverless, there’s clearly a lot of use cases as well, but so why do people jump into the serverless thing in the first place?


Cause I mean, to your point, It’s a sounds very complex as well for someone who they seem to, both of us talk about is going, yeah, I heard Ron talk about this and I’m like, oh my God, this is so complex. So, so why do people jump into this? Like, I feel like it’s one of those things, which is probably going to be like, you would see a lot more of in 20, 22, and I’d love to hear your thoughts on that as well, but a why people are jumping into this.


And do you think this is going in 2022? This is going to be a lot more.


Ran Ribenzaft: Yeah. , the reason that people are jumping through it, it has a lot of different values. , I’m putting the the title of this show is the challenges, not the benefits, but let’s, let’s pause a bit and talk about the benefits of several lists.


If you have to set up like a web server, let’s say 15 or 20 years ago, I used to do [00:19:00] that. Okay. Let’s say you need to contact it to get a new server, then you need to install it on some rec plugging, , power, adapters network adopters, put in a CD of your favorites, Linux or windows. If you prefer to install that, start to configure the operating system, make sure we’ve got DHCP or, , a static IP, et cetera.


Then you need to install all of the packages that you need. , spite on PIP installed pipe, like get piped on paper, in solve the dependencies, ship your software to their, to the server. Then you let’s say I’m using. Plus my favorite framework is fluff. I’m running flux, but that’s not alone. I need to do a reverse proxy like engineers that may be high availability program.


And making sure everything works together. And this is just for a single instance, what happens when multiple instance same goes over again and now I need the load balancer before them that will shift the traffic. That’s also a nightmare. Look how much time it took me. It’s probably, let’s say a day per server to get it up and running and with serverless, it’s literally.


Let’s say if you were very professional, it will take you probably a minute. If it’s the first time you’re [00:20:00] building it, it will take you probably like 30 minutes to get up and running with unlimited scale and no kind of messing around maintenance , patching the operating system.


So many things that are unrelated to what you really want to do. You want to focus on the business and not the the other. So that’s probably the best benefit of serverless. Do what you want to do. Focus on your business logic and don’t focus on infrastructure. Don’t focus on scale. This will be taken care of.


Ashish Rajan: Interesting. So maybe that’s a good segway into the whole land of what, does maturity scale look like for people who are probably looking at serverless right now for doing to your, what we said earlier, doing background jobs for, Hey, make sure. files are being backed up and seeking the S3 bucket.


This could be an random example, but all the way to people like yourself are building companies on. So let’s completely, so how does that maturity scale look like between the two kind of, for people who may be on the one spectrum and the beginning spectrum, and trying to get to the spectrum where I would love to have a product, which is completelyserverless what does that [00:21:00] really look like from a maturity perspective?


Ran Ribenzaft: So I think over the years, if I recall correctly, 2016 or 2017, somewhere between these years, back then, it was completely, background jobs, et cetera. And it started to grow more and more traffic. I think today serverless is something that, let’s say almost every engineer heard of it, not necessarily messed with it, but heard of it.


And I think over the time it will be more and more common use cases. It wouldn’t replace all other use cases or all other environments. It will be just another. Framework and other tools that you can use, if that makes sense to the organization and to the project that you need to build. I think moving forward from the beginning with serverless and in general, the company or the organization that you work for, or starting with serverless to something more mature is worse, serverless placed in your architecture.


If it’s a background job, it’s not, let’s put it other way. I love to call it the, the. Is it important to you? So if it drops, will you wake up at 4:00 AM? So probably if, , if you’re backing up files, no, it’s like I’ll go tomorrow and I’ll make sure, , manually back up these files. But if you’re, , API.


[00:22:00] You’ll, , you’ll wake up at any time to do that. If your data pipeline stops processing and there is no data for customers, you’ll wake up to do that. So the more important is to your organization. This is how far you’ve advanced with several others. And it’s not necessarily, , many people would say the number of functions.


You have the number of scale running through your system. I think these are byproducts to the company, the organization. The progress that you’re making with serverless, but initially it’s , how important is what you’re building with serverless.


Ashish Rajan: Yup. Yup. And I think to your point, the maturity of scale also flows from the fact that the stuff that the function is doing, if that’s really critical to your point, that you will wake up at 4:00 AM for that, that means your serverless running company, I guess at that point, your livelihood depends on the fact that the functions are responding correctly.


Thanks. Yep. No, that’s a great example of man. I’m going to ask you how to use that for some of the next one next time when I had this conversation. So we know we’ve been talking about the whole building serverless application and like the challenges that come with building application as well.


Now, is there like a. I feel like there’s a lot of information about [00:23:00] serverless and what that looks like from an architecture perspective. Where do you normally send people for learning a lot more about, say building serverless applications outside of the whole, Hey, go to your specific cloud provider thing.


Is there any other resources that you normally send people to like, Hey, go here and learn about.


Ran Ribenzaft: Yeah. So there are lots of people that would love to help , including me, for example, I’m an AWS serverless Sera and I’m happy to help, , help.


Ashish Rajan: I’m glad I’m the company.


Ran Ribenzaft: Yeah. So I really love helping any question regarding architecture regarding solutions regarding use cases, I’m happy to help.


And just as me, there are lots of. Hero’s or MVPs, , each cloud vendor name it differently. So this is one place to start then, , any online courses at this point, there’s probably an online serverless course if every, , every e-learning website, I don’t want to mention names with people have their own preferred kind of website.


And if not, , ask friends, if you don’t do serverless, you probably know a friend that is doing. Here. It’s a really question of experience. Someone that is doing serverless for three years would be able to give you really great [00:24:00] advice on , what to do, what to tackle. Et cetera. So it’s, and, and truly depends on the use case.


They can say something that is a generically applied to every several assumes case. It’s, , if you ask me, Hey, Ron, I’m planning to build this and I need to deliver this by this time. What do you suggest to do? This is one answer, but it wouldn’t apply for someone that is saying I’m building another staff, which will take me, I don’t know, four years to build.


How do you suggest to build it? So really try to use any help out there. And there were a lot of. If you want to get in the know of serverless, then, , a type of their newsletters that are coming across the globe. So , there are one of my most recommended ones is Jeremy delis.


One, I can pass it to you so you can share it group. There are people a great newsletter off by by nun. It’s the name of the newsletter? Really great articles. Summarization of the content. It’s not like just, , here are links, go and read them. It’s like, , what’s my, or what’s Jeremy’s daily tech takes on each and every point.


So it’s really nice. And it collects data from, , the social media, from content like blog posts from new releases, from different products and [00:25:00] events. So it’s really not.


Ashish Rajan: Awesome. Yeah, I’ll definitely pass it on that’s kind of like most of the questions that I had are now. Fun questions for people to kind of get to know a bit more of our ground as well. And you just three questions, not too many, right. Just, just to get to know you a bit more for audience, get to connect with you.


The first question is what do you spend most time on when you’re not working on serverless?


Ran Ribenzaft: Walking and cooking? Yeah, I really like cool. I’m walking. I just, yesterday I got to know that I’m walking, 100,000. Steps per week. Really the lot, the average person walks like 10,000, 20,000, steps per week.


So I’m really a Walker. I’m walk, I’m walking all the way through the office, which is like 45 minutes every day back and forth. I like to think to speak to chat. I’m a fan of it. It’s , when you’re running and you’re releasing, I think the dopamine hormone, which will make you a kind of relaxed and happy this,


Ashish Rajan: wait, are you, are you one of those people who has a treadmill in their house and they’re doing a meeting, just keep walking on the treadmill while doing a meeting.


Have you seen those


Ran Ribenzaft: exactly back and forth, , from one room to the others taking it? It makes me think it makes me.


Ashish Rajan: Oh, [00:26:00] right. Okay. Fair enough. I’ll say I want to take a second for the fun section, because I got a question here from, we need as well as maybe interesting. One is question is what are, what are the challenges when you move your serverless application from one cloud provider to another?


Ran Ribenzaft: Oh, that’s hard. Several us among of the challenges are vendor lock-in. When you’re using several lists, the problem is it’s not just the code. So your. You’re forced to work in a certain framework that the cloud vendor is providing you, , getting the event, getting the context, returning the response in a specific schema.


And then this is not only the part when you’re doing serverless. You’re probably tied to other services. I’ll say, for example, from AWS, you’re having API gateway and dynamo, would there be an SNS and SQS, which are not vendor agnostic at all? And not only that, you’re using their own codes, like leaderly the code of putting a message and getting a message from SQS or SNS.


It’s an AWS specific. So moving from one vendor to the other, it’s very, very hard, especially when you’re running fully serverless. I would consider, , I would go back with a question. Why do we want to [00:27:00] migrate from one cloud to the other, if it’s called. It will, it will cost you a lot to migrate from one cloud provider to the other, and you really need to think out for the long-term, whether it’s worth it, because in the short term it will definitely cost more.


But if it’s a, , a kind of my big company know thousands of people, company are planning to migrate from one cloud vendor to the other as a big project. , the CFO is leaving. So, okay. It’s probably makes sense, but if you just, , I’m having an application that costs $100 a month and I want to switch to another version though, because it will cost me, I dunno, $60 a month.


That’s probably not the change, the poor feed, but then again, it’s hard. It’s the challenge itself is just change, like a change code from one architecture, from one, tool sets or code sets to another.


Ashish Rajan: Right. And would you say also the fact that to what you said about migration, that API calls are very cloud specific, but the logic, I mean, I, because the way I was thinking about this, like it’s like driving, whether you’re driving a left-hand drive versus a right-hand drive, it’s the same [00:28:00] outcome, but very different.


Like, you kind of have to change your, thinking altogether. Yeah. Mindset. Exactly. He’s like, if you’re an Azure, There’s a very different way of doing serverless compared to how you would do it in in AWS. And the serverless functions means it looks similar from the outside. Like the car looks exactly the same from our side.


Once you get in and start driving, oh, wow. This is a very different, I’m already used to right-hand drive or die or whatever. I feel like it’s kind of one of those ones. You really want the switch. It’s kind of as the question you would ask, but it’s a great


Ran Ribenzaft: question then. Exactly. Then in this real example, , from AWS to.


It’s three buckets and blob storage doesn’t work the same way. Costlessly B and dynamo DB doesn’t work the same way, events grid or event hub and SMS doesn’t work the same way. The serverless function, the signatures themselves doesn’t work the same way. So it’s a. It, it feels the same from the outside.


No, it’s serverless, it’s function as a service. It’s no SQL databases, API gateways, et cetera. But as you mentioned on the interior, it’s completely different than now. , how do I change my whole own, , from the outside, it looks the same, but from the inside, [00:29:00] everything is different. So we need to have colors and I need to have different, appliances and different furniture and different everything.


Ashish Rajan: Yup. Yup. And it’s a great question as well. Anything thanks so much for this man. Hopefully we answered your question. Cool. All right. I just want to make sure we answered all the questions. So going back to the fun section again switching, switch, switching our mind back to the fun question. The second question that I have is what is something that you’re proud of, but it’s not only a social media.


Ran Ribenzaft: I think the Alexa part that I’ve mentioned before, oh wait. Okay.


Ashish Rajan: You want me, you didn’t go into the story. So what’s the Alexis story.


Ran Ribenzaft: Yeah. It was 2016 or 2015. I visited the us and I think it’s the first time that the Alexa echo dot released back then there was a different Alexa, but then they released the echo dot and also started to release a framework to develop for it.


And as a hacker, I fell in love with the concept that I can speak to something and it will do whatever. , it’s like and I’m not, I’m thinking more of a, , how to automate API is like a, I’m getting every morning to see, , for example, when the bus is coming, why shouldn’t I ask, Hey Alexa, when the bus is coming or.


I know I had a lot of use cases or [00:30:00] buying


Ashish Rajan: something on Amazon or getting something delivered. There are so many years it’s funny because we started a second podcast called Clark security news, and that was actually inspired by Alexa. Cause my wife and I every morning, we’d just tell Alexa, Hey, what’s the new stuff?


So it will just go into this, like less than five minutes version of what the news so far was that from yesterday, like, oh, why doesn’t there like a cloud security version for this? So we made the Alexa version for cloud security news now. So this is the exact that it was all triggered by Alexa, but yeah, I think the whole concept that you just say something and it happens.


Ran Ribenzaft: Exactly. And when you, as an engineer, you can build your own things to say what you want and do whatever you want it to do. It’s a, , like an 8%. So , long story short, I bought this Alexa, I fell in love with serverless. I had a scale of a ambient sound like a, , let’s say a beach ambient sound or a rainforest or a, , whatever, which is nice to hear and relaxing.


It’s got. Hundreds of thousands of in vocations, really back then, I built software with scale, but it wasn’t as easy as that, I literally just, [00:31:00] deployed my phone. And it’s running with, , unlimited scale. I said, what the heck? Like, , how did I get to this point when I did this last time?


, it was a team of 20 engineers. We needed to run a lot of infrastructure and I’ll just that. So I really fell in love with that. And that got me into serverless and Epsilon then. The old story of me.


Ashish Rajan: Yeah. Awesome. Thanks for sharing that, man. It’s a great story as well. Cause I think it’s funny how technology has touched a lot of people and how, I mean, I guess that’s the going is obviously an example of, for now for you personally.


And Clark’s a great news for me personally, how, if the one thing has changed our life as well. But the last question, what’s your favorite cuisine or restaurant that you can share, like socio in cooking. It’s probably a perfect question for you. What’s your favorite cuisine or restaurant?


Ran Ribenzaft: I think I’ll go with something really traditional the Italian cuisine. I love the Italian cuisine, but the not fancy one. I love the like courageously original Italian. I forgot what the, like the naming, the Italian word for a


Ashish Rajan: restaurant like pasta or linguini or spaghetti.


Ran Ribenzaft: Exactly, but they’re really tallying grapes.


The Natalya, like the real Italian great [00:32:00] Trattoria. It’s like a family place that hosts and us really the great greatest materials. It’s not fancy. They’re not trying to do some fusion food, et cetera. It’s like , the best way that makes the pastor the best cheese that they, , got to make the sauce, the best tomatoes, the best And when it’s really done right.


Cooked, right. Simple. It’s really simple. When it gets more simple, it gets more delicious. So this is a kind of,


Ashish Rajan: I think you’ve, since you mentioned that sometimes simple Ford is the best as well, but we kind of seek like some kind of a experience when we eat food. Like this would be like 45 different flavors in your mouth, but sometimes it’s, I think a, a friend of mine she’s Italian, actually, she talks about the fact that she just loves a regular past.


That’s like, as simple as that, like great, I made at home and she loves that she would just cook that with butter and that was it. So


Ran Ribenzaft: I love that. So I really love a similar class state named Katya pepper cut to his cheese, pepper, pepper, and basically it’s pasta, cheese and butter and pepper. Like a ground pepper.


It’s [00:33:00] delightful. It’s like, it’s so tasty. It’s so flavorful.


Ashish Rajan: Yeah, I’m going to try that tonight. Then I’m going to try me and say, you inspired me on, but this is, this is a great episode, man. I’m so glad you cannot look at the time for this as well. I think everyone else enjoyed it as well. Thanks for coming in Martinez and thanks.


Thanks for this need. And for seeing up late as well, Zenith, appreciate filter the am as well. Where can people find you? Obviously I’m sure people would have serverless questions after this as well. And you being a soulless hero I’m sure you can come through the rescue. Where can people find you to be rescued by you from suffer ourselves question?


Ran Ribenzaft: So the best places would be LinkedIn and Twitter. I’m on LinkedIn, just search for my name also on Twitter, but also run rib. By the way, we just announced that Ethicon is going for free for everyone. So, yeah, for observability, as part of the acquisition, we managed to get it literally free. You get all the Epsilon offering for free.


So if you were having any monitoring questions or observability, there you’ll answer. No, you’ll get a real answer. A real solution for.


Ashish Rajan: Oh, I’m going to put a link for the link for that as well. So they go, you guys are already like a symbol of hero, making a thing free for [00:34:00] everyone to use as well. Big hero saved the day, but I’ll also, man.


I appreciate that. I’ll leave the links for your LinkedIn and Twitter on the show notes as well. But thanks everyone for coming in and I will see you all in the next episode or next weekend, and I’ll see you soon rent, but thanks so much for coming in, man. Thanks everyone.