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&#x27;t be cheaper than at scale under normal circumstances. OP was beyond the breakeven point.

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.

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

I didn&#x27;t know you could do this. For anyone interested here&#x27;s a simple CF template that illustrates this scenario [1].[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;s0enke&#x2F;cloudformation-templates&#x2F;blob&#x2F;master&#x2F;templates&#x2F;lambda-alb-sam-sample.yaml" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;s0enke&#x2F;cloudformation-templates&#x2F;blob&#x2F;mast...</a>

Yes, it would be a much less dramatic headline if they&#x27;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&#x27;t find this out.They already have a classic ELB in place, so switching to an ALB wouldn&#x27;t be a significant change in cost or capability (the ALB is often cheaper, though it&#x27;s hard to tell in this case)

&gt; For us it would have been better if we could just put a normal load balancer in front of Lambda.This can be done.<a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;networking-and-content-delivery&#x2F;lambda-functions-as-targets-for-application-load-balancers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;networking-and-content-delivery...</a>

His main goal was to reduce deployment time, not to reduce costs.It&#x27;s obvious from the article that he would have even lived with a slight bump in pricing if he got that.

Better to use t3.small and use infinite burst

&gt;Deciding to do a whole infrastructure change...He didn&#x27;t decide to do a whole infrastructure change. He just ran an experiment that was about more than just cost.

&gt; It&#x27;s like renting a car 365 days out of the year instead of purchasing, it only makes sense if you only need it sporadically.Spot on! Great analogy.

&gt; To be honest I hadn&#x27;t thought at all about the pricing beforehand. I just figured &quot;Pay for what you use&quot; sounded like it would be cheaper than paying for instances that are on 24&#x2F;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&#x27;s like renting a car 365 days out of the year instead of purchasing, it only makes sense if you only need it sporadically.

You&#x27;re basically hiring an AWS devops position since you don&#x27;t need to manage anything yourself. Great for the small startup but not so great for the already established enterprise that has some devops guys anyway.

Is there any fundamental reason for this, apart from AWS&#x27; pricing model? It seems to me that ideally, serverless should scale from extremely small to very big without too many problems.

I&#x27;ve had problems with that level of use due to cold-starts. It was mitigated by pinging it every 10 seconds with CloudFront.

Agree with you, Lambda would make a lot more sense if it was kind of a scaffold for your application.Say you only have 1k users and don&#x27;t want to spend too much time on infrastructure, lambda is a perfect fit for it. Your application is taking off and now you have 100k: just click a button and migrate it to a Fargate&#x2F;ECS. That would be the perfect world.AFAIK the only framework that supports this kind of mindset is Zappa (<a href="https:&#x2F;&#x2F;www.zappa.io" rel="nofollow">https:&#x2F;&#x2F;www.zappa.io</a>). I use it in production but never had to migrate out of AWS Lambda so I&#x27;m not sure about the pain points related to it.

&gt; 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.

Aren&#x27;t there abstractions to reduce the impedance mismatch between serverless offerings, e.g. Serverless (javascript framework)[1], which should allow easier portability to self-hosted solutions - openfaas or openwhisk etc - including running in containers on more traditional infrastructure, which is cheaper for this particular scale and use-case?Sure, they&#x27;re still FaaS which seems to be the unit of deployment for the serverless movement. For (hidden) managed server container deployment, Fargate is the offered solution I believe.[1] <a href="https:&#x2F;&#x2F;serverless.com" rel="nofollow">https:&#x2F;&#x2F;serverless.com</a>

I think the problem is that moving from Lambda&#x2F;FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Not really. I converted a Node&#x2F;Express API running in lambda using the proxy integration to a Docker&#x2F;Fargate implementation in less than a couple of hours by following a Fargate tutorial. Most of that time was spent learning enough Docker to do it.The only difference between the Docker implementation of the API and the lambda implementation was calling a different startup module.There is nothing magical about any lambda, from the programming standpoint you just add one function that accepts a JSON request and a lambda context.Converting it to a standalone service (outside of APIs) is usual a matter of wrapping your lambda in something that runs all of the time and routing whatever event you’re using to trigger to a queue.

I think the problem is that moving from Lambda&#x2F;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&#x27;t changed. It&#x27;s all just containers.Personally I&#x27;d like to see the industry coalesce on &quot;serverless&quot; 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.

I thought the point of Lambda wasn&#x27;t for not so often used APIs but for APIs where you need instant autoscaling where you may need 100 servers in 2 minutes and only need them for 20 minutes.

I&#x27;ve always found Troy Hunt&#x27;s tech stack of haveibeenpwned.com interesting. The API does 5M requests a day with Azure Functions and Cloudflare caching. Ultimately only costing him 2.6c per day.<a href="https:&#x2F;&#x2F;www.troyhunt.com&#x2F;serverless-to-the-max-doing-big-things-for-small-dollars-with-cloudflare-workers-and-azure-functions&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.troyhunt.com&#x2F;serverless-to-the-max-doing-big-thi...</a>

&quot;It&#x27;s also great for when you&#x27;re first starting out and don&#x27;t know when or where you&#x27;ll need to scale.&quot;To me this is probably the most significant benefit, and one that many folks in this discussion strangely seem to be ignoring.If you launch a startup and it has some success, it&#x27;s likely you&#x27;ll run into scaling problems. This is a big, stressful distraction and a serious threat to your customers&#x27; confidence when reliability and uptime suffer. Avoiding all that so you can focus on your product and your business is worth paying a premium for.Infrastructure costs aren&#x27;t going to bankrupt you as a startup, but infrastructure that keeps falling over, requires constant fiddling, slows you down, and stresses you out just when you&#x27;re starting to claw your way to early traction very well might.

