Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 12-Factor Apps
Similar a 12-Factor Apps (20)
Más de Siva Rama Krishna Chunduru
Último
Último (20)
12-Factor Apps
- 1. 12-Factor Applications Modern Application Development Methodology Siva Rama Krishna
- 2. @sivachunduru linkedin.com/in/chunduru slideshare.net/sivachunduru 2 Siva Rama Krishna – Solution Specialist
- 3. Need for 12-Factor App To better address Scalability, Maintainability and Portability 3
- 4. Lot of Moving Parts Fat Clients Web/Native Apps Modular Web Apps Monolithic Backend on heavy weight middleware Backend services and Managed cloud services MicroServices Physical Infra + Bare Metal Servers VMs + Public/Private Cloud Multi-Cloud + Containerization 10^1 10^2 10^3
- 6. I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing Services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port Binding Export services via port binding VIII.Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep dev, staging and prod as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes The 12 Factors
- 7. 1. Codebase One codebase tracked in revision control, many deploys 7
- 8. Codebase must be tracked in a VCS 8
- 9. Code Repository for Single Application 9 Root Commit
- 10. 10 Multiple deploys with Single Codebase Environments Production Non-Production Branches Feature Branches Avoid staging deploys
- 11. Codebase is tracked in a VCS Code repo contains a single application with a common root commit. Multiple environments are handled through multiple deploys 11 Codebase - Summary PRODUCTION STAGING DEV 1 DEV 2 Codebase Deploys
- 12. 12 Codebase – Anti-Patterns PRODUCTION STAGING DEV 1 DEV 2 Codebase App-1 Deploys PRODUCTION STAGING DEV 1 DEV 2 Codebase App-2 Deploys PRODUCTION STAGING DEV 1 DEV 2 App-1 Deploys Different Codebases Different Applications
- 13. 2. Dependencies Explicitly declare and isolate dependencies 13
- 14. Common Dependencies 14 v 1.0 App 1 App 2 App 3 v 1.1 App 4 v 1.2
- 15. App 4App 3App 2 Isolation of Dependencies 15 App 1 v 1.0 v 1.0 v 1.1 v 1.2
- 16. Portability of Application 16 App Linux Windows Docker PaaS
- 17. Dependencies - Summary • No implicit system-wide packages. • Declare all dependencies using a dependency declaration manifest. • Most languages have dependency declaration and management tools. 17 Language Manifest Java Maven Node NPM Ruby Gems Python Pip
- 18. • Many dependencies • Long chains of dependencies • Conflicting dependencies • Circular dependencies • Package manager dependencies 18 Dependencies – Anti-Patterns Dependency Hell
- 19. 3. Config Store configuration values in the environment 19
- 20. Configuration includes all values needed by application that are specific to the target environment 20 ${TCP_PORT} ${HTTP_PROXY} ${HTTP_PORT} ${DB_SID} ${DB_SERVICE} ${LOG_PATH} ${ENV_TAG} ${NODE_ENV} ${HOST_NAME} ${ADMIN_URL}
- 21. App must be FREE from - • Hardwiring Credentials data – DB credentials – External service credentials • Hardwiring Environmental info. – OS level variable like PROXY – Network location • Hardwiring internal URLs 21 No hardwiring of configuration data
- 22. Application must fetch from - • External Service • Environment Variable(s) • User provided Service(s) 22 How to source configuration data?
- 23. Config - Summary 23 Application Config manifest.json Launch command and app version info All application binaries and resources Application Archive deployment.jsonEnvironment Variables, Service Bindings, Memory, Instances • Config is everything that is likely to vary between deploys like, – Resource handles to the DB, Memcached & other backing services – Credentials to external services like Amazon S3 or Twitter • Apps sometimes store config as constants in the code. This is a violation. • Config varies substantially across deploys, code does not.
- 24. • Ensure every time, when an application is deployed, the supplied configuration matches to what is expected • Don’t run the configuration management inside your container images. – Immutability matters a lot 24 Config – Anti-Pattern
- 25. 4. Backing Services Treat backing services as attached resources 25
- 26. Treat external/internal systems as local ones Swapping out the service(s) in each environment becomes easy.
- 27. • A backing service is any service the app consumes over the network as part of its normal operation. Examples include, - data stores - messaging/queueing systems - SMTP services for email - caching 27 Backing Services - Summary
- 28. • No local disk – Connect to network attached services using connection information from environment 28 Backing Services – Anti-Pattern
- 29. 5. Build, Release, Run Strictly separate build and run stages 29
- 30. Plan Code Build Test Package Release Deploy Monitor 30 CI / CD Plan Code Build Test Package Release Deploy Monitor Continuous Integration Continuous Delivery If Agile software development was the opening act to a great performance, continuous delivery is the headliner. - Kurt Bittner, Principle Analyst
- 32. Code Change Build + Release Config Change Release 32 Release process against changes Build Config Release Build Config Release
- 33. Build, Release, Run - Summary Build Release Run 33 • Convert a code repo into an executable bundle known as a build • The build stage fetches vendor dependencies and compiles binaries and assets. • Takes the build and combines it with the deploy’s config. • The resulting release contains both the build and the config and is ready for immediate execution. • Runs the app in the execution environment, by launching some set of the app’s processes against a selected release.
- 34. Install on Deploy • Build immutable images then run those images 34 Build, Release, Run – Anti-Pattern
- 35. 6. Processes Execute the app as one or more stateless processes 35
- 36. Process Centric View System Administrator Developer Application Administrator Looks @ Processes Applications Single AppServer hosting many Applications 1 Process (AppServer itself) Many Applications Single App decomposed into multiple processes Multiple Processes Multiple Processes (Applications) ROLE NOT REQUIRED sh ./helloWorld
- 37. Stateless processes – Memory specifics • Single threaded memory usage • Short lived memory usage – leverage cache technologies • Leverage DB or Cache for long term memory needs 37
- 38. • Processes are stateless and share- nothing. • Data that needs to persist must be stored in a stateful backing service like database. • Web systems rely on “sticky sessions” – a violation of 12-factor – session state data is a good candidate for a data store that offers time- expiration 38 Processes - Summary
- 39. If multiple web servers are used, don’t just use locally uploaded files. – Use internal storage host like NFS (or) – external one such as AWS S3. 39 Processes – Anti-Pattern
- 40. 7. Port Binding Export services via port binding 40
- 41. Application’s port mapped to non-standard port Communication protocol usually bind on a non-standard port, allowing it to run in a container in an isolated fashion.
- 42. Application serves its messages with routing technology 42
- 43. Enable communication even with polyglot 43
- 44. • The app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. • Implemented by using dependency declaration to add a webserver library to the app like Jetty for Java. • This happens entirely within the app’s code. The contract with the execution environment is binding to a port to serve requests. 44 Port Binding - Summary
- 45. Don’t hardcode the ports the software runs on – Get the ports from environment variables 45 Port Binding – Anti-Pattern
- 46. 8. Concurrency Scale out via the process model 46
- 48. 48 Process of Scale Law of diminishing returns
- 49. • The process model truly shines when it comes time to scale out. • The share-nothing, horizontally partitionable nature means that adding more concurrency is a simple and reliable operation. 49 Concurrency - Summary
- 50. 9. Disposability Maximize robustness with fast startup and graceful shutdown 50
- 51. • App’s processes are disposable, meaning they can be started or stopped at a moment’s notice. • This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys. 51 Disposability - Summary Security Scalability Fault Tolerance
- 52. Hug of Death – you want to make sure you have bad, corrupt, or lost data. 52 Disposability – Anti-Pattern
- 53. 10. Dev/Prod Parity Keep development, staging, and production as similar as possible 53
- 54. • App is designed for continuous deployment by keeping the gap between DEV and PROD small. – Make the time gap small: a developer may write code and have it deployed hours or even just minutes later. – Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production. – Make the tools gap small: keep DEV and PROD as similar as possible. 54 Dev/Prod Parity - Summary
- 55. 11. Logs Treat logs as event streams 55
- 56. Logs are written to streams
- 57. • App never concerns itself with routing or storage of its output stream. • It should not attempt to write to or manage log files. • Instead, each running process writes its event stream, un- buffered, to stdout. 57 Logs - Summary
- 58. Random log files all over the file system 58 Logs – Anti-Pattern
- 59. 12. Admin Processes Run admin/management tasks as one-off processes 59
- 60. • One-off admin processes should be run in an identical environment as the regular long-running processes of the app. • They run against a release, using the same codebase and config as any process run against that release. • Admin code must ship with application code to avoid synchronization issues. 60 Admin Processes - Summary
- 61. • Custom containers for tasks – Reuse application images with specific entry points for tasks 61 Admin Processes – Anti-Pattern Identical environments
- 62. Beyond 12-Factors Is there anything left out ?
- 63. More Factors • API First – Work against each other’s public contracts • Telemetry – Application Performance Monitoring – Domain specific Telemetry – Health and System Logs • Security – Authentication – Authorization
- 65. Summary 65