
Serverless: slower and more expensive - kiyanwang
http://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/
======
abiro
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.

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

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

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

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

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

~~~
peterwwillis
_> 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.

~~~
ClumsyPilot
I am similarly, reading this list and wondering

~~~
epx
One day people will rediscover installing a Linux box with an Apache server
and call it novelty.

~~~
xchaotic
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

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

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

~~~
0xDEFC0DE
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.

~~~
johnfactorial
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. :)

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

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

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

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

~~~
wolco
Heroku is owned by salesforce? You learn something everyday.

~~~
anderspitman
Yeah I actually didn't know that either. Interesting

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

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

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

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

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

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

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

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

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

~~~
ramraj07
How did you replace a site that needed rds with s3? Was it a blog that you
moved to Jekyll or something?

~~~
cdumler
If you are comfortable with React, look at GatsbyJS. It is pretty amazing what
you can build into a static site.

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

~~~
radicalbyte
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)

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

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

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

~~~
fauigerzigerk
_> 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.

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

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

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

~~~
ainiriand
Sometimes the right solution is just the easiest. Most of the time just is.
Congrats.

~~~
k__
Replacing badly executed solution A with well executed solution B is obviously
a good idea, but adds nothing to the conversation.

~~~
1337shadow
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.

------
gigatexal
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”

~~~
scarface74
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/))

~~~
zackbloom
Workers are pretty significantly different. They don't have a meaningful cold-
start time, for one.

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

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

~~~
waffle_ss
App Engine is a PaaS, not serverless/FaaS

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

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

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

~~~
hanikesn
His application runs for a total of 3 ms. So startup time is not the issue.

~~~
djm_
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)

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

~~~
nfRfqX5n
lambda is perfect for high volume bursty traffic. you will never have to worry
about a server being overloaded or going down.

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

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

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

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

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

~~~
darkwater
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)

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

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

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

------
iddqd
> 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/)

~~~
EwanToo
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)

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

~~~
EwanToo
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)

------
acd
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/)

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

~~~
committed
Which VPS provider do you use and what is your backend stack?

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

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

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

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

~~~
tarosnow
It's not just a single instance. Look at the hours billed.

~~~
mrich
That's why I multiplied by 3.

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

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

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

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

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

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

~~~
SQLite
Yeah. See
[https://www.sqlite.org/serverless.html](https://www.sqlite.org/serverless.html)

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

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

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

~~~
dkarras
How did the cost profile change? You can include reduced labor costs if you
want.

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
einaregilsson
The alternative to serverless isn't "single instance". With Elastic Beanstalk
you can have multiple instances, autoscaling etc.

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

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

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

~~~
sciurus
Tell that to
[https://github.com/apache/openwhisk](https://github.com/apache/openwhisk) ,
[https://github.com/knative](https://github.com/knative) , etc.

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

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

~~~
im3w1l
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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
westurner
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/)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
munns
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)

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

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

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

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

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

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

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

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

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

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

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

------
truth_seeker
.... and 1000x hype

------
dinnouti
Unofficial Lambda vs EC2 calculator
[https://servers.lol/](https://servers.lol/)

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

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

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

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

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

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

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

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

------
vanrysss
Lambda is the kiddie-pool of cloud computing.

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

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

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

------
eeZah7Ux
Shushh, don't rock the boat.

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

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

------
bruh88
interesting article!

------
imvetri
Thanks a lot!

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

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

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

~~~
tgeek
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)

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

~~~
munns
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:

\-------------------------------------

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.

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

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

------
hesburg
Amazon serverless is way too costly for many businesses.

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

~~~
scarface74
Well, millions have. So obviously someone has found a problem it will solve...

~~~
z3t4
A million people using using serverless? Do you have a reference ?