They&#x27;re doing over 100rps if they&#x27;re doing 10M requests a day. That&#x27;s not a good use case for Lambda. If you&#x27;re going to be that heavily utilized it makes more sense to run your API on EC2 or ECS&#x2F;Fargate&#x2F;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&#x27;s called a few times a day. It&#x27;s also great for when you&#x27;re first starting out and don&#x27;t know when or where you&#x27;ll need to scale.But once you get to 100rps for an API, it&#x27;s time to move to a more static setup with autoscaling.

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.

The alternative to serverless isn&#x27;t &quot;single instance&quot;. With Elastic Beanstalk you can have multiple instances, autoscaling etc.

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&#x2F;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.

I think this is an important consideration that a lot of people miss. One of the trends of both serverless and containers it that compared to older models they are allowing smaller and smaller teams to do bigger and bigger things.So, in certain respects it&#x27;s an enabler. Context always matters.

Counterpoint to that though: &quot;Serverless&quot; isn&#x27;t all that much &quot;easier&quot; to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly &quot;accessible&quot; for someone trying to get running ASAP.I agree tech is getting democratised, but when talking about products that allows it, I&#x27;m thinking of products like Firebase or the recent darklang, not AWS Lambda. From all the Lambda usage that I&#x27;ve encountered so far, they are still very much in the domain of a &quot;sysadmin&quot;.

It really depends what you&#x27;re doing. I&#x27;ve been trying out serverless on-and-off for weeks now and still don&#x27;t have a basic two tier application going the way I want. I&#x27;d have been substantially better off dropping $5&#x2F;month on a DigitalOcean droplet and running PostgreSQL and Rails on it. DigitalOcean even has really helpful templates to start up basic servers.This may be a specific criticism of AWS Amplify, but all I&#x27;ve been doing is trading off some arcane knowledge in open source software for arcane knowledge in some vendor-specific system. Most of my time has been spent searching for answers to Amazon-specific issues that haven&#x27;t been solved in any of their SDKs. Or I wind up walking through their SDK code trying to figure out how to metaprogram my way around it.Perhaps if I used the web UI to stand everything up, it would have gone a lot smoother. I&#x27;ll admit I&#x27;m a sucker for infrastructure as code. But, as it stands, I can&#x27;t see how this really saves anyone any time. It&#x27;s still an incredibly manual process without much in way of help or support the moment you veer off the one path Amazon has decided you should be on.(To make things more concrete, I still don&#x27;t have Cognito working with optional TOTP 2FA. The withAuthenticator component apparently only renders the TOTP setup if 2FA is required. I&#x27;ve spent hours trying to work this one out, including spending time on the Amplify Gitter channel.)

Learning how to setup everything will be too much for you.  Use Hostgator and you can start marketing immediately.

Agreed, let me add my 2cts :&gt;The whole idea of serverless is so you don&#x27;t have to manage infrastructure....when you are validating your product&#x2F;market (100 request&#x2F;day is a success here).Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.

Yeah, that would have been a much better fit. I just didn&#x27;t know you could put ALB in front. (Also, a &quot;load balancer&quot; in front of serverless... , and yes I know load balancer do more than load balance.)I mainly went with API Gateway since that&#x27;s the default setup the serverless framework uses.

One frustrating caveat of the ALB approach is there is a hard 1 MB limit on both the request and response size, while APIGW has a hard 6 MB limit.

If they had used an ALB instead of API Gateway, the cost might well have been a 2x increase, especially given that would replace the ELB they&#x27;re already using. The ALB option has it&#x27;s own caveats though...

isn&#x27;t that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it&#x27;s expensive.You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.

Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway &amp; Lambda is significantly more expensive than the more traditional options.

Burst traffic with high writes? --&gt; Use a stream.
Burst traffic with high reads? --&gt; Use a cache.Large compute and memory intense stuff isn&#x27;t suitable for serverless

Serverless works great for my apps.  My traffic is driven by hourly notifications so I get 100x more traffic on the hour than the rest of the hour.  I could write a bunch of ML to figure out load scaling but that is code I don&#x27;t want to focus on.

&gt;The whole idea of serverless is so you don&#x27;t have to manage infrastructureThat&#x27;s one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn&#x27;t use serverless.

Containers will be around for at least another 5 years.If you look at where AWS makes most of their money, it&#x27;s selling EC2 hardware.

&gt; I&#x27;m in the container camp because serverless isn&#x27;t cheap and you can&#x27;t have long running processes.Do you think you&#x27;ll have the same opinion in five years time? Or how about three years?

Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?

There&#x27;s already serverless where you don&#x27;t have to do anything with OS&#x2F;servers&#x2F;infra: PaaS, like Heroku.But no, that&#x27;s not Amazon, so no one cares either way (pro&#x2F;contra, cheap&#x2F;expensive, fast&#x2F;slow, easy&#x2F;hard) :|

There are definitely still things you need to think about with Lambda, like how much memory you want to allocate etc.

&gt; you now have to manage APIGW and Lambda, and any other &quot;wiring&quot; that you need to put in to do what you needed.You know those url.py files in a django install? Those are the equivalent of ELB&#x2F;APIGW thing. You don&#x27;t manage those, you make them once.Not sure where you personally draw the line between app development and infra work, but for me &quot;request that comes on this path, calls this function&quot;, either via ELB -&gt; backend or APIGW -&gt; lambda, or you know, whatever you use for your django app -&gt; a function defined in a view.py, is app, not infra.

&gt;The whole idea of serverless is so you don&#x27;t have to manage infrastructureIs this even achievable with Lambda though? Even with Lambda, you still have to configure your &quot;infrastructure&quot;, just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other &quot;wiring&quot; that you need to put in to do what you needed.All in all, I can&#x27;t really say Lambda is really all that &quot;easy&quot; considering options like AWS EB&#x2F;ECS can be setup relatively easily.

&gt;If this were the reason to use Serverless, it doesn&#x27;t buy you much. Ports? You set that up once and you&#x27;re done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.This is &quot;you&#x27;ll always have to do X, so might as well do 10x&quot; argument...

