Heroku founder Adam Wiggins publishes 12 elements application manifesto

Heroku is an industry-renowned cloud application platform that has been hosting and operating millions of applications since its external service. Not long ago, founder Adam Wiggins, based on these experiences, released a "12-factor Application Manifesto (the Twelve-factor app)", which was translated into Chinese by the local programmers working in the home, and the Infoq Chinese station was excerpted as follows.

Introduction to the 12 Elements application manifesto:

Today, software is often delivered as a service, known as a Web application, or as a "software as a Service" (SaaS). The 12-Factor application (12-factor app) provides a methodology for building SaaS applications such as the following:

• Use standardized processes to automatically configure, so that new developers spend the least amount of learning cost to join the project;
• and operating system as far as possible, in each system to provide maximum portability;
• Suitable for deployment in modern cloud computing platforms, thus saving resources in server and system management;
• Minimize differences in development and production environments and implement agile development using continuous delivery;
• Can be extended without significant changes in tooling, architecture, and development processes;

This theory applies to applications developed by any language and back-end services (database, Message Queuing, caching, etc.).

Background

Contributors to this article have been involved in the development and deployment of hundreds of applications and have indirectly witnessed the development, operation, and expansion of hundreds of thousands of of applications through the Heroku platform.

This article combines almost all of our experience and wisdom with SaaS applications as the ideal practice standard for developing such applications, with a particular focus on how applications can sustain benign growth, how effective code collaboration between developers is, and how to avoid software contamination.

Our intention is to share some of the systemic issues found in the modern software development process and to deepen our understanding of these issues. We provide the shared vocabulary needed to discuss these issues, and use relevant terminology to give a broad solution to these issues. This format is inspired by Martin Fowler's books: Patterns of Enterprise application Architecture, refactoring.

Who should the reader be?

Developer of any SaaS application. Operations engineers who deploy and manage such applications.

I. Benchmark code A benchmark code, multiple deployments

Always maintain a one by one correspondence between the benchmark code and the application:

• Once there are multiple datum codes, it is not called an application, but a distributed system. Each component in a distributed system is an application, and each application can be developed using 12-factor separately.
• Multiple applications sharing a benchmark code is contrary to the 12-factor principle. The solution is to split the shared code into separate class libraries and then use the dependent management policy to load them.

Although each app corresponds to only one baseline code, multiple deployments can exist at the same time.

The baseline code for all deployments is the same, but each deployment can use its different versions.

Ii. relying on an explicit declaration of dependencies

Applications under the 12-factor rule do not implicitly depend on the system-level class library. It must declare all dependencies exactly by relying on the manifest. Also, rely on the quarantine tool during the run to ensure that the program does not invoke dependencies that exist in the system but are not declared in the manifest. This approach is applied uniformly to the production and development environment.

Iii. Configuring storage configurations in the environment

12-factor recommends that the application's configuration be stored in environment variables (env VARs, env). Environment variables can be easily modified between different deployments without moving a single line of code; Unlike configuration files, the probability of accidentally checking them into a codebase is negligible, and environment variables are not related to language and system, compared to some traditional mechanisms to solve configuration problems, such as Java's property configuration files.

In 12-factor applications, the granularity of environment variables is small enough and relatively independent. They are never combined into a so-called "environment", but are isolated in each deployment. This configuration management approach allows for a smooth transition when applications are expanding and require more kinds of deployment.

Iv. back-end services treat backend services as additional resources

12-factor apps do not discriminate between local or third-party services. For applications, both are additional resources that are obtained through a URL or other service location/service certificate stored in the configuration. Any deployment of the 12-factor application should be able to replace the local MySQL database with a third-party service (such as Amazon RDS) without any code changes. Similarly, the local SMTP service should also be interchangeable with third-party SMTP services such as postmark.

V. Build, release, run strictly separate build and run

The 12-facfor application strictly differentiates the construction, release, and operation of these three steps.

Each release version must correspond to a unique publication ID.

The new code requires the developer to trigger the build operation before deployment. However, the runtime does not necessarily require a human trigger, but can be automated.

Vi. process running an app in one or more stateless processes

The process for 12-factor apps must be stateless and not shared. Any data that needs to be persisted is stored in the backend service, such as a database. Sticky session is strongly opposed by Twelve-factor. The data in the session should be stored in a cache with an expiration time such as memcached or Redis.

VII. Port Binding provides service through port binding

12-factor applications can create a network-oriented service by fully self-loading without relying on any Web server. The Internet app provides services through port bindings and listens for requests sent to that port.

Viii. concurrency is extended through the process model

In 12-factor applications, the process is a one-class citizen. The process of 12-factor application is mainly borrowed from the Unix daemon model. Developers can use this model to design application architectures and assign different tasks to different process types.

Ix. easy-to-handle quick start and graceful termination maximizes robustness

The 12-factor application process is disposable, meaning that they can be switched on or off in an instant. This facilitates fast, resilient scaling applications, rapid deployment of changing code or configurations, and robust deployment of applications. The process should pursue the minimum start-up time; Once the process receives the terminating signal (SIGTERM), it gracefully terminates. The process should also remain robust in the face of sudden death,

X. Development environment and online environment equivalence as far as possible keep development, pre-release, the same online environment

12-factor applications that want to do continuous deployment must narrow local and online differences. Developers of 12-factor applications should oppose the use of different backend services across different environments, even if the adapter can almost eliminate the difference in usage.

XI. Log treats logs as event streams

The 12-factor app itself never considers storing its own output stream. You should not attempt to write or manage log files. Instead, each running process will have a direct standard output (STDOUT) event stream. In the development environment, developers can see the activity of the app in real-time through these data streams.

XII. Management process Background management tasks run as a one-time process

The one-time management process should use the same environment as the normal resident process. These management processes, like any other process, use the same code and configuration to run based on a release version. Background management code should be published along with other application code to avoid synchronization issues. All process types should use the same dependency isolation technique. 12-factor especially favored the language that provided the REPL shell, because that would make it easier to run a one-time script.

Want to learn more about the "12 Elements Application Manifesto" of the students, you can click here to view the English version, or directly to see the Chinese version of students in Liangshan.

Heroku founder Adam Wiggins publishes 12 elements application manifesto