There are certain times we know that, if we understand certain things, our work is 22.29% 😉 done. This is one such day for you. I tell you why, before that, to point out something, there was a time, around the height of popularity in Microservice, when a lot of people were telling that Microservices are small, independent, communicate through well-defined interfaces (like REST APIs), and provide business value. We know that DevOps teams are gradually transforming their infrastructure into a self-serve platform to avoid relying on tools from any single third party. Yes, yes, I am getting to it in just about a minute. It is wise and beneficial to look at the concepts underlying such a cloud-native design. And hence, 12 factor app came into picture.

12 factor apps concept give an insight on how to build applications that give software as a service.

Advantages


  • Use declarative formats; minimize time, cost
  • Offer maximum portability between execution environments
  • Suitable for deployment on cloud platforms
  • Enabling continuous deployment
  • Can scale up easily

1. Codebase


One codebase tracked in revision control, many deploys

Code of the app is always tracked using version control systems like Git

Do


There is always a one-to-one correlation between the app and it’s codebase. If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is a 12 factor app

There may be many deploys (running instances) of the app

Don’t


Multiple apps sharing the same code is a violation of twelve-factor

2. Dependencies


Explicitly declare and isolate dependencies

Do


Declare all dependencies, completely and exactly, via a dependency declaration manifest

Use dependency isolation tool to ensure no implicit dependency leak in

Don’t


Never relies on implicit existence of system-wide packages

3. Config


Store config in the environment

Do


Keep everything that is likely to vary between deploys in config

Resource handles to the database, Mem cached, and other backing services    

Credentials to external services such as Amazon S3 or Twitter

Per-deploy values such as the canonical host name for the deploy

Environment variables needn’t be checked into GitHub

Don’t


Storing config as constants in code

4. Backing Service


Treat backing services as attached resources

Backing service is any service the app consumes over the network

For example, DB, messaging/queuing service, cache, SMTP etc


Do


Make no distinction between local and third party services

Both should be accessed via a URL or other locator/credentials stored in the config

Resources can be attached and detached to deploys at will


Don’t


Make changes to app’s code to change resource


5. Build, release, run


Strictly separate build and run stages

Codebase is converted into a deploy-able file through three stages:

Build stage: Transform code to an executable bundle. Fetches dependencies, compiles binaries and assets.

Release stage: Combines the build with the deploy’s current config.

Run stage: run the app in execution environment.

/wp-content/uploads/2016/01/buildrell_864580.png


6. Process


Execute the app as one or more stateless processes


Do


Execute app as a stateless process that share nothing between each other

Complex apps may have many stateless processes

Data that has to be persisted should be stored in stateful backing service


Don’t


Never assumes that anything cached in memory or on disk will be available on a future request or job

Sticky sessions are a violation of twelve-factor and should never be used or relied upon


7. Port binding


Export services via port binding

A 12-factor app must be self-contained and bind to a port specified as an environment variable


Do


Similar to all the backing services you are consuming, your application must also interfaces using a simple URL

Create a separate URL to your API that your website can use which doesn’t go through the same security (firewall and authentication), so it’s a bit faster for you than for untrusted clients


Don’t


It can’t rely on the injection of a web container such as tomcat or unicorn; instead it must embed a server such as jetty or thin


8. Concurrency


Scale out via the process model


Do


Because a 12-factor exclusively uses stateless processes, it can scale out by adding processes

Ensure that a single instance runs in its own process. This independence will help your app scale out gracefully as real-world usage demands


Don’t


Not desirable to scale out the clock processes, though, as they often generate events that you want to be scheduled singletons within your infrastructure


9. Disposability


Maximize robustness with fast startup and graceful shutdown


Do


Use components that are ready and waiting to serve jobs once your app is ready

Technologies to consider are databases and caches like RabbitMQ, Redis, Memcached, and CenturyLink’s own Orchestrate. These services are optimized for speed and performance, and help accelerate startup times


Don’t


You should never do any mandatory “cleanup” tasks when the app shuts down that might cause problems if they failed to run in a crash scenario

10. Dev/prod parity


Keep development, staging, and production as similar as possible

The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small


Do


Adopt continuous integration and continuous deployment models

Public cloud services make the infrastructure side easy, at least between QA/test, staging and production. This is one of Docker’s primary benefits (CF)


Don’t


Using different backing services (databases, caches, queues, etc) in development as production increases the number of bugs that arise in inconsistencies between technologies or integration


11. Logs


Treat logs as event streams

A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles


Do


View logs in local consoles (developers), and in production, view the automatically captured stream of events which is pushed into real-time consolidated system for long-term archival

Stream the logs to two places: view these logs in real-time on your dev box and store them intools, like ElasticSearch, LogStash and Kafka. SaaS products like Splunk are also popular for this purpose


Don’t


Don’t rely on these logs as the primary focus


12. Admin processes


Run admin/management tasks as one-off processes


Do


Admin/management tasks mentioned in the final factor should be done in production

Perform these activities from a machine in the production environment that’s running the latest production code

access to production console


Don’t


Updates should not be run directly against a database or from a local terminal window, because we get an incomplete and inaccurate picture of the actual production issues


Conclusion


As long as the application is stable, robust, reliable, and any adjective you give, the architecture of the application will be strong and these 12 factors are adopted by many major platforms and frameworks to improve the quality of the product. No matter where you stand, what language you use, use the right of 12 factors for the job, because, what you make with your code is how you express yourself.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply