E003: Unlocking the Power of Serverless Infrastructure

Sven Al Hamad (00:00)

Hi everyone, welcome to another episode of Enterprise Engineering, a podcast by Webiny, the content platform for enterprises. I'm your host, Sven Alhammed, CEO and co-founder. Today, we'll be discussing a topic about real-world examples of benefits that serverless infrastructure provides. And as my guest, I have Jeevan, the CEO and co-founder of Anstack. Jeevan, can you say a few words about yourself and Anstack to our audience, just so they learn a bit more about...

what you do and what Anstack offers as a service.

Jeevan (00:30)

Sure, Sven. Before that, thank you so much for recording this podcast with me. I know we have been working with Webiny for quite some time and this is the first time we got an opportunity to kind of come together.

So folks who are listening to this podcast, I am Jeevan as Sven introduced, I run Antstack. We help organizations to go serverless by helping them build cloud native modern applications or application modernization or even data engineering. We have been running the company for the last six years and I've been working.

than 50 plus companies across the world, help them test serverless and also help them build on top of serverless.

Sven Al Hamad (01:09)

Awesome. Thank you for that, Jeevan And then just to dive into the topic right away. So you've been in this space for many, many years, but going back to the very, very start, what was your first real world exposure to serverless infrastructure? And what problem were you trying to solve when you decided, there's this cool new thing serverless, let me go try it out and see if it's going to help me build this or scale this.

Jeevan (01:33)

Sure, the first very first question you asked is little personal for me and the story is little bit longer. So let me go back to 2011 and 12 where I was a DevOps engineer building and running EC2 based AWS infrastructure for an e-commerce company. I was the only DevOps engineer in the entire organization. And as we know, early 2010, 11, the...

where DevOps was fresh in the market, right? People were still trying to figure out whether is this a system admin job or a developer job. It took market and businesses some time to understand that DevOps is not admin or developer, it is actually the mix of both and that's the reason it's called DevOps, right? And I got married in 2013 and...

Ever since I got married, had, I got very little time to spend with my wife because I was always, you know, kind of panicking and anxious about whether my servers are running, my database is cool, my Redis memcache is cool and stuff like that. I have missed lot of...

great parties that I was supposed to be. I missed a lot of movies I was supposed to be. Wherever I used to go, I always used to carry a laptop with me because you never know things may, you know, bust anytime, anywhere. And I'm talking about EC2 before the security groups or before the VPC, right? We had just had security groups and we did not have the VPC mandatory to host EC2.

There was no auto scaling or probably the very early stage of auto scaling where it was still not good enough for us to use and we were scaling mostly based on the scripts. So that was my life for a good two three years and I always used to think you know why somebody has not figured out a solution for this why humans have to sit and manage machines because machines were supposed to do all the work and humans were supposed to enjoy the good time right.

That never happened with me. So I always used to think why somebody has not found a solution. Cut to 2019, my co-founder and CTO calls me one day and said, hey, is, you know, Jeevan, there is this thing called serverless, which I'm building a startup on top of that. It's a complete pure SaaS startup. And you know what? I'm just building with three, four developers. I don't need a DevOps team. All I have to worry is just...

focus on building the business logic and make sure it runs kind of bug free. I don't need a SRE team. I don't need a system admin team. I don't need a DevOps team to sit and look at monitors and look at graphs and you know uptimes, get page activity calls and whatnot. So I was like fascinated. I was like yeah, this is something that I always wanted in my life and thankfully somebody discovered a solution for my problem.

Let me jump on to that. And I had a lot of conversation with my CTO co-founder Prashanth and understood what serverless actually means. And that was the trigger point which I felt where I felt, you know, let me go out and help the world to build better.

applications without worrying much about infrastructure and give them some time to have with their families and friends which is much more productive than rather looking at tc2 instances and dashboards. yeah that was my journey and serverless is very close to my heart. It is quite personal also. So that's how I started my journey with serverless in 2019.

Sven Al Hamad (05:03)

That's quite a story, right? When you talk about serverless, usually everybody's talking about the cost it saves or the scalability, how fast it scales in and out. Nobody talks about, actually allows them to spend more time with my family and my friends, which is an amazing right thing, right? Because like, don't, as you said, you don't want to be running around with your laptop constantly hooked in.

