12 Factors to Cloud Success
12 Factors to Cloud Success
With cloud technology being adopted at such high rates, find out how you can better leverage the cloud and containers for development.
Join the DZone community and get the full member experience.Join For Free
Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.
Hey, developers! Do you care about using the best practices to apply your application to the cloud? If so then you should be using The 12-factor App, which is a methodology for building Software-as-a-Service. Today, I'd like to talk about the 12-factor App, which I had presented to a group at the Red Hat Summit last month.
Every developer that is moving their application to the cloud will face a different environment than what they are used to, their datacenter or own premise and that’s why they should care about the 12-factor methodology. This 12 step methodology was created by Heroku, which is a cloud provider who found a common solution to most of what their customers were experiencing and decided to release these solutions as a methodology. These 12 factors are intended to solve problems related to applications running in the cloud. If there was one key takeaway from my session it was not the idea to have the audience memorize these 12 factors but to have an understanding of why each one is important.
- Codebase – Use version control, one codebase tracked in revision control for many deployments.
- Dependencies – Use a package manager and don’t commit dependencies in the codebase repository.
- Config – Store the config in Environment Variable, if you have to repackage your application, you’re doing it wrong.
- Backing Services – A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code.
- Build, Release, Run – The twelve-factor app uses strict separation between the build, release, and run stages. Every release should always have a unique release ID and releases should allow rollback.
- Processes – Execute the app as one or more stateless processes. The Twelve-factor processes are stateless and share-nothing.
- Port Binding – Export services via port binding, The twelve-factor app is completely self-contained.
- Concurrency – Scale out via the process model. Each process should be individually scaled, with Factor 6 (Stateless), it is easy to scale the services.
- Disposability – Maximize robustness with fast startup and graceful shutdown, we can achieve this with containers.
- Dev/Prod Parity – Keep development, staging, and production as similar as possible, the twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.
- Logs – Treat logs as event streams, a twelve-factor app never concerns itself with routing or storage of its output stream.
- Admin Processes – run admin/management tasks as one-off processes.
The 12-factor App methodology is technology and language agnostic but satisfied by Containers, Microservices, and CI/CD Pipelines with a focus on DevOps. You can access more information on The 12-factor App here.
Published at DZone with permission of Rafael Benevides , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.