Serverless: slower and more expensive

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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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.

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".

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”

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..?

"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.

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.

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.

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.

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.

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.

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".

> 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...

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/

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.

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.

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.

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?

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.

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?

> 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.

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.

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.

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.

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.

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.

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.

> 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.

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.

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.

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.

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.

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.

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... [1]: https://read.iopipe.com/how-far-out-is-aws-fargate-part-2-e8...

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.

"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.

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.

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...)

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.

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.

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.

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.

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.

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

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.

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.

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.

Lambda is the recommended way to host an Alexa Skill:

https://developer.amazon.com/docs/custom-skills/host-a-custo...

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

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.

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?

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

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.

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...)

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.

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

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).

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/

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.

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?

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

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.

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.

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.

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.

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.

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.

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.

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

Hey there, I lead Developer Advocacy at AWS for Serverless (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

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.

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...

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.

"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.

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.

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.

Thank you so much for critcal thinking! We need more of that!

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.

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.

FYI - Lambda vs. EC2 calculator (not official) https://servers.lol/

> 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.

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

.... and 1000x hype

Unofficial Lambda vs EC2 calculator https://servers.lol/

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?

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

JFC people, just use whatever works for you and stfu. So many pearl clutchers its ridiculous.

I was trying to show this to a ton of people for a long time in general none cares :)

Main issue with serverless - Amazon charges way too much for API gateway calls.

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.

ITT: I have no idea how & when to use serverless, hence it sucks.

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.

Lambda is the kiddie-pool of cloud computing.

well, if you go serverless, someone has to pay for the server. Not surprising, especially for the cold starts

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

Shushh, don't rock the boat.

api gateway is costing too much. good thign we can trigger lambda by many other ways.

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... ) 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.

interesting article!

Thanks a lot!

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.

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.

Amazon serverless is way too costly for many businesses.

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.