Jeevan (05:19)

Actually, bro.

Sven Al Hamad (05:28)

to a Wi-Fi just to see how things are going or if it's burning, right? I remember one time I went to a concert with a friend of mine who was also a DevOps engineer. We had like five, six hours of driving and we had to stop every like two hours. He would pull up a laptop, connect to 4G over his phone to check if everything was alright. It was like...

Jeevan (05:37)

Mm-hmm.

Sven Al Hamad (05:50)

Dude, can't you just relax? But I understand, it's that type of world back then and luckily serverless freed up, I mean freed up. It did allow us to allocate that time to much more meaningful endeavors.

where actually you could help company grow or innovate much, faster instead of looking at charts and graphs all day. And when you go out and have your free time, you don't need to worry about it because of the resiliency that is built in into serverless. Awesome. And then when it comes to that actual first real world application that you started building on serverless or where you said, hey, this is a project for this project. We want to use serverless. Can you talk about that?

Jeevan (06:18)

Yes. ⁓

Sven Al Hamad (06:30)

How long was that and like what was the project about?

Jeevan (06:33)

Sure, so when we started off Anstack, actually our customers started Anstack and then we just incorporated it, that's how kind of it happened. when we kind of...

came to an agreement that, okay, let's create a company, let's start an incorporation where we can actually help companies to solve problems using serverless. It was just a concept in our head. There was absolutely nothing in the physical world.

As people say, when you aspire or wish for something, the universe will try to give you that. It actually happened with us when we were actually in the middle of conversation that we need to spin off an organization, incorporation and all. One of our first customers, they came to us saying, hey, Jeevan and Prashant, we want to...

build an application. We want you to kind of help us to build an application. But we want to build with Java and typical Kubernetes and with the legacy application, whatever you want to call it. And we got, you know, 14 months to build this.

And my CTO said, you 14 months is a too long time to build something today. This was in the early 2019 or late 2019. So we said, if you allow us, give the freedom and liberty, we would love to help you build this in just six months, probably less than that. With just three, four engineers, front end and back end mix of it. We are going to build it on...

serverless and we are going to use TypeScript, Node.js, React kind of platforms because

They were already running an application which was running the business. They were doing well. They had a team of 60, 70 people who were actually building, running, managing this application. And the VP of engineering did not want to build a second line of application in the same stack that they have already running, just typically Java, Kubernetes. They wanted to experiment with something new and latest and the greatest of all. And thankfully, that VP of engineering

was ex Amazon. So he knew serverless well and he said yes let's give it a shot. It was a field managed field service application for a telematics company and we could build it in four months with just three to four engineers complete back-end front-end, DevSecOps, CI, CD everything in place and they were blown away and we could

We did build this outside their existing engineering team and we were not dependent on their DevOps, their SRE, their system admin for anything. We just built it on our own because there is nothing much to provision or create per se. All you have to do is just write code, is, when your infrastructure is also a code, which is infrastructure as a code, right?

So they were blown away and they extended the contract and they asked us to build a complete product suite. So that was the beginning. And the rest of the customers followed on their own looking at our website because even today we have not done anything apart from serverless.

When we started off, said we will only do serverless. We will never provision, manage hardware, infrastructure, virtual machines, containers, clusters, whatever it is. Even for the day, we have been successfully managed not to do any of that and still write code on Lambda.

Sven Al Hamad (09:53)

That's amazing. And like, just thinking about going from like 16 months to four months, it is just the amount of time saved, the amount of effort and cost saved. And then not just that, this gives the customer 12 additional months.

on the market to sell, utilize and charge for the solution adding another year of revenue. This is just amazing, right? stories like that, they really...

Jeevan (10:14)

Yes.

Sven Al Hamad (10:24)

show the benefit of serverless and this commitment that you have within Anstack just not doing anything with regards to EC2 instances is a testimony that serverless can serve all of these needs. It can deliver and not just deliver, it goes way, way beyond than whatever traditional infrastructure can provide.

Jeevan (10:37)

this.

Yeah.

