Often when the development of an app starts there is a particular approach towards development which is followed. The actions taken during the development process and the entire architecture revolves around this methodology. There are many  app methodology available for a developer to choose from. However, a new methodology has surfaced in order to develop apps that have a great structure and scalability. We are talking about the 12-Factor methodology and it will completely change the way your advancement towards the architecture of your next app.

First things first! What is the 12-Factor app methodology?

In simple terms, 12-Factor app methodology is a methodology for building software-as-a-service apps that has a clear connect with the basic operating system. It enables continuous deployment with maximum pace increasing the scalability significantly. It provides independency to the app over programming languages and backend services. The 12-Factor App Methodology was derived from Heroku (a Sales Force Paas platform).

Why do we need the 12-Factor app methodology?

If you don’t have a process and good platform, even the greatest of the codes is bound to tumble down. The complexity increases furthermore if you have diverse programming environments. The 12-Factor app methodology helps you to apply some constraints so that you can easily track, use and share applications.

The 12 factors

1. Codebase – One codebase tracked in revision control, many deploys

The first and the foremost factor is your codebase. Maintain all your code in one single repository. Just put it on Github right at the beginning only. Once you grow up substantially, you may have a distributed system with multiple apps talking to each other. At this point you can treat them as separate apps with their own code repositories However, it should still be in source control. The critical point to note here is that your application must be tracked with revision control, and that it sits in a central repository that is accessible to your developers.

2. Dependencies – Explicitly declare and isolate dependencies

All the environments within which your code runs has some dependencies. It may be a database, or an image processing library, or a command-line tool. At no given point in time your application must assume that all of these things will be in place on a given machine. Back the dependencies into your software system. Anything your applications rely on to run should be controlled and managed to minimize conflicts. Most languages and frameworks provide a natural way to do this. You list out all the versions of all the libraries you want to have in one place, and when the code is deployed, a command is run that downloads all the correct versions and stack them in place.

3. Configuration – Store configuration in the environment

Configuration should never be hardcoded. The reason behind this is because it relates to services, API keys, and database credentials. Not hard coding your application eliminates the risk of both production errors and production data leaks. You must rely on environment variables to handle this sensitive information rather than hardcoding the configuration.

4. Backing Services – Treat backing services as attached resources

A backing service is one that requires a network connection to run. This is a very popular example found in modern application development. The 12-Factor App methodology advises developers that the changes or modifications should occur without making any changes in the code. This factor is best handled by calling each backing service through an API, with credentials stored in a configuration file that lives in your runtime environment.

5. Build, release, run — Strictly separate build and run stages

Build, release, and run stages should be treated as completely different from one another. Automation and tooling will help to make this principle simpler.
This can be accomplished by using existing tools to fully automate your build. The idea here is that the build stage does a lot of heavy lifting, and developers manage it.

6. Processes — Execute the app as one or more stateless processes

It’s likely you will have your application running on many servers, because that makes it more fault tolerant, and because you can support more traffic. As a rule, you want each of those instances of running code to be stateless. In other words, the state of your system is completely defined by your databases and shared storage, and not by each individual running application instance. Stateless applications are designed to degrade gracefully. That means if a dependency fails, the app itself does not become a failure.

7. Port binding – Export services via port binding

All application services should be accessible via a URL. It happens automatically for web applications. This enables 12-Factor Apps to be fully self-contained, avoiding the need to rely on various methods of runtime injection in order to create web facing services.

8. Concurrency – Scale out via the process model

It basically means that when you scale up your applications or deploy applications to the cloud, the process must be very simple. It means you create new instances of the same app concurrently. Each process should be able to scale, restart, or clone itself when needed. This approach will improve the sustainability and scalability of your application as a whole.

9. Disposability – Maximize robustness with fast startup and graceful shutdown

Whenever you app starts or shuts down, the process must be very swift. Let’s say if the system shuts down automatically with an error, so it should clean up all the resources which it was using so that it can gracefully shut down. It should not maintain any state or take any data and burn in itself.

10. Dev/prod Parity – Keep development, staging, and production as similar as possible

It’s crucial to strike consistency in any process. This factor is solely based on consistency. When your environments are similar, testing and developing gets much simpler.
With this approach, fewer bugs will find their way into your production environment, since your test cases can be applied on production-level data.

11. Logs – Treat logs as event streams

Log files keep track of a variety of things, from the basic to the critical aspects. Logging is important for debugging and checking up on the general health of your application. At the same time, your application shouldn’t concern itself with the storage of this information. You should be capturing errors and sending them to an error reporting service.

12. Admin processes — Run admin/management tasks as one-off processes

Once you have a live app you will wish to do a lot of administrative tasks like data cleanup, running analytics for a presentation etc. When a developer does these tasks he should do it from a machine in the production environment that’s running the latest version of the production code. In other words, run one-off admin tasks from an identical environment as production. Don’t run updates directly against a database, don’t run them from a local terminal window.

Some of these elements hold a mystery while some looks very promising. The whole idea is that a robust and reliable architecture is the key to a happily running system. The 12-Factor methodology helps you to create that architecture which surprises you the least and functions very smoothly. Talk to our experts and get more info on how we use great development methodologies to create amazing apps.