Today, software is often delivered as a service. 12factor is a methodology for building software-as-a-service applications. By using this methodology, you ensure best practices and lots of business benefits that come with it. Here are five benefits:
Twelve Factor applications are easily scalable. By applying the practices, you can run 1 application server, or multiple. You can easily scale out, and also don’t have to worry about “session stickiness” when the application is stateless. This means that the application can scale out during busy periods, but also scale in during when traffic is low. A lot of applications and websites have lower traffic during the night or weekends. Companies using this methodology that are able to scale down see a huge cost saving on their infrastructure bill.
Our application should be decoupled from the operating system. A Twelve factor app can be deployed on any cloud provider, on any infrastructure that supports the programming language it has been written in. This is a huge deal for resiliency and disaster recovery. Potentially, you can now boot up your application layer in just a few minutes in any other datacenter or at any other cloud provider. You don’t have to pay for any infrastructure resources anymore until you want to initiate disaster recovery. Just bear in mind that you also need to replicate your services (i.e. relational databases), but all popular database services already have this capability.
Your code will be stored in GIT, you will use dependency management, and your application (or microservice) will be robust and disposable. Deploying your application in dev / staging / prod should be very quick and easy to carry out. Developers can now use the Continuous Delivery engineering approach and produce software in short cycles. New features and bugfixes can be out much sooner than the traditional approach. All big tech companies are already following this approach to maximise software delivery. Take a look at the next diagram how this process could work (source):
Maintaining applications in production has always been expensive, but if your application is easily redeployable, you can use green/blue deployments every time you launch a new production version. It also allows Operations teams to easily redeploy your application when they want to upgrade or patch the underlying operating system, or when dependencies need to be upgraded. Upgrading dependencies when using a dependency management tool is often just the case of redeploying the application.
Lastly, the methodology can also help you achieving your Information Security Goals. Credentials or confidential information should never be in the code. When following best practices, you store the credentials in the environment of the application, not in the code repository. Companies still struggle to find good ways to store their credentials. Storing them in the environment makes it easier to enforce segregation of duties, and doesn’t leak any credentials to the developers that shouldn’t be deploying in a particular environment.
We at in4it want to help companies write great software that runs seamlessly on cloud infrastructure. Earlier we launched a new DevOps platform to make it easy to setup, and maintain applications in the cloud. Get in touch with usif you want to know more. I’m also available on social media.