The 12-Factor Apps Methodology: Implement It in Your Own Apps with AppFog
This article was sponsored by AppFog. Thank you for supporting the sponsors who make SitePoint possible.
In today’s world of SaaS products, a common methodology has emerged with the purpose of providing an outline for building well structured and scalable applications. It’s called the “12-Factor App” methodology, and it’s about to change the way you approach the architecture of your next app.
If you’ve had a lot of experience deploying applications, then you may be well aware that the deployment process can be complicated and extensive to say the least. Virtualization, networking, and setting up runtime environments are just a few of the headaches involved. The 12-Factor App methodology doesn’t eliminate the complexity altogether, but it does create a framework for organizing the process in order to maintain a healthy and scaleable application.
But how should these difficult architecture necessities be handled, in such a way that each of the 12-Factor App principles can be met? The following paragraphs explain how you can meet the standards of the 12-Factor App methodology, while easily overcoming the difficult realities involved in your application infrastructure and deployment setup.
A key tool in this process is AppFog, a Platform-as-a-Service product offered by CenturyLink Cloud to allow application developers to build software without having to focus on infrastructure.
The 12 Factors
As made apparent by the title, the 12-Factor App methodology is a list of principles, each explaining the ideal way to handle a subset of your application. The 12 factors are as follows:
1. Codebase – One codebase tracked in revision control, many deploys
The first principle of the 12-Factor App methodology is related to your application’s codebase. The most important point here is to ensure that your application is tracked with revision control, and that it sits in a central repository that is accessible to your developers. This is most commonly handled by using Git or SVN to store your code.
2. Dependencies – Explicitly declare and isolate dependencies
There is no room for assumptions when it comes to dependencies. Anything your applications rely on to run should be controlled and managed to minimize — if not completely eliminate — conflicts.
3. Configuration – Store config in the environment
Configuration, as it relates to API keys, services, and database credentials, should never be hardcoded. This prevents your application from being at risk from both production data leaks and production errors. Instead of hardcoding this information, rely on environment variables to handle this sensitive information.
4. Backing Services – Treat backing services as attached resources
A backing service is one that requires a network connection to run. This is a very popular paradigm found in modern application development, especially prevalent with the rise in popularity of microservice architecture. The 12-Factor App methodology advises developers to treat these services agnostically, meaning changes or modifications should occur without having to make any code changes.
Typically, this factor is best handled by calling each backing service through an API, with credentials stored in a configuration file that lives in your runtime environment.
5. Build, release, run – Strictly separate build and run stages
Build, release, and run stages should be treated as completely distinct from one another. Automation and tooling will help to make this principle simpler.
This can be accomplished by using existing tools to fully automate your build process. A tool like Github can be used to tag your latest build, while Jenkins can be used to automate your release stage.
6. Processes – Execute the app as one or more stateless processes
Stateless applications are designed to degrade gracefully. That means if a dependency fails, the app itself does not become a failure. Single points of failure may be difficult, but not impossible, to avoid. The 12-Factor App methodology recommends storing data outside of running code in order to prevent operational headaches and debugging nightmares.
7. Port binding – Export services via port binding
All application services should be accessible via a URL. For web applications, this process happens automatically. This enables 12-Factor Apps to be fully self-contained, avoiding the need to rely on various methods of runtime injection in order to create web facing services.
8. Concurrency – Scale out via the process model
Every process inside your application should be treated as a first-class citizen. That means that each process should be able to scale, restart, or clone itself when needed. This approach will improve the sustainability and scalability of your application as a whole.
9. Disposability – Maximize robustness with fast startup and graceful shutdown
As noted in the previous factor, treating processes as first-class citizens translates to an easier startup and shutdown process. Compare this to an application where all process are bundled together, where startup and shutdown processes can take up to several minutes depending on their size.
To ensure your startup and shutdown processes remain seamless, reach for tried and true services that are optimized for speed and performance. Databases and caches like RabbitMQ, Redis, Memcached, and CenturyLink’s own Orchestrate are just a few services that are built to help with this factor.
10. Dev/prod Parity – Keep development, staging, and production as similar as possible
Consistency is key for meeting this factor. When your environments are similar, testing and developing gets much simpler. Similar environments means ensuring that areas such as your infrastructure stack, config management processes, software and runtime versions and deployment tools are the same everywhere.
With this approach, fewer bugs will find their way into your production environment, since your test cases can be applied on production-level data.
11. Logs – Treat logs as event streams
Logging is important for debugging and checking up on the general health of your application. At the same time, your application shouldn’t concern itself with the storage of this information. Instead, these logs should be treated as a continuous stream that is captured and stored by a separate service.
12. Admin processes – Run admin/management tasks as one-off processes
One-off admin processes are essentially data collection jobs that are used to gather key information about your application. This information will be needed to asses the state of your production environment, so it’s important to ensure these one-off processes occur in your production environment. That way there can be no discrepancies between the data you need and the data coming from the visible long running production application.
On the 12-Factor App methodology site, each of these factors links to a section where an in-depth topic overview is available. While it’s impressive to see how well thought out the 12-Factor methodology is, there’s little information regarding how exactly one might best go about setting up an infrastructure that can best handle such rigorous requirements.
But there is a way to do this efficiently with a tool built with the 12-Factor App methodology in mind: AppFog
AppFog, Apps, and You
AppFog is a PaaS designed to provide you with the tools you need to satisfy the 12-Factor App methodology. AppFog manages network resources, middleware, operating systems, virtualization, servers, storage, and the runtime. All you need to do is focus on writing your code. Offered by CenturyLink Cloud, AppFog relies on the versatile open source Cloud Foundry platform.
Getting started with AppFog is as simple as signing into your CenturyLink Control Panel and enabling the AppFog service by adding a region that defines where your code will be hosted. From there, you can deploy your application to AppFog using the Cloud Foundry CLI.
Cloud Foundry then manages your applications’ runtime, middleware, and O/S environments. Additionally, tasks like load balancing, application runtimes, and streaming app logging are abstracted away from the development process and handled entirely by the cloud infrastructure that Cloud Foundry provides.
That is the entire process. Once your application has been deployed to AppFog, all of your infrastructure headaches are over. You’re now free to focus on the application’s codebase.
Tying AppFog into the 12-Factor App Methodology
Your Codebase, Dependencies, Configuration, and Backing Services are 12-Factor principles related to your application and its data. This means they are best managed by you, the developer.
Almost everything else about your app can be handled through AppFog, since AppFog has been built with the 12-Factor Application methodology in mind. For example, Concurrency, Disposability and Logging are all managed by AppFog automatically, once you’ve deployed your codebase. In fact, AppFog manages all hardware, software patching, updates, the physical and software security, and any day-to-day, routine operational tasks.
While some of the 12-Factor App principles may require a small amount of thought and configuration to set up, the majority are handled seamlessly when you deploy your application to AppFog. Not only does AppFog make this process a lot easier, the team offers plenty of documentation and support for any questions you might have. You can find all of the relevant documentation on CenturyLink’s Knowledge Base.
Building 12-Factor applications can be a challenging process, but AppFog has done the majority of the hard work for you. All that’s left for you to do is write your code and deploy.
For additional resources on the 12-Factor App Methodology and how AppFog makes it easier, be sure to review AppFog’s in-depth explanation.
Conclusion
The 12-Factor App Methodology is an exceptional blueprint that provides every necessary step to deploying a reliable SaaS product. While managing all of those steps (and choosing the correct services that do so) can be overwhelming, AppFog PaaS makes the process smoother, taking care of aspects of your app like Concurrency and Disposability so you can focus on writing good code that offers something special to your users.
Wouldn’t you rather focus on building your app and delivering “delight” to your clients, and let AppFog take care of the rest?