Let's discuss microservice best practices. The 12-factor app is a set of best practices for building web or software as a service applications. 12-factor design helps you decouple components of the application, so that each component can be deployed to the Cloud using continuous deployment and scale up or down seamlessly. The design principles also help maximize portability to different environments. The cost of 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 first factor is codebase. The codebase should be tracked in a version control such as Git. Cloud Source Repositories provide fully featured private repositories. The second factor is dependencies. There are two main considerations when it comes to dependencies for 12-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 packing them into a container. Container registry can be used to store the images and provide fine-grained access control. The third factor is configuration. Every application has a configuration for different environments like test, production, and development. This configuration should be kept external to the code and is usually kept in environment variables for deployment flexibility. The fourth factor is backing services. Every backing service, such as 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 fifth 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 is uniquely identifiable. Build will create a deployment package from the source code. Every deployment package should be linked to a specific release. That's the result of combining a runtime environment configuration with a built. This allows for easy rollbacks and a visible audit trail of the history of every production deployment. The run stage then simply executes the application. The sixth factor is processes. Applications run as one or more stateless processes. If state is required, the technique discussed earlier in this module for state management should be used. For instance, each service should have its own data store and caches using, for example, memory store to cache and share common data between services used. The seventh 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. The eighth factor is concurrency. The application should be able to scale out by starting new processes and scale back in as needed to meet demand and load. The ninth 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. 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 and keep the environments consistent. These tools include Cloud Source Repositories, Cloud Storage, Container Registry, and Terraform. Terraform uses the underlying APIs of each Google Cloud service to deploy your resources. 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 the 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 of the logs and the aggregation from distributed and often ephemeral VMs or containers. Google Cloud offers a suite of tools that help the collection, processing, and structured analysis of logs. The 12th factor is admin processes. These are usually one-off processes that should be decoupled from the application. They should be automated and repeatable, not manual processes. Depending on your deployments on Google Cloud, there are many options for this, including cron jobs in GKE, Cloud Tasks on App Engine, and Cloud Scheduler.
