Kevin Hoffman(From Capital One, twitter @KevinHoffman ) was making a speech on TalkingData T11 Smart Data Summit.
He addressed that 15 Factors of Cloud Native which based on Heroku’s original Twelve-Factor App , but he add more 3 another factors on it.
Let’s have a look at the 15 factors of Cloud Native.
1. One codebase, one App
- Single version-controlled codebase, many deploys
- Multiple apps should not share code
- Microservices need separate release schedules
- Upgrade, deploy one without impacting others
- Tie build and deploy pipelines to single codebase
2. API first
- Service ecosystem requires a contract
- Public API
- Multiple teams on different schedulers
- Code to contract/API, not code dependencies
- Use well-documented contract standards
- Protobuf IDL, Swagger, Apiary, etc
- API First != REST first
- RPC can be more appropriate in some situations
3. Dependency Management
- Explicitly declare dependencies
- Include all dependencies with app release
- Create immutable build artifact (e.g. docker image)
- Rely on smallest docker image
- Base on scratch if possible
- App cannot rely on host for system tools or libraries
4. Design, Build, Release, Run
- Design part of iterative cycle
- Agile doesn’t mean random or undesigned
- Mature CI/CD pipeline and teams
- Design to production in days not months
- Build immutable artifacts
- Release automatically deploys to environment
- Environments contains config, not release artifact
5. Configuration, Credentials, Code
- “3 Cs” volatile substances that explode when combinded
- Password in a config file is as bad as password in code
- App must accept “3 Cs” from environment and only use harmless defaults
- Test - Could you expose code on Github and not reveal passwords, URLs, credentials?
6. Logs
- Emit formatted logs to stdout
- Code should not know about destination or purpose of log emissions
- Use downstream log aggregator
- collect, store, process, expose logs
- ELK, Splunk, Sumo, etc
- Use structured logs to allow query and analysis
- JSON, csv, KV, etc
- Logs are not metrics
7. Disposability
- App must start as quickly as possible
- App must stop quickly and gracefully
- Processes start and stop all the time in the cloud
- Every scale up/down disposes of processes
- Slow dispose == slow scale
- Slow dispose or startup can cause availability gaps
8. Backing Services
- Assume all resources supplied by backingservices
- Cannotassume mutable file system
- “Disk as a Service” (e.g. S3, virtual mounts, etc)
- Every backing service is bound resource
- URL, credentials, etc-> environment config
- Host does not satisfy NFRs
- Backing services and cloud infrastructure
9. Environment Parity
- “Works on my machine”
- Cloud-native anti-pattern. Must work everywhere
- Every commit is candidate for deployment
- Automated acceptance tests
- Provide no confidence if environments don’t match
10. Administrative Processes
- Database migrations
- Run-once scripts or jobs
- Avoid using for batch operations, consider instead:
- Event sourcing
- Schedulers
- Triggers from queues, etc
- Lambdas/functions
11. Port Binding
- In cloud, infrastructure determines port
- App must accept port assigned by platform
- Containers have internal/external ports
- App design must embrace this
- Never use reserved ports
- Beware of container “host mode” networking
12. Stateless Processes
- What is stateless?
- Long-term state handled by a backing service
- In-memory state lives onlyas long as request
- Requests from same client routed to different instances
- “Sticky sessions” cloud native anti-pattern
13. Concurency
- Scale horizontally using the process model
- Build disposable, stateless, share-nothing processes
- Avoid adding CPU/RAM to increase scale/throughput
- Where possible, let platform/libraries do threading
- Many single-threaded services > 1 multi-threaded monolith
14. Telemetry
- Monitor apps in the cloud like satellite in orbit
- No tether, no live debugger
- Application Perf Monitoring (APM)
- Domain Telemetry
- Health and system logs
15. Authentication & Authorization
- Security should never be an afterthought
- Auth should be explicit, documented decision
- Even if anonymous access is allowed
- Don’t allow anonymous access
- Bearer tokens/OAuth/OIDC best practices
- Audit all attempts to access
Migrating Monoliths to the Cloud
After this 15 factors, he also gave us some tips about how to migrate monoliths to the Cloud:
- Make a rule - stop adding to the monolith
- All new code must be cloud native
- Prioritize features
- Where will you get most benefit from cloud native?
- Come up with a plan
- Decompose monolith over time
- Fast, agile iterations toward ultimate goal
- Use multiple strategies and patterns
Go - the Best Language for Building Cloud Native App
At last, he advise us the programming language Go is the best language to build Cloud Native applications for these reasons below:
- Lightweight
- Easily learning curve
- Compiles to native binaries
- Very fast
- Large, thriving, engaged community