How do you run software locally for testing, development, or experimentation?
This is probably the key question for most developer-focused products, and the answer often plays a significant role in the decision process.
Bad local development stories can be a source of enormous friction. So what does a bad local development experience look like?
- Stateful APIs without a clear forking or lightweight new environment mechanism (e.g., databases)
- Hidden errors that aren’t surfaced to the user
- Needs to integrate with multiple services behind a firewall (or on a developer’s machine) but provided network path (or tools to set up on). The SaaS version of this is “whitelist these IPs.”
- No automation or APIs for commonly automated tasks (setting up a new environment, configuration, etc.).
Potential generic solutions
- Open-source parts and let the developers figure it out
- Emulators that mimic production behavior (e.g., LocalStack/AWS)
- Minified versions of the real thing (e.g., minikube/Kubernetes)
- Stateless APIs
- APIs for ephemeral services (e.g., spin up an AWS SQS queue for local development and then delete it)
- Verbose and surfaced logs for parts of the service that need to be debugged.