The 12-Factor App Part 2: Build, release, run, Processes, Port binding, Concurrency

Automated configuration, optimal compatibility with the operating system, on-demand cloud usage and flexible scalability are important criteria in web app development. The Twelve-Factor App Method takes these factors into account in order to implement the development objectively and efficiently. But what exactly is "The Twelve-Factor App" method? We explained this in a Libelle IT Glossary post.

In the first part of our blog series on the Twelve-Factor App Method: "The Twelve-Factor App Part 1: Codebase, Dependencies, Config, Backing Services" we took a closer look at the first four factors. In the second part, we take a  look at the next four factors Build, Release & Run, Processes, Port Binding and Concurrency.

In summary, its principles are as follows:
V. Build, release, run: Strictly separate build and run stages
VI. Processes: Execute the app as one or more stateless processes
VIII. Port binding: Export services via port binding
IX. Concurrency: Scale out via the process model

Factor 5: Build, release, run

The fifth of The 12 Factor App aspects entails three critical steps: build, release, and run, although some additionally include a design step as the initial stage of the process. Dependencies, their packaging mechanism, and the way of attaching them to the application should all be defined during this added design phase. The result of the build phase is an executable artifact created from the code repository.

The “one build, multiple deploys” approach requires it to be versioned and function properly everywhere. The build is combined with the configuration in the following release stage, which is then delivered to the cloud environment. Because it integrates the initial build with a specified configuration, each release must be unique. Furthermore, if an issue occurs, it is easy to revert to a prior release.

Finally, at the run stage, cloud providers generally provide a runtime that is responsible for keeping the application operational while evaluating its performance and gathering its logs. The main goal is to isolate all phases, increase deployment speed, and automate application testing, all of which may be accomplished using cloud services. (Source)

Factor 6: Processes

Following the 12-factor model, an application should operate as a solo stateless process, or in exceptional cases, several stateless processes that share absolutely nothing. Share-nothing architecture (SNA) presents a distributed computing architecture made up of numerous isolated nodes. These nodes don’t share the same memory, which reduces possible conflicts between them (for example, causing problems while attempting to update some data simultaneously). Because cloud processes come and go, everything shared within them might vanish as well, potentially producing a cascade of catastrophes.

In the process of handling a request, the application can produce and use temporary state, but that data must therefore be gone by the time the consumer receives a response. To be clear, a state can exist, but it cannot be managed by the application, and it must be given by outer backing services if it is to be long-lasting. It could be beneficial in order to utilize some third-party solutions as a backing service for the application’s session state or caching data. This is done in order to avoid processes exchanging data that are closely linked. (Source)

Factor 7: Port binding

A cloud-native application is considered entirely self-contained and does not require insertion into any external application server or container. This port-binding factor specifies that a service or application is specified by a port number rather than a domain name by the network. Because it also maintains various network components, the cloud provider shall handle the port assignment for the application. Although a cloud provider could offer a web container, it is quite improbable that it will allow numerous applications to be hosted in the same container. This necessitates a 1:1 association between the application and the application server at all times. After all, an application that supports externalized port binding becomes incredibly strong and may easily be utilized as a backing service for another application. (Source)

Factor 8: Concurrency

By allocating each type of work to a process type, an application may be developed in order to manage a variety of workloads using the twelve-factor model. By embracing concurrency, different segments of an application can be scaled up to match the requirements when needed. Vertical scaling, which involves additional RAM, CPUs, or other resources, is no longer considered contemporary. The main idea is to generate several processes, and then divide the application’s burden across them. This technique allows the application to scale out, or horizontally - it refers to scaling up an application by adding additional instances of machines rather than increasing resources and scaling up the entire application. (Source)

Do you work in IT or are you interested in IT-related topics? Then feel free to visit our blog for more topics and follow us on LinkedIn.