&gt; You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.You can consider it so theoretically, but for many teams, especially small teams, OS-level systems admin is a different skillset and non-trivial burden that they are glad to pay a premium for, which is why offerings like heroku are successful.It may work that way for you, but it definitely does not for many many teams.&quot;You already have to walk to the store, so hiking the appalachian trail is just another part of your walking strategy&quot; -- this is an exageration, the difference between walking to the store and hiking the trail is probably larger than adding OS-level maintenance, but it shows &quot;you already have to do X so doing anything else that I can also call &#x27;X&#x27; should be trivial&quot; is a flawed form of analysis, it tells us nothing that you can call all of it &quot;walking&quot; or all of it &quot;patching strategy&quot;.

&gt; The whole idea of serverless is so you don&#x27;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.If this were the reason to use Serverless, it doesn&#x27;t buy you much. Ports? You set that up once and you&#x27;re done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.The reasons to use Serverless is the same as everything else in the cloud: 1) fast scaling, 2) sometimes it is cheaper depending on X, and finally 3) you don&#x27;t have to think about where to run it.

I tried using google cloud run, with a rust web server.
I think google only counts request processing time and rounds up to the nearest 100ms.All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.

Fargate is not a replacement for Lambda.  While there&#x27;s some capability overlap, each have their own respective niches.

Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.

I&#x27;d say modern API deployments are either containerised or go the serverless route.On one hand you have a docker image with your source code&#x2F;static binary baked in. The other you have your source code&#x2F;binary encapsulated in a serverless framework (with an Event handler of sorts as your input).The container doesn&#x27;t lock you into a particular ecosystem, but hasn&#x27;t solved how you deploy and run your container (Heroku, managed k8s, AWS ECS&#x2F;EKS&#x2F;Fargate). Serverless on the other hand will give you a runtime for your API and allow you to go live (assuming you&#x27;ve setup an account or whatever).To migrate something that already works to serverless is a bad idea. Maybe if you&#x27;re pretty comfortable with serverless frameworks and you like to hack a lot of projects up quickly, sure serverless might be a good fit. But why not instead start off with a container? At least you have the flexibility to run that on whatever you damn want - Even a t2.small instance with a docker daemon running.

Because most people with strong opinions aren&#x27;t experienced enough to justify them from direct experience. Instead we have religions, tribal affiliations, camps.

&gt; I&#x27;m in the container campCan anyone explain to me why there&#x27;s &quot;camps&quot; to this debate?

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

I wonder if it&#x27;s a generational thing but it seems to me that people nowadays have forgotten that you can host more than one site or database per server. Failing that shared hosting still offers amazing value if you don&#x27;t need anything to weird e.g. someone like Bluehost or Hostgator offers unlimited* sites + databases for about $5&#x2F;month

Some tools are&#x27;t the right one for any jobs we actually have.

I can also vouch for this. I run a low traffic website on S3 and Coudfront. And Lambda is perfect for handling the small amount of dynamic content or form processing that it requires. It costs cents a month to run and doesn&#x27;t need any maintenance.

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&#x2F;month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 &amp; Cloudfront: now my bill is $0.80&#x2F;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&#x27;ve never failed once.If you&#x27;re running a games website that gets pinged 24&#x2F;7, don&#x27;t use Serverless. But the notion that it&#x27;s slow and overpriced is misguided if you&#x27;re applying the wrong use case.

Amazon puts emphasis on &quot;certifying&quot; solutions architects to turn them into marketing mouthpieces and AWS proponents.Source: Seen it happen, am certified.

Exactly. This guy nails it. The serverless paradigm is a managed service, so you are paying extra for that management. Serverless also is built for automated connectivity within the AWS ecosystem, i.e. as a nerve center for all of AWS&#x27;s nifty gizmos. This is why Amazon places such an emphasis on training certified solutions architects who know what works best for each situation.

The whole idea of serverless is so you don&#x27;t have to manage infrastructureThat&#x27;s the selling point of AWS in general, but I wouldn&#x27;t be surprised if (non-tiny) companies are still spending at least as much on AWS&#x2F;etc. as they would on in-house infra. That is, they&#x27;re paying for it anyway, and possibly at a premium.

I disagree with all the comments posted so far.This should be a perfect use case for lambda, not &quot;oh you&#x27;re API is receiving more than 10M req&#x2F;day? Use Elastic Beanstalk instead with an EC2 instance and ELB&quot;. 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&#x27;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&#x27;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&#x27;m in the container camp because serverless isn&#x27;t cheap and you can&#x27;t have long running processes.

Not only that, but it is also way harder to structure and develop than a normal application. At least in my experience.

&gt; That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it&#x27;s e.g. 10x easier, so that e.g. 1 programmer&#x2F;ops guy can do what it took 10 before.Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write&#x2F;test cycle.Other forms of serverless might save time. However there&#x27;s always edge cases where they don&#x27;t and you can lose hours or even days investigating an issue that would be a quick fix if you actually managed the host and&#x2F;or application.So the short answer is: not always faster nor easier. It really depends on what you&#x27;re trying to accomplish.&gt; I don&#x27;t think anybody uses things like AWS or serveless services because they&#x27;re faster or cheaper...Actually yes they do. But like my previous answer, it depends on what you&#x27;re trying to accomplish.This is the problem with serverless (and cloud computing in general). People try to distil it down to &quot;this is better for x&quot; and &quot;that is better for y&quot; but actually the benefits and trade offs are far more granular than that. To the extent that you could have two companies in the same sector releasing competing products and still what architecture makes sense for one company might not for the other.This is also why nobody ever agrees about these topics online - by the time you&#x27;ve generalised the examples enough to describe them in a forum post, they lose the specificity that makes any accurate design possible.

1 programmer&#x2F;ops guy can do what it took 10 before.The myth: devs are expensive and hardware is cheapThe reality: webdevs are a commodity and AWS is making record profits

