5 ms·

> Not a single post on Hacker News can use the term "serverless" wits nhout the exact same replies being posted every time. As a serverless skeptic/critic, the

> Not a single post on Hacker News can use the term "serverless" wits nhout the exact same replies being posted every time. As a serverless skeptic/critic, the buzzword bingo aspect of serverless computing is far from being the problem, and it's a gross missrepresentation of the problems posed by serverless computing. The main problem with server applications such as AWS lambda, along with lack of control, is how utterly expensive it becomes by enforcing a SaaS business model to simple function calls, and how convoluted and needlessly complex it becomes by having to resort to yet another premium service to simply manage workflows (see AWS step functions). Suggesting that any criticism of the serverless fad is just old grumpy incompetent developers that are too dumb to understand the future and are to scared of being out of a job is a disingenuous attack on anyone who has the audacity of not falling behind a fad.

scarface74 7y ago
As if the time to manage servers is free. But lambda is far from expensive. If you’re spending even $100 a month on lambda, you probably have a successful business. And everything is “complex” if you don’t know how to do it optimally.
- rumanator 7y ago
  > As if the time to manage servers is free. I work in projects which make heavy use of function-as-a-service, and I have first-hand accounts of how FaaS offerings have lead developers to waste a couple of weeks getting FaaS to do what could have been done in a couple of hours with a tried-and-true web service. > But lambda is far from expensive. Relatively to the cost of a VM instance? Yes, it's expensive. We're in a day and age where a vCPU with 2GB of RAM can be had for 3€/month, and the pricing examples posted on AWS Lambda's page show a scenario where slightly over a month of function run time requiring 512MB of RAM would cost around $18. In addition, AWS lambda usage is rounded up in intervals of 0.1s and 128MB, thus inexpensive function calls are way overcharged. > If you’re spending even $100 a month on lambda, you probably have a successful business. This assertion is missing the fact that those $100 a month on lambdas might be handled by $10 worth of computational resources in the cloud and a software architecture that isn't convoluted or tied to a single vendor. Thus the fact is that a fad is being pushed without technical merit or sound operational reasoning.
  - scarface74 7y ago
    Let me give you another example. We have a Jenkins server for builds. Most of the time, you push code and the build starts immediately. However, at times we have 10 builds in the queue and you’re sitting there waiting for your small build behind larger builds. On the other hand, we’ve started moving to CodeBuild “Serverless builds”. When we aren’t running builds, we aren’t paying for it. However when crunch time comes, we can run up to 50 builds simultaneously (you can request a larger limit). How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle? And if you’re worried about the difference in cost between $100 and $10, you’re not running a business. Will that $10 a month server scale up with demand? As far as it taking “two or three weeks” - “its a poor craftsmen who blames his tools”. Don’t blame AWS for the missing skillset of your developers. There is no reason that it should take your developers any longer to build an API with lambda instead of a server. In fact, you can host the same APIs with lambda by only adding two or three lines of code and using proxy integration. For instance in Node: https://github.com/awslabs/aws-serverless-express https://github.com/awslabs/aws-serverless-express
    - rumanator 7y ago
      You either completely missed the point or you are too invested in going off on a tangent to try to change the subject. The $100 vs $10 was not intended to argument the merit of $10 savings: it refutes the absurd claim that $100 expenditures justifies adopting a convoluted architecture, because the fact is not adopting a convoluted architecture is actually much cheaper. Additionally, somehow you've brushed aside the fact that the main cost is developer time, and a convoluted solution based on flavor-of-the-month tech fads requires more maintenance and developer man-hours than basic tried-and-true solutions like standard run-of-the-mill web services. > How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle? I honestly fail to see what point you're trying to make because: a) you don't need "serverless" services such as AWS lambdas to get CICD pipelines to work, and b) cluster autoscaling is a basic offering provided by pretty much all major cloud providers. Thus, what's your point? > As far as it taking “two or three weeks” - “its a poor craftsmen who blames his tools”. So any proof that refutes your baseless assertions is brushed aside by your "you're holding it wrong" baseless assertion? Doesn't sound like a discussion on technical merits. You're underlining the biggest problem with buzzword-driven development: the lack of technical merit is a constant and everything boils down to petty personal politics.
