[brentmitchell25]

It's alright, but continued to find bugs and edges cases with it. The challenge is when there are a bunch of integrations cross-accounts, eventbridge, cloudwatch, etc. that you just can't emulate well locally. Or once you do, it doesn't work a month from now because things change (e.g. a developer is using a new feature that isn't supported by localstack or something). In container land, you don't have to worry about these cloud integrations. You just spin up the services you want in a docker compose file, k8s deployments, helm charts, etc. and you basically have everything without having to worry about being a AWS specific blackbelt guru expert.

[yuppie_scum]

You just have to be a Kubernetes black belt guru expert. It is better but it’s not all rainbows and butterflies on this side of the fence either. Generally it boils down to the stack taking way too many resources to run locally, or still needing access to various persistent data stores, etc..

[brentmitchell25]

You don't have to run kubernetes for containers, but even then, only 4 of our engineers know and operate kubernetes. It allows us to enforce routing, authn, and authz standards everywhere (and test locally). Application engineers only need a simple command to run their stack and some code templates to build and test applications. Not much knowledge is typically needed on their part. Is it always perfect? No, but it's a lot simpler then wiring up a bunch of vendor specific offerings.