9 ms·

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring a

by 188201 7y ago

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

rgallagher27 7y ago
Have been running our API on Gateway/Lambda for well over a year now, having migrated from EC2. We've spent almost no time "managing" API gateway, monitoring or logging since the initial setup and migration of our infrastructure. If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.
cle 7y ago
You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.
- mbrumlow 7y ago
  >> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.
  - tapoxi 7y ago
    > Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.
    - falcolas 7y ago
      Shifting blame doesn’t help much when you lose customers (or pay financial penalties) due to non—compliance. You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.
      - IggleSniggle 7y ago
        Yup! If something goes wrong with compliance, who is going to win the finger pointing game? A smaller company that needs to outsource their compute, or Amazon?
        shawnz 7y ago
        If it was really Amazon's service that was at fault, then what are the chances that only one client is affected?
      - SpicyLemonZest 7y ago
        It’s rare for things to go so disastrously wrong that legal sway is relevant. What’s much more common is an angry CTO looking for someone to be mad at, and Amazon doesn’t have any particular ability to deflect that.
        falcolas 7y ago
        If you're dealing with businesses where compliance is required, such as PCI, HIPPA, or FedRamp, legal sway is absolutely relevant. If you should have a breach and an associated fine, Amazon can easily push the blame (and the likely-company-breaking fines) back on you.
- shams93 7y ago
  Most Enterprise are still married to java, they still write off node as "not a real language" most likely node is your best bet for the most efficient lambdas Java is a poor for for that.
wongarsu 7y ago
Whenever I've spoken with engineers from AWS and Google Cloud they saw serverless as a platform for glue code, webhooks, cronjobs and the like. In that role it works great: you don't care if it takes 300ms to start and it's genuinely easier and cheaper than running that code on a server. But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. Maybe that works great for some edge cases (e.g. reaching PCI compliance), but in general that's not what it's for.
- dradtke 7y ago
  Wasn't it originally called Function as a Service? That seems to be a better name for its intended use-case than serverless.
  - erikerikson 7y ago
    FaaS is one example of a serverless service. Workflow or object storage services are others. It was the arrival of FaaS that stimulated the term.
- skywhopper 7y ago
  Marketing latches onto that because 1) executives understand front-end use cases better than glue cases; and 2) it's way more profitable.
jrumbut 7y ago
I'm not sure about your quantification of the overhead, I think you can have wins with severless there, but the other side of it is that you can make your server management a source of strength. This is becoming unfashionable because it is arcane, but *nix (and Windows I'm sure) really provide some rich functionality and tunability that can let you move fast or reach performance/scale challenges that are very expensive or perhaps out of reach otherwise. Of course, at one point I was told the same thing about managing your own hardware, and the thought of dealing with the jumpers on the back of the harddrive fills me with the same sense of frustration I'm sure a newer developer would feel when learning their disk is out of inodes for the first time.

by 188201 7y ago

rgallagher27 7y ago

Have been running our API on Gateway/Lambda for well over a year now, having migrated from EC2. We've spent almost no time "managing" API gateway, monitoring or logging since the initial setup and migration of our infrastructure. If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.

cle 7y ago

You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.

mbrumlow 7y ago
>> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.
- tapoxi 7y ago
  > Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.
  - falcolas 7y ago
    Shifting blame doesn’t help much when you lose customers (or pay financial penalties) due to non—compliance. You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.
    - IggleSniggle 7y ago
      Yup! If something goes wrong with compliance, who is going to win the finger pointing game? A smaller company that needs to outsource their compute, or Amazon?
      - shawnz 7y ago
        If it was really Amazon's service that was at fault, then what are the chances that only one client is affected?
    - SpicyLemonZest 7y ago
      It’s rare for things to go so disastrously wrong that legal sway is relevant. What’s much more common is an angry CTO looking for someone to be mad at, and Amazon doesn’t have any particular ability to deflect that.
      - falcolas 7y ago
        If you're dealing with businesses where compliance is required, such as PCI, HIPPA, or FedRamp, legal sway is absolutely relevant. If you should have a breach and an associated fine, Amazon can easily push the blame (and the likely-company-breaking fines) back on you.
shams93 7y ago
Most Enterprise are still married to java, they still write off node as "not a real language" most likely node is your best bet for the most efficient lambdas Java is a poor for for that.

wongarsu 7y ago

Whenever I've spoken with engineers from AWS and Google Cloud they saw serverless as a platform for glue code, webhooks, cronjobs and the like. In that role it works great: you don't care if it takes 300ms to start and it's genuinely easier and cheaper than running that code on a server. But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. Maybe that works great for some edge cases (e.g. reaching PCI compliance), but in general that's not what it's for.

dradtke 7y ago
Wasn't it originally called Function as a Service? That seems to be a better name for its intended use-case than serverless.
- erikerikson 7y ago
  FaaS is one example of a serverless service. Workflow or object storage services are others. It was the arrival of FaaS that stimulated the term.
skywhopper 7y ago
Marketing latches onto that because 1) executives understand front-end use cases better than glue cases; and 2) it's way more profitable.

jrumbut 7y ago

I'm not sure about your quantification of the overhead, I think you can have wins with severless there, but the other side of it is that you can make your server management a source of strength. This is becoming unfashionable because it is arcane, but *nix (and Windows I'm sure) really provide some rich functionality and tunability that can let you move fast or reach performance/scale challenges that are very expensive or perhaps out of reach otherwise. Of course, at one point I was told the same thing about managing your own hardware, and the thought of dealing with the jumpers on the back of the harddrive fills me with the same sense of frustration I'm sure a newer developer would feel when learning their disk is out of inodes for the first time.