cddotdotslash 7y ago
There are absolutely valid criticisms of serverless (as you called out, vendor lock in and complexity for large applications being a big ones). But it's still an important and interesting technology that many individuals and companies are invested in, sharing side projects, open source tools (like the OP's), etc. In many cases, it can be cost efficient, or even (human) resource efficient to use a serverless setup. So it gets quite repetitive to still be debating that, yes, we know there are servers running the code, it's just a name. Also, a lot of the value in serverless lies in time saved managing said servers, which sometimes escapes engineers who are only looking at a project from the "well let's just spin up a quick VPS and install Ubuntu and these 15 packages, get DKIM working, throw a Let's Encrypt cert on the endpoint, launch a sidecar Prometheus and Grafan server for monitoring, and boom, you're done, why even use AWS?" perspective.
- tuldia 7y ago
  You are missing the point. (the "tired responses") No, there only very few cases, such as shaving video encoding time (the one that started all this mess around "serverless") For majority of other cases, using "(human) resource efficient" or "time saved managing servers" to justify the use of "serverless" is a plain bogus argument, since you end up shifting (best case scenario) OR spending more (worst case) time "managing the cloud's alphabet soup". I will not even start talking about the code base mess.
  - scarface74 7y ago
    Again you only spend more time if you don’t know what you’re doing. I’m not a front end developer by any stretch of the imagination. Would it be a valid argument if I said that React isn’t a good solution because I have years of experienced with server side rendering? Again, don’t blame the tools just because you didn’t take the time to learn how to use them efficiently. If my name doesn’t give you a clue,I was around and developing way before AWS or hosted solutions was a thing. Being able to provision resources by writing yaml and not having to deal with the infrastructure gatekeepers is a godsend. No, there only very few cases, such as shaving video encoding time (the one that started all this mess around "serverless") There are millions of people using computers in countless different ways. Are you sure that you know all of the valid use cases?
baddox 7y ago
Okay, it may very well be true that one particular serverless product is very expensive or overly complex. That’s a fine argument to make. But that has nothing to do with whether the term “serverless” has a well-established meaning. It’s not just a buzzword, or at least it’s not always used as a buzzword and does in fact have a straightforward meaning. If I don’t like serverless products, or I think people need to be aware of problems they might face, I should just make those arguments. I should not just say “I still don’t know what serverless means” or “serverless is just a buzzword.”
- rumanator 7y ago
  > But that has nothing to do with whether the term “serverless” has a well-established meaning. It’s not just a buzzword, or at least it’s not always used as a buzzword and does in fact have a straightforward meaning. You're confounding two independent issues: "serverless" being a buzzword, and "serverless" not having a precise and well established meaning. The fact that "serverless" is indeed a buzzword is indisputable. Thus the only issue that's up for debate is whether "serverless" has a precise and well established meaning. The problem with the assertion that "serverless" is a meaningful term is that it turns a blind eye to the fact that "serverless" is expected to be an umbrella term that refers to multiple concepts, some of which are well established. For example, "serverless" is used by some people to refer to a more concrete and specific and well established concept of Function-as-a-Service (FaaS). Yet, albeit FaaS is portraied as a subset of "serverless" concept, FaaS does not represent the concept, which is assumed to be more broadly defined. This ambiguity and vagueness opens the door to discussions on whether pain old "managed services" warrant the "serverless" buzzword, which would underline the buzzword factor by the way an old and well established concept is being rebranded. Then there are futile discussions on whether irrelevant and secondary implementation details of managed services, such as the degree of automation and auto-scaling, are in line with what is true "servelessness". But in the end this collective grasping at straws just underlines the lack of substance behind the "serverless" keyword.
  - baddox 7y ago
    > The fact that "serverless" is indeed a buzzword is indisputable. It can be used as a buzzword, but it isn’t always. The same goes for “the cloud.” It’s used in marketing because it sounds cool and people think they need it, but at the same time it can be perfectly clear to use the term in technical contexts. > For example, "serverless" is used by some people to refer to a more concrete and specific and well established concept of Function-as-a-Service (FaaS). Yet, albeit FaaS is portraied as a subset of "serverless" concept, FaaS does not represent the concept, which is assumed to be more broadly defined. What’s vague about this? FaaS is a serverless product, but not all serverless products are FaaS.
