[188201]

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.

[wongarsu]

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]

Wasn't it originally called Function as a Service? That seems to be a better name for its intended use-case than serverless.

[erikerikson]

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]

Marketing latches onto that because 1) executives understand front-end use cases better than glue cases; and 2) it's way more profitable.

[cle]

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]

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

[owenmarshall]

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy.

Are you joking? Outsourcing compliance critical parts of your environment is the raison d'être of huge swaths of the enterprise IT landscape.

https://aws.amazon.com/compliance/services-in-scope/

Can you imagine how much that page costs in terms of getting the audits, developing the processes & procedures internally to execute on the requirements, etc?

That's not hand-waving away concerns: it's paying a premium to know your infrastructure was managed in scope of whichever compliance regime your business falls under, and to get attestations that prove to your auditors that things are indeed being done properly.

[avip]

But they do go away. They go straight away to a vendor which is very likely to address them faster, and with more competent resources, than you and your team (or, if that sound insulting - me and my team). They become covered with that famous someone else's problem field

[SkyPuncher]

> They go straight away to a vendor

This argument only works until you reach a certain size or security requirements.

At the end of the day, if it's critical to the business it doesn't matter what the paper says, you're still responsible for any damage to the business from a bad vendor.

----

It's just like car manufacturers, nobody cares that Takata was actually responsible for faulty airbags. They simply know their GM vehicle has a dangerous recall.

[derefr]

But, at that same “certain size”, shareholder value for your company becomes something influenced mostly by making your value-chain upstream/downstream partners happy, not by making the eventual customers of your product/service happy.

Rather than thinking about GM’s perspective, think about Takata’s perspective: they screwed up making an airbag, but everything was fine because they outsourced their audit to GM, so indeed it was “GM’s responsibility.” On top of that, GM is still happy to treat them as a partner.

Now imagine that instead of some random third-party supplier, Takata was a division of GM, selling to a different division of GM. The same considerations still apply from the Takata-as-division’s perspective, even though nominally they’re part of a company of that “certain scale.”

[tapoxi]

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

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.

[SpicyLemonZest]

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]

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.

[IggleSniggle]

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]

If it was really Amazon's service that was at fault, then what are the chances that only one client is affected?

[shams93]

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.

[rgallagher27]

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.

[jrumbut]

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.