41–50 of 733 posts
If you're really looking to save money, don't touch AWS.
Source: I run the frontend for an interactive "one-page-app" site about 3x larger on a $30 VPS with room to spare.
“ 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”
I don't understand the term or brand "serverless", to me it seems it's still using a server, meaning a fast computer somewhere running 24/7 in a datacenter. To me "serverless" implies decentralized networking, with a DHT or some kind of network authority, meaning P2P networking at one point or another. Am I missing something?
"Serverless" is "I don't have to provision a server, or worry about where it is, or maintain it, or what OS it's running, or any of the other fiddly details." You define a function, you hand that function to a company, and they make sure it runs when certain conditions are met. You then don't have to worry about the server.
You can’t do that with EC2 nearly as easily or cost effective.
This is where serverless really shines. If you have a fixed static load, you should be using the cheapest available compute instance from EC2 as possible. Reserved instances & test performance in lower cost data centers.
You can replace API Gateway by an ALB, which will be much much cheaper in the article use case.
Lambda is also great when it's triggered by everything but API Gateway. Analysing a file uploaded on S3, reacting to an SNS message or consuming messages in SQS.
Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…
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.
I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with. The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fo…
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.
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.