Serverless: slower and more expensive - <AUTHOR> http://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/ <comment><USER2> PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article:

1\. Don't use .NET, it has terrible startup time. Lambda is all about zero- cost horizontal scaling, but that doesn't work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go.

2\. Use managed services whenever possible. You should never handle a login event in Lambda, there is Cognito for that.

3\. Think in events instead of REST actions. Think about which events have to hit your API, what can be directly processed by managed services or handled by you at the edge. Eg. never upload an image through a Lamdba function, instead upload it directly to S3 via a signed URL and then have S3 emit a change event to trigger downstream processing.

4\. Use GraphQL to pool API requests from the front end.

5\. Websockets are cheaper for high throughput APIs.

6\. Make extensive use of caching. A request that can be served from cache should never hit Lambda.

7\. Always factor in labor savings, especially devops.

<comment><USER3> So, to summarize, you should:

1\. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system

2\. lock yourself into managed services wherever possible

3\. choose your api design style based on your orchestration system instead of your application.

4\. Use a specific frontend rpc library because why not.

...

I've hacked a few lambdas together but never dug deep, so I have very little experience, but these points seem somewhat ridiculous.

Maybe I'm behind the times but I always thought these sort of decisions should be made based on your use case.

EDIT: line breaks.

<comment><USER2> Think about serverless as framework-as-a-service. It has a learning curve, but if you buy in, it is an amazing productivity boost.

(If Reddit's video hosting being built and operated on a serverless stack by a single a engineer won't convince you, I don't know what will.)

<comment><USER4> 90% of Reddit videos are unwatchable for me : they start OK then the quality is downgraded to something unwatchable and there's nothing I can do about it.

I even tried to download them with youtube-dl but it doesn't work.

<comment><USER5> 100% agreed. The initial buffering time on them is ridiculous. I've started uploading to streamable and just posting that link rather than upload video straight to reddit.

</comment></comment></comment></comment></comment><comment><USER6> I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong.

"Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs.

You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework.

I have been experimenting with this approach lately and have been having some success with it, deploying relatively complex, reliable, scalable web services that I can support as a one-man show.

<comment><USER7> _> You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework._

At least I don't have to learn that complex "systems admin" stuff.

<comment><USER8> I am similarly, reading this list and wondering

<comment><USER9> One day people will rediscover installing a Linux box with an Apache server and call it novelty.

<comment><USER10> One day people will realise there is a Linux box behind Lambdas and you can run your own box in a basement a lot cheaper

</comment></comment></comment></comment></comment><comment><USER11> This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went:

Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!!

Me: What did you do about JVM warm up?

Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up.

 _... Me thinking: Uhh, but what about scale down to zero?_

Me: What do you do about pricing when your service grows?

Colleague: We use it only for small services.

 _... Me thinking: Uhh, start small and_ STAY SMALL _?_

Me: How was performance?

Colleague: It was on average 100ms slower than a regular service, but it was OK since it was a small service anyway.

 _... Me thinking: Uhh, but what about services who _depend_ on this small service, who now have additional 100ms times to comprehend with?_

Overall, I think his answers were self explanatory. Lambda seems to be a fast prototyping tool. When your service grows, it's time to think how to get out.

<comment><USER12> > Lambda seems to be a fast prototyping tool.

My thoughts EXACTLY. The great power in "serverless" architecture (i.e. AWS Lambda + AWS RDS + AWS Gateway) is how it empowers prototyping a new product.

Counterintuitively, it's future-proofing. You should know in advance that it's too slow & expensive. But you get to spin up a prototype backend very rapidly, pay only for what you're using while prototyping, and Lambda's inherent limitations force devs to build modularly, start simple, & stay focused on the product's main goals.

When the time comes to need scale, either at launch or even later when user count goes up, your "serverless" backend can be relatively easily replaced with servers. Then, just like that, in response to scale need your product's costs and response time go _down_ instead of up.

It's a nice way to build a software product: rapid prototyping plus easy future cost _decreases_ built-in.

<comment><USER13> I don't understand the prototyping angle.

Can't you just do something on your local machine?

There's stuff like dotnet new for .NET where I can just run that and have a skeleton project for a backend and I can start writing code immediately. I assume there's template creators for other languages as well.

<comment><USER12> My use case was a prototype for an iOS app I had in beta testing. It had a tiny but globally distributed user base, and serverless was a fun thing to learn on top of being relatively quick to set up. I'm sure if I had wanted to, some dynamic DNS and a small machine in my house would've sufficed. But hey-- that's future decreases in cost. :)

<comment><USER14> If you're doing a prototype, wouldn't firebase or AWS AppSync be better options? You're going to lose a lot of time dealing with devops tasks (setting up IAM accounts, configuring storage services, etc.)

</comment></comment></comment></comment></comment><comment><USER15> Something about the Lambda/FaaS/serverless hype reminds me of early 2000s enterprise Java, when everyone was trying to replace code with XML configuration.

It's obviously at a different point in the stack, but the promise is similar: "Just say what you want and it magically happens" — and indeed that's the case for FaaS when your problem is small enough. But XML-configured frameworks also offered that convenience for their "happy problem space". You could get things done quickly as long as you were within the guard rails, but as soon as you stepped outside, the difficulty exploded.

I'm not convinced AWS Lambda is all that different from a web framework, it's just on a higher level. Instead of threads responding to requests, you have these opaque execution instances that hopefully will be spun up in time. Instead of XML files, you have a dense forest of AWS-specific APIs that hold your configuration. That's how it looks from the outside anyway.

<comment><USER16> This is indeed a Pavlovic response :)

The promise of serverless is pretty simple, and pretty useful _for the right use case_ \- be it unpredictable load, or just very low load, or very frequent deployments, or pricing segmentation, or you don't have anyone as DevOps, and so on and so forth.

I don't recall anyone saying there's any magic involved. The premise is exactly same as cloud compute - you (possibly, depends on ABC) don't need to provision and babysit a server to perform some action in response to http request (or in case of aws lambda, other triggers as well).

</comment></comment><comment><USER17> Disclaimer: I work for Salesforce, Heroku's parent organisation.

I have had so many conversations with devops managers and developers who are individual contributors and the Lambda hype reached frothing levels at one point.

Contradictory requirements of scale down to zero, scale up infinitely with no cold starts, be cheap and no vendor lock in seemed to all be solved at the same time by Lambda.

Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for.

<comment><USER18> Heroku is owned by salesforce? You learn something everyday.

<comment><USER19> Yeah I actually didn't know that either. Interesting

</comment></comment></comment><comment><USER20> It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other _products_ that are often discussed on HN.

But let's be clear, we are talking about commercial products and there is a capital interest in _selling_ these services to all of us devs and engineers.

So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel that we should be MUCH more insistent in pointing out when a product does not make sense instead of jumping onto the hype train.

I am basically surrounded by "LETS TRANSFORM EVERYTHING TO KUBERNETES THIS WEEK!" exclamations, conferences are basically "DID YOU ALREADY HEAR ABOUT KUBERNETES?" and so on ...

It reminds me of Ruby on Rails, a mature and well-developed framework used by global tech firms (correct me if wrong: Airbnb, ~Stack Overflow~, Github) to handle parts of their backend in 2019. But for half a decade now even tiny companies have been screaming around about _FancyHTTPTechThisYear (tm)_ because scale while reporting 1/500th of the traffic of some famous Rails users.

This is not engineering with objectives in mind, it's more akin to the gaming community yelling for a new console.

<comment><USER21> > It's concerning how typical the hype machine is in IT.

Software engineering is still a young discipline. Probably half of the people have less than 4 years of experience. They learned from other employees that also had less than 4 years of experience. And that can be repeated for 10 generations of developers.

We are learning, and re-learning the same lessons again and again. Everything seems new and better and then we are surprised when it's not a silver bullet.

Software and cloud vendors do not help. They are the first ones to hype their new language, framework or platform. Technology lock-in is a goal for tech companies offering hardware or services.

> This is not engineering with objectives in mind

Curriculum driven development is a thing. And I cannot blame developers for it when the industry hires you and sets your salary based on it.

We need to be more mature and, as you suggest, think about our technical and business goals when choosing a technology instead of letting providers lock us in their latest tech.

<comment><USER20> > Everything seems new and better and then we are surprised when it's not a > silver bullet.

We need to live and breathe a culture that makes even young developers aware that this mistake has been done over and over until a growing collective of developers has recognized the pattern behind this.

After all, in the analogue trades even apprentices are taught many "don'ts" right from day one. Software engineering should not be any different.

</comment></comment></comment><comment><USER22> They're doing over 100rps if they're doing 10M requests a day. That's not a good use case for Lambda. If you're going to be that heavily utilized it makes more sense to run your API on EC2 or ECS/Fargate/etc.

Lambda is a good use case for when you have lots of not-often-used APIs. Lambda is a great solution for an API that's called a few times a day. It's also great for when you're first starting out and don't know when or where you'll need to scale.

But once you get to 100rps for an API, it's time to move to a more static setup with autoscaling.

<comment><USER23> I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Whereas starting with a simple, single container solution and organically evolving that into container-orchestration is much simpler - because the fundamental building block hasn't changed. It's all just containers.

Personally I'd like to see the industry coalesce on "serverless" containers rather than FaaS which are organised around functions being the fundamental blocks. Please just run my Docker container(s) like a magic block box that is always available, scales as necessary and dies when no longer needed.

<comment><USER24> > requires a complete re-architect of your stack.

