24F_CST8915_Week2 Lecture - The Twelve-Factor Application.pdf

Week 2 – The Twelve-Factor Application CST8915 – Full-stack Cloud-native Development September 11th, 2024  Lesson Overview (Agenda) In the following lesson, we will explore: 1. What is the Twelve-Factor methodology? 2. The Twelve Factors 3. Three extra factors for modern cloud-n...

Week 2 – The Twelve-Factor Application CST8915 – Full-stack Cloud-native Development September 11th, 2024  Lesson Overview (Agenda) In the following lesson, we will explore: 1. What is the Twelve-Factor methodology? 2. The Twelve Factors 3. Three extra factors for modern cloud-native app 2  The pillars of cloud native 3  Modern Design: The Twelve-Factor Application A widely accepted methodology for constructing cloud-based applications is the Twelve-Factor Application. A set of principles and practices to construct applications optimized for modern cloud environments. Special attention is given to portability across environments and declarative automation. While applicable to any web-based application, many practitioners consider Twelve-Factor a solid foundation for building cloud-native apps. Systems built upon these principles can deploy and scale rapidly and add features to react quickly to market changes. 5  The Twelve-Factor Application + Microservice 12 Factor App Microservice Great, Scalable Principles Principles Architecture + = 6  Modern Design: The Twelve-Factor Application 7  Factor 1: Code Base “One codebase tracked in revision control, many deploys” A twelve-factor app must have a single codebase, which is managed in a version control system (e.g., Git), and there should be multiple environments (staging, production, etc.) where this codebase is deployed. Code Version Control Deployed Version 8  Factor 1: Code Base 9  Factor 1: Code Base There is always a one-to-one correlation between the codebase and the app: If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor. Multiple apps sharing the same code is a violation of twelve- factor. 10  Factor 2: Dependencies “Explicitly declare and isolate dependencies” All dependencies that the application needs should be explicitly defined, usually Dependencies in a dependency management file (like requirements.txt for Python or package.json for Node.js). Code Never depend on the host to have your dependency. Binarie s Instead, package all dependencies and use isolated environments like containers. 11  Factor 2: Dependencies 12  Factor 3: Configurations “Store config in the environment” Development Configuration values such as database credentials or external service URLs should be Production stored in environment variables, not hard- coded into the application or stored in the codebase. This ensures separation between the code and configuration for better portability and security. At runtime the container gets config from the environment. 13  Factor 3: Configurations 14  Factor 4: Backing Services “Treat backing services as attached resources.” A backing service is any service the app consumes over the network as part of its normal operation, such as datastores and messaging/queueing systems. Backing services should be exposed via an addressable URL. Treat local services just like remote third-party ones. The app should be able to swap between different instances of a service (for example, switching from a local to a cloud database) without code changes, simply by modifying the configuration. 15  Factor 4: Backing Services 16  Break! Register your attendance by completing the attendance quiz of the lecture. 17  Build Artifact Factor 5: Build, Release, Run Dependencies Code A codebase is transformed into a (non-development) deploy through three stages: Binaries The build stage is a transform which converts a code repo into an Releas executable bundle known as a build. Using a version of the code at Build Artifact Config e a commit specified by the deployment process, the build stage fetches vendors dependencies and compiles binaries and assets. The release stage takes the build produced by the build stage and + = combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment. Task Definition Release v1.0.0 The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s processes against a selected release. Task Definition Release v1.0.1 18  Build Artifact Factor 5: Build, Release, Run Dependencies Code “Strictly separate build and run stages” Binaries Each release must enforce a strict separation across the build, release, and run stages. Build Artifact Config Releas e For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. + = Each release should be tagged with a unique ID and support the ability to roll back. Task Definition Release v1.0.0 Modern CI/CD systems help fulfill this principle. Task Definition Release v1.0.1 19  Factor 5: Build, Release, Run 20  Factor 6: Processes “Execute the app as one or more stateless processes.” Database Durable store of truth. The app should run as stateless processes, MySQL, PostgreSQL, meaning it should not rely on in-memory MongoDB, DynamoDB data between requests or jobs. Twelve-factor processes are stateless and Cache share-nothing. Fast, temporary state store. Any data that needs to persist must be redis, memcached stored in a stateful backing service, typically a database. Stateless processes need external, stateful backing services to store data. 21  Factor 7: Port Binding "Export services via port binding." In traditional web application deployments, you often have a separate web server (like Apache or Nginx) that listens for incoming requests on a specific port (like port 80 for HTTP). This web server is responsible for receiving HTTP requests and then passing them on to your application, which runs separately. Port Binding in the Twelve-Factor App methodology encourages the application itself to handle this responsibility. Instead of relying on external web servers to route traffic, the app should bind directly to a port and be able to accept HTTP requests on its own. This makes the application self-contained, so it can run independently without needing external server software. 22  Factor 8: Concurrency “Scale out via the process model” Processes are a first-class citizen! Instead of scaling the app vertically (making a single instance more powerful), twelve-factor apps scale horizontally by running multiple instances of stateless processes. Develop the application to be concurrent making scaling out in cloud environments seamless. The process model truly shines when it comes time to scale out. 23  Factor 9: Disposability “Maximize robustness with fast startup and graceful shutdown” Service instances should be disposable. Favor fast startup to increase scalability opportunities and graceful shutdowns to leave the system in a correct state. Docker containers along with an Fast Launch Responsive Graceful orchestrator inherently satisfy this Shutdown requirement. 24  Factor 10: Dev/Prod Parity “Keep development, staging, and production as similar as possible” Keep environments across the application Local Application Remote lifecycle as similar as possible, avoiding costly Dev #1 Staging / QA shortcuts. Development and production environments Production should be as similar as possible, to avoid issues Dev #2 that arise from environmental differences (e.g., using different databases locally and in production). Here, the adoption of containers can greatly contribute by promoting the same execution environment. 25  Factor 11: Logging “Treat logs as event streams” The apps should not concern themselves with managing log files. Instead, they should treat logs as streams of events and output them to stdout (standard output). Log processing, storage, and analysis should be handled by external systems (like log aggregation services). Propagate log data to data-mining/log management tools like Azure Monitor or Splunk and eventually to long-term archival. 26  Factor 12: Admin Processes “Run admin/management tasks as one-off processes” Any administrative or maintenance tasks (such as database migrations, data cleanup, or backups) should be executed as one-off processes using the same codebase and environment as the application itself. This ensures consistency and avoids issues with divergent environments. The idea behind "one-off processes" is that these admin tasks should be run as short-lived, on-demand processes, rather than as long-running services. Once the task is done (for example, migrating the database or running a script), the process exits. 27  Factor 12: Admin Processes 28  Factor 12: Admin Processes 29  Three extra factors for modern cloud-native app API First: Make everything a service. Assume your code will be consumed by a front-end client, gateway, or another service. Telemetry: On a workstation, you have deep visibility into your application and its behavior. In the cloud, you don't. Make sure your design includes the collection of monitoring, domain-specific, and health/system data. Authentication/ Authorization: Implement identity from the start. Consider RBAC (role-based access control) features available in public clouds. 30  Putting it all together The 12 Factor App principles are designed to allow developers to create applications intended to run at web-scale. They can seem overwhelming at first, and in many ways, they are. Fortunately, implementing the principles of The 12 Factor App is not an all or nothing deal. You can take them in small digestible chunks, starting with the first one and then progressing through the remaining. The trick is to commit to following the principles and then taking that first step. 31  Learning Activity: Twelve-Factor Principle Quick Debate Divide the class into small groups of 3-4 students. Evaluate the Algonquin Pet Store app and determine whether it complies with the Twelve-Factor App principles. Provide your analysis for each factor and identify whether the app complies with the principle. If not, provide suggestions for improvements. Complete the knowledge check quiz. 32  Conclusion In this lesson, we covered the modern design pillar of cloud native. You learned about the Twelve-Factor methodology, factors that reflect today's modern cloud application design, principles, patterns, and best practices for cloud-native app design, and infrastructure and operational concerns. In the next lesson, you will learn more about microservices. 33