5 ms·

> 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 offeri

> 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.
  - scarface74 7y ago
    Your “proof” is an anecdote that was easily disproven by a link. If it takes your developers two weeks to host an API in a Lambda when I showed you a link on how simple it is. It says more about your developers than AWS. My time is far from cheap and any time that we can spend letting someone else do the grunt work is valuable.
    - rumanator 7y ago
      > Your “proof” is an anecdote that was easily disproven by a link. Real-world problems don't go away when you try to brush them aside. You either face the facts or remain in fantasy land. > If it takes your developers two weeks to host an API in a Lambda Please don't put words in other people's mouths. You have absolutely no idea about what the problems were and already made it quite clear that you don't care about facts or reality, and simply prefer to fabricate accusations to avoid discussing technical issues. That speaks volumes about your own competence and technical ability.
mypalmike 7y ago
I'd rather be on call for a serverless system than otherwise. Getting paged at 2am because some log file filled up a disk, or a million other details that your "couple of hours" solution didn't take into account? No thanks.
- scarface74 7y ago
  You’re right. If my print statements cause CloudWatch logs to fill up. AWS has bigger issues.... I refuse to work for any company at this point in my career that expects me to be on call to manage a bunch of pets.
- rumanator 7y ago
  > I'd rather be on call for a serverless system than otherwise. Getting paged at 2am because some log file filled up a disk, or a million other details that your "couple of hours" solution didn't take into account? No thanks. How about getting paged at 2am because somehow a lambda called by AWS step functions workflow is failing due to hitting a timeout while uploading a 20MB file to a S3 bucket? Because this is an actual real world case that happened in the real world.
  - scarface74 7y ago
    Well, with step functions you can have auto retry with exponential back off in case of failure. But you had a lambda that couldn’t upload a 20Mb file to S3 in 15 minutes? Whatever the issue was, you would have more than likely had the same issue with a VM. A lambda runtime environment is nothing special for all intents and purposes but a Linux VM with well known constraints - a 512MB /tmp storage, and up to a 15 minute runtime.

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.
- scarface74 7y ago
  Your “proof” is an anecdote that was easily disproven by a link. If it takes your developers two weeks to host an API in a Lambda when I showed you a link on how simple it is. It says more about your developers than AWS. My time is far from cheap and any time that we can spend letting someone else do the grunt work is valuable.
  - rumanator 7y ago
    > Your “proof” is an anecdote that was easily disproven by a link. Real-world problems don't go away when you try to brush them aside. You either face the facts or remain in fantasy land. > If it takes your developers two weeks to host an API in a Lambda Please don't put words in other people's mouths. You have absolutely no idea about what the problems were and already made it quite clear that you don't care about facts or reality, and simply prefer to fabricate accusations to avoid discussing technical issues. That speaks volumes about your own competence and technical ability.

mypalmike 7y ago

I'd rather be on call for a serverless system than otherwise. Getting paged at 2am because some log file filled up a disk, or a million other details that your "couple of hours" solution didn't take into account? No thanks.

scarface74 7y ago
You’re right. If my print statements cause CloudWatch logs to fill up. AWS has bigger issues.... I refuse to work for any company at this point in my career that expects me to be on call to manage a bunch of pets.
rumanator 7y ago
> I'd rather be on call for a serverless system than otherwise. Getting paged at 2am because some log file filled up a disk, or a million other details that your "couple of hours" solution didn't take into account? No thanks. How about getting paged at 2am because somehow a lambda called by AWS step functions workflow is failing due to hitting a timeout while uploading a 20MB file to a S3 bucket? Because this is an actual real world case that happened in the real world.
- scarface74 7y ago
  Well, with step functions you can have auto retry with exponential back off in case of failure. But you had a lambda that couldn’t upload a 20Mb file to S3 in 15 minutes? Whatever the issue was, you would have more than likely had the same issue with a VM. A lambda runtime environment is nothing special for all intents and purposes but a Linux VM with well known constraints - a 512MB /tmp storage, and up to a 15 minute runtime.