Click to show the outline

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
  • http://gopherize.me

Kevin also wrote a book Cloud Native Go to show how to Building Web Applications and Microservices for the Cloud with Go and React. This book has been translated to Chinese by four guys from TalkingData with ❤️. 《Cloud Native Go 构建基于 Go 和 React 的云原生 Web 应用与微服务》published by PHEI publisher house.

Kevin was signing his name on the book

This is his first visit to China, as a main translator of this book I an honored to be with him to take this photo.