9 ms·

CGI scripts with a new name. Lambda and the like are interesting but any system is a composable set of components. You can say the same about Object oriented

by dpweb 9y ago

CGI scripts with a new name. Lambda and the like are interesting but any system is a composable set of components. You can say the same about Object oriented programming or func programming. separation of concerns but on the network. Server functions arent a panecea cause you still have to manage all the other pieces. An elegant thing would be your entire app is in that single lambda but without state there goes your db. even so, people cant resist taking something and adding and adding more to it.

emj 9y ago
More like CGI scripts with a loadbalancer that promises to run your application on a host with enough memory within at most 600ms. That solves an actual problem with CGI scripts, but I really would love to see more tiers with lower latency brackets, sub 10 milisecond should be doable for certain lambdas and costs.
- wahnfrieden 9y ago
  The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO technologies like nodejs less compelling, because throughput capacity isn’t really relevant anymore.
  - k__ 9y ago
    What are good alternatives to nodejs that are better suited for this kind of architecture?
    - wahnfrieden 9y ago
      It’s more that you’re dealing with a different set of constraints on which to evaluate technologies. There’s not an overall better suited technology than nodejs - still good reasons to use it on Lambda. To make the most of Lambda though you’ll want something that affords small code size (as there’s a 50MB limit), and has fast single execution latency.
  - bpicolo 9y ago
    Which will never accumulate a backlog because it is happy to kill your task. ;)
    - wahnfrieden 9y ago
      Still need to use a dead letter queue, yes :)
  - rdsubhas 9y ago
    > The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane. If I have autoscaling with an upper bound, I can stay within a fixed budget per month. If I reach my budget, yeah no more new servers, but whatever running keeps running. My business doesn't disappear, I get business continuity. Paying based on % of traffic sounds insane. How will I plan for business continuity if my monthly budget is reached with this kind of model? (without any "minimum xx requests" kind of crap free tier, business continuity means fixed upper bound AND continuing service, not OR)
    - icebraining 9y ago
      I don't know if platforms already support it, but there's no reason why you can't have a throttle (calls/minute).
      - alpha_squared 9y ago
        I can't speak for all serverless platforms, but AWS API Gateway does support throttling and burst throttling[0]. [0] http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html http://docs.aws.amazon.com/apigateway/latest/developerguide/...
    - wahnfrieden 9y ago
      You’re looking for throttling which you can do with Lambda/API Gateway. If you don’t have spikiness in your traffic and provisioning for peak capacity is affordable and simple, then serverless is a bit less compelling.
- Cthulhu_ 9y ago
  sub 10 ms would only work if they had an instance running and warm, ready to take requests - if they still have to look up your function, provision a machine, interpret it etc it's easy to go past that. 600ms is still respectable if it's from a "cold start". But if you've got time critical applications maybe serverless is not for you.
  - naasking 9y ago
    I don't see why this is necessarily the case. You can boot lightweight VMs with a unikernel in under 10ms [1]. [1] http://cnp.neclab.eu/projects/lightvm/lightvm.pdf http://cnp.neclab.eu/projects/lightvm/lightvm.pdf
  - emj 9y ago
    I know it's an edge case that doesn't fit Amazon Lambdas atm. I do it by hand ATM, so I know it can be done, but sure I run it on too many preowned servers to handle peaks. Controlling serverless resources in a more fine grained way is a way to use your servers more effectively.
not_kurt_godel 9y ago
> CGI scripts with a new name "Electric lightbulbs: candles with a new name"
- emj 9y ago
  Back when we only had shared hosting or bare metal there where some pretty good CGI hosters. So a better comparision is compact fluorescent lamp: incandescent light bulb with a new name, CFL are clumsy and expensive for many things but a cheap and easy way to use less energy. I'm waiting for the LED version.
  - not_kurt_godel 9y ago
    Would those hosters scale up to serve arbitrary amounts of traffic? Would they automatically replace hosts that failed? Could they seamlessly integrate with systems that can store and query unlimited amounts of data? Did they have a system like API Gateway to put your CGI scripts behind? Did they have deployment systems that would set up all of the above and more with a single command, like Serverless? Also are you aware that Lambda is exceedingly cheap?
- printf_kek0 9y ago
  Weak argument from analogy given the (lacking) degree of relevant similarity. See: On Analogy, A System of Logic by John Stuart Mill for a thorough analysis of analogical reasoning: https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_logic/chapter35.html https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_...
  - weego 9y ago
    considering how tenuous the original comment claiming cloud functions are just basic evolution of cgi scripting I think providing similarly poor analogies is quite apt.
  - kazagistar 9y ago
    Seems to me like they are both dismissive statements about a technology that provides the same thing in a new improved way. But more importantly, linking to a book of logic is an especially poor form of argument.
fuball63 9y ago
I'm actually working on this concept; a serverless platform utilizing the CGI standard. I call it bigCGI. It addresses a lot of the drawbacks another user mentioned: Vendor lock in: The CGI standard is supported by almost every server technology. Plus bigCGI is open source and can be self hosted. Security/Monitoring: one of my biggest challenges, but separate processes, by their nature, offer separation of resources. Debugging: CGI scripts are super easy to run locally. I've also configured bigCGI to collect STDERR from apps. Statelessness: CGI is a stateless standard. If anyone is interested in this, I'd love extra eyeballs on it, especially for security. https://github.com/bmsauer/bigcgi https://github.com/bmsauer/bigcgi (Please excuse the bad README, I'll update it next chance I get)

