45 lines
1.6 KiB
Markdown
45 lines
1.6 KiB
Markdown
|
# Development Principles
|
||
|
|
||
|
> **Note:** This document outlines guidances behind some development decisions
|
||
|
> behind the Hipster Shop demo application.
|
||
|
|
||
|
### Minimal configuration
|
||
|
|
||
|
Running the demo locally or on GCP should not require minimal to no
|
||
|
configuration unless absolutely necessary to run critical parts of the demo.
|
||
|
|
||
|
Configuration that takes multiple steps, especially such as creating service
|
||
|
accounts should be avoided.
|
||
|
|
||
|
### App must work well outside GCP
|
||
|
|
||
|
Demo application should work reasonably well when it is not deployed to GCP
|
||
|
services. The experience of running the application locally or on GCP should
|
||
|
be close.
|
||
|
|
||
|
For example:
|
||
|
- OpenCensus prints the traces to stdout when it cannot connect to GCP.
|
||
|
- Stackdriver Debugging tries connecting to GCP multiple times, eventually gives
|
||
|
up.
|
||
|
|
||
|
### Running on GCP must not reduce functionality
|
||
|
|
||
|
Running the demo on the GCP must not reduce/lose any of the capabilities
|
||
|
developers have when running locally.
|
||
|
|
||
|
For example: Logs should still be printed to stdout/stderr even though logs are
|
||
|
uploaded to Stackdriver Logging when on GCP, so that developers can use "kubectl
|
||
|
logs" to diagnose each container.
|
||
|
|
||
|
### Microservice implementations should not be complex
|
||
|
|
||
|
Each service should provide a minimal implementation and try to avoid
|
||
|
unnecessary code and logic that's not executed.
|
||
|
|
||
|
Keep in mind that any service implementation is a decent example of “a GRPC
|
||
|
application that runs on Kubernetes”. Keeping the source code short and
|
||
|
navigable will serve this purpose.
|
||
|
|
||
|
It is okay to have intentional inefficiencies in the code as they help
|
||
|
illustrate the capabilities of profiling and diagnostics offerings.
|