...

• ✅ Use package management system – declare complete and exact list of dependencies in a dependency declaration manifest 

• ✅ Do not rely on system-wide packages 

• ✅ Ensure implicit system-wide dependencies do not “leak in” from the surrounding system using isolation 

• ✅ The dependency list is applied uniformly both in production and development 

• ✅ Language runtime and dependency manager as pre-requisites are allowed 

• ✅ Deterministic build command sets up everything required to run the code 

• ✅ App should also not rely on any system tools, e.g., curl. If an app needs to shell out to a system tool, it should be vendored into the app 

...

• ✅ Use config to control variables that change between deployments (staging, production, etc.), e.g., database, credentials, per-deploy values, etc. 

• ✅ Config should not be part of the code 

• ✅ Application configuration that does not change between deployments can be stored in code 

• ✅ Instead of scattering config files and risking them getting committed to source control, utilize environment variable files instead 

• ✅ Environment variables are not grouped together into “environments” for specific deployments, they are granular controls managed independently for each deployment 

...

• ✅ Build stage transforms code repo into an executable bundle (build). Using a version of the code at a commit specified by the deployment process, the build stage also fetches dependencies and complies binaries and assets 

• ✅ The release stage combines build with deployments current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment 

• ✅ The run stage runs the app in the execution environment, by launching some of app’s processes against a selected release 

• ✅ The stages are strictly separated, e.g., there is no way to make changes to the code at runtime 

• ❓ Releases should have a unique release identifier (ex. Timestamp or incremental versioning), be append-only (cannot mutate a release) 

• ❌ It should be possible to rollback to previous release 

• ✅ The run stage should be as simple as possible, with the complexity being shifted into the build stage (since the run stage can be triggered automatically if an app crashes and there is no one around to debug any issues, for example) 

...

• ✅ Processes are disposable, meaning they can be started and stopped at a moment’s notice, allowing fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys 

• ❌ Startup time is minimized (ideally a few seconds) 

• ❓ The process shut down is graceful. For web processes this means ceasing to listen on the service port, allowing any current requests to finish and then exit 

• ✅ Http requests are short (no more than a few seconds) 

• In case of long polling, client should seamlessly attempt to reconnect when the connection is lost 

• ⚫ Worker processes achieve graceful shutdown by returning current job the work queue. All jobs are reentrant through wrapping the results in a transaction or by making the operation idempotent. 

• ❓ Processes should be robust against sudden death (non-graceful termination) 

10. Dev/prod parity 

Keep development, staging, and production as similar as possible. Historically there have been substantial gaps between development and production (code making its way from developer’s local deploy to production). This results in 3 gaps, that can be reduced using continuous deployment 

...

• ✅ Logs are the stream of aggregated time-ordered events collected from the output streams of all running processes and backing services 

• ✅ App should not concern itself with routing or storage of its output stream. Each process writes its events into stdout. Locally this is viewed in the terminal.  

• ✅ In production, each stream is captured by the execution environment, collated together with all other streams, and routed to one or more final destinations for viewing and long-term archival 

...

• ✅ One-off admin processes should be run in an identical environment as the regular long-running process of the app 

• ✅ These processes should run against a release, using the same codebase and config as any process run against that release 

• ✅ Admin code is shipped with application code 

• ✅ Same dependency isolation is used on all process types, e.g., if a python program normally uses virtualenv, bin/python should be used for running both the Tornado webserver and any admin processes 

• ✅ Use REPL shell if available to make run one-off scripts. Locally this is done by starting the shell inside the app’s checkout directory, while in production developers can use SSH or other remote command execution mechanism. 

Additional Cloud Native Factors 

...

Additional factors for cloud native apps: 

13. API-First 

API-first was introduced as a factor to place emphasis on the importance of APIs within cloud-native application development. 

...

• ❓ Health and system metrics include application start/shutdown, scaling, web request tracing and results of periodic health checks are collected, e.g., Prometheus  

• ❌ Domain specific metrics (those needed or required by our specific organization/department/team) are collected 

15. Authentication and authorization 

...