[thehappypm]

I feel like the cognitive load here is just different, not worse.

Dev environments in traditional shops are usually a PITA and only really resemble production. We’re all just used to it. This model is different but once you’re used to it, must be quite a joy. The main drawback seems to be developing against real services (rather than emulated) is slower, but that seems like a worthwhile trade off IMO.

[fauigerzigerk]

It seems risky though. One runaway process that accidentally floods this infinitely scalable Amazon cloud with requests and you could quickly rack up a huge bill. I'm not sure I want this hanging over my head during development and testing. It's problematic enough in production.

[thehappypm]

That’s a trade off. With the traditional approach you may introduce bugs into production when your dev environment isn’t a perfect emulation (works in dev!). With this approach dev and prod are much more identical.

[fauigerzigerk]

True, but this problem is greately exacerbated by the incredible complexity of this sort of architecture. And running dev in the cloud doesn't completely solve it either as configuration issues have always been a major cause of the "works in dev" issue.

[thehappypm]

Again, “incredible complexity” is not correct, it’s just complex in a different way. Serverless is pretty remarkable because it abstracts a huge amount of pain away. Never deal with weird file issues or even having to think much about scalability.. that’s a huge luxury. There are other parts that are more complex but you’re basically trading a lot of nuisance away

[WhyNotHugo]

I feel like we reached a sweet stop with Docker or dedicated VMs, where the dev environment was near-identical to production.

The serverless trend breaks this a lot by making the production environment cloud-only and not something that you can run offline.