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.
I'm fully aware of this but never do it because I'm pretty much incompetent as a sysadmin. I don't want to be in a position where I can break an existing project while trying to configure something new I don't understand yet. Nor do I want to run security updates for a blog I setup 5 years ago.
I'm not 100% thrilled with going serverless because it makes debugging awful, but it has saved me money and it makes most things easier. If I went back to shared hosting, I'd just be paying for the privilege of getting to shoot myself in the foot.
- Mumble server for my wife's WoW guild (They don't use Discord because some of their peeps are running on really dated hardware that can barely handle WoW, let alone an Electron app running concurrently with WoW)
- Taiga.io task tracker
- Dev server for a web game I'm working on (If I ever decide the game is good enough to publish, obviously I'd run dev and prod servers on separate instances)
- IRC bouncer
- Pi-hole DNS for my phone
Containers? Don't need 'em. And each process requires next to no CPU time, so I always have nearly full CPU credits. RAM is enough unless I'm building the latest version of my IRC bouncer, but hitting the paging file for a few minutes is no big deal.
Since the organization only has the one site, there's not enough usage to warrant $5 a month for even a tiny a virtual server.
So e.g. if the queries you are making aren't time sensitive or are easily cached switching to s3 can be okay.
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.
Sure, if you ping your lambdas frequently to keep them from having cold starts, and you’ve worked with Amazon to increase your concurrency limits 100 fold, you might be able to handle 1M requests in a second. But then you’re being charged a lot more than just for those 1M requests.
Why would you need to put a Lambda in a VPC? For access to a database, other EC2 bound resources, or overall network security reasons (such as outbound network monitoring).
Here's the meat, to save you a click:
> AWS says that the one-time setup of the shared network interface can take 90 seconds to complete. But because the network interface gets created when Lambda functions are first created or VPC settings updated, the connectivity-related latency during cold start approaches zero. The same goes for function scaling, which no longer requires new network interfaces for each new execution environment.
Plus, receiving 1 million requests in one second, you'll have cold starts for every new container that gets created for you, so achieving consistent low latency would be impossible since you don't control that.
This is a very predictable and constant traffic load and not at all suitable for serverless/lambda.
In fact, its the complete opposite.
Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from work and turning things on).
See also: traffic jams and people switching on their electric kettles en-masse during intermission of major soccer matches. The first disrupts whole economies and the second has given rise to 'fast pumped storage' at the electrical grid level.
Just because you don't see the accumulated effects does not mean they aren't there.
So the patterns are (obviously) predictable, but the 'dynamic range' of the load is extremely wide, ranging from stampedes on the cardinal points of the clock face (0/15/30/45 min) to crickets the rest of the time. Some form of elasticity is required unless you are willing to pay for idle servers sized for the episodic peaks.
For example, to avoid the 00/15/30/45 issue you offset yourself randomly over a few minutes within that range to avoid overloading mesh & cellular radio networks.
This has a smoothing effect on the traffic as a whole (as seen from the server) which reduces the "dynamic-range" as you're terming it.
What you propose is one way of doing so. Again, I remind you that an IoT SaaS has multiple tenants and these tenants can't be expected to collectively coordinate. And in certain domains, it is not possible to dictate timing requirements to the client tenant and thus enforce the (SaaS) providers traffic requirements.
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.
Large compute and memory intense stuff isn't suitable for serverless
Source: Seen it happen, am certified.
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.
You know those url.py files in a django install? Those are the equivalent of ELB/APIGW thing. You don't manage those, you make them once.
Not sure where you personally draw the line between app development and infra work, but for me "request that comes on this path, calls this function", either via ELB -> backend or APIGW -> lambda, or you know, whatever you use for your django app -> a function defined in a view.py, is app, not infra.
>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.
This may be a specific criticism of AWS Amplify, but all I'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'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'll admit I'm a sucker for infrastructure as code. But, as it stands, I can't see how this really saves anyone any time. It'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't have Cognito working with optional TOTP 2FA. The withAuthenticator component apparently only renders the TOTP setup if 2FA is required. I've spent hours trying to work this one out, including spending time on the Amplify Gitter channel.)
> I'll admit I'm a sucker for infrastructure as code.
... which you have to maintain, which probably means Ansible/Chef/Puppet/Salt/etc scripts. Which is fine, it's just a trade-off. I've spent weeks maintaining those kinds of things though, and inevitably when you come back in a year, something's broken.
CloudFormation isn't great, but it usually gets the things provisioned - CF Cognito support sucks though, and haven't been impressed with Cognito at all. Seems too enterprise-y. Like e.g. CodeBuild, which supports 0 open-source use-cases. IDK what some of those teams are doing, but even Azure Pipelines is years ahead.
I think that's a general problem with AWS at the moment. Too many sub-par offerings. Still worth it for S3, DynamoDB, SQS, and Lambda or EC2 (just, the EC2 UX is awful). And those are huge time savers.
I suppose I could look at Aurora instead, although Amplify only supports MySQL Aurora, so no luck with Postgres again. Likewise, the price advantage goes away. And now I'm stuck figuring out a wildly convoluted TCO calculator. I could look at another hosted DB solution, but now I either need to move everything to a new provider or find a way to deal with WAN latency for simple DB operations. Moving means learning yet even more otherwise useless knowledge about a single provider.
I'm sure a lot of this is just growing pains. But as a lone dev just poking at something in his spare time, all these "get running in 30 min. or less" tutorials fall apart the moment you try to do something outside that tutorial. And the number of services available, their weird pricing structures, their implicit deficiencies and explicit limitations, just mean I'm still wasting time not building software :-/
I agree tech is getting democratised, but when talking about products that allows it, I'm thinking of products like Firebase or the recent darklang, not AWS Lambda. From all the Lambda usage that I've encountered so far, they are still very much in the domain of a "sysadmin".
You only have to setup security groups if you are running lambda's in a VPC, which in the simple case (e.g., not running a cloud extension of an internal corporate network) you probably don't.
https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/
And, yeah, its a lot simpler than a traditional server setup without that. And even with it.
When there is is no infra to deal with, U/DevX becomes much easier. "Remix this" is pure product joy
So, in certain respects it's an enabler. Context always matters.
I mainly went with API Gateway since that's the default setup the serverless framework uses.
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.
Can anyone explain to me why there's "camps" to this debate?
On one hand you have a docker image with your source code/static binary baked in. The other you have your source code/binary encapsulated in a serverless framework (with an Event handler of sorts as your input).
The container doesn't lock you into a particular ecosystem, but hasn't solved how you deploy and run your container (Heroku, managed k8s, AWS ECS/EKS/Fargate). Serverless on the other hand will give you a runtime for your API and allow you to go live (assuming you've setup an account or whatever).
To migrate something that already works to serverless is a bad idea. Maybe if you'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.
All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.
You can create a web service in whatever language and framework you want, all you need to do is read a PORT environment variable for incoming messages. The freedom was really awesome, instead of being confined to supported languages and frameworks you get in the functions landscape. Only confinement was that you're pretty much limited to HTTP calls, unless that has changed.
Personally i find the freedom of pick your own language and framework a big positive, and billing is finer on cloud run compared to AWS Fargate(rounded up to next sec) if im not mistaken. I do wish they would make billing even more finer instead of rounding up to the next 100 ms, rounding up to the next 10ms would be nicer when you use non GC or Runtimed languages, like Rust.
There are three use cases for lambda:
1. Event based triggers where something happens externally that you want to process. You can do the same thing with Fargate by either having a continuously running process that reads from a queue or responds to an API request (AWS Event -> SNS -> API).
2. Timed events. You can do this with Fargate directly (https://aws.amazon.com/about-aws/whats-new/2018/08/aws-farga...)
3. APIs. Fargate supports autoscaling.
Fargate can do anything that lambda can do without the limitations - request and response payload size, a 10GB temporary storage drive instead of a half megabyte, and no 15 minute runtime limit. Of course no cold start times since you can have a minimum number of instances always running without Ping hacks.
Lambdas relatively fast to spin up and thousands instances can be run at once. But they are time limited running for at most 5 minutes and using 3GB of RAM.
You can do most of the same things with either (after all, they just execute code), but you cannot ignore their very different limitations and that they are conducive to different workloads.
But, also you can have up to 4 vCPUs with Fargate as opposed to one with lambda.
The point of both is to sacrifice some capabilities in order to remove operational complexity. Lambda just goes farther along that spectrum than Fargate does.
My Docker file that I used to convert my Node/Express API that was running in lambda consisted of...
- setting environment variables (I had to do the same thing in my CF template for lambda)
- retrieving the Node Docker image (one line of code - I had to specify one line of code in my CF template with lambda to specify that is was using the Node runtime)
- copying the files from the directory to the container (as opposed to specifying the locsl path of the source code in the CF Template)
- Specifying the Docker Run command (as opposed to specifying the lambda handler).
- running “Docker build” as opposed to “CloudFormation package”.
How it does it is an implementation detail.
In fact, if you use lambda layers, it’s almost equivalent to building Docker images.
But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|
Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.
And so it seems to miss the obvious middle ground between raw EC2 (or Elastic Beanstalk managed EC2) and full on-demand Lambda, which is modern managed hosting (PaaS, Deis/Dokku/Heroku).
https://aws.amazon.com/lambda/serverless-architectures-learn...
https://aws.amazon.com/fargate/
AWS Fargate is a compute engine for Amazon ECS that allows you to run containers without having to manage servers or clusters. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers
Running FaaS on AWS without knowing anything about servers and "OS stuff" screams like building the roof without the foundation. And I know that it sounds convenient to run everything as isolated little abstract functions, and ... it works, but it's pricey. But you can do it for cheap, you can deploy Kubless or OpenFaaS (or OpenWhisk or whatever is Apache's equivalent). Naturally AWS exploits this knowledge gap for a lot of their managed services.
Do you think you'll have the same opinion in five years time? Or how about three years?
If you look at where AWS makes most of their money, it's selling EC2 hardware.
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.
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.
"You already have to walk to the store, so hiking the appalachian trail is just another part of your walking strategy" -- 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 "you already have to do X so doing anything else that I can also call 'X' should be trivial" is a flawed form of analysis, it tells us nothing that you can call all of it "walking" or all of it "patching strategy".
This is "you'll always have to do X, so might as well do 10x" argument...
Just because I have to manage patches for 'my app and it's libraries' doesn't mean also handling the OS and everything else that would already be covered by the serverless service is no biggie...
If you're doing a toy demo app, or a website for your local flower shop, yes...
Any non trivial company's systems are not just some random container with a "Nodejs app" inside. They need to keep state, handle caching, redundancy, global CDNs, and lots of other layers.
You either build all those and full ops on top of containers (or whatever), or you get them off the selves and ready to play with a serveless service and their state solution, plug-and-play ready-to-use caching layer, and so on...
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.