&gt; it&#x27;s e.g. 10x easier, so that e.g. 1 programmer&#x2F;ops guy can do what it took 10 beforePerhaps it&#x27;s more related to the programmer than the tech stack...It&#x27;s also not solely developping, but debugging too. And serverless does make things a lot harder.

If we really want easy, we’d all be writing ColdFusion or Visual Basic.

They can be a lot cheaper. Maybe only in some cases but then it can make a difference.

&gt;We should accept that most famous CTOs, engineers and other &quot;thought leaders&quot; are not geniuses (also, they&#x27;re often corrupted by financial interests)That goes without saying!That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it&#x27;s e.g. 10x easier, so that e.g. 1 programmer&#x2F;ops guy can do what it took 10 before.I don&#x27;t think anybody uses things like AWS or serveless services because they&#x27;re faster or cheaper...

There are enough results to prove that serverless is useful (may I say, correct) architecture in many use cases. Not everyone is dumb, contrary to a common belief. Don&#x27;t be religious.

It isn’t about “reality” it’s about trade offs. Every choice you make when it comes to infrastructure, whether to build or buy, etc comes with trade offs. The trade offs and benefits of using lambda isn’t a secret.

Hey nickjj, you may want to update your blog post to reflect that the Lambda timeout is now 15m, not 5m.

Agreed.~2 years ago I seriously looked into Serverless and very quickly discarded it after seeing a large production deployment of it. I didn&#x27;t have access to the billing info but the site loaded much slower than a regular site and developer productivity was quite low.I&#x27;m going to stick with good old servers for now. If anyone is curious, a few years ago I did a write up on &quot;Should your next project be built as a Serverless app?&quot; which compares deployment styles in a bit more detail: <a href="https:&#x2F;&#x2F;nickjanetakis.com&#x2F;blog&#x2F;should-your-next-project-be-built-as-a-serverless-app" rel="nofollow">https:&#x2F;&#x2F;nickjanetakis.com&#x2F;blog&#x2F;should-your-next-project-be-b...</a>

I suspect if you were to put &quot;your money where your mouth is&quot; those 80% of yours would turn into 20 or less. ;)

Not a strawman, nope. Please put the React salesmen on this list of bogus hype as well. It’s all projection and propaganda—zero substance.Here’s the proof of evil intent behind React, for example:<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20711598" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20711598</a>

While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

Wow everyone all excited about hosted FreeBSD jailsSome of us had deploy pipelines into “containers” working like a Lambda in 2003.Nothing in software is all that novel these days, IMO.All these features that have been there for a decade plus are just wrapped in a corporate brand now.Progress.

&gt; For the 80% or more, serverless works just fine.Citation?

&gt; For the 80% or more, serverless works just fine.Cite this. I don&#x27;t believe you. I&#x27;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 &#x27;thought leaders&#x27; 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.

The only application where I&#x27;ve found serverless to work well is for simple plumbing&#x2F;event sourcing in AWS. They are less apps and more &quot;tiny scripts that automatically run&quot;. 99% of the work is still done in containers on actual servers. The serverless portion is by far the least &quot;developer ergonomic&quot; but that&#x27;s not a problem if your code is less than a hundred lines and rarely subject to changes.The idea of running your entire app as serverless sounds like pulling teeth. Thought leaders are free to pat each other on the back on that one... I won&#x27;t mind being called a luddite.

The most interesting thing about serverless for me isn&#x27;t &#x27;web scale&#x27; its &#x27;scale to zero&#x27;. My apps tend to be bursty, with trickles of data in between. I mostly concerned in reducing their &#x27;idle&#x27; costs, so not having to manage the OS, security etc is a massive cost saving for us.

&gt; There are valid reasons for serverlessThose scenarios are probably just as happy with a PHP script on Apache.

It sounds like what you&#x27;re saying is for OP to have been able to leverage serverless properly, he should have fired a devops engineer?

&gt; most people choose it for reasons other than hype[citation desperately needed]

Managed servers also exist and are in quite of a sweet spot if you need the performance.

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.

The true cost of any product is the project lifecycle cost. There are many cases where a serverless architecture would cut down on that.

serverless is just servers_over_there :&#x27;). same shitty security. just a bit flexible pricing which might or might not benifit people depending on the pricing model and load averages &#x2F; paterns.most excuses people give for going serverless is just handing off responsibilities to cloud providers to be able to point and blame if the shit hits the fan.

if you work for an org that has cash on hand but not a lot of developer talent, the tradeoff is worth it. If the difference is going to cost you $50k a year but let you hire one less programmer, it&#x27;s worth it.

Serverless was just a lock in model pushed by big cloud vendors.

If you want something performant and cheap you just need to go with Assembly. It&#x27;s expected that super flexible software platforms are very costly.

Those SRE infra skills pretty much crossover with knowing what your app is doing in FaaS environment.How do you know those async requests are completing? What&#x27;s the percentage of failures? Are you meeting those SLAs? Who&#x27;s patching the code? How do you test and deploy new versions?Those are all typically seen as ops tasks, now you&#x27;re doing them.Small bit of concern around you saying you&#x27;re using the console, because good testing generally requires Infrastructure as Code, but I suspect the reality is your operational readiness meets your risk profile. That or you&#x27;re winging it ya big cowboy. :p

Everytime I read these types of articles, I immediately login to AWS billing console and review our costs.We switched to AWS serverless about a year ago (API gateway and Lambda) and there have been no real surprises.I&#x27;ve been able to increase our contractual SLA uptime to customers (and charge for it).We can kick-off more backend async processes and let the magic of auto-scaling just do it&#x27;s thing.If anything, I now have a fear of getting too complacent, as we no longer have a FTE SRE monitoring infra. If something goes seriously wrong, we have to rely on our DevOps AWS console skills to troubleshoot.But similarly, if the power goes out in California, I have to rely on PGE to fix the issue. Serverless is also a cultural decision to outsource the infra.