I would like to add some more points on just what you said. So if you look at it from a very far off lens, right? Why serverless is very personal to me and it should be personal for lot of other people is because cost is others, right? Somebody is spending, some organization is spending the money. It's not you that you are spending the money from your own pocket.

Complexity is somebody's problem at the end of the day when you quit an organization and go, right? So cost is handled by somebody, complexity is going to handle by somebody once you get out of that place.

But when you are there inside an organization, the time is the only thing that is yours. And you make sure you, you know, you use that time for the best of the things. Not to spend it on managing infrastructure, but to spend it with family, friends, and doing something which is more meaningful and useful, right? So, if you are a selfish person, if you respect your time, if you value your time,

you should be looking at serverless very seriously because ultimately cost and complexity becomes somebody's else problem.

Sven Al Hamad (11:51)

Bye.

True. I mean, when we started Webiny, when we picked serverless, it was one of those like, hey, we are engineers. We want to be engineering coding. We want to be creating features, right? We don't want to be creating the underlying infrastructure and worrying about that. We want to use all of that energy and effort and that time and invest it into building a better product and a better feature set, not the underlying infrastructure, right?

it is so much more beneficial when you free up that time and reallocate it to the more meaningful initiatives within the organization. And I mean when it comes to like some of those advantages so you sure does that

time-saving, faster to market. So these are like, let's say initial stages of the project. But once the project goes live, so from your customers, what did they see as the main benefits? Increase in reliability maybe, I don't know, was it the maintenance costs? Like what was some of their metrics and their feedback to you once you've delivered some of those projects?

Jeevan (12:55)

Yeah, before I get on to answering those points, one thing what I want to make very clear to all of us listeners is when you go serverless, obviously you are going to get locked up with the vendor. Basically, you will be vendor locked. Suppose if you use Lambda, you're vendor locked with AWS, right? And if you want to move to some other cloud, you end up rewriting it.

So the analogy here what I strongly believe I have been following is when you build something on a cloud provider, your cloud provider is not a vendor, he is a partner, right?

So when you create partnership, when you treat somebody as a partner, you look for long term relationship. It is like, say, your airline and your hotel reward points, right? You stick to a particular airline and no matter what, how inconvenient it is, you always try to fly in those that particular airline because you climb up the membership, you accumulate points later, which you can use it for your own.

purpose, right? And you also try to stick to a particular hotel group, may it be Hilton, Marriott, IHT, whatever it is. It may be far from the city, they may not serve you great breakfast, the rooms may not be bigger, but still you try to have a partnership with those hotels and try to kind of stay in those hotels so that you accumulate points, right? So even cloud is very similar to that.

when you partner with a cloud vendor, the more you integrate yourself, the better rewards you will gain in terms of cost, reducing the complexity and easy to hire, easy to build because you know what kind of engineers you want to hire. You know the technology yourself really well because you have been sitting on the technology and cloud provider for so long, right? Your knowledge of the cloud vendor or

cloud partner increases. So there are lot of advantages which comes with sticking to a one cloud partner. Of course, I will not discount the compliance part, especially in banking and finance where you have to spread your application across multiple cloud to reduce the risk and compliance and whatever. I completely respect that.

But how many of businesses are in that space today, if you compare, right? So that is one thing. And number two is the primary advantages is of course,

Cost saving, will say cost saving with a pinch of salt because I've seen a lot of companies doing serverless not in the so right way of doing it and incurring a lot of cost and blaming serverless as expensive. It's not for our use case, but if you do serverless the right way, it is going to massively cut down on your cost, especially running cost. And the time, the developer time,

which goes in provisioning your infrastructure. A very recent report by S &P Global, which published a report on serverless, it was actually, they worked along with AWS. Probably I can share the link with you later.

So a lot of time has been spent to provision infrastructure even today. Mostly 23 to 28 % of time developer time goes in provisioning infrastructure today, which can be used to watch a Netflix series rather than, of course. Yeah.

Sven Al Hamad (16:09)

Even that is ⁓ a better spent time as you said, right? And now imagine if you could

code at that same time, which is like...

Jeevan (16:16)

Yeah, Yeah, even if you don't want to code, you know, it's

a significant amount of time, which is mostly the quarter of the entire hour basically, because infrastructure provisioning. The second, the third advantage would be...

