12-Factor Best Practices

• The twelve-factor app:

  • The twelve-factor app is a set of best practices for building web or software-as-a-service applications. Twelve-factor design helps you decouple components of the application so that each component can be deployed to the cloud using continuous deployment and scaled up or down seamlessly. The design principles also help maximize portability to different environments. Because the factors are independent of any programming language or software stack, 12-factor design can be applied to a wide variety of applications. Let’s take a look at these best practices
• The 12 Factors:

  
• • The first factor is codebase. The codebase should be tracked in a version control such as Git. Cloud Source Repositories provides fully featured private repositories.
• • The second factor is dependencies. There are two main considerations when it comes to dependencies for twelve-factor apps: dependency declaration and dependency isolation. Dependencies should be declared explicitly and stored in version control. Dependency tracking is performed by language-specific tools such as Maven for Java and Pip for Python. An app and its dependencies can be isolated by packaging them into a container. Container Registry can be used to store the images and provide fine-grained access control.
• Third-Factor:

  • The third factor is configuration. Every application has a configuration for different environments like test, production, and development. This configuration should be external to the code and usually kept in environment variables for deployment flexibility.
• Fourth-Factor

  • The fourth factor is backing services. Every backing service such as a database, cache, or message service, should be accessed via URLs and set by configuration. The backing services act as abstractions for the underlying resource. The aim is to be able to swap one backing service for a different implementation easily.
• The 12 Factors

  
• Fifth-Factor:

  • The 5th factor is build, release, run. The software deployment process should be broken into three distinct stages: build, release, and run. Each stage should result in an artifact that's uniquely identifiable. Build will create a deployment package from the source code. Every deployment package should be linked to a specific release that's a result of combining a runtime environment configuration with a build. This allows easy rollbacks and a visible audit trail of the history of every production deployment. The run stage then simply executes the application.
• Sixth-Factor:

  • The 6th factor is processes. Applications run as one or more stateless processes. For instance, each service should have its own datastore and caches using, for example, Memorystore to cache and share common data between services used.
• Seventh-Factor:

  • The 7th factor is port binding. Services should be exposed using a port number. The applications bundle the web server as part of the application and do not require a separate server like Apache. In Google Cloud, such apps can be deployed on platform services such as Compute Engine, GKE, App Engine, or Cloud Run.
• Eighth-Factor:

  • The 8th factor is concurrency. The application should be able to scale out by starting new processes and scale back in as needed to meet demand/load.
• The 12 Factors:

  
• Ninth-Factor:

  • The 9th factor is disposability. Applications should be written to be more reliable than the underlying infrastructure they run on. This means they should be able to handle temporary failures in the underlying infrastructure and gracefully shut down and restart quickly. Applications should also be able to scale up and down quickly, acquiring and releasing resources as needed.
• Tenth-Factor:

  • The 10th factor is Dev/production parity. The aim should be to have the same environments used in development and test/staging as are used in production. Infrastructure as code and Docker containers make this easier. Environments can be rapidly and consistently provisioned and configured via environment variables. Google Cloud provides several tools that can be used to build workflows that keep the environments consistent. These tools include Cloud Source Repositories, Cloud Storage, Container Registry, and Terraform.
• Eleventh-Factor:

  • The 11th factor is Logs. Logs provide an awareness of the health of your apps. It’s important to decouple the collection, processing, and analysis of logs from the core logic of your apps. Logging should be to standard output and aggregating into a single source. This is particularly useful when your apps require dynamic scaling and are running on public clouds because it eliminates the overhead of managing the storage location for logs and the aggregation from distributed (and often ephemeral) VMs or containers.
• Twelfth-Factor:

  • The 12th factor is Admin processes, These are usually one-off processes and should be decoupled from the application. These should be automated and repeatable, not manual, processes. Depending on your deployment on Google Cloud, there are many options for this, including: cron jobs in GKE, cloud tasks on App Engine, and Cloud Scheduler.