OK, "twelve-factor application" is not just one word of the week, it's a three-word mouthful! It's also an important concept for developing software-as-a-service applications.
Software-as-a-service (SaaS) describes any application that is hosted by a provider and delivered over the internet as a service. It's one of the three most popular forms of cloud computing, along with infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS). SaaS is a great model for companies as it creates a subscription model with recurring revenue. It also provides benefits for users, such as lower upfront costs to entry, more frequent updates, better security, and access to new features.
The twelve-factor app methodology was developed by Heroku in 2012, and has been documented at 12factor.net. Hey, that's easy to remember! This methodology uses the following concepts (quoted from their site):
- Use declarative formats for setup automation, which minimizes time and cost for new developers joining the project
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments
- Are suitable for deployment on modern cloud platforms
- Minimize divergence between development and production, enabling continuous deployment for maximum agility
- Can scale up without significant changes to tooling, architecture, or development practices
The twelve factors are:
1. Code base: Use a single codebase and address the needs of specific devices using version control.
2. Dependencies: All dependencies should be explicitly declared and isolated.
3. Configuration: Design the app to read its config from the environment instead of storing it as constants in code.
4. Backing Services: Back-end services should be treated as resources to be accessed with a URL or other locator that is stored in the config.
5. Build, Release, Run: The build and run stages should be strictly separated.
6. Processes: The app should be executed through stateless processes. Persistent data should be stored in a stateful backing service.
7. Port binding: Twelve-factor apps do not use external app containers, so these services should be exported using port binding.
8. Concurrency: Construct your app with independent processes based on process types, which enables your app to scale up and down based on workload requirements.
9. Disposability: Treat your app and infrastructure as disposable resources in order to handle temporary loss of infrastructure and should be able to gracefully shut down and restart.
10. Environment parity: The development, staging, and production environments need to be as similar as possible.
11. Logs: Logs should be used as event streams to track the app health. Treat logs as event streams. Logs should not be concerned with routing or app output storage.
12. Admin processes: Run admin tasks as one-off processes from a machine in the production environment.
There is a great visual representation of the twelve-factor app idea here.
Companies like IBM, Red Hat, and Google have also been promoting twelve-factor app development as part of their cloud strategies. If you are developing cloud apps, use this methodology to make sure you have a scalable and robust application.
Let's discuss how this methodology impacts your work.
What benefits do you see in using the twelve-factor app development methodology for developing cloud-based applications? What are some of the challenges you anticipate in implementing this methodology for cloud-based applications? What tools and technologies do you use?
