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.
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.
It shifts blame, especially if it's in the contract with the provider.
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.
If you don't adhere to the shared responsibility model and a contractor checks long lived IAM credentials into Github, that breach is definitely attributable to you and you deserve all the "blame" you get.
But if someone figures out how to trick AWS' IAM into issuing credentials that allow PHI to be pulled out of S3, do you think that gets passed along to a customer?
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.
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.”
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.
If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.
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.