scarface74 7y ago
I use to only program in assembly in the 80s because I “lacked control” higher level languages.... What perceived “control” are you missing?

scarface74 7y ago

As if the time to manage servers is free. But lambda is far from expensive. If you’re spending even $100 a month on lambda, you probably have a successful business. And everything is “complex” if you don’t know how to do it optimally.

rumanator 7y ago
> As if the time to manage servers is free. I work in projects which make heavy use of function-as-a-service, and I have first-hand accounts of how FaaS offerings have lead developers to waste a couple of weeks getting FaaS to do what could have been done in a couple of hours with a tried-and-true web service. > But lambda is far from expensive. Relatively to the cost of a VM instance? Yes, it's expensive. We're in a day and age where a vCPU with 2GB of RAM can be had for 3€/month, and the pricing examples posted on AWS Lambda's page show a scenario where slightly over a month of function run time requiring 512MB of RAM would cost around $18. In addition, AWS lambda usage is rounded up in intervals of 0.1s and 128MB, thus inexpensive function calls are way overcharged. > If you’re spending even $100 a month on lambda, you probably have a successful business. This assertion is missing the fact that those $100 a month on lambdas might be handled by $10 worth of computational resources in the cloud and a software architecture that isn't convoluted or tied to a single vendor. Thus the fact is that a fad is being pushed without technical merit or sound operational reasoning.
- scarface74 7y ago
  Let me give you another example. We have a Jenkins server for builds. Most of the time, you push code and the build starts immediately. However, at times we have 10 builds in the queue and you’re sitting there waiting for your small build behind larger builds. On the other hand, we’ve started moving to CodeBuild “Serverless builds”. When we aren’t running builds, we aren’t paying for it. However when crunch time comes, we can run up to 50 builds simultaneously (you can request a larger limit). How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle? And if you’re worried about the difference in cost between $100 and $10, you’re not running a business. Will that $10 a month server scale up with demand? As far as it taking “two or three weeks” - “its a poor craftsmen who blames his tools”. Don’t blame AWS for the missing skillset of your developers. There is no reason that it should take your developers any longer to build an API with lambda instead of a server. In fact, you can host the same APIs with lambda by only adding two or three lines of code and using proxy integration. For instance in Node: https://github.com/awslabs/aws-serverless-express https://github.com/awslabs/aws-serverless-express
  - rumanator 7y ago
    You either completely missed the point or you are too invested in going off on a tangent to try to change the subject. The $100 vs $10 was not intended to argument the merit of $10 savings: it refutes the absurd claim that $100 expenditures justifies adopting a convoluted architecture, because the fact is not adopting a convoluted architecture is actually much cheaper. Additionally, somehow you've brushed aside the fact that the main cost is developer time, and a convoluted solution based on flavor-of-the-month tech fads requires more maintenance and developer man-hours than basic tried-and-true solutions like standard run-of-the-mill web services. > How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle? I honestly fail to see what point you're trying to make because: a) you don't need "serverless" services such as AWS lambdas to get CICD pipelines to work, and b) cluster autoscaling is a basic offering provided by pretty much all major cloud providers. Thus, what's your point? > As far as it taking “two or three weeks” - “its a poor craftsmen who blames his tools”. So any proof that refutes your baseless assertions is brushed aside by your "you're holding it wrong" baseless assertion? Doesn't sound like a discussion on technical merits. You're underlining the biggest problem with buzzword-driven development: the lack of technical merit is a constant and everything boils down to petty personal politics.

cddotdotslash 7y ago

