PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article:
1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go.
2. Use managed services whenever possible. You should never handle a login event in Lambda, there is Cognito for that.
3. Think in events instead of REST actions. Think about which events have to hit your API, what can be directly processed by managed services or handled by you at the edge. Eg. never upload an image through a Lamdba function, instead upload it directly to S3 via a signed URL and then have S3 emit a change event to trigger downstream processing.
4. Use GraphQL to pool API requests from the front end.
5. Websockets are cheaper for high throughput APIs.
6. Make extensive use of caching. A request that can be served from cache should never hit Lambda.
7. Always factor in labor savings, especially devops.
I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong.
"Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs.
You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework.
I have been experimenting with this approach lately and have been having some success with it, deploying relatively complex, reliable, scalable web services that I can support as a one-man show.
> 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.
Exactly, it's like saying to someone running a restaurant that buying their bottled water from a convenient store is more expensive than buying it in bulk from Costco.
It's entirely missing the point. At the end of the day, you have to look at your specific usage pattern and pick the best option for you. Obviously, as with any other technology, anyone who forces a specific option in every possible situation is most likely wrong.
To eliminate the need of a web framework? I don’t understand the rationale, if I can get all what’s mentioned done with a good web framework, I will be more than happy to do that.
Firebase now makes most of these painless. They've done a really good job. If your starting from the grounds up and can stomach using a google product Firebase is the easiest to work with by far.
This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went:
Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!!
Me: What did you do about JVM warm up?
Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up.
... Me thinking: Uhh, but what about scale down to zero?
Me: What do you do about pricing when your service grows?
Colleague: We use it only for small services.
... Me thinking: Uhh, start small and STAY SMALL?
Me: How was performance?
Colleague: It was on average 100ms slower than a regular service, but it was OK since it was a small service anyway.
... Me thinking: Uhh, but what about services who _depend_ on this small service, who now have additional 100ms times to comprehend with?
Overall, I think his answers were self explanatory. Lambda seems to be a fast prototyping tool. When your service grows, it's time to think how to get out.
Something about the Lambda/FaaS/serverless hype reminds me of early 2000s enterprise Java, when everyone was trying to replace code with XML configuration.
It's obviously at a different point in the stack, but the promise is similar: "Just say what you want and it magically happens" — and indeed that's the case for FaaS when your problem is small enough. But XML-configured frameworks also offered that convenience for their "happy problem space". You could get things done quickly as long as you were within the guard rails, but as soon as you stepped outside, the difficulty exploded.
I'm not convinced AWS Lambda is all that different from a web framework, it's just on a higher level. Instead of threads responding to requests, you have these opaque execution instances that hopefully will be spun up in time. Instead of XML files, you have a dense forest of AWS-specific APIs that hold your configuration. That's how it looks from the outside anyway.
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).
Disclaimer: I work for Salesforce, Heroku’s parent organisation.
I have had so many conversations with devops managers and developers who are individual contributors and the Lambda hype reached frothing levels at one point.
Contradictory requirements of scale down to zero, scale up infinitely with no cold starts, be cheap and no vendor lock in seemed to all be solved at the same time by Lambda.
Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for.
It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other products that are often discussed on HN.
But let's be clear, we are talking about commercial products and there is a capital interest in selling these services to all of us devs and engineers.
So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel that we should be MUCH more insistent in pointing out when a product does not make sense instead of jumping onto the hype train.
I am basically surrounded by "LETS TRANSFORM EVERYTHING TO KUBERNETES THIS WEEK!" exclamations, conferences are basically "DID YOU ALREADY HEAR ABOUT KUBERNETES?" and so on ...
It reminds me of Ruby on Rails, a mature and well-developed framework used by global tech firms (correct me if wrong: Airbnb, ~Stack Overflow~, Github) to handle parts of their backend in 2019. But for half a decade now even tiny companies have been screaming around about FancyHTTPTechThisYear (tm) because scale while reporting 1/500th of the traffic of some famous Rails users.
This is not engineering with objectives in mind, it's more akin to the gaming community yelling for a new console.
They're doing over 100rps if they're doing 10M requests a day. That's not a good use case for Lambda. If you're going to be that heavily utilized it makes more sense to run your API on EC2 or ECS/Fargate/etc.
Lambda is a good use case for when you have lots of not-often-used APIs. Lambda is a great solution for an API that's called a few times a day. It's also great for when you're first starting out and don't know when or where you'll need to scale.
But once you get to 100rps for an API, it's time to move to a more static setup with autoscaling.
I've always found Troy Hunt'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.
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.
Is there any fundamental reason for this, apart from AWS' pricing model? It seems to me that ideally, serverless should scale from extremely small to very big without too many problems.
"It's also great for when you're first starting out and don't know when or where you'll need to scale."
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's likely you'll run into scaling problems. This is a big, stressful distraction and a serious threat to your customers' 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'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're starting to claw your way to early traction very well might.
I thought the point of Lambda wasn'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.
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.
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.
>The whole idea of serverless is so you don't have to manage infrastructure
That'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't use serverless.
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'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't have to manage infrastructure
Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.
All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.
>The whole idea of serverless is so you don't have to manage infrastructure.
...when you are validating your product/market (100 request/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.
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're already using. The ALB option has it's own caveats though...
The whole idea of serverless is so you don't have to manage infrastructure
That's the selling point of AWS in general, but I wouldn't be surprised if (non-tiny) companies are still spending at least as much on AWS/etc. as they would on in-house infra. That is, they're paying for it anyway, and possibly at a premium.
> 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.
If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you'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't have to think about where to run it.
It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines).
Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchmarks to work that much out - it's software development 101. However you then went on to compare JIT compiled languages on lambda vs EC2 you'd notice the performance is much closer to each other.
You say tech should be about the results rather than religion and while I do agree there is a lot of cult-like behaviours in IT (and there always has been - emacs/vi, GNOME/KDE/etc, Windows/Linux/MacOS, etc) organisations that really depend on their services genuinely do load test their stuff to hell and back to ensure they are getting the best price, performance, scalability (where required) and resilience too.
That last point is also important when looking at infrastructure. Serverless often (though not always - you need to look at it on a case by case basis) offer you better resilience than rolling your own with EC2 instances. I mean sure, you can span multiple AZs yadda yadda yadda - it's all doable. But again you have to factor in spin up times and spare capacity (eg if you lose an AZ and then have 100% of your traffic over 2/3s of your existing hosts, are they going to have enough spare capacity to survive the spin up time of additional hosts or are you going to lose everything like toppling dominoes?)
Ultimately though, if you predictable traffic and don't have a requirements for redundancy then you could just host it yourself for a fraction of the cost of running stuff in the cloud. The real technical challenge isn't hosting though, it's all the edge cases around what needs to happen when your typical hosting plan isn't enough.
> To be honest I hadn't thought at all about the pricing beforehand. I just figured "Pay for what you use" sounded like it would be cheaper than paying for instances that are on 24/7.
Deciding to do a whole infrastructure change to save money without even stopping 5mins to do a quick math on the expected savings seems like a recipe for disaster.
Just switching from m1.small to t2.small would bring their costs down to $55 from $96 for the compute. Just make sure to create a monitor in case you use up all your burst capacity. Other than that a quick reservation would bring that down even further, and all of this with zero re-architecting.
Serverless is super cheap if your workload is not serving requests constantly. It's like renting a car 365 days out of the year instead of purchasing, it only makes sense if you only need it sporadically.
The pricing he quotes in the article he quotes 1350$ per month.
If you remove API gateway (which appears you can) , price is about 300$ (from the article itself).
He never mentions what memory provisioning he uses for his lambda but he does remarks that he has 10M requests a day and that'll cost 10$ a day in lambda costs. Which comes to 0.000001 per request. That puts his service at 512MB memory at 0.000000834 (+ 0.0000002 per request).
If instead he used a 128MB instance (which is reasonable if your request is 3ms, but probably not enough to run .net core) you'll be at ~0.0000004 . Which would put it at roughly half cost. At about ~120$, which is the same as his server setup.
He did mention that he could cut his costs by reducing memory usage.
Seems like there's no reason why it couldn't match up to the server-side cost. I don't think the cost-benefit analysis is as bad as he makes it out to be.
Seems also like there's a very big mismatch in pricing here. If his workload is about 3ms per request but he is charged for 100ms a request, then that's a 33 fold increase in pricing compared to being charge per millisecond. Seems like quite an opportunity for some cloud provider to differentiate itself.
I 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.
To me, serverless promises "no hassles" hosting. If what I save on sysadmin stuff needs to be replaced with a lot of new accounting stuff, where's the saving?
I recently saved a company from serverless: development had completely stalled, continuous delivery was insanely inefficient (you couldn't deploy your set of functions at once because of dependencies), vendor lock-in made it a pain to develop locally (cognito in particular), CI testing was also a big pain (serverless-offline), the project also had reached the endpoint limit so basically they had to split the project (it wasn't even in production at the time ...) a dev implemented an aggregator for serverless config so that they could keep on working locally ... An epic disaster, we all thought there was no way this company wouldn't die, the founder developed suicidal thoughts and I could only understand him.
All my congratulations to the "Agile leading company" that provided a 800€/day consultant (probably going to read this) who just followed the tutorial to setup a new project on serverless without any web framework, because you know, "it's the future", and "i like to sleep at night", after they and some of the team had been brainwashed by an AWS event (my initial review concluded with "I admire the courage to start a project without a framework" which was replied with "what is a framework ?"). A waste of hundreds of thousands bucks, but that was not the only mistake : they had 100% code coverage from tests but all tests like all the runtime code was wrapped in huge try...except blocks, I have never seen a team talk as much about "Clean Code" and have such a pile of debt. The Agile company consultant called in recently and said they were sorry, that actually Lambda wasn't good for the use case, and that the consultant was now senior and twice the price.
The company now deploys with Ansible and Docker with compose and practicing what I call eXtreme DevOps (one ephemeral deployment per branch on branchname.ci.example.com), development is back on track, new versions every week... They also trashed the serverless code in favor of a Django Rest Framework app that I coded in 3.5 hours during a night after being there for 2-3 weeks (it was the 6th or 7th week that development had stalled "refactoring" "making lambda happ" "trying to have a local environment"), basically presented it to the team the next day at the retro (where we could see nothing creating value was actually moving forward) and said: make your serverless thing work, or let the frontend people choose what they want to build on : a backend code that became an unusable pile of debt or a backend code that works, presents a self-documented REST API, with an administration interface that they needed, and save the company by creating value instead of "just trying to fit into the proprietary framework that is serverless lambda".
I thought commenter W. Van Dam made some good points:
“ First, you don't need API Gateways if you use an AWS SDK. Like this guide shows. And of course you don't need a load balancer, because that's precisely one of the things that serverless takes care of for you :-)
More importantly, you didn't actually compare serverless to your current situation.
With serverless solutions you can typically save cost in terms of server management. Serverless isn't maintenance free, but you should be able to reduce your monthly cost (e.g. lower labor cost).
You're right to research whether it actually works for you, but I think you're not done yet ;-)
Also, perhaps CloudFlare Workers are of interest to you. It's a rather new offer in the market. They charge 0.50 dollar per million requests, with a time limit of 50ms per request. Sounds like this combination would work well for you in comparison to AWS Lambda”
Our company has customers who install our SDK, and that SDK pushes and pulls data from our service.
We service ~400 million API calls per month. Half of the calls pull static cached data from a CDN (Cloudfront), and the other half ingests data pushed to it from the SDK (anywhere from 10kb to 400kb per call).
We run of Elastic Beanstalk, which is basically an abstraction later on top of an autoscaling EC2 cluster.
Back when Lambda (and API Gateway) first came out we were excited. It sounded like the perfect way to break free from our “legacy” server architecture.
Until you do the pricing calculations. It wasn’t even close. Managed services like Lambda and API Gateway were prohibitively expensive. (Thank god we didn’t begin development with the services before scaling - we would have never been able to scale at those prices).
Not only price, but performance was horrible. Lambdas take forever to warm up (unacceptable for latency sensitive use cases).
I’ve never really thought of Lambda / API Gateway as anything other than a cool pet toy. Although maybe thats being a little harsh..?
"Serverless", or "App Engine" as it was called for the few years prior the hype, actually delivers pretty good results for a range of parameters. It might even be a wider range of parameters than the ones where the results are subpar... Or not, I'm not sure how to weight the "I have a predictable base load large enough for its cost to dominate the other factors" vs the other cases. But as always - popularity of a tool is a poor predictor of fitness to particular job at hand.
This feels very "Serverless is cool, everyone is saving money on it, lets do the same"
> I only had to add a simple config file, add one dependency and one small startup class to my existing API project.
This is not the way to do it, you have to spend some time on lambda approach.
Usually splitting up your code in to smaller chuncks so you don't end up with long spool up times and you can do things like keeping your lambda warm and caching high impact parts of the code. (sometimes of course you can't cache, I know)
Having gone through this process myself with a very very large code base, it would have not worked to just slap it into serverless.
Going server less can save you money, but not by just taking your existing app and throwing it on Lambda.
I enjoy using AWS Lambda and believe it has many valid use cases. Unfortunately, Einar learned the hard way and hastily made a significant decision with regards to their architecture. To be fair, Einar admitted their faults in their decision was rooted in a lack of understanding in the AWS API Gateway and Lambda pricing model. However, a lot of comments are using this as a source to validate their opinions on why they believe AWS Lambda and AWS API Gateway is bad. Lambda is excellent for low volume, bursty traffic. It is not designed to be a solution for a web api that gets 300M reqs/month. It is technically feasible but fiscally irresponsible. Conversely, if going Serverless means you can get rid of a system administrator for a dedicated API server then that is a whole different situation where it would be fiscally irresponsible not to use serverless. With regards to the performance concerns, concurrent requests spin up concurrent Lambda functions. If you can limit the number of concurrent processes you _might_ actually see better performance with Lambda than you are seeing now.
Serverless has it's place. If you have lots of events and they don't fire all the time it's great. Or, for small additive things on a mostly static site (like one hosted out of s3). Or for some other specific cases.
Serverless may change the landscape of development but it's going to take time. The costs need to settle into place while tools and processes need to come together.
Right now it appears it takes longer to build something with serverless, is more difficult to manage for day-2 deployments, and it costs more to operate for things like API servers.
I look forward to serverless doing a lot more in a cost effective manner. It's just going to take time to get there if it ever does.
A comparison of Serverless to any kind of compute that uses line-item comparison and, crucially, doesn't mention Total Cost of Ownership (TCO) of the latter is flawed.
To conclude that Serverless is more expensive one would have to compare the calculated TCO of managing EC2 against the line-item cost of Lambda.
The article is also operating at the small change end of the spectrum where cost differences are basically noise. Replacing the TCO of operating a thousand instances with the line-item cost of lambda would be an improved analysis.
[+] [-] abiro|6 years ago|reply
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.
[+] [-] claudiusd|6 years ago|reply
"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.
[+] [-] 0xbadcafebee|6 years ago|reply
At least I don't have to learn that complex "systems admin" stuff.
[+] [-] ehsankia|6 years ago|reply
It's entirely missing the point. At the end of the day, you have to look at your specific usage pattern and pick the best option for you. Obviously, as with any other technology, anyone who forces a specific option in every possible situation is most likely wrong.
[+] [-] teacpde|6 years ago|reply
[+] [-] Illniyar|6 years ago|reply
[+] [-] rdsubhas|6 years ago|reply
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.
[+] [-] pavlov|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] neuronic|6 years ago|reply
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.
[+] [-] jedberg|6 years ago|reply
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.
[+] [-] crypteasy|6 years ago|reply
https://www.troyhunt.com/serverless-to-the-max-doing-big-thi...
[+] [-] aserafini|6 years ago|reply
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.
[+] [-] joelthelion|6 years ago|reply
[+] [-] danenania|6 years ago|reply
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's likely you'll run into scaling problems. This is a big, stressful distraction and a serious threat to your customers' 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'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're starting to claw your way to early traction very well might.
[+] [-] johnnyfaehell|6 years ago|reply
[+] [-] ajhurliman|6 years ago|reply
[+] [-] tedk-42|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] discordance|6 years ago|reply
That'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't use serverless.
[+] [-] ilimilku|6 years ago|reply
[+] [-] hdra|6 years ago|reply
Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.
All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.
[+] [-] lucasverra|6 years ago|reply
>The whole idea of serverless is so you don't have to manage infrastructure.
...when you are validating your product/market (100 request/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.
[+] [-] EwanToo|6 years ago|reply
[+] [-] rhizome|6 years ago|reply
That's the selling point of AWS in general, but I wouldn't be surprised if (non-tiny) companies are still spending at least as much on AWS/etc. as they would on in-house infra. That is, they're paying for it anyway, and possibly at a premium.
[+] [-] skrebbel|6 years ago|reply
Can anyone explain to me why there's "camps" to this debate?
[+] [-] scarface74|6 years ago|reply
[+] [-] pas|6 years ago|reply
But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|
[+] [-] dunk010|6 years ago|reply
Do you think you'll have the same opinion in five years time? Or how about three years?
[+] [-] peterwwillis|6 years ago|reply
If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you'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't have to think about where to run it.
[+] [-] laumars|6 years ago|reply
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.
[+] [-] vasco|6 years ago|reply
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|6 years ago|reply
He didn't decide to do a whole infrastructure change. He just ran an experiment that was about more than just cost.
[+] [-] necovek|6 years ago|reply
It's obvious from the article that he would have even lived with a slight bump in pricing if he got that.
[+] [-] snak|6 years ago|reply
Spot on! Great analogy.
[+] [-] euph0ria|6 years ago|reply
[+] [-] Illniyar|6 years ago|reply
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|6 years ago|reply
[+] [-] yummybear|6 years ago|reply
[+] [-] 1337shadow|6 years ago|reply
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|6 years ago|reply
[+] [-] gigatexal|6 years ago|reply
“ 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”
[+] [-] cj|6 years ago|reply
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..?
[+] [-] lrem|6 years ago|reply
[+] [-] botto|6 years ago|reply
> 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.
[+] [-] lovetocode|6 years ago|reply
[+] [-] rapsey|6 years ago|reply
The point of all these levels of abstraction is it takes less work to manage. Cost and performance is always worse.
[+] [-] mfer|6 years ago|reply
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.
[+] [-] opsunit|6 years ago|reply
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.