Do you remember 2011? The second year of a decade saw the Occupy Wall Street movement, and the loss of tech visionary Steve Jobs as the Apple iPhone 4S was released. It was a big year, but hidden behind those headlines, Heroku launched the 12-Factor App manifesto, which has now become a gold standard of modern software design and development.
I have to admit that the first time (or the first several times) I looked at the 12-Factor App elements in the early 2010s, I treated it as an infrastructure road map. That’s because I didn’t understand how software was becoming so intertwined with infrastructure and the processes around it. While so many new methods (e.g. DevSecOps) and technologies (e.g. containerization) have been introduced since 2011, I see 12-Factor as an increasingly relevant model for modern applications.
I am writing to emphasize how the 12-Factor App is a very sound evaluation of an application’s Cloud Maturity, and that it is surprisingly easy to evaluate a large application portfolio for 12-Factor compliance using solutions like CAST Highlight.
What is the 12-Factor App?
The 12-Factor App manifesto is an approach to building and maintaining a modern application that ensures it is scalable, self-sustaining, and fit for a cloud-based deployment. It was published by Heroku, a cloud platform (PaaS) provider. The 12-Factor App guidelines address application architecture design and processes.
12-Factor App architecture should be:
-
Loosely coupled with back end (clean contract)
-
Deployed on a cloud platform
-
Explicit dependencies in a single neat (small) package
-
Separation of services from the core app (e.g. webserver)
12-Factor App Processes should achieve the following objectives:
-
Everything is automated
-
Everything is scalable
-
Code is tracked in a single place
-
Process is never bypassed
How do the 12-Factor App guidelines help with modernization and cloud optimization initiatives?
The 12-Factor App guidelines direct our attention to design and processes around the application or applications in question. Based on the manifesto and through following the guidelines, IT leaders should be able to:
-
Minimize ramp up time and cost of new developers joining the same project
-
Increase portability between environments
-
Eliminate the need for administration of servers and systems
-
Maximize the agility of the continuous deployment process
-
Reduce the amount of changes to tooling, architecture, and processes when scaling up
-
Reduce time to-market for new innovations by adopting modern cloud services (e.g., AI, ML, Serverless)
But how can you be sure an application or project is compliant with the 12-Factor App guidelines? Where do non-compliant projects fall short?
12-Factor App: Is Your Application Compliant?
Let’s take a look at what a 12-Factor App self -ssessment would look like, one factor at a time.
Factor I - Codebase: One codebase tracked in revision control
The key here is whether or not you are keeping your source code isolated and scoped cleanly. If you can answer “Yes” to the following questions, you’re doing well:
-
Is this application's source code stored in a source control repository?
-
Is this application's source code stored in a single repository or several repositories that share a single root commit?
-
Do all the deploys of this app share the same code base?
If no other applications share some or all of the code base with your application, then you're not quite compliant with Factor 1.
Factor II - Dependencies: Explicitly declare and isolate dependencies
12-Factor compliant apps do not rely on system dependencies, and declare all dependencies explicitly. If your code refers to or uses any of the following components or performs some of the listed operations, you are not 12-Factor App compliant:
-
COM Components
-
Using file system
-
GetTempPath
-
System DLLs
-
System.ServiceProcess (Windows services)
-
Windows registry
-
Directory Manipulation
-
File Manipulation
-
ConfigurationManager
-
Auto Generated Machine Key
On the other hand, use of the following dependency declaration methods are signs that your app is 12-Factor App compliant:
-
Use of Pip (Python)
-
Use of Virtualenv (Python)
-
Use of UberJar or FatJar (JEE)
-
Use of Maven to Define Dependencies POM.xml (JEE)
Factor III - Config: Store config in the environment
This factor is looking for whether you are storing your config in your code, which is a bad practice for 12-Factor Apps. Storing your config in the environment separate from your code ensures that your code is not environment dependent, and free of potential security threats like hard-coded credentials.
Signs of your app failing this factor can be that the following items are found in your code:
-
Access to environment variables
-
Application server dependencies
-
Using JEE Configuration
Factor IV - Backing services: Treat backing services as attached resources
A 12-Factor compliant app treats all backing resources such as databases or webservers as attached resources. This means that no matter where it is deployed, it refers to the resources the same way, via config stored in the environment. Signs that this is being done correctly in your app can be:
-
Using a Cloud-based Key storage (KMS)
-
Using a Cloud-based middleware application (Pub/Sub)
-
Using a Cloud-Based Storage
-
Using a Cloud-based Stream and Batch data processing
-
Using a Cloud-based task scheduling service
-
Using BigQuery product cloud data warehouse
-
Using BigTable product fully managed NoSQL database service
-
Using Cloud Datastore product NoSQL document database
-
Using Cloud IAM (Identity & Access Management) for managing specific resources access authorization
-
Using Cloud IAP (Identity Aware Proxy)
-
Using Cloud Memorystore for Redis fully managed in-memory data store service
-
Using Cloud Spanner product relational database service
-
Using Firebase Google's mobile platform
-
Using Kubernetes product open-source platform for managing containerized workloads and services
-
Using a Cloud-based Service Bus
Factor V - Build, release, run: Strictly separate build and run stages
Factor V is about the deployment process. To be compliant, each stage of your deployment needs to be autonomous and follow a strict process. To comply you must be able to answer “no” to the following questions:
-
Can releases be changed or tampered with after it has been created?
-
Can run (or production) code be changed without a build or release being triggered?
You should also be able to answer “yes” to the following:
-
Are you using an automated deployment platform?
-
Does the current deployment orchestrator have automated rollback capabilities?
Factor VI - Processes: Execute the app as one or more stateless processes
To take full advantage of scalable cloud infrastructure, stateful processes will not work. A 12-Factor App should be run as stateless processes to ensure that it does not rely on “remembering” data or user input. If the following are present in your code, you are NOT compliant with Factor VI:
-
Using New Process in System.Diagnostics namespace
-
Using stateful session (Servlet)
-
Using stateful session (Spring)
-
Using Webform Authentication
On the other hand, if the following are present in your code, your app is on its way to be, if not already, compliant with this factor:
-
Using a cloud-based Batch Job Orchestration
-
Using a Cloud-based cache management framework
-
Using CDI Beans Configuration
Factor VII - Port binding: Export services via port binding
12-Factor Apps should be self-contained. Simply put, if you’re using a web server like WebSphere, JBoss, or TomCat, your app is NOT compliant with this factor.
Factor VIII - Concurrency: Scale out via the process model
The concurrency factor assesses whether the architecture of the app is constructed in a scalable manner. Each incoming request should be handled by a different process, and each “type” of request should rely on the system’s process manager to scale. Processes should not share resources. The one key question to ask about your app is: Does this app have separate and distinct processes that are assigned to handle different types of requests and tasks? If you answer “no”, you are probably not compliant with this factor.
If a code scan turns up the following in your code, you are NOT compliant with this factor:
-
Use of unsecured network protocols (HTTP, FTP)
-
Use of unsecured database connection strings
-
Code creates Daemos to run processes
-
Code writes PID files
Factor IX - Disposability: Maximize robustness with fast startup and graceful shutdown
12-Factor Apps should shut down quickly and gracefully, meaning they will shut down once a process is complete and not affect any other processes. They must also boot up quickly. To be compliant, you must be able to answer “yes” to this question:
- Does this app finish processing all active requests prior to shutdown when it receives a termination signal (SIGTERM)?
The answer to the following question should be “no more than a couple of seconds”:
-
What is the average time for this app to boot after a shutdown?
Factor X - Development/production parity: Keep development, staging, and production as similar as possible
Keeping all your environments in sync ensures that your deployments are smooth. This is pretty simple. You should be syncing your development, staging, and product environments daily, and you should be using the same database (or other supporting services) in all your environments.
Factor XI - Logs: Treat logs as event streams
The 12-Factor App treats logs as streams, and does not have code that manages specific log files. The idea is that events are constantly streaming and managed by a tool to store data separately instead of creating code that addresses the log.
Factor XII - Admin processes: Run admin/management tasks as one-off processes
The last factor sounds simple, but you should be careful - while this sounds like a code issue, it is actually a process issue. The manifesto urges that you ship your admin code with your core code, and one-off admin tasks are run in the same (or similar) environment as your long-running processes. Can you answer “yes” to both of these?
Rapidly Assess a Portfolio for 12-Factor Compliance
To truly assess your application or system for 12-Factor App compliance, you must perform a software composition analysis (SCA), a code scan, and a survey of your team about the development and deployment processes. Collecting this information can be burdensome, let alone centralizing and analyzing the data to take some action. Now, imagine assessing a large enterprise portfolio consisting of thousands of web and cloud applications for 12-Factor App compliance. Are you getting a headache?
CAST Highlight provides all three of the necessary data collection components (SCA, code scan, and survey). By configuring a custom survey and creating a custom indicator, organizations can use CAST Highlight to perform 12-Factor Application Assessments. This assessment can be completed on hundreds of applications in less than a week compared with the weeks (or months) it would take using a traditional survey-only approach.
Contact us today to find out more about how CAST Highlight can assist with your 12-Factor App compliance assessment and accelerate your migration to the cloud.
SHARE