There are absolutely valid criticisms of serverless (as you called out, vendor lock in and complexity for large applications being a big ones). But it's still an important and interesting technology that many individuals and companies are invested in, sharing side projects, open source tools (like the OP's), etc. In many cases, it can be cost efficient, or even (human) resource efficient to use a serverless setup. So it gets quite repetitive to still be debating that, yes, we know there are servers running the code, it's just a name. Also, a lot of the value in serverless lies in time saved managing said servers, which sometimes escapes engineers who are only looking at a project from the "well let's just spin up a quick VPS and install Ubuntu and these 15 packages, get DKIM working, throw a Let's Encrypt cert on the endpoint, launch a sidecar Prometheus and Grafan server for monitoring, and boom, you're done, why even use AWS?" perspective.

tuldia 7y ago
You are missing the point. (the "tired responses") No, there only very few cases, such as shaving video encoding time (the one that started all this mess around "serverless") For majority of other cases, using "(human) resource efficient" or "time saved managing servers" to justify the use of "serverless" is a plain bogus argument, since you end up shifting (best case scenario) OR spending more (worst case) time "managing the cloud's alphabet soup". I will not even start talking about the code base mess.
- scarface74 7y ago
  Again you only spend more time if you don’t know what you’re doing. I’m not a front end developer by any stretch of the imagination. Would it be a valid argument if I said that React isn’t a good solution because I have years of experienced with server side rendering? Again, don’t blame the tools just because you didn’t take the time to learn how to use them efficiently. If my name doesn’t give you a clue,I was around and developing way before AWS or hosted solutions was a thing. Being able to provision resources by writing yaml and not having to deal with the infrastructure gatekeepers is a godsend. No, there only very few cases, such as shaving video encoding time (the one that started all this mess around "serverless") There are millions of people using computers in countless different ways. Are you sure that you know all of the valid use cases?

baddox 7y ago

Okay, it may very well be true that one particular serverless product is very expensive or overly complex. That’s a fine argument to make. But that has nothing to do with whether the term “serverless” has a well-established meaning. It’s not just a buzzword, or at least it’s not always used as a buzzword and does in fact have a straightforward meaning. If I don’t like serverless products, or I think people need to be aware of problems they might face, I should just make those arguments. I should not just say “I still don’t know what serverless means” or “serverless is just a buzzword.”

rumanator 7y ago
> But that has nothing to do with whether the term “serverless” has a well-established meaning. It’s not just a buzzword, or at least it’s not always used as a buzzword and does in fact have a straightforward meaning. You're confounding two independent issues: "serverless" being a buzzword, and "serverless" not having a precise and well established meaning. The fact that "serverless" is indeed a buzzword is indisputable. Thus the only issue that's up for debate is whether "serverless" has a precise and well established meaning. The problem with the assertion that "serverless" is a meaningful term is that it turns a blind eye to the fact that "serverless" is expected to be an umbrella term that refers to multiple concepts, some of which are well established. For example, "serverless" is used by some people to refer to a more concrete and specific and well established concept of Function-as-a-Service (FaaS). Yet, albeit FaaS is portraied as a subset of "serverless" concept, FaaS does not represent the concept, which is assumed to be more broadly defined. This ambiguity and vagueness opens the door to discussions on whether pain old "managed services" warrant the "serverless" buzzword, which would underline the buzzword factor by the way an old and well established concept is being rebranded. Then there are futile discussions on whether irrelevant and secondary implementation details of managed services, such as the degree of automation and auto-scaling, are in line with what is true "servelessness". But in the end this collective grasping at straws just underlines the lack of substance behind the "serverless" keyword.
- baddox 7y ago
  > The fact that "serverless" is indeed a buzzword is indisputable. It can be used as a buzzword, but it isn’t always. The same goes for “the cloud.” It’s used in marketing because it sounds cool and people think they need it, but at the same time it can be perfectly clear to use the term in technical contexts. > For example, "serverless" is used by some people to refer to a more concrete and specific and well established concept of Function-as-a-Service (FaaS). Yet, albeit FaaS is portraied as a subset of "serverless" concept, FaaS does not represent the concept, which is assumed to be more broadly defined. What’s vague about this? FaaS is a serverless product, but not all serverless products are FaaS.

scarface74 7y ago

I use to only program in assembly in the 80s because I “lacked control” higher level languages.... What perceived “control” are you missing?