Rapid scaling without having the anxiety of, you know, will it scale, will it work because you are offloading the problem to AWS. Of course, you have to limit your quotas and, you know, increase the quotas. All these things are required, but you don't have to look at the cluster and get panic whether this is going to scale or not. Number three. Number four, which is very, very important, is very agile.

A lot of application which has been built on EC2 or Kubernetes today, they are not able to build new features on top of it because they have already hit a place where any single line of code you write and deploy, it's going to blow up the entire application.

because they built something and on top of it they have done monkey patching, monkey patching, monkey patching, monkey patching, monkey monkey patching. Because when they built something it was very traditional and monolith in nature and whatever the new features they tried to build was all microservices in nature. When you place a microservices or the bunch of microservices on a monolith, God bless. But serverless

default kind of enforces you stick to a microservices architecture so you can keep building, can keep adding new set of features without impacting at least not much of an impact on your existing features and set of application. And more than anything else now as we know we have to talk about it as a tradition, as a custom that the entire world is moving towards AI.

Building anything on AI is much more relevant and makes sense technically with serverless because obviously you run the AI part of your workload outside your application, maybe on a bedrock or your own hosting or probably chat GPT OpenAI, whatever it is.

So serverless is event-driven in nature. So you keep the model trained outside. You just do a request and response with that, which is an event-driven architecture and serverless makes all the sense. And lastly, when I say serverless, don't think about Lambda. Think about managed services where you are not sitting and operating it. You are just focusing on building it the right way.

So anything under this roof becomes serverless and also it should be scalable to zero. That's the P0 condition. Any managed services you take to call it a serverless, it should be scalable to zero and if you not using it, you should not be paying anything. You should be paying zero. That is called serverless at the end of the day.

Sven Al Hamad (18:55)

I agree, serverless is...

far beyond just Lambda, there's hundreds and hundreds of different services that fall into that category. I just want to thread back to a couple of other things that you mentioned. So first of all, like you're talking about the vendor lock-in. Like everybody keeps saying vendor locking is a problem, but everybody has a problem of demonstrating that problem, I find, right? They keep building these...

architectures that are more agnostic and they spend time, money, it costs them also in terms of degradation in performance, it adds complexity to maintenance, just so that maybe someday they can move away. But even like when they move away, they have to re-architect bunch of stuff regardless. So it's like, it's pointless. But on the other side, like, yes, for example, let's take a real world example, Apple ecosystem. It's completely vendor locked in.

And you know what? I love it.

I come home, my lights turn on, I'm listening to my music on my AirPods, I touch my Siri, it continues across multiple rooms, I can control my TV, even from my phone if I can't find my remote. Everything's connected. I'm completely locked in and I love it because everything's so seamless. It works and I have an amazing experience. I don't want to have 10 different operating systems and whatnot just so I can easily maybe move away. I don't want to move away. I'm happy with this.

it works perfectly right so yes serverless is similar to that but like even when you feel like locked in like i don't know i know when we write logic for Webiny right

All our code is TypeScript. It's not serverless code, right? Sure, it works on certain events, but these are like maybe outliers. This is my maybe 5 to 10 % that makes it sticky to AWS. And if you want to do cloud agnostic, it's those 5 to 10 % that we need to re-architect. It's not everything, right? but...

Also on the other side of like you mentioned things like cost savings, right? So people are looking at serverless in terms of cost savings versus things like, I don't know, Kubernetes and stuff like that. So Kubernetes and containers in general, how I found it is like people moved away from like traditional EC2 into these containers just so they can manage costs, but it's backwards compatible. And they said, okay, let's be there.

and then we're going to move the serverless to even further kind of like progress on that cost savings. But they kind of didn't make that next step, right? They got stuck on Kubernetes.

And the main reason is because, their legacy code works on Kubernetes and they still haven't found a justifiable reason to do more investments to move to things like serverless and similar until the pain becomes too great. then like we, that's when we get calls, right? Hey, we've got a bunch of content or we've got a massive database or something. Like we want to modernize architecture and can Webiny do that? Yes, it can, right? But they are only doing

that when they're pushed against the wall and then they're trying to again forcefully do that migration and that's where they rush into things they're expecting an experience similar to Kubernetes or EC2 but it's actually not it's very different and then they don't do good planning the cost explodes and then they find it service is not that good well I mean

