The Twelve-Factor app was published by Heroku co-founder Adam Wiggins in 2011. The Twelve-Factor App Methodology is used to build a successful SaaS Applications. I have discussed 6 factors of The Twelve-Factor App Methodology in the previous article. And the remaining factors will be discussed on here.
7. Port Binding
The twelve-factor app is completely self-contained. It does not rely on runtime injection of a web server into the execution environment to create a web-facing service. The web app exports HTTP(HyperText Transfer Protocol) as a service. It is done by binding the service to a port and listening to requests which coming into that port.
In the local development environment,
-The developer visits a service URL like http://localhost:5000/ to access the service exported by their app.
Production environment,
- A routing layer handles routing requests from a public hostname to the port-bound web processes.
In the enterprise level, several web applications are host in the same container, But applications are separated by the port number (or URL hierarchy). After that, they use DNS to provide a user-friendly facade around that server.
Ex - You have a host called applicationServer. And several applications are assigned from port number 8085 to 8095 on that host. You don't need to remember all the port numbers. Rather than that DNS is used to associate a hostname for each port numbers. Like webapp1 with applicationServer:8085, webapp2 with applicationServer:8086, and so on.
8. Concurrency
In the computer, the running computer program is represented by one or more processes. Processes are a first-class citizen in the twelve-factor app. It takes strong cues from the Unix process model for running service daemons. This model helps to the developer to architects his application to handle diverse workloads by assigning each type of work to a process type. As an example, Long-running background tasks is handled by a worker process and HTTP requests is handled by a web process. This does not deny individual processes handling their own internal multiplexing via threads or another way.
The process model really helps when adding more concurrency into the application. So the application is scaled out via the process model. Twelve-factor app processes should never daemonize or write PID files. Instead of that the operating system’s process manager manage output streams, respond to crashed processes, and handle user-initiated restarts and shutdowns.
9. Disposability
The twelve-factor app’s processes can be started or stopped at a moment’s notice. So the processes are disposable. This facilitates
- Fast elastic scaling
- Rapid deployment of code or config changes
- Robustness of production deployments
The process should be designed by minimizing its startup time. A process takes a few seconds as a startup time (The time duration between the launch command is executed and the process is up and ready to work). The process manager can easily move processes to new physical machines when warranted if the processes have a short startup time. It provides more agility for the release process and scaling up. And it aids robustness.
Processes shut down gracefully when the process manager sends a SIGTERM signal to them. The SIGTERM signal is sent to a process to request its termination. This allows the process to perform nice termination releasing resources and saving state if appropriate. A web process is graceful shutdown by terminating to listen on the service port (By refusing any new requests) and allowing any current requests to finish and exiting. A worker process shutdown gracefully by returning the current job to the work queue. The job is returned to the queue automatically whenever a worker disconnects.
Processes should also be robust against sudden death(Ex - A failure in the underlying hardware). Sudden death is a less common occurrence than a graceful shutdown with SIGTERM. It is recommended to use a robust queueing backend (Ex-Beanstalkd) to handle unexpected, non-graceful terminations. That returns jobs to the queue when clients disconnect or time out. Either way, a twelve-factor app is architected to handle unexpected, non-graceful terminations.
10. Dev/prod parity
In most cases, there is a substantial gap between the development environment and the production environment. These gaps can be categorized into three areas
- The Time Gap: The developer implements a functionality which takes much time to go into the production environment
- The Personal Gap: The Developer implements functionality and then it will be deployed to the production environment by DevOps Engineer
- The Tool Gap: The development environment uses one tech stack (Nginx, SQLite, OS X) and the production environment uses another tech stack ( Apache, MySQL, Linux)
The twelve-factor app keeps development, staging, and production environments similar as possible. And it is designed for continuous deployment by keeping a really small gap between these environments.
These gaps can be minimized as follows.
- The Time Gap: The developer deploys the functionality within a few minutes after it implements.
- The Personal Gap: The developer deploys the functionality and watches its behaviour himself.
- The Tool Gap: Use the same tech stack in all the environments
Sometimes developers use lightweight backing service in their development environments and robust backing service will be used in a production environment. The twelve-factor app developer should not use different backing services between development and production environment.
11. Logs
Logs use to monetize the behaviour of a running application. Logs are written to file on a disk in server-based environments. these are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. The application creates logs continuously as long as it is operating.
Twelve-factor app treats logs as event streams and never concerns itself with routing or storage of its output stream. So the app is not attempting to write or manage log files. Instead, Each running process writes its event stream, unbuffered, to stdout.
During local development, the foreground terminal will view this stream into the developer to observe the app’s behaviour.
In the staging or production environment, each process’ stream will be captured by the execution environment and routed to one or more destinations for viewing and long-term archival. These archival destinations are not visible or configurable by the app. instead of that these are completely managed by the execution environment. Open-source log routers (such as Logplex and Fluentd) are available for this purpose.
The event stream of an application can be routed to a file. Or you can see via real-time tail in a terminal. the stream can be sent to a "stash" like Elasticsearch. Then Kibana lets users to visualize data with charts and graphs in Elasticsearch.
12. Admin processes
Sometimes Developers has to do one-off(which run only once) administrative or maintenance tasks for the application such as:
- Migrates the database
- Inspect the applications' models against the live database.
- Run shell commands
- Run one-time scripts
The environment which is used to run one-off admin processes should be identical to the regular long-running application environment. One-off administrative/maintenance tasks will run with a new release. And same release codebase and configurations and used to run it. And codes related to one-off tasks must ship with application code to avoid synchronization issues. The same dependency isolation techniques should be used on all process types.
Twelve-factor strongly favours languages which provide a REPL shell (Read–eval–print loop: A procedure that just loops, accepts one command at a time, executing it, and printing the result) Because REPL shell makes it easy to run one-off scripts.
In a
- Local deployment:- Developers invoke one-off admin processes by a direct shell command inside the app’s checkout directory.
- Production deploys:- Developers can use ssh or other remote command execution mechanism provided by that deployments' execution environment to run such a process.
*The Twelve-Factor app methodology become more popular because it aligns with the microservices principle.and It suitable for modern cloud platforms because a Twelve-Factor app can scale up without significant changes to tools, architecture or development practices.
Source - https://12factor.net
No comments:
Post a Comment