To my mind this completely negates any value proposition of the container. The only thing missing, at face value, is something as straightforward as the Dockerfile for building base images. I imagine that shouldn't be hard using things like guestfish etc in guestfstools.
Lambda works great as a deployment and execution model. This allows anything to run on Lambda, not just specially prepared runtimes.
Prefer containers because build once run anywhere, as opposed to build for each deployment target.
When your container is not running (say, 99% of time), other customers' containers are running. No need to ever boot the kernel, etc.
One might say that an unikernel has advantages over it. But it also has a higher barrier to entry.
How similar is AWS Fargate to what you're describing?
With Fargate-Lambda crossover I wouldn't be running anything 24/7, and it would be a lot less resource intensive than one Lambda-Container per request as well.
Google's App Engine gets / got this right when they first launched, but to make it work they had to demand apps be written for their sandbox (like AWS Lambda), because of which the model isn't as general purpose. Firecracker would allow regular containers to be used this way, making a Firecracker service the first service to allow general purpose servers to be started and stopped (all the way to zero) based on incoming traffic.
https://cloud.google.com/blog/products/gcp/introducing-app-e...
(and, as thesandlord notes below, arbitrary containers is the idea behind g.co/serverlesscontainers)
Disclaimer: I work on GCP.
It would be great if they announced that they were gonna remove EKS master costs altogether. Technically Firecracker should make it possible for them to run that infrastructure more efficiently :)
- If we're talking about a business that provides a service to local companies, there are quite a few hours during the week where everyone is either asleep or enjoying their weekend. Not every company has millions of users spread across every time zone; some companies provide a niche service to a small number of high paying users.
- Lots of developers have small hobby projects that are inactive for most of the day/week.
Scale to zero can be convenient, but it's not usually a make-or-break thing.
What I was getting at is that the "scale to zero" feature with Knative is rather worthless if you spend more money just running the Kubernetes master on EKS alone than you would spend running a $5 or $10 per month DigitalOcean instance.
Lambda scales all the way to zero, and it's free when it's at zero. You just pay for what you use. Actually, you pay for what you use minus $7, since every account always gets the free tier for Lambda.
5M GB seconds (2 * 86e3 * 28)
2400M function invocations @1k qps, (86e3 * 1e3 * 28 / 1e6)
Does the math checkout?
I know which model allows me to "scale to zero" faster. If I hand you $10, you will give me a nice used Honda?
Using your numbers and current Lambda prices:
5M GB-seconds * $0.00001667/GB-sec = $83.35
(5,000,000 * 0.00001667 = 83.35)
2400M function invocations * $0.2/million = $480
(2400 * 0.2 = 480)
total = $480 + $83.35 = $563.35/month, which is nowhere close to $17k/mo. I have no idea how you got that number.
I also find it highly unlikely that most businesses are servicing 2.4B requests per month on their API. In my opinion, you either have to be an absolutely enormous monster of a business or have a really unusual business model to be at that level of utilization and not be huge.
Whatever your business, you're unlikely to be spending $10/mo in resources to service nearly 30 billion requests per year. You're probably going to need more than $10/mo just to store the access logs for your API, let alone useful customer data!
In reality, a lot of entire businesses would be much lower in utilization than that. The downsides of a single DigitalOcean droplet are many: a single point of failure, and you'll never achieve high availability if you apply updates regularly and reboot, unless you have multiple $10/mo droplets and a load balancer. You'll also have high latency to customers outside of your region of the world, unless you run a HA-cluster of multiple droplets in each regional datacenter that you care about. Call it three droplets per region and we'll say you want to run them in five regions, so that's $150/mo just in droplets alone, plus a $10/mo load balancer per region, so $200/mo. Did I mention that you or your engineers are going to be responsible for doing the maintenance and replication across regions? Surely the number of engineering hours devoted to this upkeep will be worth more than $350/mo. Huh, I guess we just justified Lambda's costs.
And again, I never claimed this was some kind of snake oil magical solution.
I don't know why you think I'm opposed to the DigitalOcean solution and some sort of salesman for Lambda. I use DigitalOcean heavily for my personal stuff, and I almost never use Lambda, even though I like the idea. You've created a strawman, and you're trying to expertly knock it down... except for the whole math thing as noted above.
If we really dig into this, neither the DigitalOcean solution nor the Lambda solution discussed accounts for the cost of running your stateful infrastructure, whether it's a traditional RDBMS, some NoSQL system, Kafka, or just a giant object store like S3.
My singular point in this entire thread was that scale-to-zero is worthless if the solution that enables scale-to-zero costs more than not scaling to zero. If DigitalOcean is the solution that costs less than scaling to zero, then obviously that is more valuable than the solution that scales to zero.
The economics are laid before us like a golden fleece.
This allows things like per second billing for container runs, serverless containers (there's no container running 24/7, only when there's traffic), etc.