If you don't know how to drive a car, you'll have a bad experience with a car. Same thing, right? Learn. Learn it, and then you're going to have an amazing experience. It's going to open so much more doors for you, right?

Jeevan (22:22)

as Vin Diesel says in one of the Fast and Furious movie, it's not about the car, it's about who is behind the wheels. So, yeah, yeah, yeah. So, another thing I want to add on the vendor locking and also on the modernization journey because this is my bread and butter and...

Sven Al Hamad (22:29)

There you go. Smart man. Maybe he should be designing some architectures.

Jeevan (22:42)

I talk to tens of people on a weekly basis on the similar topics. People who complain about vendor locking saying that one fine day they have to move out of their existing cloud provider to a new provider are the same set of people.

who have been saying this and not made that move to another cloud. And they have been sitting on the same cloud for more than five to eight years. And they're still complaining that what if one day I have to move, right? This is number two. And number one. Number two, when it comes to modernization, if you look at the technology evolution from data center to cloud, it took us a lot of time to...

commoditize or democratize cloud. From cloud to container, it was hardly seven, eight years of journey, or probably six, seven years of journey. And from containers to say Kubernetes-based clusters, it was just two, three years. And from Kubernetes to serverless, it is much shortened, right?

And now you look at AI from 2019 to 2020 to 2025, we have evolved so much. Like this is the fastest technology evolution era that we are living in. Right. I mean, things are changing every week now. And also, if you look at software, people who have built software 30, 40 years ago, it would last forever. And people who have built software around

15, 20 years ago, they have to modernize after 10, 12 years. People who have built software around 10 years ago, they have to modernize almost five, six years. Now people who have built like in 2015, 16, who have built the software or rather migrated to cloud, they are all going through this modernization journey now because they have realized they are no longer.

makes relevant because technology itself has changed. The underlying infrastructure has changed, number one. Number two, more than anything else, the business itself has evolved. So whatever the code they have written 10 years ago, 40 % of them is not even being used, but they are still spending money to run that code base and nobody is using it. And you are carrying more and more technical debt for the next generation, next year, next quarter, next week, next month.

So you might as well kind of get rid of that one fine day. So all good, good, yeah.

Sven Al Hamad (24:55)

You're

right on that. You're right on that. those, let's say, loops of technical, let's say, modernization, they are shorter and shorter. We see that. I mean, it also depends on some of the industries, but it's always there.

Jeevan (25:01)

Oops.

Sven Al Hamad (25:13)

Right? It's always there. You always need to be modernizing. Otherwise, you're going to fall behind. Your cost of doing business is going to be much higher than your competitors cost of doing business. Thus the competitor has more money to reinvest and capture a wider market? So it is, it is there. But I think like also it is, it is a double-edged sword, right? Sure. You want to be modernizing every year, but it's too costly at some. ⁓

Jeevan (25:19)

Yes.

Yes.

Yeah, yeah,

to costly.

Sven Al Hamad (25:38)

Too costly and you can also have maybe a big code base that takes a long time to modernize and by the time you modernize you're already out of date. This is currently the world of AI. If you do something in AI you're already behind. But I see that, I mean, when you look at the evolution as you said on-prem to cloud

Jeevan (25:47)

Yep.

Yeah, yeah.

Sven Al Hamad (26:03)

plowed to virtual machine that is virtual machine to container and then container to serverless.

What I find with, for example, in serverless world is the fact that I can modernize my code base much much faster using serverless than modernize my code base when I'm running containers because I don't need to do too many rearchitecting. I don't need to do too much. Like I don't need to break or pull apart the current setup that I have to put this new modern thing in. With serverless these things just click like a puzzle.

Jeevan (26:15)

Yes.

Sven Al Hamad (26:35)

and you can keep building it coming back to your comment of monkey patching old stuff right that is the world currently of containers where a lot of solutions just try to modernize by moving the same legacy code from a virtual machine or on-prem into a container well you kind of modernize but right now really there's a lot more that's on the table for you to

Jeevan (26:47)

Mm-hmm.

Sven Al Hamad (27:00)

