h a l f b a k e r yIf you need to ask, you can't afford it.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Bucket lambda
Lambda programming is expensive but what if you could buy an automatically scaling bucket lambda where each bucket corresponds to an instance type and your costs are fixed until you hit the next bucket type. | |
Pay as you go can be expensive with existing cloud infrastructure layout and costs.
The beginning of the plan can be on shared servers, so you pay minimum costs, the next bucket can be a tiny instance on AWS, the next plan is a higher instance and so on.
It's pay as you go but with more capped
costs.
Pay as you use?
https://en.wikipedi...wiki/Pay-as-you-use
Wikipedia [a1, Dec 16 2023]
[link]
|
| |
Is this just a different way of saying "pay as you use?" |
|
| |
a1, the problem with lambda is that there is a point when it becomes more economic to just buy a virtual server and port your lambda application to a dedicated server. but then you're paying for a fixed resource for a fixed capacity. But then you have a server to manage and all the costs of managing a server and keeping it online. |
|
| |
I think it would be nice if lambdas were bounded in their costs similar to a fixed server model and this is what this idea is about. |
|
| |
Maybe we're talking about different things. But I thought pay as you USE (not pay as you GO) was inherently scalable to avoid the kind of waste / cost you're talking about. |
|
| |
But this is more in your speciality than mine. Explain it to me like I know nothing at all about SAAS or lambda - or that all I know came from a 30 second perusal of a Wikipedia article (which is not far from the truth). |
|
| |
To analogise, you can buy a truck with a capacity of X units of product and pay time costs it in X period of time (for a journey) |
|
| |
In AWS Lambda, you pay for execution time AND number of requests. |
|
| |
The problem with Lambda is that if you are making millions or hundreds of millions requests per day, then the cost can scale upwards. |
|
| |
I *think* but I don't know, that a lambda is more expensive than a dedicated server for the same number of requests. |
|
| |
A dedicated server has a fixed capacity, you pay £100 a month for that server regardless how much traffic you get. Or you pay the costs of a truck regardless how much journeys you do, except for fuel. |
|
| |
//I *think* but I don't know, that a lambda is more expensive than a dedicated server for the same number of requests. // |
|
| |
If so there would be some break-even point. How would you go about confirming that? |
|
| |
//each bucket corresponds to an instance type// |
|
| |
An instance of lambda, of course. |
|
| |
In cloud computer systems, rather than run your own datacentre, you have a virtual data centre, one that is programmed rather than physically moving servers into racks and attaching rack coolers, network equipment, hard disks, storage and network appliances. |
|
| |
It's all done my talking to a computer then the computer arranges all the above things automatically. It's digital datacentre in a datacentre. |
|
| |
An "cloud instance" is a server or fraction of a server, in AWS a nano instance or micro instance are small servers. nano instances have 512mb memory and 2 virtual CPUs, they are dual core machines. |
|
| |
Amazon (AWS) slices up a server into fragments of resource, a bit like dividing a cargo ship into sections or a lorry into sections. |
|
| |
So ... scratching my head and trying to recall the Azure training course I did a few years ago ... |
|
| |
There's "Infrastructure as a Service", where you, the customer, know about and control the individual servers (although they're virtual servers) - you just don't know about the metal underneath them. Then there's "Platform as a Service", where you don't; you just write an application that invokes functions, without ever specifying the host name or IP address of where those functions are going to run - right? |
|
| |
So, if I understand this correctly, you're proposing to do something in between these two models, where your application invokes processing without explicitly referencing specific servers (as in PaaS), but you save some money by conceding that the underlying servers that your application doesn't know about can be cheap ones (which is analogous to explicitly buying cheap virtual servers in IaaS). |
|
| |