Not necessarily. The reason I decided to try this was exactly because I found a tutorial showing you could easily host a bog-standard ASP.NET web app on Lambda with the serverless framework. I had to add a small startup class, and one config file to our existing app and I was up and running.

<comment><USER25> Recently we had to test a posibility of our core application being hosted in contenerized environment. It was really hard, because some tweaks we used are not really documented well. Kernel Tweaks had to be tested separately because we were not sure whether they work or not, recource management had to be done from zero level. JVM optimalizarion from zero level. Service Discovery configuration from zero level. \--- Sure it works from the go for punny small apps. But when it comes to huge corporations running extrordinary workloads - no its not that easy.

</comment></comment></comment></comment><comment> tedk-42 I disagree with all the comments posted so far.

This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with.

The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. Is it worth 8x the cost and 15% reduction in performance? The article argues no. If anything, AWS should price API GW and Serverless more competitively.

It's nice to see though that the Firecracker implementation savings has been passed down to AWS Customers.

If the article saw a 1.5-2 times increase in cost, the debate would be much more interesting.

I'm in the container camp because serverless isn't cheap and you can't have long running processes.

<comment><USER26> Exactly. Like anything, right tool for the right job.

I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month.

Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock up or go down, for whatever reason, creating chaos for the servers that needed specific jobs run frequently.

We switched to AWS Lambda functions for those cron jobs and they've never failed once.

If you're running a games website that gets pinged 24/7, don't use Serverless. But the notion that it's slow and overpriced is misguided if you're applying the wrong use case.

<comment><USER27> How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?

<comment><USER28> If you are comfortable with React, look at GatsbyJS. It is pretty amazing what you can build into a static site.

</comment></comment></comment></comment><comment><USER29> It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines).

Also AOT compiled languages like C# will run slower on lambda than pre- compiled on an EC2. You shouldn't need benchmarks to work that much out - it's software development 101. However you then went on to compare JIT compiled languages on lambda vs EC2 you'd notice the performance is much closer to each other.

You say tech should be about the results rather than religion and while I do agree there is a lot of cult-like behaviours in IT (and there always has been - emacs/vi, GNOME/KDE/etc, Windows/Linux/MacOS, etc) organisations that really depend on their services genuinely do load test their stuff to hell and back to ensure they are getting the best price, performance, scalability (where required) and resilience too.

That last point is also important when looking at infrastructure. Serverless often (though not always - you need to look at it on a case by case basis) offer you better resilience than rolling your own with EC2 instances. I mean sure, you can span multiple AZs yadda yadda yadda - it's all doable. But again you have to factor in spin up times and spare capacity (eg if you lose an AZ and then have 100% of your traffic over 2/3s of your existing hosts, are they going to have enough spare capacity to survive the spin up time of additional hosts or are you going to lose everything like toppling dominoes?)

Ultimately though, if you predictable traffic and don't have a requirements for redundancy then you could just host it yourself for a fraction of the cost of running stuff in the cloud. The real technical challenge isn't hosting though, it's all the edge cases around what needs to happen when your typical hosting plan isn't enough.

<comment><USER30> C# is compiled to an intermediate language (MSIL/CIL^) which is then JIT-ed.

The JIT cost actually adds a fair bit to the start-up time for C# code. This is why on the webserver there's an option to keep the C# code resident so it's always ready to go. In the past - before this option - it was common have scheduled jobs which pinged your webapp regularly to keep it hot :)