pretty much grab and achieve the faster time to market cost control or whatnot. But, done.

Jeevan (27:07)

Yeah, you... Sorry.

So, you rightly said I really sympathize or rather pity those organizations today who are doing containerization in the name of modernization and thinking they have modernized, but they don't know... It's a ticking time bomb. I have seen...

This ticking time bombs usually explode between 18 to 24 months. I have a pattern for that. I have seen that pattern also. If you modernize, if you containerize today in the name of modernization, get ready to roll up your sleep, sleeves, have sleepless nights in the year of 2000, probably 27 mid to kind of...

modernize again, hopefully, you know, kind of the right kind of modernization. Not that time. And containerization in the name of modernization, according to me, you have a piece of garbage in a recycle-level plastic cover. You are just taking that garbage and putting inside a fancy box. But the garbage here is the same garbage here as well, right? Both the sides. So, yeah.

Sven Al Hamad (28:10)

Yeah, true,

true. like we also see with some of our customers in a way that some of them are using Webiny for like four years, five years, and we're still the most modern piece of technology in their stack, far ahead of any other other solutions that they're using. And they keep running with us because yes, we are bringing those benefits to them. We're bringing them that peace of mind that

Jeevan (28:22)

Yeah.

Yes, yes.

Sven Al Hamad (28:34)

the technology works. It's always reliable, it's always up and it's scalable. But let's flip the coin a bit. Let's talk about some of the most common misconceptions about serverless. What do you hear as feedback from people you're talking or from the market that are getting things wrong about serverless?

Jeevan (28:54)

First misconception is cold starts. Having worked with 50 plus customers writing more than 10,000 Lambda functions or rather 8,000 Lambda functions. Honestly, if you do it rightly, cold start will never be a problem, number one. Number two, serverless is way too expensive. Obviously, when you do it...

not so in the right way, it becomes expensive and it becomes, trust me, becomes way expensive than your EC2 as well. It's going to not just put a hole in your pocket, but it can actually burn down your entire wardrobe. It can be that expensive. And the second thing is serverless is not right for my work, my workload or my use case for some reason. So these are the three...

common misconceptions that I have heard when I speak to lot of people outside.

Sven Al Hamad (29:41)

Yeah, yeah, yeah. So I just had a, I was just recording another episode on the podcast where one of the company they moved the one of the largest e-commerce retailers in Turkey from from I don't know it was containers or EC2 to serverless right in e-commerce world like hundred milliseconds can cost you millions of dollars in lost revenue if it slows down. It didn't slow down because the world there's no problem.

Jeevan (30:02)

Yes.

Sven Al Hamad (30:08)

cold starts. That is a misconception as you mentioned. it's, think maybe a misconception, you like you publish a blog post on the internet 10 years ago, it was true, but it's no longer true today, but it still lingers. It's still lingers. It's like, hey, can you go and update that? That this is an out of date article, right? The second one is like the cost. The cost is, Soros does bring costs down, but as you mentioned earlier,

Jeevan (30:21)

Yeah

Sven Al Hamad (30:34)

it's about architecting correctly. I see once a month, I'll post on let's say Hikernyus, I don't know, I wrote a loop on my serverless function and now AWS is asking me to pay, I don't know, 10 grand. Serverless is not a child's play. It does scale infinitely almost, right? So be careful with it. It's great power and great responsibility.

but if you do it right, it will definitely be cheaper, right? Because like, I know when we are building stuff for Webiny, we're building architectures, there's a layer of, hey, does this achieve the performance? Yes. Does this achieve the scale? Yes. And one thing that nobody thinks about coming from the container or EC2 world is how much will this cost at scale? How will that cost scale per utilization, right? So we are architecting

and cost is one of the fundamental pillars when we say, hey, this solution needs to work like this, otherwise your cost will explode. Yes, there might be a more, let's say, elegant solution or solution that I can ship to the market sooner and cheaper, and it will scale, it will be reliable, it will work, but it's gonna burn a hole through your wallet.

That's one consideration we're always looking like, hey, can we do this much smarter? Can we adjust the buffer windows on how, I don't know, SQS is doing events on Lambda and whatnot, right? Because we want to optimize for that, making sure you get the best bang for your buck. And that, when you get that right, you really feel that savings that serverless provides. But if you get it wrong, of course, you're going to have a miserable experience with serverless.

