Implementation of The 12 Factors App Methodology with AWS Cloud for a SAAS Product - Part 1

This article helps the developers, programmers, solutions architects directly to integrate a #saas application following the 12 Factor App methodology in the #aws cloud architecture and the DevOps guys to maintain this type of apps under AWS platform although this methodology is absolutely applicable to several cloud platforms as well.

The 12 Factor App is an approach for creating Software-as-a-Service (SaaS) products that is:

• To create highly-scalable, cloud native software services
• To ensure portability, maintain a clean contract with the underlying OS
• To utilize declarative forms for automation setup
• To change the typical monolithic structure to #microservices architecture
• Being appropriate for cloud platform deployment with native cloud features like #serverless
• To enable continuous deployment and minimize divergence between development and production following best #cicd practices to maintain maximum agility
• To be capable of scaling up without major changes (human-less and automatic)?

The Twelve-Factor App principles, written by Adam Wiggins , co-founder of Heroku , are listed below that are should be implemented while building a #saas product.

1. Codebase

2. Dependencies

3. Config

4. Backing services

5. Build, release, and run

6. Processes

7. Port binding

8. Concurrency

9. Disposability

10. Dev/prod parity

11. Logs

12. Admin processes

Let’s discuss here every factor in short step by step and communicate with the related AWS services that serve The Twelve-Factor App methodology's purposes actually. But in this article I am discussing about only 3 factors as codebase, dependencies and config.

1. Codebase (One codebase tracked in revision control, many deploys)

The first factor requires each application to have its own single source code repository, and any changes to the code should be tracked and recorded, but the application code can be deployed into many environments. This factor assumes that the application code is always stored and managed in the version control system in the different environments like dev, staging, production port, etc.?

In this case, private Git repositories are hosted by AWS CodeCommit, a managed source control solution that is safe, scalable, and secure. Teams may easily and securely collaborate on code with contributions that are both in transit and at rest encrypted. Developers don't have to worry about scaling the infrastructure of the source control system or manage it themselves while using CodeCommit.

CodeCommit can be used to store anything, including binaries and code. It integrates seamlessly with the other Git-based tools the developers already have because it supports all of Git's standard features.

To get started with #git and #aws CodeCommit, go through this blog.

2. Dependencies (Explicitly declare and isolate dependencies)

The majority of languages include a method for packaging systems for distributing support libraries like CPAN for Perl, Rubygems for Ruby, NPM for Node and so on. The second factor, which addresses dependencies, states that, for the application to be consistent with this point, implicit dependencies on packages or operating system libraries need to be avoided. The application should also use a dependency isolation tool, such as;

• Maven or Gradle in Java
• Pip for Python or
• NPM for Node or
• C# for NuGet or
• Go for Go etc.

They have no implicit dependencies “leak in” from the surrounding system. Leveraging such tools makes it easier for freshly hired engineers to configure their environment and applications.

AWS CodeBuild is a fully managed continuous integration service that assembles source code, conducts tests, and generates deployable software packages. With CodeBuild, the developers never need to provision, manage, and scale their own build servers. The build process won't be kept in a queue because CodeBuild scales constantly and handles several builds at once by using prepackaged build environments.

Here is a great overview of An Introduction to AWS CodeBuild

3. Config (Store config in the environment)

Everything that is likely to change between deploys is an app's configuration (staging, production, developer environments, etc.) such as?

• Resource handles to the database, and other backing services like SMTP, Memcached
• Credentials to third-party services like #Twitter or #amazons3
• Per-deploy values such as the CNAME or alias DNS record type for the deploy

Many apps will occasionally retain configuration data as code constants. 12 Factor, which demands a strong separation of configuration from code, is broken by this configuration in the code base. Across deployments, configuration varies greatly, but code does not.

AWS has several services to serve this purpose such as AWS Secret Managers, Secret Manager Parameter Store, AWS Key Management Service (KMS) etc.

AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, API keys, and other secrets throughout their life cycles. Also, it's configurable to rotate automatically with the help of #lambda functions defining how to that works. So the main features of secrets manager are as follows:

• To create a version of the secret newly.
• To keep the secret in Secrets Manager.
• To enable storing configuration data in ciphered form that is encrypted with a KMS service key
• To configure the protected service for using the new version.
• To equip the secret with automatic password rotation technique like in Amazon RDS that is supported natively
• To verify the new version.
• To consider the new version regarding as production ready.

The communications among the process are as follows:

1. The Lambda context are initialized by responding Lambda service to an event.
2. The wrapper script is the Lambda init phase actually.
3. Then Golang executable is passed in the ARN for the secret to recover.
4. The Secrets Manager API is used by Golang executable to encrypt the decrypted secret.
5. Then the wrapper script converts the config info into environmental variables and go for the next step in processing.

A 12-factor application requires the strict separation of configuration from the application code that is fulfilled in the stage.

For more info about this, read this blog Creating AWS Lambda environment variables from AWS Secrets Manager

Also, I discussed about other factors on part 2 and part 3 accordingly. Links are given below:

Implementation of The 12 Factors App Methodology with AWS Cloud for a SAAS Product - Part 2

Implementation of The 12 Factors App Methodology with AWS Cloud for a SAAS Product - Part 3

The Twelve-Factor App methodology is the twelve best practices that help the developers to decouple components of the app, so that each component can be reusable easily, or scaled up or down seamlessly that is considered nowadays actually as a modern, cloud-native application.?

Above all, I have discussed in this article about the topic at a high level overview and of course different solutions will have different architecture where the cloud service usages are varied based on that architecture. It will help the developers who are building a #saasstartup for brainstorming to create a software architecture.

Please follow me to get more articles in future.

Helpful contents and credit:

The official website of Twelve Factor App is The12 Factor App

How to Apply the Twelve-Factor App Methodology to Serverless Applications

How to Develop Twelve-Factor Apps using Amazon ECS and AWS Fargate

AWS SAAS Factory Program