15 Factor App

Slide deck related to 15 Factor App. Covers all the aspects related to Cloud Native application development using 15 Factor App methodology.

Transcript

1. Fifteen Factor Apps Nilesh Gule @nileshgule
2. $whoami { “name” : “Nilesh Gule”, “website” : “https://www.HandsOnArchitect.com", “github” : “https://GitHub.com/NileshGule" “twitter” : “@nileshgule”, “linkedin” : “https://www.linkedin.com/in/nileshgule”, “YouTube” : “https://www.YouTube.com/@nilesh-gule” “likes” : “Technical Evangelism, Cricket”, “co-organizer” : “Azure Singapore UG” }
4. Agenda
5. Gartner Forecast Public Cloud Spending ~600 Billion in 2023 Gartner Forecasts Worldwide Public Cloud End-User Spending to Reach Nearly $600 Billion in 2023
6. Codebase One codebase tracked in version control, many deploys Dependencies Explicitly declare and isolate dependencies Config Store config in the environment Backing services Treat backing services as attached resources Build, Release and Run Strictly separate build and run stages Processes Execute the app as one or more stateless processes Port Binding Expose services via port binding Concurrency Scale out via process-model Disposability Maximize robustness with fast startup and graceful shutdown Dev/Prod Parity Keep development, staging and production as similar as possible Logs Treat Logs as event streams Admin Processes Run admin/management tasks as one-off processes
7. Customer environments and application requirements are evolving Govern and operate across disparate environments Ensure security across the entire organization Best enable innovation and developer agility Meet regulatory requirements and overcome technical hurdles 100’s–1,000’s of apps Diverse infrastructure Hybrid & Multi-Cloud Credit: Lior Kamrat
8. Codebase One codebase tracked in version control, many deploys Dependencies Explicitly declare and isolate dependencies Config Store config in the environment Backing services Treat backing services as attached resources Build, Release and Run Strictly separate build and run stages Processes Execute the app as one or more stateless processes Port Binding Expose services via port binding Concurrency Scale out via process-model Disposability Maximize robustness with fast startup and graceful shutdown Dev/Prod Parity Keep development, staging and production as similar as possible Logs Treat Logs as event streams Admin Processes Run admin/management tasks as one-off processes API First Define service contract Telemetry Monitor process performance Authentication Secure applications across hardware, network, and software layers
9. One codebase, many deploys • A version control system like Git always tracks the fifteen-factor app • There is only one codebase per app, but there are many deploys of the app. • The app is the same across all deploys, but different versions may be active in each deploy Configuration settings Provisioning settings Source code Production Staging QA Source code repository
10. Explicitly declare and isolate dependencies • Declare all external dependencies, completely and exactly via dependency declaration manifest • Helps to have a deterministic build • Do not rely on the implicit existence of any system tools
11. Externalize configuration • Values vary across deployments (dev workstation, QA / staging, Production) • URLS and other info about backing service such as Web Services and SMTP servers • Database connection strings • Information bundled in configuration files such as properties file or XML or YAML configs • Externalize configuration • Use product or service designed to expose configuration preferable with version management
12. Treat backing services as attached resources • Common types of backing services include file storage, databases, messaging systems, caching systems, SMTP servers, etc. • Bound resource connects an application to a backing service • Rules for resource binding • An application should declare its need for backing service but allow cloud environments to perform resource binding • External configuration is used to bind an application to backing service • It should be possible to attach and detach backing service from an application without redeploying the application Application Storage Service Authentication Service Database Service Messaging Service
13. Strictly separate Build and Run stages • Separate each stage of the application into the Design, Build, Release, Run • Continuous Integration (CI) creates the build artifact. There is 1:Many relationship between builds and deployments • Separating build and release phases and storing artifacts makes it easier for rollback and auditing • Run stage provides Scalability, Observability, Resiliency, etc. Build Run Release Code Design Configuration
14. Execute app as stateless processes • Applications should execute as a single, stateless process • All long lasting state must be external to the application, provided by backing services • Processes come and go, scale horizontally and vertically, and are highly disposable. Use Share-Nothing pattern. 1000 (configurable) messages Batch of 50 (configurable) messages https://github.com/NileshGule/pd-tech-fest-2019
15. Expose services via Port Binding • Application is identifiable to the network by port number, not a domain name • Self-contained apps does not require runtime injection of webserver into execution environment • Always maintain a 1:1 correlation between application and application server • Web application exports HTTP as a service by binding to a specific port and listening to requests Production www.handonarchitect.com:8080 Staging www.handsonarchitect.com:8081 QA www.handsonarchitect.com:8085 https://www.flaticon.com/free-icons/development - Icon source Website / webapp
16. Scale-out via process model 1000 (configurable) messages Batch of 50 (configurable) messages https://github.com/NileshGule/pd-tech-fest-2019 • Scale out using a process model, distribute workload across multiple processes • Prefer Horizontal scaling over vertical scaling • Cloud providers can scale dynamically using rules based on load or runtime telemetry
17. Fast Startup and Graceful Shutdown • Processes are disposable, started or stopped at a moment’s notice • Maximize robustness with fast startup and graceful shutdown • Extremely slow startup time could prevent the app from starting at all in the cloud • Ensure apps shutdown quickly and gracefully and maintains correct state
18. Keep all environments as similar as possible • Keep all our environments (Dev / QA / Staging / Pre-Production / Production) as similar as possible • Differences arise due to factors such as scaling and reliability needs, database drivers, security rules, firewalls and other environmental configuration settings • Common culprits for gaps between environments • Time – Reduce the time gap from checking code to production deployment • People – Automate deployments using CI CD pipelines • Resources – Reduce differences between environments using tools like Docker Production Staging Dev Production Staging Dev
19. Treat Logs as event streams • Write all entries to stdout and stderr • Treat aggregation, processing, and storage of logs as non-functional requirements satisfied by the cloud provider Log collector Log storage Log search, visualise, dashboards rabbitmq-producer- service rabbitmq-consumer- deployment
20. Run admin/management tasks as one-off processes • One off tasks in identical environment as the regular long-running processes • Run database migrations • Run periodic scripts (daily / nightly / monthly) • Run one time script to fix data issues • Run REPL Batch Process Database Service Azure Function
21. Define Service Contract • Well suited for cloud development • Allows rapid prototyping • Support a services ecosystem • Facilitates automated deployment testing and continuous delivery pipelines • Enables consumers and service developers to work in parallel • Helps to avoid bottlenecks and facilitates virtualization of APIs by allowing consumers to run tests against the mocks
22. Monitor process performance • Categories of data • Application Performance Monitoring (APM) • Domain-specific telemetry • Health and System logs • Helps to scale, self-heal and manage alerts for end users and platform operators
23. Secure applications across hardware, network and software layers • Security should never be an afterthought • Secure all endpoints with Role-based access control (RBAC) • Enhance security using • OAuth2, OpenID Connect, SSO servers and standards • Language-specific authentication and authorization libraries
24. Secure applications across hardware, network and software layers
25. 15 Factor Apps Extension to 12 Factor App Key enhancements to 15 Factor App ✓ Use Declarative Formats for setup automation ✓ Have a Clean Contract, offering maximum portability between execution environments ✓ Suitable for deployment on modern Cloud Platforms, obviating the need for servers and system administrators ✓ Minimize Divergence between development and production ✓ Dynamically Scalable without significant changes to tooling, architecture, or development practices ✓ Service-Driven Approach – Availability of the contract ✓ Monitoring the distributed applications deployments for domain/application-specific logs/data, health information, or more statistics on modern cloud platforms ✓ Security (Authentication & Authorization) is addressed appropriately
26. The 12 Factor App Beyond the Twelve-Factor App by Kevin Hoffman GitHub repo by Christopher M. Judd on 15 Factor Apps GitHub repo by Vikas Gupta on Fifteen Factor Apps Medium post by Vikas Gupta IBM post on 15 Factor Cloud-Native Java application 15 Factor Apps YouTube series
27. Codebase One codebase tracked in version control, many deploys Dependencies Explicitly declare and isolate dependencies Config Store config in the environment Backing services Treat backing services as attached resources Build, Release and Run Strictly separate build and run stages Processes Execute the app as one or more stateless processes Port Binding Expose services via port binding Concurrency Scale out via process-model Disposability Maximize robustness with fast startup and graceful shutdown Dev/Prod Parity Keep development, staging and production as similar as possible Logs Treat Logs as event streams Admin Processes Run admin/management tasks as one-off processes API First Define service contract Telemetry Monitor process performance Authentication Secure applications across hardware, network, and software layers
28. Nilesh Gule ARCHITECT | MICROSOFT MVP “Code with Passion and Strive for Excellence” nileshgule @nileshgule Nilesh Gule NileshGule www.handsonarchitect.com https://bit.ly/youtube-nileshgule