Twelve-Factor Application of Microservices

Posted on

Alt Text
Original post can be found here: https://www.programmingwithjon.com/blog/12Factor



Why Do We Need This?

The twelve-factor application is a methodology for Software as a Service(SaaS) or web applications or software deployed in the cloud. It tells us about the characteristics of the output expected from such applications. It essentially is just an outline of necessities for making a well-structured and scalable cloud application.



What are the Twelve-Factors?

These are the 12-factors to follow:
Codebase: We maintain a single code base here for each microservice, with a configuration specific to their own environments, such as dev, staging and production. Each microservice would have its own repository in a version control system.

Dependencies: All microservices will have their dependencies as part of the application bundle. In Node.js, there is package.json, which mentions all the development dependencies and overall dependencies. You can also use a private repository where the dependencies can be pulled.

Configs: All configurations should be externalized, based on the server environment. There should be a separation of config from code. You can set environment variables directly in your project or use Docker compose to define other variables.

Backing Services: Any Service consumed over the network such as a database, I/O operations, messaging queries or SMTP the cache will be exposed as microservices and using Docker compose and be independent of the application.

Build, release, and Run: Use automated tools like, Docker and Git in distributed systems. Using Docker you can isolate all the three phases using its push, pull, and run commands.

Processes: Microservices designed would be stateless and would share nothing, hence enabling zero fault tolerance and easy scaling. Volumes will be used to persist data thus avoiding data loss.

Port binding: Microservices should be autonomous and self-contained. Microservices should embed service listeners as part of service itself. For example – in a Node application the HTTP module, service network that exposes services for handling ports for all processes.

Concurrency: Microservices will be scaled out via replication. Microservices are scaled out rather than scaled up. Microservices can be scaled or shrunk based on the flow of workload diversity. Concurrency will be dynamically maintained.

Disposability: To maximize the robustness of application with fast startup and graceful shutdown. Various options include restart policies, orchestration using Docker swarm, reverse proxy, and load balancing with service containers.

Dev/Prod parity: Keep development/production/staging environments exactly alike. Using containerized microservices helps the build once, run anywhere strategy. The same image is used across various DevOps stages.

Logs: Creating a separate microservice for logs makes it centralized, to treat as event streams and send it to frameworks such as Netlify or Elastic stack.

Admin processes: Admin or any management tasks should be packed as one of the processes, so they can be easily executed, monitored, and managed. This includes tasks such as database migrations, one-time scripts- fixing bad data, etc.



Summary

I hope this helps to demystify the Twelve-Factor app a little bit. I know when I was first learning about this and how to properly set up microservices it was hard to remember all of the factors. I created this post to be used as a cheat sheet if you will to revert back to every so often in case you can’t quite remember all of the factors. Let me know if I missed anything.

Thanks

Leave a Reply

Your email address will not be published.