[Music] Welcome to ”Twelve-Factor App Methodology.” After watching this video, you will be able to: Describe characteristics of modern software development, describe the goal of twelve-factor apps, identify the twelve factors and describe how these factors map to three phases of the software delivery lifecycle. In modern software development, software is often delivered as a service. Software is centrally hosted and accessed through the internet. This software is often called a web app or software-as-a-service, which is abbreviated SaaS. You have likely used a variety of web apps within the last day! When you use the internet to book reservations or file your taxes, you are interacting with a web app. The twelve-factor app methodology is suited for these types of applications. Microservices are not a requirement for twelve-factor apps. However, microservices are often used in conjunction with the twelve-factor application methodology. Twelve-factor app methodology is designed to ensure that applications are ready for cloud-native deployment. Twelve-factor app methodology enables automation for developers. Applications should be maximally portable across various execution environments and deploy on modern clouds so that servers and systems administrators are not needed. Applications development and production environments should remain as similar as possible to enable continuous application development. Finally, twelve-factor apps should be scalable without requiring significant change or effort. The twelve factors can be grouped into the code, deploy, and operate phases of the software delivery lifecycle. We’ll start with the three factors that map to the code phase of the software delivery lifecycle. First is Factor 1, Codebase. The codebase for an application should always be tracked in a version control system, such as Git. There is a one-to-one relationship between a codebase and an app. An app should be contained in a single codebase. However, there will be multiple deploys, or instances, of the app. While the codebase is the same across those deploys, different app versions can be present in each deploy. For example, dev or test environments can have changes that have not yet reached production. Next is Factor 5: Build, release, run. This phase demonstrates how a codebase becomes a production deploy. The build stage compiles the code, gathers dependence, and then transforms the codebase into an executable unit called a build. The release stage combines the build with the deployment’s current configuration so that the code is ready to run. Then, the run stage implements the application. These three stages should be strictly separated. For example, the code should not be changeable at runtime as that would prevent those changes from being included in the build stage. Factor 10 is dev/prod parity. This factor minimizes the differences between development and production environments, which is necessary to enable continuous delivery so that changes are quickly promoted into production. This action reduces the chance that code runs appropriately in one environment but not in another. Parity is especially important for backing services. If you use a MySQL database in production, you should use the same MySQL database in your development environments. This helps catch failures earlier in the development process. The first deploy factor we’ll discuss is Factor 2, Dependencies. An app is only as reliable as its least reliable dependency. As a result, twelve-factor apps do not rely on the implicit existence of any packages or dependencies. All dependencies must be explicitly declared. This way, when a new developer grabs the codebase, there is no assumption that any dependencies already exist on her machine. Next is Factor 3, Config. The configuration is everything that can differ between deployments. Different databases are likely used in staging and production, so a developer should configure the credentials and the location of that database per deploy. Sometimes developers store configuration as constants in their code, but this should be avoided since configurations might differ among environments. Config should be strictly separate from code since code doesn’t vary across deploys but config does. Store the Config within environment variables, which are easy to change across deploys without changing the code. Factor 4 is Backing services. A twelve-factor app should not distinguish between local and third-party services. Both should be accessible via a URL and credentials, so that a developer can easily swap out the backing service without changing code. For example, if a database experiences problems, a new database can be spun up and substituted in without having to change code. Factor 6 is Processes. An app executes in an environment as one or more processes. Processes should be stateless and share nothing. Persistent data needs to be stored in a backing service like a database, since memory and filesystems aren’t shared across processes. If another process handles a subsequent transaction, the subsequent transaction won’t have access to data within the prior process. As a result, data needs to be centrally stored. Port binding is Factor 7. When you create a web-facing service, a webserver should not be injected into an application at runtime. Instead, the web app should export HTTP by binding to a port and listening to incoming requests on that port. Port binding can be used for HTTP and other services. Binding a port is generally done in the code by declaring a webserver library as a dependency. Subsequently, because these apps are accessible via a URL, these apps can become backing services for other apps. Factor 9, Disposability, specifies that application processes require minimal startup time and should end gracefully when terminated. Quick startup lets us quickly deploy changes to code or config. We can also easily scale apps because new deploys start quickly. Factor 11 dictates how to handle logs. Logs give visibility into application performance. An app should not concern itself with storing logs. Rather, an application environment should handle logs as a stream of events that are written to “stdout.” The execution environment can capture the log streams for all running apps, aggregate the log streams, and route the log streams to their destination. This action is especially helpful when the destination is a log analysis tool. Next are operate factors. Let’s begin with Factor 8, Concurrency. Processes are first-class citizens in a twelve-factor app, because they are the unit of execution. An application runs concurrent processes to handle increased load. Since processes are stateless and share nothing, an application can start additional processes to handle incoming requests and load without creating interdependencies among processes. You can add or subtract processes to handle concurrency needs. Finally, the last factor is Factor 11: Admin processes. Admin processes are one-off processes used for managing an app, such as a database migration. Admin processes run against a release, using the same codebase and config. Additionally, the code should include admin processes so that the admin processes remain synchronized with the app. In this video, you learned that: Modern software development often delivers centrally hosted, web-based, Software as a Service applications, twelve factor app methodology enables developers to create more efficient SaaS applications, and the twelve factors maps to the code, deploy, and operate stages of the software delivery lifecycle.
