The Twelve-Factor App — How it Helps in A Successful Microservices Architecture

With the growth of microservices – essentially, designing applications as a collection of individual services rather than One Big Thing – some developers are turning to a development methodology known as “twelve-factor app development” to inform their architecture strategy.

Microservices apps are an excellent candidate for twelve-factor app development methodologies, which were expressly formulated for Software as a Service (SaaS) app development.

One major reason for this is that in a microservices environment, even slightly different development methodologies between teams can result in incompatibility issues and other integration challenges once multiple apps reach testing and real-world deployment.

Twelve-factor development expert Adam Wiggins lays out the principles of the methodology in this manner:

1. Codebase: One codebase tracked in revision control, many deploys
2. Dependencies: Explicitly declare and isolate dependencies
3. Config: Store config in the environment
4. Backing services: Treat backing services as attached resources
5. Build, release, run: Strictly separate build and run stages
6. Processes: Execute the app as one or more stateless processes
7. Port binding: Export services via port binding
8. Concurrency: Scale out via the process model
9. Disposability: Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity: Keep development, staging, and production as similar as possible
11. Logs: Treat logs as event streams
12. Admin processes: Run admin/management tasks as one-off processes

These principles maximize some of the most important characteristics for SaaS solutions:

Performance, security, scalability and flexibility.

They help developers set boundaries for what is included in their microservices architecture, and (often more importantly) what is not. This reduces conflicts, speeds up the delivery cycle, improves performance and makes it easier for companies to evolve their architecture over time.

As with any development methodology, organizations often customize the details of twelve-factor development to meet their own needs or work within existing systems or structures.

Most importantly, any customization of the principles must be consistent across all teams, so that the value of a common methodology isn’t eroded by growing inconsistencies between teams developing interactive microservices.

If you’re interested in learning more about how twelve-factor development can help you develop interactive applications, contact us today.