Table of Contents Introduction Twelve factors: Codebase Dependencies Concept Config Backing Services Build, Release, Run Processes Port Binding Concurrency Disposability Dev/Prod Parity Logs Admin Processes References The 12factor.net website discusses the best technique to develop web apps or software as a service. So, I'm going over these 12 factors and using this list as the foundation, but I am going to cover items they don't mention. Myth : 12 Factor is a silver bullet for all cloud deployments. While 12 Factor provides excellent guidelines, it's not a one-size-fits-all solution. Consider adapting its principles to your specific project needs and infrastructure constraints. Reality: Introduction A group of people within Heroku developed the 12 Factors manifesto describing the rules and guidelines that needed to be followed to build a cloud-native application in 2011. Currently Azure, AWS, GCP, and Oracle are the leaders in the cloud, not Heroku. However, most of it is still relevant today. How do you create a cloud-based app so that it is robust, scalable, efficient, and cost-effective? First of all, let's understand what are an app and a cloud: App: In any environment, a single instance can be run or deployed. Cloud: The cloud is a distributed collection of servers, where users can manipulate, configure, and access the application or software over the internet. Enter, the Twelve Factors: Objective guidelines and regulations A visual checklist and guidelines for evaluating designs during design sessions. The 12 Factor App's main concepts are briefly explained in the section below. Codebase 1. One codebase tracked in revision control, many deploys There must be a relationship between the repository and the application. Whereas , and many big company uses mono repo i.e., relationship. 1-1 Google, Meta, Twitter, Microsoft 1-many cloud-native apps must always consist of a single codebase that is tracked in a version control system like GitHub, GitLab or Bitbucket. The main goal of a single codebase is to produce any number of immutable releases(build artifacts that remain unchanged). If you found a bug then go to the previous version fix it and then build the code again. These can be deployed to various environments, such as testing, staging, and live production servers. It helps you to do easily CI/CD process for your applications. 2. Dependencies Explicitly declare and isolate dependencies Every Application needs dependencies to be built and deployed, such as external libraries(also known as ) from third parties that are not native code to the respective language. ex: Java given as a JAR, Apache Logging library as a log4j.jar, node.js. packages, .NET DLLs, etc or internal libraries (also known as ) are the ones that the particular platform provides. linked libraries embedded libraries War ( ) vs Jar( ) web application archive java archive a file called a "war" that is packaged and deployed to any servelet or Jsp container address. It includes web-related Jsp, HTML, Js, servlets, and other files required for the development of the web application. It is for a browser-based web application. Jar contains java related libraries, resources, & accessories files like property files. it is for desktop applications and works on machines. Concept declaring dependency & bundling (also called ) vendoring Specify the dependencies your program requires. dependency manifestation: npm ( ) for JS - package.json file( ), node package manager javascript object notation maven for java - dependencies in an XML file, known as Project Object Model ( ), POM gradle for java- build.gradle file, NUGET for .net bundler for ruby, godeps for go, sbt for scala, pip for python 2. dependency isolation App only uses the dependencies it explicitly mentions. You cannot presume that certain dependencies are using it without your knowledge because there are no implicit dependencies that leak in. Main Goal It is simple to deploy, i.e. no pre-setup is required via container, with consistent builds across environments that can be repeated and easy for debugging and troubleshooting. 3. Config store config in the environment Configuration varies depending on the deployment type (such as ) and the time of application run. “config” here doesn’t mean the app’s internal information. If the value remains the same across all deployments then it is part of immutable builds. production, QA, or staging Some examples of configuration are: URLs, hostname, port number, credentials secret keys, API tokens service config( ) Memcached, threat pool For the non-containerized environment: configuration management tools like Ansible, Chef, Puppet, etc to install system-level dependencies. For the containerized environment: docker-compose.yml file, a Kubernetes manifest file, etc Configuration manifest Environment variables, zookeeper, spring cloud config, etc 4. Backing Services Treat backing services as attached resources what is a backing service? Any service on which the functioning of your application depends is a backing service. Services such as databases, caches, messaging systems, Simple Mail Transfer Protocol ( ) services, etc SMTP loosely couples the application - your source code does not couple with other services so, it never relies on any backing services and allows for scaling/flexibility. Locally maintained or provided by some third parties, these services have both options then it is possible to attach and detach backing services without redeploying the application. 5. Build, Release, Run Strictly separate build & run stages Build stage Input: source code Output: executable Bundle Release stage Input: build & configuration (immutable build) Output: release in an executable environment Run stage Input: release Output: a running process Use CI/CD tools to automate the builds and deployment process There is a 1:many relationship between builds & deployments. The entire process is ephemeral, which is the key to Build, Release, and Run. All artifacts and environments can be completely rebuilt from scratch if something in the pipeline is destroyed, utilising resources kept in the source code repository. Main goal a one-directional flow from code to release Note: Never work on production or staging. let it be a one-directional flow. 6. Processes Executes the app as one or more stateless processes Stateless vs. stateful processes Stateless: Without storing any data, a stateless system sends a request to the server and receives the response ( ) back. or the state Stateful: monitor data, anticipate a response, and, in the absence of one, resend the request. Note: all long-lasting states must be external to the application, provided by backing services. Avoid using web servers ( ) sticky sessions Pre-caching in memory, the data must be saved to a store and used from there rather than being kept in memory 7. Port Binding Export services via port binding The twelve-factor app is entirely independent and does not depend on the runtime injection of a webserver into the execution environment to create a web-facing service. An app created to enable externalised, runtime port binding may serve as a backing service for another app. The flexibility is powerful. Using port forwarding, any problems resulting from a conflict/clash between a port number assigned privately to the network and one used publicly by another operation can be avoided. Containers like Tomcat, JBoss, Liberty, jetty, undertow and Web Sphere are common in the Java world. Other web applications might run inside other containers, like Microsoft Internet Information Server . (IIS) In a non-cloud environment, These containers receive web application deployments and are responsible for allocating ports to the applications when they launch. 8. Concurrency Scale out via the process model Processes should be separated after being organised according to their purposes so that they can be scaled up and down as required. The utilisation of resources might fluctuate. Old model: Vertical scaling is the process of adding additional and other resources ( ) to a single monolithic application. CPUs, RAM, physical or virtual New model: Scaling out, or horizontally, is the process of adding more nodes( ) and is a much more contemporary strategy that is suitable for the type of elastic scalability that the cloud allows. workers Building disposable, stateless, share-nothing processes then use horizontal scaling not vertical, and run multiple, concurrent instances of your application. 9. Disposability Maximize robustness with fast startup and graceful shutdown The processes of a cloud-native application are disposable, allowing for quick startup and shutdown. If an application cannot start quickly and shut down gracefully, it cannot scale, deploy, release, or recover quickly. High traffic scale out - When the load is high, new instances are created, and the time consumed by these instances affects user performance. Watch for lengthy startup efforts, and initialization work and externalize them to . backing services Fast shutdown is acceptable, but graceful shutdown is preferred and make sure that the entire state is unharmed and robust against sudden failure. 10. Dev/Prod Parity Keep development, staging & production as similar as possible Reduce, minimize, and eliminate differences between an app’s development, staging, production environment, and so on as identical as possible. Although there are countless chances to create a gap between environments, the most common gap areas are: - Time gap Developers take a long time to move across environments. There must be processes, automated pipelines, possibly one-click production deployment, and takes hours rather than months or days to deploy. Ci/CD - Personnel gap The developers team write the code, operation team deploy it. Don't have manual procedures and there must be automated deployments, predictable deployments that can be and deployment to production. repeated, one-click - Tools gap The tech tools/stack/libraries used should be as similar as possible across environments. To support this principle: the use of containers – a very powerful tool here, as they enable you to run the same execution environment from local development through production. and most of the tools are and ideally all cloud environments (except development) then reduce it works in this environment issues, can easily catch issues and can fix/patch issues. Docker containerization open-source 11. Logs Treat logs as event streams Logging is essential for monitoring how your application behaves and here, it treats log entries as routed to a separate service for analysis and archival. Every developer needs to read logs (to access it) ex: log4J config, etc. event streams The App should not worry about how logs are written; instead, just write to and . The application is unable to predict factors like disc position, log size, rollover time, and others. stderr stdout Logs need to be non-functional requirements i.e., , , , . log aggregation log storage log processing log access To track and analyse your log emissions, you can use tools like the ELK stack (ElasticSearch, Logstash, and Kibana), Splunk, Sumologic, or other 3rd party applications. Logs become a separate service that helps in elastic scalability. 12. Admin Processes Run admin tasks as one-off processes This rule states that management or administrative tasks should be carried out by applications in an environment that is the same as that of the app's normal and ongoing operations. It also recommends running such scripts on the production server using a tool included in the execution environment. Some examples of tasks that might require reevaluation include database migrations, interactive programming consoles (REPLs), running timed scripts like nightly batch jobs, and one-off jobs executing custom code. Moreover, it's crucial to align administrative processes with the cloud provider's features and avoid relying on traditional methods in cloud-native environments. Instead Use cloud-enabled processes like to run instead of traditional administrative processes. cloud functions/lambdas All should be implemented as separate cloud-native processes. data migrations Don't use as an admin. REPL Conclusion In , building applications demands agility, scalability, and resilience. The 12 Factor App guides developers towards creating applications that seamlessly produce in cloud environments. If you are just starting your cloud journey, the 12-Factor App methodology is worth exploring. Its principles offer a solid foundation for building modern, cloud-native applications that can adapt and flourish in the face of continuous change. cloud computing References: https://www.redhat.com/architect/12-factor-app https://12factor.net/ https://www.oreilly.com/library/view/beyond-the-twelve-factor/9781492042631/ Send me a direct message on If you're curious or have any questions on the subject; I'd be pleased to chat with you! X , Also published here.

This story contains new, firsthand information uncovered by the writer.

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

The 12 Factor App: Principles Every Cloud Developer Should Know

Too Long; Didn't Read

Ankitjha

STORY’S CREDIBILITY

Original Reporting

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The 12 Factor App: Principles Every Cloud Developer Should Know

Too Long; Didn't Read

Ankitjha

STORY’S CREDIBILITY

Original Reporting

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES