In my book, the innovation in Lambda is, above everything else, about the billing model. My company moved the work of 40 dedicated servers onto Lambda and in doing so decimated our costs. Paying for 1500 cores (our current AWS limit) in 100ms increments has been a game changer.
I'm sure there are upsides to adopting the same programming model with your own hardware or VMs, but the financial benefit of Lambda will not be there.
There is no disputing the financial model behind AWS Lambda is revolutionary. I know of a visitor NDA signing service that charges $5 per visitor. The backend runs entirely on AWS API Gateway and Lamdba and their cost per visitor transaction to AWS is $0.25. Think about how powerful this is! Now you can develop an app in your spare time and bring it to market for practically nothing. Once developed, your fix infrastructure costs are zero.
That said, there are financial benefits on premise too. Short lived processes that need 1 CPU and 512Mb memory are ideal candidates for oversubscription. If you had a server where CPU utilization never peaked beyond 60% and 15Gb memory was free then you could fit 20 Lambda functions in this 'slack capacity' without resource contention. Driving up utilization when the cost of the server is sunk is effectively capacity for free.
That's only if you compare raw compute. When you create a VM on AWS it will get <10% utilization (many times close to 1%). Sometimes you need to factor in for varying utilization so you need to overprovision but if you have many services and the deployment unit is the VM then you end up having tons of VMs doing nothing.
With containers the deployment model becomes more granular, hence you can share the VM and increase utilization, but you'll still pay for idle time.
With hosted functions (like lambda) you don't pay idle time, so in many cases it's much more efficient.
Indeed, if you host your own "lambda" implementation, you may or may not have cost improvements. In this case it may be just a matter of operational efficiency.
It's highly dependent on your usage. If you want a crib job to run that isn't on your production server and it's to run every few hours. Great to schedule that on AWS lambda. EC2 would be more expensive.
Trying to process 1000s of requests on AWS lambda could end up hitting the limits of lambda and cost you more.
I use lambda to process exif data in images as they are uploaded to S3. Which is awesome because it doesn't require services running on the web server and costs me nothing because it comes into the free tier of AWS lambda.
Oh and AWS database access sucks balls. Because you cannot pool connections you must open/close db connections. If you fail to close you will exhaust the database connections quickly and kill your app until the connections expire.
Phillip - have you tried making your database connection in 'static' code? With container re-use (see https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...), you should see multiple invokes going to the same container, and you can use the same connection for all of them. That will only happen if your traffic is high enough.
I wonder why Google Compute charges a minimum of ten minutes to spin up an instance. I understand there is some setup cost, but ten minutes is $0.00056 for the cheapest (f1-micro) instance [1]. I know this sounds sort of cheap, but that's the cost just to deliver the interface (the VM) that is going to be used. That's a relatively large amount of money to spend on not having any work done at all yet. A diskless VM, which can just send data for storage to a database over HTTP, shouldn't require much setup work, as it really just is the execution of CPU instructions (with the OS being the CPU interface rather than JavaScript).
Couldn't someone write a virtualized VM that runs inside Lambda, thus providing zero (or Lambda-equivalent) startup costs for generic VMs? Then the VM would just be a function running inside Lambda, transforming incoming user data and then storing the result in a database, after which it would disappear.
Or maybe the OS just is the problem? One model of bypassing it is Lambda-like services, which would be the more centralized solution, while the more decentralized solution (of the two) would be bare metal/unikernels, which basically achieve the same thing: (close to) zero startup time/cost (~30 ms for a HaLVM unikernel).
Wasn't this the very earliest billing model in multiuser computing? Give us a program to run on our big iron, we charge you for the CPU time it consumes?
This is how university supercomputers work currently. You don't get dedicated hosts; your project has a budget of CPU hours.
How do Mesosphere ops (who are developers first, maybe not so experienced with the operations side) normally manage these services, like Gestalt? How do you keep track of what should be running and how resources should be allocated? Do you just install directly from this service repository, and then update resource allocations as needed, through Marathon or the service itself? Or, do you have a system for managing and versioning the entire cluster?
I'm new to Mesosphere, and right now, I'm figuring out a process for managing the cluster that would work well for a small but growing team. It would be nice to have a specification of what the cluster should look like, and how it has changed over time. For that, I'm thinking of having a "{company}-DC" git repository with a collection of Ansible playbooks that would set up the DCOS cluster, and then install, configure and set up scaling policies for the services and applications that we want to run. Is this how most people do it? Do you see problems with the general idea of keeping all of Mesosphere under configuration management? Where do secrets fit into this, where do you store them and how do you make them available to your applications?
I'm very clueless to this new architecture, but a concern i frequently hear about is lockin (both in language and vendor).
Does this style of computing / engineering hinder open source adoption in languages? Eg, OS images pre-setup with some type of PHP-style provider, letting you run whatever language you want with low startup time to handle each request?
I'm sure much of this is way off the mark, so to explain it differently, i'd love to be able to work with a Rust framework tailored to this "serverless" model, and hosted on any generic box i want (or fleets of boxes, etc).
And of course, apologies for the ignorance i'm sure is visible :)
So their docs seem pretty clear that their lambda engine runs jvm based languages. Or at least java and scala, but if you can run java you can run scala and clojure and jruby etc.
I'm sure there are upsides to adopting the same programming model with your own hardware or VMs, but the financial benefit of Lambda will not be there.