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

[owenmarshall]

AWS' compliance model isn't a magic wand that makes your crappy app's XSS vulnerabilities go away. The real question: do you think AWS will try to push responsibility for a breach to their customers unjustly?

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?

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