Jeevan (32:13)

As I said, it's not only going to burn a hole in your pocket, it can bring down your wardrobe, probably it can bring down the house itself. So it can be that expensive. Yeah.

Sven Al Hamad (32:23)

Yeah,

true. But let's do one more question, which is, are there any scenarios where you would say no, serverless is actually not a good use case? I know you mentioned that one of the common misconceptions is when people say, serverless is not for my workloads. Are you sure? Of course. But are there really some cases where you would say no, serverless really doesn't make sense here?

Jeevan (32:45)

So when you have a long running, continuously running processes, that is when you may think about going with semi serverless like ECS, Fargate kind of not everything on Lambda. And also you have a very strict compliance. You come from an industry segment where you have a lot of compliance.

security measures and probably you don't have a language or a protocol to do those compliances with serverless, Lambda or any other services, then it makes sense. Otherwise, I don't see any reason.

why you should not use serverless. So far, having worked with eight industry segments, customers from eight industry segments, I have not found a reason why we should not do serverless. So when people say, know, hey, I don't think so, it's, don't think serverless is the right fit for me, I ask them one simple question. So that question is, if your application has

15 % 1.5 % quite time not downtime quite time like nobody's using it nobody no request no response just sitting like that you can close your eyes and modernize with serverless you will outrightly save 38 % cost on top of it

Sven Al Hamad (34:04)

Yep.

Jeevan (34:05)

15 %

quite time. So in a 24 hours day, if your application is not being touched for almost two and a half to three hours, which is most likely 2 a.m. to 5 a.m., 1 a.m. to 5 a.m., then that is something that you can actually.

go serverless and you can outrightly save some 33 to 38 % infrastructure cost.

Sven Al Hamad (34:35)

Yeah.

So, I know like when we started building also Webiny it was like we knew like, okay, Lambda, you give it an event, it processes it, it returns a response. And then like we went into a bit more challenging use cases. Hey, now I need to, I don't know, handle web hooks. Can serverless do that? Now it can. Then we went into, hey, I need to have a long running job. So it's like, yes, but what does the job do?

be

long running or does it just need to continuously run and doing some checks on specific timeframes like every minute, every hour or something like that. Like we found that every one of those use cases over time, you can handle very efficiently with serverless without doing work arounds, without doing any hacks. Now there are architectures and blueprints on how to handle that. And so far we haven't hit a wall.

at all with regards to any of those use cases.

Jeevan (35:30)

Yes, yes,

yeah, that is true. And the long running processes, especially in today's world, is purely bad architecture or a business planning because everything is event driven unless and until something gets triggered, you don't have to do anything. And whatever you want, you can listen. As you said, we have books. We have...

cron jobs to make it very simple. You can check every one minute, two minute, three minute, five minutes, whatever it is. And it becomes much easier to use this instead of just keep running an EC2 instance or a container. yeah, that's, so even I have not seen any workloads which would be long running so far.

Sven Al Hamad (36:10)

Awesome.

All right, think we've touched on a lot. And I hope we've shared a lot of valuable information with the community. I know a lot of them will still kind of say, no, containers work fine. Fine, fine. But keep an open mind. If you want to have a chat, we're happy to show you that there's a better world with a lot more power and scale. And you're to be a happier person because you won't be looking at up

time graphs and stuff like that. It's going to be a thing of the past basically. Awesome, Jeevan. So maybe any last words? Where can people find you? Where can people learn more about Anstack yourself?

Jeevan (36:46)

Yeah, so to know more about Antstack visit Antstack.com, A-N-T-S-T-A-C-K.com, Antstack.com. And you can find me on Twitter, Jeevandongre on LinkedIn, Jeevandongre. You can also drop me an email, Jeevan@antstack.com as well. I'll be more than happy to chat.

Sven Al Hamad (37:08)

Awesome. We'll also add all the relevant links to the episode in the descriptions so people can check that out. And for all our listeners, please subscribe. We have more episodes coming and I'll see you all on the next one. Jeevan, thank you once again for your time. It was a pleasure.

Jeevan (37:22)

Yeah. Thank you.