&gt; Tech should be about results, it should not be a religion.I couldn&#x27;t agree more with this.I&#x27;m trying to get a small library [1] I wrote popular and it&#x27;s insane how much resistance I get because it doesn&#x27;t fit the &quot;mainstream religion&quot; of using GraphQL.People are brainwashed to think API = REST or GraphQL. How many times did I see a RESTful (or even worse GraphQL) for an internal API where RPC would be so so much simpler... (GraphQL is great for third parties but sh*t for internal stuff.)[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api</a>, a RPC library for Node.js server &lt;-&gt; Browser.

You know what I actually like Serverless (AWS Lambda) for?Adding a script that is triggered upon a new message to an SQS queue. The cost in using AWS Lambda is actually in the use of API Gateway, and it doesn&#x27;t use that, as well.Now, you&#x27;re right, I didn&#x27;t find this from any thought leaders, etc. In fact, I would disregard anyone who couldn&#x27;t give me a concrete use-case and a cost&#x2F;benefit overview for a technology. I have met a few executives that more or less were trojan horse leaders for other companies&#x27; technologies. Salesforce rings a bell.

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 &quot;thought leaders&quot; are not geniuses (also, they&#x27;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&#x27;s your own decision, you will learn from it sooner because you&#x27;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.

Instead, you worry about the provider, and when their worries become your worries you hope you&#x27;re significant enough to warrant worrying about...

Of course there&#x27;s still a server. What it means is that you don&#x27;t have to worry about it.

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 &quot;serverless&quot; - for example, SQLite is called a &quot;serverless database&quot; because it&#x27;s an embeddable library that just operates off a file as opposed to client-server DBs like Postgres or MySQL.

&quot;Serverless&quot; is &quot;I don&#x27;t have to provision a server, or worry about where it is, or maintain it, or what OS it&#x27;s running, or any of the other fiddly details.&quot;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&#x27;t have to worry about the server.

Think of serverless as “framework-as-a-service”.
Edit: why the downvote? 
From infrastructure, through platform, serverless is the natural evolution of the cloud to framework-as-a-service.

It&#x27;s a misnomer, but the underlying idea has lots of valid uses.

I don&#x27;t understand the term or brand &quot;serverless&quot;, to me it seems it&#x27;s still using a server, meaning a fast computer somewhere running 24&#x2F;7 in a datacenter.To me &quot;serverless&quot; implies decentralized networking, with a DHT or some kind of network authority, meaning P2P networking at one point or another.Am I missing something?

that is why I wrote &quot;that fraction&quot;, hoping that it means that its the same fraction.Though, your example still does not mean you lost. that 1&#x2F;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).

1&#x2F;10 and 1&#x2F;100 are both fractions. If 1&#x2F;10 of the salary of a developer is saving 1&#x2F;100 of that developer&#x27;s time, you lost. Fractions are not equal, blanket statements about fractions are not good business practice.

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.

That screenshot likely shows a warm startup; while they&#x27;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]: <a href="https:&#x2F;&#x2F;medium.com&#x2F;thundra&#x2F;the-fundamental-problem-solving-net-lambda-cold-start-part-i-1ff4400bb6eb" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;thundra&#x2F;the-fundamental-problem-solving-n...</a>

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

&gt; This feels very &quot;Serverless is cool, everyone is saving money on it, lets do the sameMore like &quot;seems like there&#x27;s an easy way for me to try this new thing out, lets give it a shot&quot;. It took a couple of hours to switch over to this, and I learnt something in the process. Also, our API is very simple, pretty much all the actions are a single database call, so I don&#x27;t think in this case we would have gained anything by splitting things up into more pieces. But I can see how it would make sense for a larger, more complicated app.

This feels very &quot;Serverless is cool, everyone is saving money on it, lets do the same&quot;&gt; 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&#x27;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&#x27;t cache, I know)Having gone through this process myself with a very very large code base, it would have not worked to just slap it into serverless.Going server less can save you money, but not by just taking your existing app and throwing it on Lambda.

I disagree. Whether it&#x27;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&#x27;t)

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. &quot;server software&quot; is not just Internet software, the world is larger than that.

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.

&gt; Finally, I&#x27;m not trying to bash API Gateway, Lambda or serverless in general here...AWS API Gateway should be bashed because it truly is shoddy.

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&#x27;t get too much benefit from serverless.

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.

&gt; popularity of a tool is a poor predictor of fitness to particular job at hand.It is, however, a good predictor of the ease of finding people to do the job.

It&#x27;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.

Is that your personal definition? On App Engine I deploy a function that gets invoked whenever an HTTP endpoint is requested.  It clearly maps to the semantic of &quot;function as a service&quot; and I don&#x27;t know about or control the number of servers so it also has the properties of &quot;serverless&quot;.

I don&#x27;t think there&#x27;s a real difference<a href="https:&#x2F;&#x2F;engineering.khanacademy.org&#x2F;posts&#x2F;original-serverless.htm" rel="nofollow">https:&#x2F;&#x2F;engineering.khanacademy.org&#x2F;posts&#x2F;original-serverles...</a>

App Engine is a PaaS, not serverless&#x2F;FaaS

&quot;Serverless&quot;, or &quot;App Engine&quot; 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&#x27;m not sure how to weight the &quot;I have a predictable base load large enough for its cost to dominate the other factors&quot; vs the other cases. But as always - popularity of a tool is a poor predictor of fitness to particular job at hand.

The frontend is a ~$30 bucks VPS with OVH. This thing serves about 2 million users &#x2F; 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&#x27;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 &#x2F; month. But the main site and most files don&#x27;t use cloudflare (they&#x27;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.

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

A $10 VPS would&#x27;ve been enough to handle the kind of load his site sees too, which is about 15x cheaper again than AWS.If you&#x27;re really looking to save money, don&#x27;t touch AWS.Source: I run the frontend for an interactive &quot;one-page-app&quot; site about 3x larger on a $30 VPS with room to spare.

Yeah I just wanted to point out like the authors whose post I copied here that the way of going serverless taken by the story author was probably not ideal.

Workers are pretty significantly different. They don&#x27;t have a meaningful cold-start time, for one.

You can do the same thing with Lambda @ Edge and CloudFront for .60 per million requests and there is a free tier. (<a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;lambda&#x2F;pricing&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;lambda&#x2F;pricing&#x2F;</a>)

I thought commenter W. Van Dam made some good points:“ First, you don&#x27;t need API Gateways if you use an AWS SDK. Like this guide shows. And of course you don&#x27;t need a load balancer, because that&#x27;s precisely one of the things that serverless takes care of for you :-)More importantly, you didn&#x27;t actually compare serverless to your current situation.With serverless solutions you can typically save cost in terms of server management. Serverless isn&#x27;t maintenance free, but you should be able to reduce your monthly cost (e.g. lower labor cost).You&#x27;re right to research whether it actually works for you, but I think you&#x27;re not done yet ;-)Also, perhaps CloudFlare Workers are of interest to you. It&#x27;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”

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 &amp; test performance in lower cost data centers.

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&#x27;s triggered by everything but API Gateway. Analysing a file uploaded on S3, reacting to an SNS message or consuming messages in SQS.

he&#x27;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 &gt;100% there.

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

&gt; Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms.No because Lambdas are proprietary which means you can&#x27;t run it in a CI or locally.
Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does.&gt; Serverless isn&#x27;t much younger than say, node.js and Rust are.AWS Lambdas which I consider to be the first widely used Lambda service was was released in April 2015 which is 6 years after the release of Node.js.
Also, Node.js is way more popular and mature than Lambda solutions.Overall Lambdas are only useful for small, infrequent tasks like calling a remote procedure every day.Otherwise, things like scheduling, logging, resource usage, volume and cost make Lambdas a bad choice compared to traditional VPSs &#x2F; EC2.

Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service.State could be somewhere else, but if you are not also &quot;pure&quot;, you don&#x27;t have any improvement over a normal service.

&gt; Testability?Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms.&gt; Framework adoption?Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up <a href="https:&#x2F;&#x2F;arc.codes" rel="nofollow">https:&#x2F;&#x2F;arc.codes</a> at re:Invent, which is what I&#x27;m using and I generally like it.&gt; Stability? Industry Skills? Proven Architectures...?These are all excellent questions. GAE, the original serverless platform, was around 2010 (edit: looks like 2008 <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Serverless_computing" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Serverless_computing</a>). Serverless isn&#x27;t much younger than say, node.js and Rust are. There are patterns (like sharding longer jobs, backgrounding and assuming async operations, keeping lambdas warm without being charged etc) that need more attention. Come ask me to speak at your conference!

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever.  Thing looked like an absolute nightmare to get up and running.

You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax.And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re already locked in. If you are using it for APIs, just use one of the officially supported packages that let you add a few lines of code and deploy your standard C#&#x2F;Web API, Javascript&#x2F;Node Express, Python&#x2F;Flask&#x2F;Django... app as a lambda.Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for.If you haven’t heard the “right answers” for those questions you haven’t been listening to the right people.Lambdas are just as easy to test as your standard Controller action in your framework of choice.

Unless its a disclaimer, because the poster knows that there is likely to be bias in their post, is aware of that and doesn&#x27;t want to fix that.

&#x2F;disclaimer&#x2F;disclosure&#x2F;When you disclose something, it&#x27;s a disclosure.

Yeah I actually didn&#x27;t know that either. Interesting

Salesforce has stock in many companies through Salesforce Ventures, including Optimizely, Twilio, Box, Dropbox and Stripe.

Heroku is owned by salesforce?  You learn something everyday.

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.

In tech you either die a hero or live long enough to become the villain.

The community is to blame for this.If &quot;serverless heros&quot; are running around promoting Lambda, newcomers will use it without thinking twice...

Because Rust doesn&#x27;t have a runtime initialization.

The Rust runtime has a fast start time as well, FWIW.

I don’t think anybody advocates for rewriting all existing projects as serverless. But if you’re starting a startup, going all in on serverless will let you deliver better products faster. If Paul Graham’s Beating the Averages would be written today, the secret weapon would be serverless, not Lisp.

That&#x27;s more steps than &#x27;just use containers and ignore the serverless meme&#x27;.

If you have 10m requests uniformly distributed, then yes it’s less of a problem, but that’s unlikely. (Even then lambda containers will be recycled multiple times throughout the day, so there is still a small penalty.)

I built an azure function that runs for free that just pings my .NET MVC pages periodically so they are always hot on my cheap hosting.

If the lambdas are always hot, what is the advantage over having a server? I thought the big selling point of serverless was not having to pay for long stretches of time where you don&#x27;t have any requests.

&gt; 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.Shouldn&#x27;t this not be a problem if you&#x27;re doing 10 million requests a day? If you have enough requests, your lambdas should stay hot most if not all the time.

&gt; PSA: porting an existing application one-to-one to serverless almost never goes as expected.Came here to post this and agree 100%. Moving to Serverless requires evaluating the entire stack, including the server side language choice, and how the client handles API calls.Often a move to serverless is better accomplished gradually in stages than the quick &quot;lift and shift&quot; that AWS like to talk about so much. Sometimes you can simply plop your existing app down in Lambdas and it runs just fine, but this is the exception not the rule.

Having used serverless a bit, I’ve run into many of the same issues and generally agree with the advice but depending on your use case it may not be worth contorting your architecture to fit serverless. Instead, I’d look at it as a set of criteria for if serverless would fit your use case.At this point in time the only places I’d use lambda are for low-volume services with few dependencies where I don’t particularly care about p99 latency, or DevOps-related internal triggered jobs.

Once you factor in the learning time for AWS per a developer the cost is even higher.At my previous company we had project with an AWS deploy process that only two developers could confidently use. Teaching a new developer &amp; keeping them up to date was a big time sink.For comparison we had a Rails app setup on heroku that on day one junior devs were happily deploying to (plus we had Review apps for each PR!)

I also feel the same about point 7.The big difference we are migrating away from Heroku to Kubernetes for the same reason.

Same for us.- Corrupted build? Reverse button for the rescue.- SSL? They got you.- Adding new apps in less than 1m?and so on ...

I&#x27;m curious. Did you look into Googles AppEngine? It seems to have a lot of the benefits that Heroku offers, but is much cheaper.Granted that it does impose some limitations, and therefore isn&#x27;t right for all apps. But it does seem like it would work for a large percentage of web apps and REST api&#x27;s.

The cost you&#x27;re talking about is really hard to measure. Were they able to reduce the team sizes and get rid of positions after the change? Did the payroll reduce at all?

I can&#x27;t support point 7. enough. People often forget about the cost of labor.We migrated our company webapp to Heroku last year. We pay about 8 times what a dedicated server would cost, even though a dedicated server would do the job just fine. And often times, people tell me &quot;Heroku is so expensive, why don&#x27;t you do it yourself? Why pay twice the price of AWS for a VM?&quot;But the Heroku servers are auto-patched, I get HA without any extra work, the firewall is setup automatically, I can scale up or down as needed for load testing, I get some metrics out of the box, easy access to addons with a single bill, I can upgrade my app language version as needed, I can combine multiple buildpacks to take care of all the components in our stack, build artifacts are cached the right way, it integrates with our CI tool, etc, etc.If I had to do all of this by hand, I would spend hours, which would cost my company way more. In fact, I&#x27;d probably need to setup a Kubernetes cluster if I wanted similar flexibility. By that point, I&#x27;d probably be working full-time on devops.

Saves time and money by writing and executing less code + S3 is optimized for this task, so it will always perform better than an ad hoc serverless function.

I haven&#x27;t thought about step 3 before, but makes sense. Maybe I should show this to the guy who used Google Cloud Functions to upload images in our previous project :)I guess the reasoning would be that this way the actual time spent in serverless code is shorter and by proxy the service becomes cheaper?

It might do, bu let for some APIs caching doesn&#x27;t even make sense.

&gt; The only valid options for performance sensitive functions are JS, Python and Go.With custom runtimes that&#x27;s not the case anymore. I write my lambdas in Rust.Can&#x27;t stress (7) enough, would also add &#x27;morale&#x27; savings. It can be really stressful for developers to deal with gratuitous ops work.

If you use Cognito for identity management, then there isn’t even need for that. You can just assign users the appropriate IAM role and you can upload directly from the front end.

RE: #3. This still requires a Lambda to pre-sign the URL. No?Granted, this approach is much lighter than uploading an image directly.

&gt; 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.I always sorta assumed that Amazon pre-initialized runtimes and processes and started the lambdas from essentially a core dump. Is there some reason they don&#x27;t do this, aside from laziness and a desire to bill you for the time spent starting a JVM or CLR? Does anyone else do this?

&gt; I&#x27;ve hacked a few lambdas together but never dug deepThen why comment? You clearly don&#x27;t understand the use-case that AWS fits.I&#x27;ve had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS&#x27;s free tier limits.For the right workloads it is 100% worth realigning your code to fit the stack.

You are not wrong. But it is all about saving money on labor. The rest are just the constraints of the system you use. (Aka requirements) its like complaining about the need to use posix for Linux.

That&#x27;s so true and I&#x27;m happy people begin to realize that.The worst for me is the vendor lock in, directly followed by the costs.

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

The way read above comment is - If you can live with following limitations, then use lambda&#x2F;serverless, works great. I have got to a point where for any internal systems used by internal users, lambda is my defacto standard. Very low cost of operation and speed to market. For anything that is external facing I prefer not to use lambda, specially if growth of usage is unpredictable.

I think the comment is exactly opposite of what you are suggesting.The comment is saying that Lambda has limitations and works best when considering those limitations. If those limitations don&#x27;t fit your use case, you shouldn&#x27;t be using Lambdas - or, at least, don&#x27;t expect it to be an optimal solution.

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 system2. lock yourself into managed services wherever possible3. 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&#x27;ve hacked a few lambdas together but never dug deep, so I have very little experience, but these points seem somewhat ridiculous.Maybe I&#x27;m behind the times but I always thought these sort of decisions should be made based on your use case.EDIT: line breaks.

Well, given the feature set of API Gateway compared to a Load Balancer I think it should be expected that it costs more. But that’s also beside the point which is to use managed services to do the heavy lifting. Eg. if you need a PubSub service for IoT, that shouldn’t go through API Gateway and Lambda, there is a specific AWS service for that.

As general rules these sound great at first sight, but don’t really address the main culprit from TFA - like for like API Gateway costs a lot more to process n number of requests.

These are usually the read N items from a database type of queries that GraphQL makes trivial to batch together. Will barely increase response time, but will provide a better experience for users on bad connections.

&gt; 4. Use GraphQL to pool API requests from the front end.What does this look like in practice? Doesn&#x27;t this increase response time for the initial requester?

You forget C++. It’s a great choice for Lambda due to startup times. Python startup time is actually terrible and should be avoided if the call rate is really high.
Actually, Lambda instance is reusable and after spinning up it will be used to handle multiple requests (if ones are coming often enough).

On &quot;7) Always factor in labor savings, especially devops&quot;:DevOps is not a synonym for &quot;ops&quot; or &quot;sysadmin&quot;. It&#x27;s not a position. DevOps is like Agile or Lean: it&#x27;s a general method with lots of different pieces you use to improve the process of developing and supporting products among the different members of multiple teams. DevOps helps you save money, not the reverse.You don&#x27;t even need an &quot;ops person&quot; to do DevOps.

I measured startup of the runtimes a long time ago, and back in the days of node.js 010.x at least, Python 2&#x27;s startup time was twice as fast as Node.js&#x27;s, and Java&#x27;s wasn&#x27;t much worse than Node.js. I don&#x27;t know how .NET fares compared to Java, but I imagine it&#x27;s about the same.Furthermore, eople like to compare runtime startup times, but this tells a very small portion of the story. For most applications, the dominant startup cost isn&#x27;t the startup of the runtime itself, but the cost of loading code the app code into the runtime. Your node.js runtime has to load, parse, compile, and execute every single line of code used in your app, for instance, including all third-party dependencies.Compare, for instance, the startup cost of a &quot;hello world&quot; node.js function with one that includes the AWS SDK. At least, six years ago, the Node.js AWS SDK wasn&#x27;t optimized at all for startup and it caused a huge (10x?) spike in startup time because it loaded the entire library.I would argue that the only languages that are a really good fit for Lambda are ones that compile to native code, like GoLang, Rust, and C&#x2F;C++. The cost to load code for these applications is a single mmap() call by the OS per binary and shared library, followed by the time to actually load the bytes from disk. It doesn&#x27;t get much faster than that.Once you&#x27;ve switched to native code, your next problem is that Lambda has to download your code zip file as part of startup. I don&#x27;t know how good Lambda has gotten at speeding that part up.

Number 3 - thinking in events instead of REST actions, can&#x27;t be stressed enough. Of course, some things must be actions (or another for that is commands), and in those situations, you need something that will turn a command into an event, this is one of the features of CloudState (<a href="https:&#x2F;&#x2F;cloudstate.io" rel="nofollow">https:&#x2F;&#x2F;cloudstate.io</a>), which offers serverless event sourcing - you handle commands, and output events that can be further processed downstream by other functions.

&gt; Below is a report for one request, you can see we&#x27;re using 3.50ms of compute time and being billed for 100ms, which seems like a big waste.Doesn&#x27;t sound like your point number 1 is valid at all, quite the opposite.

&gt; The only valid options for performance sensitive functions are JS, Python and Go.I can think of a number of other languages that would probably easily surpass these, especially on latency.

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.

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 &quot;saving one event to the database&quot;.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 &quot;15%&quot; 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 &quot;0.42s vs 0.48s&quot; 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 &quot;4x slower&quot; instead of &quot;15% slower&quot;.

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

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

The use case is lumpy work. You have some batch processes that are unpredictable. Could be hours without a call, then suddenly you need to scale up to 20 cpu to process a bunch of requests. One example is say processing pdfs in a crud app where people can generate pdfs on demand with large images.I have used Azure Functions so I will talk to that: There are two options, one is a consumption plan where it is truly &#x27;serverless&#x27; and they provide you with server time on demand. The other plan - app service plan - allows you to run these on your existing Azure resources. Another option is to get the runtime on a Docker image and run it on a container outside of Azure completely (but you lose a lot of the monitoring benefits).Anyway the point is that at least in Azure you can sort of slide the dial to how &#x27;serverless&#x27; you want to be - one extreme is the consumption plan, then you can go with the app service plan, then less serverless would be to run AKS (Kubernetes) with autoscaling, then to run VM&#x27;s with autoscaling, then VM&#x27;s with manual scaling, then finally perhaps rent a physical server in a data centre, then buy a physical server and stick it in a rack in your office.The advantage of pure serverless over the less extreme ways is if you have wildly unpredictable loads going from 0 to high to 0 at different times, and don&#x27;t want to (or can&#x27;t) set up a reasonable scaling system to suit (or don&#x27;t want to wait for the scaling to &#x27;kick in&#x27;).

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&#x27;t find any use case where it would make sense.

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&#x2F;price trade-off.

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.

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.

This is all true, but serverless is wonderful for light tasks that aren&#x27;t run very often (it&#x27;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.

...and the language choice has a measurable impact on the cold start time. I&#x27;ve measured it - as have others[1][2].You&#x27;re right that it&#x27;s not just about the language runtime though. I must admit I&#x27;d forgotten about the container spin up et al as well (thankfully the recent ENI fix for VPC lambda&#x27;s has been released because that was threatening to bite us hard on one project).[1] <a href="https:&#x2F;&#x2F;mikhail.io&#x2F;serverless&#x2F;coldstarts&#x2F;aws&#x2F;languages&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mikhail.io&#x2F;serverless&#x2F;coldstarts&#x2F;aws&#x2F;languages&#x2F;</a>[2] <a href="https:&#x2F;&#x2F;levelup.gitconnected.com&#x2F;aws-lambda-cold-start-language-comparisons-2019-edition-%EF%B8%8F-1946d32a0244" rel="nofollow">https:&#x2F;&#x2F;levelup.gitconnected.com&#x2F;aws-lambda-cold-start-langu...</a>

&gt; Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn&#x27;t need benchmarks to work that much out - it&#x27;s software development 101.This isn&#x27;t true. The overhead from the article comes from API Gateway, and has nothing to do with running faster&#x2F;slow via a Lambda or EC2 instance. The real performance hit in Lambda comes from cold-starts. But if you&#x27;re willing to accept minor cold starts for not running infrastructure 24&#x2F;7 then it can be a huge benefit.

It&#x27;s not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For &quot;spiky&quot; 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&#x27;t need benchmarks to work that much out - it&#x27;s software development 101. However you then went on to compare JIT compiled languages on lambda vs EC2 you&#x27;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&#x2F;vi, GNOME&#x2F;KDE&#x2F;etc, Windows&#x2F;Linux&#x2F;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&#x27;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&#x2F;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&#x27;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&#x27;t hosting though, it&#x27;s all the edge cases around what needs to happen when your typical hosting plan isn&#x27;t enough.

Serverless: slower and more expensive