by dpweb 9y ago

emj 9y ago

More like CGI scripts with a loadbalancer that promises to run your application on a host with enough memory within at most 600ms. That solves an actual problem with CGI scripts, but I really would love to see more tiers with lower latency brackets, sub 10 milisecond should be doable for certain lambdas and costs.

wahnfrieden 9y ago
The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO technologies like nodejs less compelling, because throughput capacity isn’t really relevant anymore.
- k__ 9y ago
  What are good alternatives to nodejs that are better suited for this kind of architecture?
  - wahnfrieden 9y ago
    It’s more that you’re dealing with a different set of constraints on which to evaluate technologies. There’s not an overall better suited technology than nodejs - still good reasons to use it on Lambda. To make the most of Lambda though you’ll want something that affords small code size (as there’s a 50MB limit), and has fast single execution latency.
- bpicolo 9y ago
  Which will never accumulate a backlog because it is happy to kill your task. ;)
  - wahnfrieden 9y ago
    Still need to use a dead letter queue, yes :)
- rdsubhas 9y ago
  > The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane. If I have autoscaling with an upper bound, I can stay within a fixed budget per month. If I reach my budget, yeah no more new servers, but whatever running keeps running. My business doesn't disappear, I get business continuity. Paying based on % of traffic sounds insane. How will I plan for business continuity if my monthly budget is reached with this kind of model? (without any "minimum xx requests" kind of crap free tier, business continuity means fixed upper bound AND continuing service, not OR)
  - icebraining 9y ago
    I don't know if platforms already support it, but there's no reason why you can't have a throttle (calls/minute).
    - alpha_squared 9y ago
      I can't speak for all serverless platforms, but AWS API Gateway does support throttling and burst throttling[0]. [0] http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html http://docs.aws.amazon.com/apigateway/latest/developerguide/...
  - wahnfrieden 9y ago
    You’re looking for throttling which you can do with Lambda/API Gateway. If you don’t have spikiness in your traffic and provisioning for peak capacity is affordable and simple, then serverless is a bit less compelling.
Cthulhu_ 9y ago
sub 10 ms would only work if they had an instance running and warm, ready to take requests - if they still have to look up your function, provision a machine, interpret it etc it's easy to go past that. 600ms is still respectable if it's from a "cold start". But if you've got time critical applications maybe serverless is not for you.
- naasking 9y ago
  I don't see why this is necessarily the case. You can boot lightweight VMs with a unikernel in under 10ms [1]. [1] http://cnp.neclab.eu/projects/lightvm/lightvm.pdf http://cnp.neclab.eu/projects/lightvm/lightvm.pdf
- emj 9y ago
  I know it's an edge case that doesn't fit Amazon Lambdas atm. I do it by hand ATM, so I know it can be done, but sure I run it on too many preowned servers to handle peaks. Controlling serverless resources in a more fine grained way is a way to use your servers more effectively.

not_kurt_godel 9y ago

> CGI scripts with a new name "Electric lightbulbs: candles with a new name"

emj 9y ago
Back when we only had shared hosting or bare metal there where some pretty good CGI hosters. So a better comparision is compact fluorescent lamp: incandescent light bulb with a new name, CFL are clumsy and expensive for many things but a cheap and easy way to use less energy. I'm waiting for the LED version.
- not_kurt_godel 9y ago
  Would those hosters scale up to serve arbitrary amounts of traffic? Would they automatically replace hosts that failed? Could they seamlessly integrate with systems that can store and query unlimited amounts of data? Did they have a system like API Gateway to put your CGI scripts behind? Did they have deployment systems that would set up all of the above and more with a single command, like Serverless? Also are you aware that Lambda is exceedingly cheap?
printf_kek0 9y ago
Weak argument from analogy given the (lacking) degree of relevant similarity. See: On Analogy, A System of Logic by John Stuart Mill for a thorough analysis of analogical reasoning: https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_logic/chapter35.html https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_...
- weego 9y ago
  considering how tenuous the original comment claiming cloud functions are just basic evolution of cgi scripting I think providing similarly poor analogies is quite apt.
- kazagistar 9y ago
  Seems to me like they are both dismissive statements about a technology that provides the same thing in a new improved way. But more importantly, linking to a book of logic is an especially poor form of argument.

fuball63 9y ago

I'm actually working on this concept; a serverless platform utilizing the CGI standard. I call it bigCGI. It addresses a lot of the drawbacks another user mentioned: Vendor lock in: The CGI standard is supported by almost every server technology. Plus bigCGI is open source and can be self hosted. Security/Monitoring: one of my biggest challenges, but separate processes, by their nature, offer separation of resources. Debugging: CGI scripts are super easy to run locally. I've also configured bigCGI to collect STDERR from apps. Statelessness: CGI is a stateless standard. If anyone is interested in this, I'd love extra eyeballs on it, especially for security. https://github.com/bmsauer/bigcgi https://github.com/bmsauer/bigcgi (Please excuse the bad README, I'll update it next chance I get)