4 ms·

But they significantly reduce the workload on the people that would otherwise have to manage those things, just like a serverless architecture does. If you wan

But they significantly reduce the workload on the people that would otherwise have to manage those things, just like a serverless architecture does. If you want to argue about vendor lockin, sure. But removing the necessity of managing scaling, individual instances, and OS / software patching is significant.

geggam 8y ago
Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain
- moduspol 8y ago
  > Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. This is no different from any other abstraction. > Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. That's not to say they won't ultimately limit (e.g.) how many S3 buckets you create, but being able to create unlimited S3 buckets is not necessary to use S3 as designed in a near-infinitely scalable way.
  - geggam 8y ago
    >Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. All of those services have limits, just because you havent experienced that scale doesnt mean others havent.
    - moduspol 8y ago
      > All of those services have limits, just because you havent experienced that scale doesnt mean others havent. See the sentence literally immediately after the one you quoted. People are already using those services all day every day at far greater scale than most of us can ever hope to achieve. It's meaningless to pontificate on theoretical limits when the practical ones are higher than you can reach.
      - liveoneggs 8y ago
        > pontificate on theoretical limits These "limits" are real and are hit pretty quickly (and it's easy to ask for bumps but they are still there) S3 buckets is one of the first ones most people hit
        moduspol 8y ago
        Parent comment is talking about hard limits--those which they will not raise. The soft limits aren't architectural--they're arbitrary to help prevent newbies racking up huge bills by mistake. And (as you noted) they do raise them.
falcolas 8y ago
> But removing the necessity of managing scaling, individual instances, and OS / software patching is significant. With AWS (and other cloud provider) APIs and tools like Packer, these difficulties are vastly overstated. Building VM images is just another step in the CI/CD pipeline, and patching and deploying a zero day fix becomes "kick off the CI/CD pipeline". You can even do automated unit testing of an image with tools like Inspec. Scaling is an API call to change a "desired instance count" value (if it's not already automated), and complex problems with any individual instance can be resolved with STONITH (terminating the instance).
- moduspol 8y ago
  > Building VM images is just another step in the CI/CD pipeline, and patching and deploying a zero day fix becomes "kick off the CI/CD pipeline". You can even do automated unit testing of an image with tools like Inspec. There is a non-zero cost in maintaining that process, including paying people to know and understand things like Inspec, packer, and Linux troubleshooting. There are also full OS upgrades where assumptions made could be invalidated, along with revising your process accordingly. > Scaling is an API call to change a "desired instance count" value (if it's not already automated) That automation is significant complexity. You'll be maintaining whatever health / resource checks are necessary to determine when scaling up is necessary, when scaling down should be done, what initialization / teardown tasks need to be done, etc. You'll also need some kind of health checks / monitoring to ensure this process is operating as it should so that you can detect if there's a problem with it. All of that needs to be known / understood / documented / maintained by someone. And that's only for the stateless part. If you're trying to do with same with a relational database, it only gets tougher. > and complex problems with any individual instance can be resolved with STONITH (terminating the instance). Only if the problem is truly non-recurring and only in a single instance. Otherwise, it will be Linux troubleshooting to find out if it's your software, an OS patch, a third party software patch, or some other issue.
  - falcolas 8y ago
    TL;DR: Both paths require knowledge beyond how to write a web application; using Lambda doesn't absolve you of having to learn about or hire someone to manage your infrastructure. > There is a non-zero cost in maintaining that process Just as there is a non-zero cost associated with maintaining Lambda, API Gateway, and the associated CloudFormation scripts, and finding people who can (and are willing to) maintain them. > That automation is significant complexity 99% of that complexity is already shouldered by AWS and their ilk. They implement log forwarding, metric dashboards, instance health checks, and simple (complete) examples of how to scale based on CPU and memory - the two metrics used for scaling in most cases. As for OS upgrades, yes, those can require a bit more expertise. That said, those occur every two to four years, and for the past few OS upgrades I've had to handle, the pain was limited to converting sysvinit scripts to upstart scripts, to unit files (none of which were strictly required, as an aside, since both upstart and systemd support sysvinit scripts natively). > If you're trying to do with same with a relational database, it only gets tougher. You mean RDS? Databaes need to be maintained no matter how the application is run. For a quick personal anecdote, there's a world of hurt waiting unless someone is hired who knows how to manage and tune databases, no matter who runs the infrastructure. > Otherwise, it will be Linux troubleshooting to find out if it's your software, an OS patch, a third party software patch, or some other issue. How is this different? Linux troubleshooting skills won't help to identify if it's third party software or your software - and those pains don't go away magically with Lambda. In the exceptionally rare case that it is the OS, it will be fixable by kicking off your CI/CD pipeline. A small tip: Like compilers, the problem isn't the OS. Even when you think it's the OS, it's not. It's your software. OOM killer taking out processes? Those processes are leaking memory. Running out of disk space? Clean up the logs. Cron is misbehaving? Fix the typo. It's also worth mentioning that all of those problems are at least temporarily resolved by STONITH; enough to give time to fix the application.

geggam 8y ago

Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain

moduspol 8y ago
> Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. This is no different from any other abstraction. > Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. That's not to say they won't ultimately limit (e.g.) how many S3 buckets you create, but being able to create unlimited S3 buckets is not necessary to use S3 as designed in a near-infinitely scalable way.
- geggam 8y ago
  >Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. All of those services have limits, just because you havent experienced that scale doesnt mean others havent.
  - moduspol 8y ago
    > All of those services have limits, just because you havent experienced that scale doesnt mean others havent. See the sentence literally immediately after the one you quoted. People are already using those services all day every day at far greater scale than most of us can ever hope to achieve. It's meaningless to pontificate on theoretical limits when the practical ones are higher than you can reach.
    - liveoneggs 8y ago
      > pontificate on theoretical limits These "limits" are real and are hit pretty quickly (and it's easy to ask for bumps but they are still there) S3 buckets is one of the first ones most people hit
      - moduspol 8y ago
        Parent comment is talking about hard limits--those which they will not raise. The soft limits aren't architectural--they're arbitrary to help prevent newbies racking up huge bills by mistake. And (as you noted) they do raise them.

falcolas 8y ago

> But removing the necessity of managing scaling, individual instances, and OS / software patching is significant. With AWS (and other cloud provider) APIs and tools like Packer, these difficulties are vastly overstated. Building VM images is just another step in the CI/CD pipeline, and patching and deploying a zero day fix becomes "kick off the CI/CD pipeline". You can even do automated unit testing of an image with tools like Inspec. Scaling is an API call to change a "desired instance count" value (if it's not already automated), and complex problems with any individual instance can be resolved with STONITH (terminating the instance).

moduspol 8y ago
> Building VM images is just another step in the CI/CD pipeline, and patching and deploying a zero day fix becomes "kick off the CI/CD pipeline". You can even do automated unit testing of an image with tools like Inspec. There is a non-zero cost in maintaining that process, including paying people to know and understand things like Inspec, packer, and Linux troubleshooting. There are also full OS upgrades where assumptions made could be invalidated, along with revising your process accordingly. > Scaling is an API call to change a "desired instance count" value (if it's not already automated) That automation is significant complexity. You'll be maintaining whatever health / resource checks are necessary to determine when scaling up is necessary, when scaling down should be done, what initialization / teardown tasks need to be done, etc. You'll also need some kind of health checks / monitoring to ensure this process is operating as it should so that you can detect if there's a problem with it. All of that needs to be known / understood / documented / maintained by someone. And that's only for the stateless part. If you're trying to do with same with a relational database, it only gets tougher. > and complex problems with any individual instance can be resolved with STONITH (terminating the instance). Only if the problem is truly non-recurring and only in a single instance. Otherwise, it will be Linux troubleshooting to find out if it's your software, an OS patch, a third party software patch, or some other issue.
- falcolas 8y ago
  TL;DR: Both paths require knowledge beyond how to write a web application; using Lambda doesn't absolve you of having to learn about or hire someone to manage your infrastructure. > There is a non-zero cost in maintaining that process Just as there is a non-zero cost associated with maintaining Lambda, API Gateway, and the associated CloudFormation scripts, and finding people who can (and are willing to) maintain them. > That automation is significant complexity 99% of that complexity is already shouldered by AWS and their ilk. They implement log forwarding, metric dashboards, instance health checks, and simple (complete) examples of how to scale based on CPU and memory - the two metrics used for scaling in most cases. As for OS upgrades, yes, those can require a bit more expertise. That said, those occur every two to four years, and for the past few OS upgrades I've had to handle, the pain was limited to converting sysvinit scripts to upstart scripts, to unit files (none of which were strictly required, as an aside, since both upstart and systemd support sysvinit scripts natively). > If you're trying to do with same with a relational database, it only gets tougher. You mean RDS? Databaes need to be maintained no matter how the application is run. For a quick personal anecdote, there's a world of hurt waiting unless someone is hired who knows how to manage and tune databases, no matter who runs the infrastructure. > Otherwise, it will be Linux troubleshooting to find out if it's your software, an OS patch, a third party software patch, or some other issue. How is this different? Linux troubleshooting skills won't help to identify if it's third party software or your software - and those pains don't go away magically with Lambda. In the exceptionally rare case that it is the OS, it will be fixable by kicking off your CI/CD pipeline. A small tip: Like compilers, the problem isn't the OS. Even when you think it's the OS, it's not. It's your software. OOM killer taking out processes? Those processes are leaking memory. Running out of disk space? Clean up the logs. Cron is misbehaving? Fix the typo. It's also worth mentioning that all of those problems are at least temporarily resolved by STONITH; enough to give time to fix the application.