- Codebase
- Dependencies
- Config
- Backing Service
- Build, Release, Run
- Processes
- Port Binding
- Concurrency
- Disposability
- Dev/Prod Parity
- Logs
- Admin Process
Codebase:
Code should be version controlled. We can track our code changes by using version control systems. Running code and code from version control has to have a one-to-one relationship. We can also deploy our Codebase to multiple deployment environments without any issues. So, we might have different environments like Development, Staging and Production.
Dependencies:
Dependencies are declared and isolated. This factor states that we never use System level packages with in our application. These dependencies like any kind of tools, libraries and even databases. Instead of assuming everything is there, we should define it in manifest.yml/POM.xml file that has the power to bring all need together.
For example, we want to use specific version of libraries for any of the technology instead of latest one. So, we can specify that libraries version. This allows to eliminate conflicts too.
Config:
Configuration is Stored in the Environment. Code should be separated from configuration as much as possible and we can provide the configurations inside the environment that we are running our application in.
For example, Connection string varies from environment to environment. So, that’s not good idea to declare in a static way in our code. The better way is to configure it in the environment and use.
Backing Service:
Backing services as attached resources. This factor is really an important to build an Cloud or any other application. Our application might have lot’s of services that uses like Databases, Queuing, Caching, Web services etc. These all we can access through network which will not differ from our local. Importantly we can attach and detach these services from our application at anytime we want. Only the difference between is, environment variables that we are running our application.
Build, Release and Run:
Build and Run stages are separate. Once we deploy our application in production, there is no come back. Only we can simply change our code in production. Some times it is not possible and even impractical in most cases. So we should have build and run stages separate by using unique identifier. So, if any problem occurs in production we can simply know the problematic version and easy to identify code.
Processes:
Application executed as Stateless processes. We should never assume that State or Processes are part of our application. They can go away at anytime and simply crash. Of course we can go and use state of the application sometimes, but these kind of information should be stored in a state-full backing store. With this way we could separate application logic from states and we can get back to our application where it has been crashed because we know where we left off.
Port Binding:
Services are exported via Port Binding. This is one of the most important factor of 12 factor app which simply states that our application must be self contained. It should not rely on a specific web server or a port. So application should be listening on a very specific port rather than 80, 100 and 44. Because these are the ports can be used for Caching mechanism from a Queuing mechanism.
Concurrency:
Application scaled out via Process Model. Process must be embrace as First class citizens in our application because they simply do everything. We have processes for listening Queue and making HTTP requests and listening coming request. These are all being handled by individual processes.
Disposability:
Processes are disposable. Minimal startup time and graceful shutdown is key here. Assume our application has been crashed. So, do you want it to recover back withing seconds or after few minutes? definitely want to recover Seconds of time because time equals to money.
Dev/Prod Parity:
Important point of Parity between application environments factor is to avoid time personal and through gaps between environment. We should be designing for a Continuous deployment pipeline. For example, developer want to run some sql scripts into production which is working in development. Suddenly it’s not working in production because Parity between the environments are missing. What about the time gap? should a developer go to the production on everyday or a month? if we shift to continuous, developer move code to production very often.
Logs:
Logs treated as Even Streams. Logs are very important aspect of running system because they can capture time order, chronological list of events happened through out the application life cycle. We treat them as Streams of events because they carry important information of application states. An application should never be concerned with storing it’s own log files. Logging framework must be taking care of where it has to collect them.
Admin Process:
Management task run as one-off processes. These task are important in any application to maintain and upgraded. So we should be using identical environments to running them. If our application is running in cloud, then we should run necessary scripts and tasks in the cloud.
For better understanding about the 12 factors of PaaS application use the below official website link.
Anti-Patterns of PaaS:
These are few bad practices or Anti-patterns of the PaaS application.
- We should not rely on local file systems
- Scaling up services the old way
- Trying to change the code on the server-side
- Manually coordinating builds
- Hard-coding configuration
- Trying to be monolithic everywhere
Master From Us 