^ [https://en.wikipedia.org/wiki/Common_Intermediate_Language](https://en.wikipedia.org/wiki/Common_Intermediate_Language)

<comment><USER31> This to me smells like "things I shouldn't have to care about when using a serverless architecture". I would expect the serverless provider to keep my code fully AOT compiled in the fastest cold-start-format instead (wasn't ".net native" a thing?) of JITing things at the last second.

<comment><USER30> Unfortunately .Net Native doesn't support a lot of project types at the moment.

Serverless is all built around fully automated and managed containers, right? So it abstracts the whole runtime environment for webserver code. You use it if you don't have the skills/capability to run your own deployment/scaling pipeline.

The technology is a great 80/20 style leveler; I would highly recommend it to new developers and to people coming from a less technical background (such as design, marketing etc).

</comment></comment></comment></comment><comment><USER32> > To be honest I hadn't thought at all about the pricing beforehand. I just > figured "Pay for what you use" sounded like it would be cheaper than paying > for instances that are on 24/7.

Deciding to do a whole infrastructure change to save money without even stopping 5mins to do a quick math on the expected savings seems like a recipe for disaster.

Just switching from m1.small to t2.small would bring their costs down to $55 from $96 for the compute. Just make sure to create a monitor in case you use up all your burst capacity. Other than that a quick reservation would bring that down even further, and all of this with zero re-architecting.

Serverless is super cheap if your workload is not serving requests constantly. It's like renting a car 365 days out of the year instead of purchasing, it only makes sense if you only need it sporadically.

<comment><USER33> _> Deciding to do a whole infrastructure change..._

He didn't decide to do a whole infrastructure change. He just ran an experiment that was about more than just cost.

</comment></comment><comment><USER34> The pricing he quotes in the article he quotes _1350$ per month_. If you remove API gateway (which appears you can) , price is about _300$_ (from the article itself).

He never mentions what memory provisioning he uses for his lambda but he does remarks that he has 10M requests a day and that'll cost 10$ a day in lambda costs. Which comes to 0.000001 per request. That puts his service at 512MB memory at 0.000000834 (+ 0.0000002 per request).

If instead he used a 128MB instance (which is reasonable if your request is 3ms, but probably not enough to run .net core) you'll be at ~0.0000004 . Which would put it at roughly half cost. At about ~120$, which is the same as his server setup.

He did mention that he could cut his costs by reducing memory usage.

Seems like there's no reason why it couldn't match up to the server-side cost. I don't think the cost-benefit analysis is as bad as he makes it out to be.

Seems also like there's a very big mismatch in pricing here. If his workload is about 3ms per request but he is charged for 100ms a request, then that's a 33 fold increase in pricing compared to being charge per millisecond. Seems like quite an opportunity for some cloud provider to differentiate itself.

<comment><USER35> I looked at his site and he's pushing game state over websockets. I think he could eliminate almost all of his back end calls to his servers besides game initialization by using DynamoDB directly via Cognito, though the logic for proposing a move from one user and having it accepted in the game state by another user becomes an interesting problem.

</comment></comment><comment><USER36> I recently saved a company from serverless: development had completely stalled, continuous delivery was insanely inefficient (you couldn't deploy your set of functions at once because of dependencies), vendor lock-in made it a pain to develop locally (cognito in particular), CI testing was also a big pain (serverless-offline), the project also had reached the endpoint limit so basically they had to split the project (it wasn't even in production at the time ...) a dev implemented an aggregator for serverless config so that they could keep on working locally ... An epic disaster, we all thought there was no way this company wouldn't die, the founder developed suicidal thoughts and I could only understand him.

All my congratulations to the "Agile leading company" that provided a 800€/day consultant (probably going to read this) who just followed the tutorial to setup a new project on serverless without any web framework, because you know, "it's the future", and "i like to sleep at night", after they and some of the team had been brainwashed by an AWS event (my initial review concluded with "I admire the courage to start a project without a framework" which was replied with "what is a framework ?"). A waste of hundreds of thousands bucks, but that was not the only mistake : they had 100% code coverage from tests but all tests like all the runtime code was wrapped in huge try...except blocks, I have never seen a team talk as much about "Clean Code" and have such a pile of debt. The Agile company consultant called in recently and said they were sorry, that actually Lambda wasn't good for the use case, and that the consultant was now senior and twice the price.

The company now deploys with Ansible and Docker with compose and practicing what I call eXtreme DevOps (one ephemeral deployment per branch on branchname.ci.example.com), development is back on track, new versions every week... They also trashed the serverless code in favor of a Django Rest Framework app that I coded in 3.5 hours during a night after being there for 2-3 weeks (it was the 6th or 7th week that development had stalled "refactoring" "making lambda happ" "trying to have a local environment"), basically presented it to the team the next day at the retro (where we could see nothing creating value was actually moving forward) and said: make your serverless thing work, or let the frontend people choose what they want to build on : a backend code that became an unusable pile of debt or a backend code that works, presents a self-documented REST API, with an administration interface that they needed, and save the company by creating value instead of "just trying to fit into the proprietary framework that is serverless lambda".

<comment><USER37> Sometimes the right solution is just the easiest. Most of the time just is. Congrats.

<comment><USER38> Replacing badly executed solution A with well executed solution B is obviously a good idea, but adds nothing to the conversation.

<comment><USER36> AWS Lambda made both deployment and development a pain, even though the decision to use that platform for their use-case (a regular API) was just one of the mistakes done by a team that was brainwashed by expensive marketing and then paid the price for having only cheap and proprietary tools for development and deployment at their disposal.

If only AWS was open source, then we could have deployed our own cognito and lambda instances to develop locally, instead of the open source mocks that didn't pass the field test in my opinion: lack of quality, maintenance, documentation were critical factors.

</comment></comment></comment></comment><comment><USER39> I thought commenter W. Van Dam made some good points:

" First, you don't need API Gateways if you use an AWS SDK. Like this guide shows. And of course you don't need a load balancer, because that's precisely one of the things that serverless takes care of for you :-)

More importantly, you didn't actually compare serverless to your current situation.

With serverless solutions you can typically save cost in terms of server management. Serverless isn't maintenance free, but you should be able to reduce your monthly cost (e.g. lower labor cost).

You're right to research whether it actually works for you, but I think you're not done yet ;-)

Also, perhaps CloudFlare Workers are of interest to you. It's a rather new offer in the market. They charge 0.50 dollar per million requests, with a time limit of 50ms per request. Sounds like this combination would work well for you in comparison to AWS Lambda"

<comment><USER40> You can do the same thing with Lambda @ Edge and CloudFront for .60 per million requests and there is a free tier. ([https://aws.amazon.com/lambda/pricing/](https://aws.amazon.com/lambda/pricing/))

<comment><USER41> Workers are pretty significantly different. They don't have a meaningful cold- start time, for one.

<comment><USER40> Lambdas @ edge don't either. There are different optimizations than regular lambdas and you wouldn't use a heavyweight environment and of course they wouldn't be running attached to a network.

</comment></comment></comment></comment><comment><USER42> "Serverless", or "App Engine" as it was called for the few years prior the hype, actually delivers pretty good results for a range of parameters. It might even be a wider range of parameters than the ones where the results are subpar... Or not, I'm not sure how to weight the "I have a predictable base load large enough for its cost to dominate the other factors" vs the other cases. But as always - popularity of a tool is a poor predictor of fitness to particular job at hand.

<comment><USER43> App Engine is a PaaS, not serverless/FaaS

<comment><USER44> It's interesting how many still seem to (in this thread) believe you either have to run your own Linux servers in your basement or do FaaS (much better word to avoid the confusion), when there are many great in-between options.

</comment></comment></comment><comment><USER45> Our company has customers who install our SDK, and that SDK pushes and pulls data from our service.

We service ~400 million API calls per month. Half of the calls pull static cached data from a CDN (Cloudfront), and the other half ingests data pushed to it from the SDK (anywhere from 10kb to 400kb per call).

We run of Elastic Beanstalk, which is basically an abstraction later on top of an autoscaling EC2 cluster.

Back when Lambda (and API Gateway) first came out we were excited. It sounded like the perfect way to break free from our "legacy" server architecture.

Until you do the pricing calculations. It wasn't even close. Managed services like Lambda and API Gateway were prohibitively expensive. (Thank god we didn't begin development with the services before scaling - we would have never been able to scale at those prices).

Not only price, but performance was horrible. Lambdas take forever to warm up (unacceptable for latency sensitive use cases).

I've never really thought of Lambda / API Gateway as anything other than a cool pet toy. Although maybe thats being a little harsh..?

</comment><comment><USER46> This feels very "Serverless is cool, everyone is saving money on it, lets do the same"

> I only had to add a simple config file, add one dependency and one small > startup class to my existing API project.

This is not the way to do it, you have to spend some time on lambda approach.

Usually splitting up your code in to smaller chuncks so you don't end up with long spool up times and you can do things like keeping your lambda warm and caching high impact parts of the code. (sometimes of course you can't cache, I know)

Having gone through this process myself with a very very large code base, it would have not worked to just slap it into serverless.

Going server less can save you money, but not by just taking your existing app and throwing it on Lambda.

<comment><USER47> His application runs for a total of 3 ms. So startup time is not the issue.

<comment><USER48> That screenshot likely shows a warm startup; while they've improved recently, from personal experience .NET has the worst cold startup times of all the officially supported languages on Lambda by quite a large margin.

A source which supports that. [1]

[1]: [https://medium.com/thundra/the-fundamental-problem- solving-n...](https://medium.com/thundra/the-fundamental-problem-solving-net- lambda-cold-start-part-i-1ff4400bb6eb)

</comment></comment></comment><comment><USER49> I enjoy using AWS Lambda and believe it has many valid use cases. Unfortunately, Einar learned the hard way and hastily made a significant decision with regards to their architecture. To be fair, Einar admitted their faults in their decision was rooted in a lack of understanding in the AWS API Gateway and Lambda pricing model. However, a lot of comments are using this as a source to validate their opinions on why they believe AWS Lambda and AWS API Gateway is bad. Lambda is excellent for low volume, bursty traffic. It is not designed to be a solution for a web api that gets 300M reqs/month. It is technically feasible but fiscally irresponsible. Conversely, if going Serverless means you can get rid of a system administrator for a dedicated API server then that is a whole different situation where it would be fiscally irresponsible not to use serverless. With regards to the performance concerns, concurrent requests spin up concurrent Lambda functions. If you can limit the number of concurrent processes you _might_ actually see better performance with Lambda than you are seeing now.

<comment><USER50> lambda is perfect for high volume bursty traffic. you will never have to worry about a server being overloaded or going down.

</comment></comment><comment><USER51> Compared to EC2. If you went bare metal hosting, it would be cheaper and faster. But more work on your end.

The point of all these levels of abstraction is it takes less work to manage. Cost and performance is always worse.

<comment><USER52> Smoother scaling and lower entry cost as well.

It seems obvious that at scale, someone running machines for you could not be cheaper, unless they had access to technology allowing to operate at lower costs or cheaper electricity.

Renting can't be cheaper than at scale under normal circumstances. OP was beyond the breakeven point.

</comment></comment><comment><USER53> Serverless has it's place. If you have lots of events and they don't fire all the time it's great. Or, for small additive things on a mostly static site (like one hosted out of s3). Or for some other specific cases.

Serverless may change the landscape of development but it's going to take time. The costs need to settle into place while tools and processes need to come together.

Right now it appears it takes longer to build something with serverless, is more difficult to manage for day-2 deployments, and it costs more to operate for things like API servers.

I look forward to serverless doing a lot more in a cost effective manner. It's just going to take time to get there if it ever does.

<comment><USER54> Serverless may work well for sites that don't have a lot going on or don't have a lot of traffic. In our case, Serverless could not handle the number of requests we were receiving nor could it handle the small compute job we handed it (zipping image files and pushing them to S3) at any kind of scale.

Even if Serverless performs well for certain sites, I think it is too much of a pain in the ass to set up for local development and deployment. There are better technologies out there that provide easier development setups and easier deployments that can also handle greater loads and compute needs. After using Serverless for the past year, I'm having a really hard time finding where it might make sense. It certainly doesn't belong in our tech stack and I would never reach for it again personally.

</comment></comment><comment><USER55> A comparison of Serverless to any kind of compute that uses line-item comparison and, crucially, doesn't mention Total Cost of Ownership (TCO) of the latter is flawed.

To conclude that Serverless is more expensive one would have to compare the calculated TCO of managing EC2 against the line-item cost of Lambda.

The article is also operating at the small change end of the spectrum where cost differences are basically noise. Replacing the TCO of operating a thousand instances with the line-item cost of lambda would be an improved analysis.

<comment><USER56> This "TCO" thing usually comes out always from people interested in making companies migrate (i.e. consultants). Do you account into this TCO the time spent in retraining an gaining operational, production grade experience with serverless for all the teams involved? It's a one-shot cost, true, but it's a long one. And laying off perfectly capable employees because they are now redundant because serverless has a cost too (financial and emotional)

<comment><USER57> > Do you account into this TCO the time spent in retraining an gaining > operational, production grade experience with serverless for all the teams > involved?

Hopefully, or else it wouldn't be a total cost of ownership!

> And laying off perfectly capable employees because they are now redundant > because serverless has a cost too (financial and emotional)

No doubt. But if your capable employees aren't providing value outside of "keeping the servers humming" there's a very good chance that someone is counting up their fully loaded cost and comparing it to bids from Accenture, Capgemini or Infosys.

I'm fairly ambivalent on the whole push towards serverless but arguments like this feel an awful lot like the pushback against virtualization vs. running bare metal.

<comment><USER56> > No doubt. But if your capable employees aren't providing value outside of > "keeping the servers humming"

But you would usually consider serverless to need _less_ people to manage it. So, even if they all work hard, someone will be not that useful one day or another. Anyway I really don't see all this fuss about doing more with less (or doing more with the same) going serverless if you are already using infra as code and have a 100% automated CD/CI pipeline.

A greenfield project? Totally! But in an established org with good practices? Dunno.

</comment></comment></comment></comment><comment><USER58> As I understand it, the author conducted the test on an unusually slow connection. With a roundtrip time of almost half a second. Even a typical consumer line is multiple times faster.

He states that the workload is "saving one event to the database".

And then sees 0.42s for his old solution and 0.48s for the serverless solution.

Even if the server waits for the event being written to disk before it answers the request - that should be a negligible time compared to the roundtrip time he sees.

So the "15%" only hold for his very slow connection. If he repeated the same test on a faster connection, then it could turn out the serverless architecture is not only 15% slower but multiple times slower.

If 0.40s of those "0.42s vs 0.48s" he sees are due to his slow connection, then on a fast line it would be 0.02s vs 0.08s. Then his conclusion would be "4x slower" instead of "15% slower".

</comment><comment><USER59> > For us it would have been better if we could just put a normal load balancer > in front of Lambda.

This can be done.

[https://aws.amazon.com/blogs/networking-and-content- delivery...](https://aws.amazon.com/blogs/networking-and-content- delivery/lambda-functions-as-targets-for-application-load-balancers/)

<comment><USER60> Yes, it would be a much less dramatic headline if they'd used an ALB instead of an API Gateway, it shows the complexity of the AWS product offering though that someone picking up lambda for the first time didn't find this out.

They already have a classic ELB in place, so switching to an ALB wouldn't be a significant change in cost or capability (the ALB is often cheaper, though it's hard to tell in this case)

<comment><USER24> Yes, ALB would have been a much better fit for us. We used API Gateway because that's what the serverless framework sets up (at least by default) and I didn't know you could use ALB in front of Lambda.

<comment><USER60> Yes, it does show there's a gap in the documentation, hopefully someone from AWS will pick this up (and the serverless framework has only just added ALB support a couple of months ago)

</comment></comment></comment></comment><comment><USER61> In AWS it is better to use Fargate. You can use standard docker containers with Fargate, you do not need to baby sit and patch servers. Fargate has warm caches in comparison to Lambda. Also it is easier to version control a docker container vs serverless functions. Plus if you do not like Fargate you can move, if you have written everything in proprietary Lambda code you are locked in.

Performance comparison between Fargate and Lambda. AWS Fargate Deep Dive [https://www.learnaws.org/2019/09/14/deep-dive-aws- fargate/](https://www.learnaws.org/2019/09/14/deep-dive-aws-fargate/)

</comment><comment><USER62> A $10 VPS would've been enough to handle the kind of load his site sees too, which is about 15x cheaper again than AWS.

If you're really looking to save money, don't touch AWS.

Source: I run the frontend for an interactive "one-page-app" site about 3x larger on a $30 VPS with room to spare.

<comment><USER63> Which VPS provider do you use and what is your backend stack?

<comment><USER62> The frontend is a ~$30 bucks VPS with OVH. This thing serves about 2 million users / month and about 20k concurrent users (with persistent websocket connections etc.).

The backend is:

\- $10 VPS with OVH + $10 VPS as a fallback with another provider for my DB. \- $5 VPS with OVH to host my central debian package repository.

\- About $500 worth of dedicated servers for serving hundreds of TB of files a month (usually below one petabyte though). This is not really relevant to this discussion, because OPs application doesn't have a file serving aspect to it. His application is basically just my frontend and a DB.

\- Small files and thumbnails go through cloudflare for another $20 / month. But the main site and most files don't use cloudflare (they'd kick me out if I passed that kind of traffic through them). They serve about 30TB-70TB of traffic a month on my account.

</comment></comment></comment><comment><USER64> Lambda is cheap, API Gateway is expensive. Lambda with API Gateway should be used for low or unpredictable volumes.

You can replace API Gateway by an ALB, which will be much much cheaper in the article use case.

Lambda is also great when it's triggered by everything but API Gateway. Analysing a file uploaded on S3, reacting to an SNS message or consuming messages in SQS.

</comment><comment><USER65> My take on AWS Lambda is that it is the perfect glue code to automate operations between different AWS services, but not really something you want to build your entire application on. Especially since you need to make Lambda- specific optimizations in your deployed function to get good a good performance/price trade-off.

</comment><comment><USER66> The AWS bill seems high already. $90 dollars for m1.small, which has 1 vcpu and less than 2GB memory? At my current hosting provider that machine costs less than 5euro! What am I missing? Looking at the hourly usage it seems to be the equivalent of 3 machines running 24/7, so 15 euro, but still?

<comment><USER67> It's not just a single instance. Look at the hours billed.

<comment><USER66> That's why I multiplied by 3.

</comment></comment></comment><comment><USER68> 1350$ per month is still fraction of salary of developer. So if it saves you that fraction of your (or your colleagues) time, it is definitely worth it.

<comment><USER69> 1/10 and 1/100 are both fractions. If 1/10 of the salary of a developer is saving 1/100 of that developer's time, you lost. Fractions are not equal, blanket statements about fractions are not good business practice.

<comment><USER68> that is why I wrote "that fraction", hoping that it means that its the same fraction.

Though, your example still does not mean you lost. that 1/100 time is time that developer is not working on something else, that might be worth much more (though if ita 1%, its less likely. but my point is that developer time is more valuable than proportional amou t of his salary).

</comment></comment></comment><comment><USER70> I don't understand the term or brand "serverless", to me it seems it's still using a server, meaning a fast computer somewhere running 24/7 in a datacenter.

To me "serverless" implies decentralized networking, with a DHT or some kind of network authority, meaning P2P networking at one point or another.

Am I missing something?

<comment><USER71> "Serverless" is "I don't have to provision a server, or worry about where it is, or maintain it, or what OS it's running, or any of the other fiddly details."

You define a function, you hand that function to a company, and they make sure it runs when certain conditions are met. You then don't have to worry about the server.

<comment><USER72> I think the problem is that these terms had meanings before the last five or so years. There are setups that are actually accurately describable as "serverless" \- for example, SQLite is called a "serverless database" because it's an embeddable library that just operates off a file as opposed to client- server DBs like Postgres or MySQL.

<comment><USER73> Yeah. See [https://www.sqlite.org/serverless.html](https://www.sqlite.org/serverless.html)

</comment></comment></comment></comment><comment><USER74> > Finally, I'm not trying to bash API Gateway, Lambda or serverless in general > here...

AWS API Gateway should be bashed because it truly is shoddy.

</comment><comment><USER75> While there is a lot of lambda/serverless hate in this thread, I (who have no experience with it) am reluctant to conclude based on this alone that lambda is useless/stupid. Need more info.

Is there anyone who has had success using lambda, or can anyone find a write- up of a success story?

That would help me (and others) understand/believe better I think; if it's a very rare case where lambda ends up being helpful (which is the opinion of this HN thread apparently), a case study write-up of a real world success story would still help us understand when we _aren't_ in that situation.

<comment><USER76> For my organization, Lambda has been instrumental in allowing us to take some highly trafficked, small API services, and migrate them from NodeJS based servers that we manage to Lambda and Application Load Balancer that just works with no involvement. We're not relying on the API gateway (which is expensive and better suited for non-public APIs).

Many of these APIs are Ajax type status updates, JWT issuers, authentication handlers and other utilities. We use the serverless framework to deploy the code, and it works very nicely for us.

The hate is real in these comments, but for us we are able to move 500 million+/month API requests with minimal code changes, easy scaling up and down, and we were able to learn a little something about serverless architectures and their viability for other possible things in the future.

<comment><USER77> How did the cost profile change? You can include reduced labor costs if you want.

</comment></comment></comment><comment><USER78> I disagree with most of the comments here.

Right now, you can build much much quicker and with a less skilled team using serverless than traditional servers. This is very very important.

Serverless is not static and stuck in time, it's going to change and become cheaper over time as competition increases. Pretty soon everyone except already built products and large businesses will be using serverlesss architecture. The barriers to entry of building a website will be so low, you would be an idiot not to use serverless.

<comment><USER79> I disagree with your comment. Not every workload is well suited to serverless, and there will always be companies who have both the infrastructure and knowledge to _not_ use serverless.

</comment></comment><comment><USER80> If you have predictable load and constant expenses then yes, lambda should cost more than EC2 ondemand, and hardware hosting should cost less than cloud. You started development on AWS, but once infrastructure become static and all tasks well known, you can migrate and find the same of even faster hardware for almost half price. Cloud gives you a lot of flexibility, serverless make flexibility almost unlimited, but it should have its price.

</comment><comment><USER81> There are valid points in the article. But the author seems enraged that he is charged $35 for 10M API calls per day (his main complaint). He knew (or should have known) that he needs in the ballpark of 10M API calls per day and the pricing explicitly calls out $3.50 per million API calls. This may or may not be a lot (probably is), but he should not be surprised. Before any purchase, check the price. My 2c.

</comment><comment><USER82> Building out MVPs for very ambitious clients, I'm so glad to be working with Serverless to manage my lambdas. I'm able to test locally and deploy in seconds, it's the most efficient dev setup I've ever had.

<comment><USER83> I think the issues with serverless are when you grow well beyond the MVP stage and are pushing a production load. I'd recommend doing that cost analysis for your clients.

</comment></comment><comment><USER84> Serverless is good for doing extreme parallelism. You can literally have 5,000 CPU cores working on your task in seconds.

You can't do that with EC2 nearly as easily or cost effective.

This is where serverless really shines. If you have a fixed static load, you should be using the cheapest available compute instance from EC2 as possible. Reserved instances & test performance in lower cost data centers.

</comment><comment><USER85> > I guess it's because Lambda has built in support for .NET Core (only 2.2 > though), whereas in Beanstalk it's only supported if you use Docker and > manage it yourself.

The article doesn't mention this, but I this makes me suspicious that the ELB and Lambda version might be running different versions of .NET Core, which could explain part of the performance difference.

</comment><comment><USER86> I meant to say this in another post I saw the other day about serverless. Serverless is mostly hyped up by marketing sure. But the benefit is not in just running a Function as a Service.

The real gem of Serverless is that if you're using a cloud say for example Microsoft Azure (I'm just more familiar with their offering) you can have events triggered when: a new file/blob is added to your Azure Blob Storage. Another case and I know there's likely a none cloudy way of doing this: when new records are inserted into a database you can run a function. It's cronjobs on crack that will only fail in your code usually, I've never seen a failure of an Azure Function getting triggered, can't speak to other cloud providers offerings.

Yes I agree, it's a lot of marketing hype, and it's even dumber IMHO that they emphasize on the RESTful aspects, and not the useful cronjob like aspects that save you time on figuring out when and how to work on something as it hits your cloud.

</comment><comment><USER87> I was ready to look past the title as just the cost of doing "business" in 2019, but the article has a lot of problems. Stuff like measuring latency from 1 computer in Iceland -- gaining empirical results from your actually running user-base (logs & analytics) would be a much better test, as it is you can probably effectively ignore that part of the article because that's not an effective test.

8x multiplier on ~1K a month ignores the actual value proposition of serverless. Which is that you're not spending staff hours designing, building, and maintaining scalable infrastructure. If you don't have scalability issues (which at 1K a month, you don't), then it's maybe not the right technology for your use case. If you do, then maybe it's the right technology -- yeah you're paying more but you gotta do the math on what you'd need to build and then discuss tradeoffs with the business. Classic technology cost analysis, this is not new.

</comment><comment><USER88> Treat serverless like another thing in your toolbelt. With Zappa, Julia, Jets, or any other platform that lets you use classical web server code to host a Lambda with API Gateway, you're getting the flexibility to inexpensively deploy new services and evaluate their utility ahead of having to go through the full exercise of productionalizing a service, purchasing reserved instances, or any of the other heavyweight stuff you may normally associate with rolling out a service.

I'd also like to point out that Lambda is _a_ serverless option. Fargate is another. I've worked with infrastructures that use ECS + Fargate in cases where a real long-running server is a better spend than millions of lambda invocations. In other words, there's definitely a right-tool-for-the-job consideration to be had here.

Working with new tech is always a learning experience, and it's nice to see concrete numbers about what was learned.

</comment><comment><USER89> This is all true, but serverless is wonderful for light tasks that aren't run very often (it's basically like cron jobs for your cloud setup, without having to bother with machines) or for moderately used APIs. Spending cents instead of having a dedicated server for such stuff is very nice. So it has a niche where it excels.

</comment><comment><USER90> It is a great apples to oranges comparison. If you do not take into consideration that somebody has to setup and manage the instance that runs 0/24 and you do not care about availability (single instance can go down easily) then you might even say that you are comparing apples to apples.

<comment><USER24> The alternative to serverless isn't "single instance". With Elastic Beanstalk you can have multiple instances, autoscaling etc.

</comment></comment><comment><USER91> If your workload isn't sparse, then AWS Lambda has a complimentary service called AWS Fargate built on the same tech designed for more predictable workloads). Here's a comparison with AWS Lambda [0] and a crash course in setting up a load balanced web app on it [1].

[0]: [https://read.iopipe.com/how-far-out-is-aws- fargate-a2409d2f9...](https://read.iopipe.com/how-far-out-is-aws- fargate-a2409d2f9bc7) [1]: [https://read.iopipe.com/how-far-out-is-aws- fargate-part-2-e8...](https://read.iopipe.com/how-far-out-is-aws-fargate- part-2-e87088f3ee26)

</comment><comment><USER92> Serverless makes a lot of sense if you are paying the system administrator. Most of the cost for running servers I've seen is the support of those servers. Whether it's paying DevOps or a SysAdmin team. However I found it was much too slow to meet SLAs. It takes time to provision lambdas on demand. Then again we did our POC back when Lambda first came online. I think now you can pre-provision tasks which makes things a lot faster.

Lambda meets the requirement of being very low maintenance, reactive, and scalable. I'm not surprised they are charging a premium for it. You don't have to pay multiple $100k sys-admins to keep it running.

</comment><comment><USER93> "Serverless" is basically yet another manifestation of the fact that (despite recent controversy about, well, him being weird) Stallman was right about open-source. The alternative to serverless - open-source products like Mesos, DCOS, Nomad, etc. - offer the same functionality to engineering organizations at lower cost with vastly more pleasant (and manageable) support for things like CI. It's been a great money-making scam for the "cloud" companies though. "Serverless" is closed-source by nature, and it will never be as efficient as open-source solutions.

<comment><USER94> Tell that to [https://github.com/apache/openwhisk](https://github.com/apache/openwhisk) , [https://github.com/knative](https://github.com/knative) , etc.

</comment></comment><comment><USER95> Lambda is too expensive at the moment, sure. But I think we all know that the costs will, over time, go through the floor, and in 5 years time nobody will want to create server software using anything else.

<comment><USER69> Predicting the future is a job for fortune tellers, not developers. Being sure about what will be the cost in 5 years is beyond fortune telling. Based on what I know, my company will continue to have on-premise servers and all the companies in the sector will continue to do the same. "server software" is not just Internet software, the world is larger than that.

<comment><USER96> I disagree. Whether it's a good design depends critically on what the future holds. Will costs go through the floor? We should, and can predict this.

What does it cost to host lambdas? Not a lot. So we are good from that PoV.

Will it be commoditized, or will there be crazy markups? Can any random guy set this up? If you really want to check this, try setting one up yourself and see if there are any roadblocks. (I didn't)

</comment></comment></comment><comment><USER97> Related: Hellerstein et. al's paper evaluating the limitations of serverless frameworks for different use cases. ([https://blog.acolyer.org/2019/01/14/serverless-computing- one...](https://blog.acolyer.org/2019/01/14/serverless-computing-one-step- forward-two-steps-back/))

tl;dr FaaS lifetimes, lack of cache locality, network rates and isolation make serverless platforms great only for embarassingly parallel, short-lived, I/O-bound tasks that don't require high performance and are only occasionally run. Anything else will be more expensive and slower than just maintaining your own server.

Lambda thus would be perfect for irregular batch jobs or orchestration tasks. Trying to serve an API isn't advisable because of the low-latency requirements.

On a tangential note, AWS Lambda is actually insufficient to serve an API by itself - you also need to use AWS API Gateway to serve incoming requests, create your own route tables and dedicated subnets if you need to allow VPC access, enable Cloudtrail logging and monitoring (very limited), and add IAM rules to allow all of these to interoperate. It is _not_ a turn-key solution by any means.

Add to this the limits on deployment artifacts (50 MB max), and you've basically done all the work needed to launch your own EC2 instance in its own subnet and availability zone, but resulting in something with smaller capacity and worse observability.

Use a server, dammit.

</comment><comment><USER98> I'm personally not a big fan of "serverless", but I think this article is a bit unfair.

First off, API Gateway might not have been the best choice here; an ALB would probably do the trick for this use case and be cheaper. Debatable if it's fair to include API Gateway in the cost anyway; Lambda is really the "serverless" bit here, but I guess Lambda by itself isn't all that useful if you have no way of invoking it.

Beyond that, they're pushing "slower and more expensive" as a sort of indictment of serverless, that it's worthless. It's a trade off. You're trading price and performance for someone else managing the infrastructure for you. For some people that might be a reasonable trade off, and for others it might not.

Put another way: serverless is more expensive than EC2 -> EC2 is more expensive than a dedicated server -> a dedicated server is more expensive than buying your own and racking it -> etc.

Well, yeah, that's only all true if you only consider the narrow band of cost that you've cherry-picked to be relevant. Obviously buying your own server and racking it has other costs than just the server and the colo space, managing an EC2 instance costs more than just the per-hour rate AWS charges, and so on.

</comment><comment> oh-4-fucks-sake At the end of the day, it all comes down to usage patterns. It often makes total sense for low-volume tasks to be processed by Lambda. If your company only has low-volume usage, or even just bursty usage, then Lambda is a slam dunk.

Now, say your company has a mix of low-volume and high-volume tasks--sure, you could comingle your low-volume work use some of the cycles from the high- volume workloads--e.g. add some endpoints to your high-volume application that handles low-volume tasks. But, isn't this trending towards the monolith of yesteryear? Which, is fine, I guess--monoliths aren't pure evil--but with microservices and serverless we've finally been able to apply the tried-and- true design patterns of separation-of-concerns/do-one-thing-well to entire applications (not just to little utilities and libraries).

The point is, there's nothing wrong with embracing the right-tool-for-the- right-job and using a mix of infra strategies is often what's best for an org. You don't have to go all serverless, nor do you have to go all containerized. Let your big-dog 24/7 high-volume applications do their thing in Kubernetes and let your one-off admin tasks spin up for 100ms and die and not bother anyone else.

</comment><comment><USER99> There are many even-handed comments here. But I feel a few might be influenced by "relief bias".

As in:

> phew! that Serverless stuff turned out to be pure hype, lets dump on it and > destroy the hubris of human-kind

But that is just not the case, serverless is a legitimate option. I've seen it work (increasingly well) at various companies.

I will also say, I'm loving the comments here that are trying to boil down the core-principles to follow to achieve serverless success. Great stuff.

</comment><comment><USER100> One question, which is puzzling me:

\- there is a company which provides you with IT administration, which you trust it cpu management, memory management, network management,...

\- in most cases (not all, but in most cases), you are developers not system administrators

\- you dont have resources in term of hardware budget (in form of multi year plan), network budget, human resources budget, own knowlidge budget,... to set it up as a single man / company operation

Why do you believe, that some company that offers you all those "favors" would make it cheaper than if you wouldnt lack those topics? Even more as there is a huge mountain of knowlidge/time/money/... you dont have?

If I were them, I would spoil everybody to the point where developers wouldnt know what ip is, run operation on my own expenses and then raise up the prices a lot. And I dont think I am much smarter then "them".

To me it is dead simple. Same as all the cloud topics. It is a reasonable trade off, the companies are offering you a "favor" for money in same way that you do it customers.

</comment><comment><USER101> We had a requirement early on in our org where we had to split off long- running tasks to run asynchronously, while remaining painfully easy to test and deploy, configure, or swap out, as our dev team was not very comfortable with new technology and we had to move fast.

I looked in to Serverless before, and decided, then and now, it was wholly unnecessary, and I don't know when it will ever become necessary for our org. Azure already had what was necessary - Webjobs. I set up a simple event framework, drop some events into a DB, which get processed asynchronously by some Webjob. It's easy to run on local as it's just a console application, gets pushed to CI and again, is just a console application so it tests the same as other projects, is easily scalable, configurable, and it uses no new technologies.

I always look to see what pre-existing technology or paradigms are already existing that can accomplish the solution, and I found that serverless, in the idea the cloud providers employ it, is usually unnecessary

</comment><comment><USER102> I think we you implemented a solution you never know which way is cheaper until you see the bill. Then it really becomes the chicken and egg question. Will you decide to go serverless is whether your solution will be very complicated one day. If the solution is simple already then you won't get too much benefit from serverless.

</comment><comment><USER103> Lambda is not suitable for certain workloads. It's impossible to know what is the problem in this particular case from the details provided by the author. I can give some common examples where Lambda would NOT work well:

* if the code you run has heavy initialization phase that could be amortized across multiple runs. Lambda is not a god fit because you'd do initialization for every request. Cold start latency compounds with code initialization to make the problem worse

* if the function workload involves lots of waiting for network I/O (REST APIs, lots of database calls, web crawling). In this case you'll be paying for each lambda function to wait for the network, while if you run the same workload on a single machine it will be cheaper because you can wait for many requests in parallel in different threads without consuming much resources.

Having mechanical sympathy for your workload does help.

</comment><comment><USER104> For decades I'm paying $80/month for each 2U dell poweredge R815 with 1TB of RAM and 48 cores, hosted in a datacenter with redundant power. I'm sure it is fun to play around with all these expensive services Amazon offers, but when you see the billing side of what they do, its not really worth it.

</comment><comment><USER105> Lambda is the recommended way to host an Alexa Skill:

[https://developer.amazon.com/docs/custom-skills/host-a- custo...](https://developer.amazon.com/docs/custom-skills/host-a-custom-skill- as-an-aws-lambda-function.html)

<comment><USER106> It's the perfect use-case for it tbh. If you read the comments here, the pricey part of Serverless is API Gateway. With Alexa Skill development the Alexa service triggers your lambda directly, bypassing API Gateway. So it's really super cheap. I have built numerous skills and my bill is literally $0.00. Alexa also gives you $100 credits per month if you build & publish a skill..which is also free.

</comment></comment><comment><USER107> Thank you for writing this! It's always interesting to see how other people set up their stacks.

Recently, I created some twitter bots to test out for fun and put them on Lambda with a 12 hr schedule to run from SNS... I was sending 15 tweets a day (from ~15 accounts) and my bill was $35/mth... That is silly

<comment><USER49> There is a lot to ask here. There is no way you are operating outside of the free tier based on the description you provided.

</comment></comment><comment><USER108> A big part of the savings would come from reducing the operational overhead of managing instances. Serverless is turnkey and doesn't require any ops personnel, or skills. Even k8s requires a lot of TLC to get proper scaling and do upgrades and rolling deployments without downtime.

</comment><comment> nevi-me Yes, there's probably benefit in using functions/serverless, but other than for a few endpoints where spinning an always-running VM/container/server, I've also always questioned their value.

[Anecdote time]: I've seen a product team (of otherwise clueless people) design their whole product around a serverless architecture. In one instance I heard them trying to 'solve' the authentication on each connection problem, where they could have kept connection state and authenticated a user with cookies or the like.

Assuming that some would pay for the slightly slower and more expensive serverless option; is the touted goal of scalability better than n well- optimised instances of a service, where n = 1 for most of the time?

</comment><comment><USER109> Server less seems very case specific. Either it works for your model or it doesn't. And if it doesn't then its a lost cause given the inflexible nature of the limitations. Its not tweak able in most cases

This just reads like a casestudy where it was not the right answer.

I also think people giving others flak for "abusing" the free tiers are missing the point. The free allocation is there to be used. Sure don't go create 5x fake accounts but to me structuring your app to stay within limits is a very reasonable proposition

Its not like the cloud provider is getting screwed - they want as much mindshare to their ecosystem as they can get.And someone learning and deploying their tech gets them quite far on that

</comment><comment><USER110> There is one crucial piece of data I was unable to find in the article, what memory size was Lambda set at?

For those unfamiliar with Serverless, you can choose how much RAM each function gets. Higher RAM costs more but also gives you a faster CPU. His Lambda functions are, on average, being billed for 500ms (according to one graphic).

If he is running with the base RAM allocation bumps it up he might see significantly faster performance and potentially billed for less.

Tuning lambdas and selecting the most optimal RAM (CPU) allocation is automatic with the help of tools provided by the community.

tl;dr Lambda is billed in 100ms increments and has configurable RAM. Higher RAM Lambda is more expensive but faster CPU. This can reduce your bill.

</comment><comment><USER111> This makes me think of the Amazon CTO's analysis from Modern Applications on AWS where they push Serverless as the future:

"...we anticipate that there will soon be a whole generation of developers who have never touched a server and only write business logic."

Honestly, which sounds more like a nightmare than a dream. Knowing what your software runs on and how it works is critical if you want to create REALLY GREAT software.

(reference article: [https://www.allthingsdistributed.com/2019/08/modern- applicat...](https://www.allthingsdistributed.com/2019/08/modern-applications- at-aws.html))

</comment><comment><USER112> This is interesting. I'm guessing the Dev-Ops (Cloud infrastructure people) are going through the same thing as what I, an on-premise infrastructure guy had gone through already. Everybody was preaching Cloud at the beginning. It was slower, it was more expensive. Now look how much cloud had grown and had improved. I believe the same will happen with serverless. A lot of the cloud infrastructure will be abstracted from you. All that will be left are software developers / engineers managing everything. Lowering the requirement of having Ops people. - Coming from an Ops person.

</comment><comment><USER113> I've seen great success with Lambda in two specific cases:

1\. Highly variable load with lots of concurrency

2\. Services that are mostly idle

In the former case, you avoid needing to scale up and down. Lots of excess compute is avoided (and periods of underprovisioning are eliminated while load is increasing). In the latter case, simply not keeping a machine warm during long periods of idle time can save a bit of money, with the ability to pick back up almost instantly.

I would think you'd find it tricky to gain meaningful cost savings with Lambda over another option if your use case doesn't fall into one of those two buckets.

</comment><comment><USER114> The best application for serverless that I've found is supplemental, not wholesale.

Have a server, but offload resource-intensive tasks to cloud functions. Trying to shove everything into that paradigm wastes unnecessary time.

</comment><comment><USER115> I've got downvotes for suggesting the same thing during the hype. In fact all my truths get downvoted. Read them, they are hilarious some of them.

And not only that, breaking news, serverless with aws is severe vendor lockin.

</comment><comment><USER116> I don't find this so surprising really. Serverless removes a significant amount of initial work and ongoing maintenance. No server, no patches, no initial setup, no lots-of-things. Seems like a premium offering with premium pricing.

I also don't find it the least bit surprising that a semi-cold box in a data center can't accept a request, associate it my my account, spin up a worker thread with my stack and service my request in the same time as a box running my stack with a pool of ready worker threads.

It's nice to see someone put some real metrics on it though.

</comment><comment><USER117> Serverless is the shiny new tool in the toolbox. It's great at a few very specific problems, and pretty terrible at a lot of other problems. Some people want to use it for everything because it's shiny, and they're wrong.

That doesn't mean it's not great at those tasks it's great at.

Example: I have an hourly script I need to run that downloads some files. It's been running as a lambda for 3 years without failure. It's cost me zero dollars (free tier). Even if there were no free tier, it would be less than a dollar total

</comment><comment><USER118> Serveless is a sort of a trap. Maybe a good thing for teams who do not have System Engineers, SREs, SysAdmins, etc., due its pragmatism and less cost of operation and maintaining, but its a blackbox: you don't know exactly what's going on and besides that, you don't know if it is really secure. Have to really measure the trade-offs of having and not having this technology on your environment. Don't get caught by the buzzword, and try to really understand, benefits and non-benefits of this approach.

</comment><comment><USER119> Not all projects are concerned with speed and cost. Our in-house CRM has a total of 4 users and is probably used for about a total of 2 hours per working day. Server less is a pretty good fit.

</comment><comment><USER120> I'm using firebase as it was best choice for single developer application. No need to worry about server side parts, and a healthy free tier means no need to worry about few mistakes you make about architecture. Sometime I worry as my app constrained to single supplier, but I doubt I would be large enough to actually worry about it, and when I will be that big, hopefully I would be afford to hire to move to better solutions or optimise to better suit to existing platform.

</comment><comment><USER121> When I put on my instructor hat, serverless is ideal as it drastically simplifies what a student has to learn to get a website up and running.

But if you already are a full-stack engineer, then I think having an entire stack at your hands is way more powerful and flexible.

I think it's matter of time though where just like how Bootstrap paved the way for re-usable components, serverless will soon pave the way for re-usable functions or even services which I think would be a total game changer.

</comment><comment><USER122> Serverless is simply not worth the premium cost for convenience. It's get expensive if using it for serving APIs with decent traffic. Serverless however is good for low volume one-off requests that you can compose together. For example a lamda function to resize an image which then calls another lamda function to put it in a S3 bucket which then calls another lamda function to trigger a notification. Each function just does one thing and does it well.

</comment><comment><USER123> I've seen a few good applications for 'serverless' and a whole raft of bad ones. Yes, the tech has its upsides if you have a few million devices in the field and they can randomly start reporting. But for most applications it is overkill and some forethought might save you having to deal with that particular problem in the first place. Forethought: randomize your connect moments and exponential back-off in case you can't connect.

</comment><comment><USER124> The title is misleading, serverless is slower and more expensive for this particular use case, assuming that the author used the best practices for lambda performances.

</comment><comment><USER125> I'm one person: I cannot make all possible mistakes on my team. Eventually I have to let someone else on my team innovate make those decisions without me second guessing this.

You could also call the above management, and second guessing micromanagement. Even as a senior engineer who has been around a while there is a lot I don't know, and some of that I need to be content to leave to the other engineers to make the mistakes and do the learning not me.

</comment><comment><USER19> I would be interested to see the latency averaged over all their requests, not just a few test runs from Iceland. Surely for many of their customers Lambda would be faster than wherever the closest EC2 instance happens to be running.

My personal default is to control as much of my infrastructure myself as possible, but at a certain point the edge model can have some huge benefits. Same reason I use a CDN even though it introduces another point of failure.

</comment><comment><USER126> I was confused, I thought this was talking about serverless as a concept, which the static file s3 bucket hosting I think is the best thing to happen to front-end deployments in a long time. I don't have to bounce nginx. As a front-end developer I can own my own pipeline from building artifacts to hosting on s3, to cloudfront and WAF with just two template files and almost no devops experience. Its beautiful

</comment><comment><USER127> API Gateway appears to be the biggest bugbear here - and it's definitely got price/overhead issues.. that I'm sure AWS will resolve.

Serverless is great if you're starting from scratch, and have flexibility with your tech stack. If not, you're better of carving off chunks that make the most sense for lambda (with the upshot that this will make your existing components simplier/faster/etc).

</comment><comment><USER128> It'd be interesting to see how much this same workload would cost with e.g. OpenFaaS on k8s with autoscaling to zero; but there also you'd need to include maintenance costs like OS and FaaS stack upgrades. [https://docs.openfaas.com/architecture/autoscaling/](https://docs.openfaas.com/architecture/autoscaling/)

</comment><comment><USER129> Typical of new technologies. You naively start building a startup thinking the new stuff (today that is react and serverless) will be more cutting edge. And then you find out the new stuff adds complexity you don't need especially while starting out with a new product idea. You are misinformed because of the hype and end up paying for it because you are inexperienced.

</comment><comment><USER130> Has anyone migrated in the other direction, away from AWS onto their own servers?

There was a response to a comment I made some time ago that seemed to imply Netflix was doing this (beyond edge delivery) because of AWS costs or funding their direct competitor. A few of us asked for specifics but never got any confirmation that this was happening.

Has anyone been unhappy with cloud?

</comment><comment><USER131> It should be noted that the major pain of the price tag came from AWS API gateway, not Lambda itself, according to the article.

</comment><comment><USER132> I hate adding extra latency, cold start times meant that for any API that was serving data to a customer lambda is a no go for me. Cold start times, just suck for UX imo.

I have one lambda function in my backend at the moment. It is a trigger from Cognito to create a user in my database. It makes sense here, this lambda will only be run once for each user.

</comment><comment><USER133> I really think we're talking about things the wrong way. The argument shouldn't be slower/more expensive. Use the right tool for the right job. If it's simple REST don't use serverless. It's CPU bound stuff like generating thumbnails, parsing xml/json or file conversion is where serverless helps.

</comment><comment><USER134> Anyone who wanted to deploy easy should either prefer a hosted/low code solution or something similar to GAE/Heroku.

The deal with server less is that while it looks attractive, it, like many AWS products, is great for starting out but often not helpful when running anything for large workloads. Then it turns really expensive.

</comment><comment><USER135> I was recently at a AWS company conference, run by AWS. Serverless was being pushed so hard, yet no one could explain exactly why it was superior. Note: we are a fortune 500 company that receives constant traffic.

Are there use cases? Absolutely. Does anyone really understand those use cases? Not really, from what I've seen.

</comment><comment><USER136> Author doesn't even attempt to explain the 15% performance hit, but I suspect it's cold start related... ASP.NET is a poor choice for Lambda if you're hoping for good performance.

The authors use case isn't well suited to Lambda. In fact, something like ECS would be a much better fit and an improvement over Elastic Beanstalk.

</comment><comment><USER137> Any of the IaaS, PaaS, SaaS, "serverless" (I'd slide that into the SaaS category) computing is just differing levels of out sourcing. Did you expect a managed service provider to be faster? Look after the stack yourself to avoid someone else's junk on your monthly rented computer.

</comment><comment><USER54> We implemented Serverless and OpenFaaS at work for part of a large financial application. We're now in the process of ripping it all out. I'm sure Serverless and OpenFaaS have their places on low-traffic, low-compute sites, but both fall down hard when things get at all serious.

</comment><comment><USER138> Serverless - not efficient. Cloud computing - More resource usage and lot of intermediate agents. Client - server model - Server needs to be up all time. More traffic.

Standalone / Primitive softwares - Uses computing power for running business.

No software - Better humanity. Lets evolve biologically than just 0s and 1s.

</comment><comment><USER139> As a new user of AWS services, I was planning to to migrate the website &app to Lambda services, does it mean the platform will get slower? Thanks for the feedback

But, I love to work in NodeJs for it's easy scalability , using GraphQL will disrupt the process. What do you think about that ? Thanks

</comment><comment><USER140> Stuff like CloudFlare Workers and Fastly's Terrarium offer some interesting options - run WASM or JS at the edge. Maybe this can get enough compute done with low overhead and close to the user, which could push Lambda-like functionality further up.

</comment><comment><USER141> Hey there, I lead Developer Advocacy at AWS for Serverless ([https://twitter.com/chrismunns](https://twitter.com/chrismunns)) and have been involved in this space since pretty much the start. Thought I'd toss my hat in the ring there as there seem to be some fairly passionate responses across the board here.

This post is accurate. It's accurate in the new dev experience of someone picking up a framework tool and following the standard walkthroughs/examples that folks like my team and I have been creating the past few years. As far as I'm concerned Einar (the author of the post) did everything I would have done in their position with their experience with this tech. The math Einar did also seems to be accurate given a 1gb RAM and <100ms function duration as well as the API-GW costs, which don't fluctuate based on request duration or Lambda configuration.

Einar got feedback later on that they should have looked at ALB (Application Load Balancer) which does provide a different HTTP request interface back to a Lambda invoke. ALB is the right choice for dead simple proxy requests where you aren't using any of the more advanced features of API-GW. It would lower the cost _significantly_ as well as increase the performance due to a slightly lesser overhead in request path. It would change both the numbers in the blogs title though I can't say it would be 1:1.

We've done a shit job of making this clear and thanks to Einar's post lighting the fire under our butts we'll make work to correct that.

What I am happy about in Einar's post is that they were able to get up and running in almost no time, explore, poke, test, and write this post about their experience very very quickly.

The other thing to highlight here is that I am _happy_ to lose a battle to Elastic Beanstalk, or ECS, or Fargate pretty much any day of the week. All of these exist to significantly reduce the operator burden which compared to running your own container management can be incredibly high. Most companies I've run into in the past 7 years that I've been at AWS have struggled to really measure operator _cost_ but when they compare it to just raw _time_ difference both the technologies I just mentioned and "Serverless" tech like Lambda shift the time spent factor so greatly that cost savings becomes painfully obvious.

Anyway, we're here, we're listening, there's a _lot_ going on behind the scenes (see recent announcement about how VPC cold-start pains will be gone soon).

Thanks, \- Chris Munns - AWS - Serverless - [https://twitter.com/chrismunns](https://twitter.com/chrismunns)

<comment><USER142> and I totally posted this from the wrong account... sigh.. this is me. Thanks, - Chris Munns - AWS - Serverless - [https://twitter.com/chrismunns](https://twitter.com/chrismunns)

</comment></comment><comment><USER143> Uhhh did you check what a vserver costs on aws and compare it to digital Ocean? The cost increase is quit a too!

What you actually buy is abstraction and the need to not manage... Well everything beside code (in simple terms)... It is not an apple to Apple comparison...

</comment><comment><USER144> It seems to me Serverless is meal kit delivery of IT. Expensive with dubious benefits. But it might just work because IT departments have lot more money and incompetent people to buy costly solutions and move on to next buzz when the current one fails.

</comment><comment><USER145> "Serverless" is just an aggressive form of container-based autoscaling, and thus has no fundamental difference from it, although of course pricing can unfortunately be arbitrary and thus cause artificial distinctions.

</comment><comment><USER146> Plain and simple, it's an awesome way to get started quickly and cheaply and some things will always be better suited for the cloud. But long term, there's some parts of your network where you should roll your own.

</comment><comment><USER147> This is a matter of billing, if Lambda charged per millisecond instead of the current model of 100ms chunks, this wouldn't be an issue.

At scale/high performance there's a lot of waste with the current pricing model.

</comment><comment><USER148> Thank you so much for critcal thinking! We need more of that!

</comment><comment><USER149> Serverless is just good old vendor lock-in disguised as an interesting idea. Some people are going to have a fun time migrating their lambdas off AWS in a few years.

</comment><comment><USER150> This post is an order of magnitude higher than any other post on the front page. I think people are finally starting to see through the serverless hype.

</comment><comment><USER151> FYI - Lambda vs. EC2 calculator (not official) [https://servers.lol/](https://servers.lol/)

</comment><comment><USER152> > yes we should probably be using t2.small

Go with t3.small. It's cheaper, faster, and you don't have to watch your CPU credits like you do with a t2.

</comment><comment><USER153> I'm curious about this statement, does anyone else have experience of this?

> We have two because deploying .NET Core in Docker on AWS takes minutes

</comment><comment><USER154> .... and 1000x hype

</comment><comment><USER151> Unofficial Lambda vs EC2 calculator [https://servers.lol/](https://servers.lol/)

</comment><comment><USER155> That's because serverless IS NOT REALLY SERVERLESS.

Remember when mainframes were king, and then people got desktop computers?

The broadband explosion got everyone addicted to always-on Internet. Before this, we had some pretty awesome protocols, like IRC and USENET, etc. which didn't assume your dialup connection was always on.

We need to have the software autonomously link up with one another, with servers just being dumb hubs that store encrypted data. Then they would be commodities that can get paid in crypto. Have you seen MAIDSAFE?

</comment><comment><USER156> Talking about results go for Firebase and Functions there, it's cheaper no need for API Gateway complexity / costs.

</comment><comment><USER157> JFC people, just use whatever works for you and stfu. So many pearl clutchers its ridiculous.

</comment><comment><USER158> I was trying to show this to a ton of people for a long time in general none cares :)

</comment><comment><USER159> Main issue with serverless - Amazon charges way too much for API gateway calls.

</comment><comment><USER160> the 8x cost is worth it if you have cash on hand but not a lot of developer time. If using serverless costs you $50k a year more, but lets you hire one less programmer, it's worth it.

</comment><comment><USER161> ITT: I have no idea how & when to use serverless, hence it sucks.

</comment><comment><USER162> In practice our infrastructure costs for scale-to-zero technology like Lambda and DynamoDB has been a lot lower. So much of the cost in reality comes from idling non-prd instances.

</comment><comment><USER163> Lambda is the kiddie-pool of cloud computing.

</comment><comment><USER164> well, if you go serverless, someone has to pay for the server. Not surprising, especially for the cold starts

</comment><comment><USER165> hmm, only 15% slower for a service that spins up on demand? That's not too bad at all, actually..

<comment><USER166> he's going from Iceland to us-west (Oregon). surely his RTT is dominated by the length of the cable, not any useful work.

my closest AWS DC is in Frankfurt with HTTP ping below 40ms. if i consider 100ms for actual work, the overhead for serverless is 46%. still impressive, i would have expected >100% there.

</comment></comment><comment><USER167> Shushh, don't rock the boat.

</comment><comment><USER168> api gateway is costing too much. good thign we can trigger lambda by many other ways.

</comment><comment><USER169> Serverless doesn't make sense for every workload, and it may not be a good fit here, but there's a few issues with this article and the setups discussed on both the serverless and regular setups.

I'll start with the initial setup: We can see m1 and t1 instances in there, as well as an m3. These first two are almost certainly running paravirtualized AMIs, and there is a chance the m3 is as well. PV AMIs are going to run slower in most cases to begin with (see: [http://www.brendangregg.com/blog/2017-11-29/aws- ec2-virtuali...](http://www.brendangregg.com/blog/2017-11-29/aws- ec2-virtualization-2017.html) ) and are running on old instance types that have poor cost/performance ratios compared to modern ones - m1 and t1 are ancient. So, they could likely get even better performance by switching to modern instance types, getting away from old PV style virtualization on Xen, to the more modern Nitro stuff - t3 should be able to replace all of those instances, and you gain access to SR-IOV based drivers for disk and network. Even just switching to HVM instances and going to previous generation t2 would likely be a big win vs. t1.micro and m1.small.

And this brings me to my first point in favor of serverless: With Lambda, you don't have to worry about this. You don't have to keep up on which EC2 instance has the best price/performance ratio, you don't need to bother with migrating AMIs from Xen PV to Xen HVM (or PVHVM) or KVM compatible with NVMe and ENA drivers and all of that. You just manage your code. There's a mountain of other things to worry about when managing your own EC2 instances as well, even beyond this - just general patching, keeping up to date with new kernel versions, worrying about deprecation/EOL of the OS running in your instance, making sure your code works with new versions of glibc and all the other packages when you move to a new major release, etc. You might be able to skate by for a while ignoring all of this, but eventually, it's likely to cause problems. I know what I charge people to help manage all of that sort of stuff, and it's way more than the cost difference between the two setups.

Second: There's no indication if the latency calculation includes cold-start response times. They would likely be enough to drag the average up quite a bit for lambda, and there's lots of documented ways to eliminate them from a production lambda setup. (Though, they'd also likely see a latency decrease moving to t3 for their EC2 based setup as well, as previously mentioned.)

Third: API Gateway might not be the best tool for the job, especially as the author notes they don't make much use of all of the API gateway features. You can just use an ALB instead (or depending on your use case, potentially skip any sort of front end altogether, though it sounds like ALB is probably a better fit for what they're doing) and save on complexity and cost.

All in all, this comparison isn't really showing a setup that is well optimized on either the EC2/Beanstalk or Serverless sides - there's major wins on both the performance and cost sides for both implementations. Without both being optimally setup, it's really hard to draw a good conclusion on which is a better solution from a technical standpoint, and the discussion also completely ignores the cost in managing EC2, even with Beanstalk vs. a serverless setup.

</comment><comment><USER170> interesting article!

</comment><comment><USER138> Thanks a lot!

</comment><comment><USER171> Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion.

We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assessments.

Even if you make the wrong decision initially, at least it will be your own decision and you will learn from it. Moreover, when it's your own decision, you will learn from it sooner because you're not going to be getting undue reinforcement from peers.

If you over-idealize thought leaders, you will tend to stick to the popular doctrine instead of listening to your own reasoning.

<comment><USER172> This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

<comment><USER173> > For the 80% or more, serverless works just fine.

Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that looks to 'thought leaders' and Gartner to tell them what technologies to use.

if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

<comment><USER141> Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless ([https://twitter.com/chrismunns](https://twitter.com/chrismunns)).

I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing.

If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sharepoint, SAP, or similar) and then look at how many business applications take on a trivial amount of load over time, then the author's post becomes more of an outlier. Few folks have apps that do 100rps realistically. And so for data processing/streaming/batch or web/api workloads serverless actually does work out pretty well. Is this 80%, I am not sure.

There is 100% an inflection point where if your operator cost is low enough(human work+3p tools+process+care and feeding) then the "metal to metal" costs can be comparable. Even the author admits that's leaving something on the floor and so it really comes down to what your organization values most.

I would _love_ for most of our serverless app workloads to be top-down organizationally driven but the reality of it is that it comes often from developers themselves and/or line of business organizations with skin in the game of seeing things move faster in most organizations. This will then typically require buy in from security and ops groups. If these folks you know have the trick to driving top down incompetent strategic management towards serverless I'd buy in on that newsletter.

In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. I think there's also a larger number of people that represent IT vendors that would love to see AWS fail here :)

Thanks, - Chris Munns - AWS - Serverless - [https://twitter.com/chrismunns](https://twitter.com/chrismunns)

<comment><USER173> > And so for data processing/streaming/batch [...] serverless actually does > work out pretty well.

This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the query side unless your queries are trivial enough to be piped straight through to the underlying store. And if your workload is trivial, you should just use clickhouse or straight up postgres because it vastly outperforms serverless stacks in cost and performance[1]

For non-trivial pipelines, tools like spark and dask dominate. And it just so happens that both have plugins to provision their own resources through kubernetes instead of messing around with serverless/paas noise.

And PasS products, well.

[https://weekly-geekly.github.io/articles/433346/index.html](https://weekly- geekly.github.io/articles/433346/index.html)

>One table instead of 90

>Service requests are executed in milliseconds

>The cost has decreased by half

>Easy removal of duplicate events

Please explain.

[1] [https://blog.cloudflare.com/http-analytics- for-6m-requests-p...](https://blog.cloudflare.com/http-analytics- for-6m-requests-per-second-using-clickhouse/)

IaaS is the peak value proposition of cloud vendors. Serverless/PaaS are grossly overpriced products aimed at non-technical audiences and are mostly snake oil. Change my mind.

<comment><USER142> The issue of the application artifact size is definitely real and it blocks some NLP/ML workloads for sure. Consider that a _today_ problem that isn't hard in Lambda.

But we've 100% got customers doing near realtime streaming analytics in complicated pipelines feeding off of things like Kinesis Data Streams. This FINRA example is one datapoint: [https://aws.amazon.com/solutions/case- studies/finra-data-val...](https://aws.amazon.com/solutions/case- studies/finra-data-validation/) and this Thompson Reuters one: [https://aws.amazon.com/solutions/case-studies/thomson- reuter...](https://aws.amazon.com/solutions/case-studies/thomson-reuters/)

These are nontrivial and business critical workloads.

Thanks, - Chris Munns - AWS - Serverless - [https://twitter.com/chrismunns](https://twitter.com/chrismunns)

edit:

\</comment></comment></comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-

Missosoup i see you making changes to your comment and it greatly changes the tone/context. i won't adjust my own reply in suit but leave it as it was for your original comments on this.

<comment><USER173> I'm not going to make any elaborations on my comment now. Please feel free to edit yours or post another to answer anything I raised. Your original reply containing some generic sales brochures isn't what I expected from someone representing aws stepping into this discussion.

</comment></comment><comment><USER174> It depends on the load. You need to make your own calculations, for some sparse loads lambda gets the bill down up to 90%, for a load that is stable over time (like the 10 million request OP has), it makes sense to go with elastic bean or kubernetes.

You need to choose based on your load. Also, I would like to see OP slim down his app, so every lambda only has the code it needs to run and also has a permanent DB connection at least (lambda's good practices)

</comment><comment><USER175> Amazon serverless is way too costly for many businesses.

</comment><comment><USER176> Serverless is a cool solution looking for a problem to solve. However much I want to use it, eg. not having to manage servers myself, I can't find any use case where it would make sense.

<comment><USER40> Well, millions have. So obviously someone has found a problem it will solve...

<comment><USER176> A million people using using serverless? Do you have a reference ?</comment></comment></comment>