It’s a methodology
for developers to follow when building modern web-based applications.
These rules are typically applied to SaaS/Cloud based/Multi-tenant application
12 Factor Apps
Code Base: One Code base for all our
applications. It could be Git, SVN, etc.\
- Can there be multiple code bases? No. If it has, this means it’s a distributed system. So each system in distributed system should be considered as an application and then each app should follow 12 factor app rules
- Can multiple app share the same code? Yes. But only as a library which is then managed by dependency manager
Dependencies: 12FA should be explicit about dependencies. For example having manifest that gives details of dependencies. For example if you application uses a database connection within java, never assume that server you would be deploying will have the required libraries. So you give all the required details like lib, version, etc and when you build it, the app downloads all the respective libraries
Configuration: Different deployment may have different configuration. As a best practice, it is often said that config and code must be separate .i.e. apps that store configurations in code as constants is not acceptable.
The twelve-factor app stores these configurations in environment variables These vars are easy to change between deploys without changing any code and unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
Backing Services: It’s a service that your application may use. It could be external db connection or email connection. The code adhering to twelve-factor makes no distinction between local and third party services. To the app, both are attached resources, accessed via an URL with credentials being stored in the configuration file. For example, if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.
Build/Release/Run: The 12FA follows strict
separation of Build, Release & Run.
a.
Build Stage: Application Code is compiled. This
could also fetch vendor dependencies.
b.
Release Stage: Build Stage + Configuration
(specific to deploy environment)
c.
Run Stage: Actual execution of the app.
By strict separation I mean For
example, it is impossible to make changes to the code at run time, since there
is no way to propagate those changes back to the build stage.
Processes: 12FA processes should be stateless and
share nothing. If any data needs to be shared between restarts or releases, it
should be stored in the database.
Port Binding: 12FA should be totally self contained.
This means any application that relies on web server is not 12FA. Instead these
apps bind to port and listens to request directly.
Concurrency: Scale out via the process model
Disposability: The twelve-factor app’s
processes are disposable, meaning they can be started or stopped at a moment’s
notice. This facilitates fast elastic scaling, rapid deployment of code or
config changes, and robustness of production deploys. This mean applications should have little
startup time as possible and apps should be robus against sudden death.
Dev/Pro Parity: Keep Dev/QA/Production
environment as close as possible. Usually there are substantial gaps due to time any other release. The
twelve-factor app is designed for continuous deployment by keeping the gap
between development and production small. So in 12FA, code is moved between
deployment sooner that earlier, developers are more involved with deployment
process and tools used in various environments are similar.
Logs: Logs provide visibility into the
behavior of a running app. In server-based environments they are commonly
written to a file on disk. A 12FA is
never worried about storage of its output stream. It should not attempt to write
to or manage log files. Instead, each running process writes its event stream,
unbuffered, to stdout. During local development, the developer will view this
stream in the foreground of their terminal to observe the app’s behavior. In production,
these logs can be captured by the execution environment, collaged and routed to
final destination like Splunk
Admin Processes: Run admin/management tasks
as one-off processes .i.e. having scripts compared to running individual
commands.
For more information, refer to the below link
http://12factor.net/
No comments:
Post a Comment