Скачать или смотреть Building Microservices | 12 Factor App - Stateless Process - Share Nothing | InterviewDOT

Click here -    / @interviewdot   to get notifications.

Tamil Building Microservices | 12 Factor App - stateless process | InterviewDOT

The twelve-factor app methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications with portability and resilience to be deployed to the web.

The 12 Factor App Manifesto gives some recommendations on how best to develop web apps for the cloud. A good SaaS application must be easily scalable, quickly deployable and easily portable. However, this is not so easy to guarantee. However, the standards proposed by the manifest are not applicable to all applications.

A 12-factor app relies on the explicit existence declaration of all dependencies, completely and exactly, via a dependency declaration manifest. And you must also use a dependency isolation tool along with dependency declaration.

Run the app as one or more processes
The app runs as one or more processes .

In the simplest case, the code is a stand-alone script, the execution environment is a developer's local laptop with a language runtime environment installed, and the process is started from the command line (for example python my_script.py). At the other end of the spectrum, a sophisticated app can use many types of processes that run in one or more processes .

Twelve-factor apps are stateless and shared nothing . All data is stored in support services , usually a database.

The process RAM or file system can be used as a short-term cache for the duration of a transaction. For example, a process can download a file, process it, and save the results to a database. The twelve-factor app never assumes that anything cached from RAM or in the file system will be available for a future request or job. It is quite possible that a future request will be served by another process. Even if only one process is running, a restart (caused by code deployment, configuration change or relocation of the execution environment to a different physical location) will delete the entire local state (RAM and file system).

Asset packers (such as Jammit or django -compressor ) use the file system as a cache for compiled assets. A twelve-factor app like the Rails asset pipeline would do this kind of compilation in the build phase rather than at runtime.

Some web systems rely on “sticky sessions” - they cache user session data in the RAM of the app process and expect future requests from the same user to be sent to the same process. Sticky sessions are a violation of the twelve factors and a good candidate for a data store that offers time-based deletion, such as Memcached or Redis .

A stateless application makes no assumptions about the contents of
memory prior to handling a request, nor does it make assumptions
about memory contents after handling that request.

The Share-Nothing Pattern
Processes often communicate with each other by sharing common
resources. Even without considering the move to the cloud, there
are a number of benefits to be gained from adopting the sharenothing pattern.
Firstly, anything shared among processes is a liability that makes all
of those processes more brittle. In many high-availability patterns,
processes will share data through a wide variety of techniques to
elect cluster leaders, to decide on whether a process is a primary or
backup, and so on.
All of these options need to be avoided when running in the cloud.
Your processes can vanish at a moment’s notice with no warning,
and that’s a good thing. Processes come and go, scale horizontally
and vertically, and are highly disposable. This means that anything
shared among processes could also vanish, potentially causing a cas‐
cading failure.
It should go without saying, but the lesystem is not a backing ser‐
vice. This means that you cannot consider files a means by which
applications can share data. Disks in the cloud are ephemeral and, in
some cases, even read-only.
If processes need to share data, like session state for a group of pro‐
cesses forming a web farm, then that session state should be exter‐
nalized and made available through a true backing service.