Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

The 12 Factors for Building Cloud-Native Software

4.521 visualizaciones

Publicado el

Each slide covers one of the 12 factors, including what it is, why it's important and suggestions for how to implement it (with a focus on dot net applications). By Ed King, Pivotal.

https://drive.google.com/file/d/13_lD7Ve68_VbLeew7iqlkEpBVuPy7wXO/view

Publicado en: Software

The 12 Factors for Building Cloud-Native Software

  1. 1. The 12 Factors > A methodology for building Software as a Service applications > Originated from engineers working at Heroku > A focus on stateless applications suitable for modern cloud platforms
  2. 2. The 12 Factors > Codebase > Dependencies > Config > Backing services > Build, release, run > Processes > Port binding > Concurrency > Disposability > Dev/prod parity > Logs > Admin processes
  3. 3. Codebase What > Each codebase must be stored in version control > One-to-one relationship between application and codebase > One-to-many relationship between codebase and deploys Why > To support collaboration between developers and teams > To enable proper versioning How > Git, Subversion, Mercurial, etc.
  4. 4. Dependencies What > Explicitly declare and isolate application dependencies > Use a declaration manifest that’s stored with the codebase > Use a dependency isolation tool during application execution Why > Provides consistency between dev/prod environments > Simplifies setup for developers new to the application > Supports portability between cloud platforms How > Nuget
  5. 5. Config What > Ensure strict separation between code and configuration > Store configuration in environment variables Why > Modify application behaviour without making code changes > Simplifies deployment to multiple environments > Reduce risk of leaking credentials and passwords How > Extract all application config to environment variables > cf set-env
  6. 6. Backing Services What > Treat backing services (E.g. MySQL) as attached resources > Make no distinction between local and third party services > Attach resources via URLs stored in the app’s config Why > Provides loose coupling between service and deployment > No code changes required to update backing services > Allows operators to swap services out as they see fit How > cf marketplace, cf create/bind-service
  7. 7. Build, Release, Run What > Strictly separate the build, release and run stages Why > To prevent changes to code and/or configuration at runtime … > … which in turn lowers the number of unexpected failures How > cf push
  8. 8. Processes What > Execute the app as one or more stateless processes > Ensure all stateful data is stored in a backing service Why > Reduce deployment complexity > Reduce operational complexity > Allow for much simpler scaling How > Store any stateful data in backing services > Do not use sticky sessions or the local filesystem!
  9. 9. Concurrency What > Scale out via the process model > Treat processes as first class citizens > Do not daemonize processes or attempt to write PID files Why > Allows for easy, horizontal scaling How > Split app into separate, runnable processes > Scale independently
  10. 10. Disposability What > Maximise robustness via fast startup and graceful shutdown > Treat app instances as cattle, not pets > Be resilient to unexpected and sudden shutdowns (SIGKILL) Why > To facilite fast, elastic scaling > To allow for rapid deployment of new code/config changes > Provide robustness in production deployments How > Minimise work on startup, don’t depend on shutdown hooks
  11. 11. Dev/prod Parity What > Keep development, staging and production deploys as similar as possible Why > Lower risk of unexpected errors / downtime in production > To support continues deployment How > Ensure the same backing services are used for all deployments > Ensure a solid Continues Integration pipeline > Deploy to production as often as possible
  12. 12. Logs What > Treat logs as event streams > Log to stdout and stderr only > Do not think about storage of logs at all Why > To make logging a platform concern, not a developer concern > Improved flexibility for introspecting behaviour over time How > log to stdout/stderr only, cf logs
  13. 13. Admin Processes What > Run admin/management tasks as one-off processes > Store code for admin tasks with the app’s codebase > E.g. One-off debug tasks, REPL access to production Why > Safely support debugging/admin of production applications How > cf run-task

×