My 12cents on 12 Factor Apps

I. Codebase
One codebase tracked in revision control, many deploys.

Seriously if your code isn't in a code repository you can forget the rest.

It you are not already using a code repository, at least try GitHub, Bitbucket or get a local copy of Git, SVN repos. 

How Important? Critical 

II. Dependencies
Explicitly declare and isolate dependencies

'We have no dependencies', 'our app will run on any environment with no issues', 'I mean of force you need to have that library this Java server, that is common knowledge isn't it?' sound familiar? have heard these types of statements many many times. 

Most environments you run your application is not going to be the same as where you developed the application. Typically you would have gotten all dependencies needed during your development period. 

How Important? High to Critical.


III. Config
Store config in the environment

'Why is my app doesn't connect to the database, it should !!! I have tested it many times', 'why can't it find the web server'. Once again familiar terms. 

Separating configuration information from the code has been a known practice or a very long time. Yet, there are some who would like to keep it in the code. Highlight and cut it out from the code and replace with variables that you are going to read from external configs.

Store all your configuration data in a separate place from the code, and read in by the code at runtime. Therefore when you deploy code to an environment, you can correct configuration files or apply the configuration files applicable to the environment for your app. Nowadays PaaS solutions offer automation of these processes, so that you do not have to manually fix them.

How Important? High (Don't be sloppy, little effort now can save you heaps in the future)


IV. Backing Services
Treat backing services as attached resources

Your application will talk to many services databases, email, caching, monitoring etc, and these services may or may not deployed locally. Regardless of where these services are offered your application shouldn't care, it should be able connect and talk to them seamlessly.

Therefore you need to treat them as end-points where references are made via a URL with a username and a password (if required). This gives you greater flexibility and your team too. For example one could replace a database services you run locally with a database services offered via a cloud SaaS provider. 

How Important? High ~ Critical

V. Build, release, run
Strictly separate build and run stages

Collating all assets required (e.g: code, config, dependencies etc) to build your application and then releasing it as a package which consists of assets that are required to run the app seamlessly in production. 

In build phase you wants ensure that the heavy lifting is carried out in-order to successfully build your application. Some of the initial build pipelines you may need manual tinkering in order to get the build correct, however overtime you shouldn't have to touch a solid build pipeline. Once it is build and running your developers and devops should be able to sleep at night without having to think about it or tinker anything. It should run auto-magically and if crashes startup gracefully and continue to run without any human intervention.

How Important? High ~ Critical {It is important not just because you can sleep at night, but also you can automate your test process after the build/run, and push to prod if all policies are good to go}


VI. Processes
Execute the app as one or more stateless processes

Web was originally designed to be stateless; however with the rapid growth and adoption, sessions were introduced to save different states of application and its interaction with users. While it is not impossible to scale sessions based applications, the process is much complicated. Therefore if you are using sessions in your application you will need to have process that can protect the sessions during failure.  

Therefore it is best to create applications stateless, therefore it can scale or fail-over with minimal efforts.

How Important? High 


VII. Port binding
Export services via port binding

Port binding is an addition or extension to IV (Backing services). Similar to how your application consume Backing services sometime it also needs to connects to external URLs.

Most frameworks today give you this, however you may also need to think beyond what they offer. For example if you are providing an API for your customers and partner to connect different to port you open-up for the application you may need to look at what security and firewall rules needs to be applied.

Someone may also treat API as a separate application, in which case you may already doing this via IV or in the application itself. 

How Important? Medium


VIII. Concurrency
Scale out via the process model

This is pretty much around breaking down your work processes in to different worker processes. For example you could break processes such as requesting/responding to API queries, sending emails, updating tweet feeds etc. Running these processes independently will improve the scalability of the entire application. 

Having them running separate will be able to process lot of things concurrently. If one of them slowing down, you could add more CPU/RAM for that process while not impacting others.

How Important? Medium

IX. Disposability
Maximize robustness with fast startup and graceful shutdown

Of course you want your application to start-up quickly as possible. Unless you are applying a major release you should be able to apply changes to the smaller components of the application even without having to shutdown and startup the entire application. For example minor release in your e-mail process shouldn't impact your entire application, however the email process will stop for a while.

In the event you are applying a major upgrade or patch where entire application needs to shutdown, it should start-up gracefully. Even if it did crash in a normal situation t should start-up cleanly. 

How Important? Medium to High


X. Dev/prod parity
Keep development, staging, and production as similar as possible

Hmmm we wish if our dev, staging, test and production environments looks the same. Yes it is near possible now thanks to virtualisation and contrainerisation, which was near impossible earlier due to hardware, software, setup and maintenance costs.

While production environment may run on bare-metal for performance, existing investment and various other reasons  staging, test and other environments can be setup to be the same as dev thanks to virtualization and containerization by utilizing configuration management tools OR PaaS solutions {where configuration management and deployment are Orchestrated at a higher abstraction layer}

Hopefully one-day we will see most complex applications gets productionised by a single click. 

How Important? Medium to High {Personally I believe developers hate when they have to fix environment issue they had already fixed in the development environment. Therefore if the right process, technologies can be adopted early in the lifecycle, lot of time and effort will be saved. Therefore I don't believe it will be a hard-sell to the developers at all}

XI. Logs
Treat logs as event streams

Depending on type of logs used in the application, typically if you depend on the standard logs you may get somewhere but there is not guarantee. Therefore it is important to spit-out logs that have useful meanings and helpful hints for debugging and resolving issues.

There are emerging trends such as monitoring and management APIs for capturing application, service assurance data. Therefore logs may not be the only medium used for diagnosis or finding trends within the application.

How Important? Medium

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

For various obvious reasons you will want to run one off admin processes once your application is live. For example you may need to apply one of features that was needed for a one off performance testing.

Therefore it is important to run the one off admin processes from environment identical to production. 

How Important? High


Conclusion

Some of these items are not new, however the adoption rate is much higher compared to ten years ago. Nowadays these 12 factors are being adopted by most major software platforms and frameworks, therefore in a way they indirectly enforce the factors in to your development life-cycle. I believe it is important to openly discuss and see how you could have immediate wins and improve quality of your application/s and their design.