[^ps1] In traditional server-based development projects, developers would typically run the full stack on their local development machine. Once a feature is ready and merged into the main branch, it would be deployed (either via a CI/CD process or manually by an engineer) to a shared environment for further testing. In serverless stacks however, while local emulators do exist for some cloud-native services (e.g. [DynamoDB Local](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html)), I almost always want to use the real cloud services for a few reasons: - It’s faster and less error prone to consistently setup across the team (baseline cloud environments are more homogeneous than individual developer machines) - It reduces integration bugs that “worked on my machine” (e.g. often around IAM permissions or infra config) - I only need to configure a resource once (e.g. using CloudFormation YAML) rather than first manually creating and configuring a local emulator at dev time and having to separately configure the cloud equivalent once my feature is ready to integrate. [^ps1]: [Give developers their own AWS account](https://serverlessfirst.com/give-developers-own-aws-account/) by [[@Paul Swail]] --- ## References - [Why local development for serverless is an anti-pattern](https://dev.to/garethmcc/why-local-development-for-serverless-is-an-anti-pattern-1d9b) by [[@Gareth McCumskey]] --- tags: #Serverless #DeveloperWorkflow