The document discusses the Twelve Factors methodology for building cloud-native applications. The Twelve Factors emphasize agility, portability, and scalability through principles like codebase management, externalized configuration, statelessness, and treating logs as event streams. Adopting these best practices helps applications maximize benefits of modern cloud platforms like rapid deployment, continuous delivery, and horizontal scaling. The document provides an overview of each factor and examples to illustrate how they enable cloud-native architectures like microservices and containerization.

1. The Twelve-
Factor App
Ravi Okade @Philly.net 2018

2. Why Twelve Factors?
“Twelve Factor apps are built for agility and rapid deployment, enabling continuous delivery
and reducing the time and cost for new developers to join a project. At the same time, they
are architected to exploit the principles of modern cloud platforms while permitting
maximum portability between them. Finally, they can scale up without significant changes to
tooling, architecture or development practices,”
https://blog.heroku.com/twelve-factor-apps

3. Twelve Factor App leads to a..
- Microservice
- Small, low complexity service
- Easily replaceable if something better comes along, without consumers noticing
- Does one thing (Single Responsibility Principle)
- Cloud Native Application
- Ephemeral, Stateless, Location transparent, Fault tolerant
- Quick to build, deploy, release, recycle
- Efficient Team
- Smaller services = less dependence between teams = more efficient
- Better Dev Ops
- Similarity across environments
- Automation everywhere

4. Quick Refresher - IAAS/PAAS/SAAS
Image Credit: BMC

5. Quick refresher - Microservices
https://www.microsoft.com/net/learn/architecture
Martin Fowler and Team:
The microservice architectural style [1] is an approach to developing a single application as a
suite of small services, each running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API. These services are built around business capabilities
and independently deployable by fully automated deployment machinery
https://martinfowler.com/articles/microservices.html
Microsoft: Microservices (& Docker)
Microservices are small, modular, and independently deployable services. Docker containers (for
Linux and Windows) simplify deployment and testing by bundling a service and its dependencies
into a single unit, which is then run in an isolated environment.

6. Monolith vs Microservice
https://martinfowler.com/articles/microservices.html

7. Microservice - an analogy
Effort to replace a window

8. The Twelve Factors
I. Codebase
One codebase tracked in revision control, many
deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful
shutdown
X. Dev/prod parity
Keep dev, staging, and production as similar as
possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off
processes

9. I. Codebase One codebase tracked in revision control, many
deploys
Usecases:
1 Codebase = 1 App: Awesome!

10. I. Codebase One codebase tracked in revision control, many
deploys
Usecases:
1 Codebase = Many Apps: Implies a monolithic app with overlapping functionality. Find
boundaries to break it up.
Order Management Codebase
- Order management
- Realtime fraud detection
- Inventory monitoring
and alerts Inventory alerting
service
Realtime Fraud
detection service
Order Management
System
Order Pub-Sub
Before After

11. I. Codebase One codebase tracked in revision control, many
deploys
Usecases:
Many Codebase = 1 App : Indicates multiple disparate applications hosted as one. Likely that
different teams are working on each part. Must be broken up.
Order Management
Codebase
Billing Codebase
Search Codebase
Content Management
Codebase
E-Commerce
Application
Search Service
Content Management
Service
Billing Service
Order Management
Service
Before
After

12. II. Dependencies Explicitly declare and isolate dependencies
- Dont assume dependencies will exist in GAC or Classpath etc. Bring your binary
dependencies with you.
- Declare platform dependencies in your manifest. E.g. Java8 or .NET 4.5
- Don't assume file system structure e.g. temp folder, app root folder

13. III. Config Store config in the environment
- Externalize all configuration that is specific to an environment
- Most cloud providers can push properties as environment variables. So this is a good
option.
Code Build
Relea
se
Config {}
Run
Config {}

14. III. Config Store config in the environment
- Large enterprises also need to version the configuration (just like a build version). The
most common solution to this would be to tag your configuration in source control and
point your app to it.
- Secret management is also natively provided by Cloud providers or you can use
external providers/solutions like Hashicorp Vault.

15. V. Build, release, run Strictly separate build and run stages
Separation of phases:
- Build phase: One versioned build, deployed many places. Single image, so no
surprises.
- Release Phase: Repeatable, automated releases and factors in the environment
constraints (e.g. Production deploy = limited to production team)
- Run Phase: Let the platform figure out how to glue the runtime with the required
services, configuration.

16. V. Build, release, run Automate!
- Build phase: Continuous Integration (CI)
- Release Phase: Continuous Deployment (CD), Blue green deployment (deployment
slots)
- Run Phase: Config Server, Service Registry, Circuit Breaker, Self health monitoring,
Publish Monitoring Events and Metrics

17. VI. Processes Execute the app as one or more stateless
processes
- Don't keep state (Session state, shopping basket etc). State makes everything hard on
the cloud.
- Hot swapability is critical on the cloud for many reasons:
- Scaling up/down
- Cloud instances can be terminated any time for upgrades, capacity management etc
- Blue green deployment

18. VIII. Concurrency Scale out via the process model
- Many small processes rather than few large processes will help scale easily in a cloud
environment
- Lower cost, no waste
- Scale up/down intra-day or during specific events to handle load and optimize cost

19. VIII. Concurrency Scale out via the process model...
This does not exclude individual
processes from handling their own
internal multiplexing, via threads inside
the runtime VM, or the async/evented
model found in tools such as
EventMachine, Twisted, or Node.js. But
an individual VM can only grow so large
(vertical scale), so the application must
also be able to span multiple processes
running on multiple physical machines.
https://12factor.net/concurrency

20. X. Dev/prod parity Keep dev, staging, and production as
similar as possible
Cloud applications must be designed to go to production in hours or minutes rather than
days. Therefore it is critical to have similar setup in all environments. This enables release
automation, simplifies configuration and ensures the developer is aware of how the
application will be deployed and run in any environment.
This also ensures that you can have any number of environment types, for example dev[1..N],
QA[1..N], UAT[1..N] and so on.

21. IX. Disposability Maximize robustness with fast startup and
graceful shutdown
Cloud applications should startup quickly and be ready for termination with almost no notice.
This is the nature of a horizontally scalable cloud application.
This means you should minimize the processing you do at startup. Avoid caching data at
startup. Don't persist data locally. Any transactional consumption must be designed for
redelivery and be idempotent. For example if the application consumes a message from a
queue, the queue server must re-deliver the message if the application does not
acknowledge the message in a timely fashion.

22. XI. Logs Treat logs as event streams
In the cloud, application instances are ephemeral i.e., potentially short lived. So you cannot
rely on your logs being stored in a location you can access.
Streamed logs are challenging at first if you are used to logs from a process being present in
a single file chronologically. You need to build your search skills to narrow down to what you
are looking for.
There are many products that support log streaming like ELK or Splunk. ELK (ElasticSearch-
LogStash-Kibana) provides end-to-end setup for log streaming. Log events are indexed and
easily searchable in Kibana.

23. XI. Logs Treat logs as event streams
ELK Introduction and Demo
https://demo.elastic.co/app/kibana#/home

24. The Twelve Factors - review
I. Codebase
One codebase tracked in revision control, many
deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful
shutdown
X. Dev/prod parity
Keep dev, staging, and production as similar as
possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off
processes

25. Demo
- Create a Cloud Foundry web service
- Externalize Configuration
- Stream logs
- Bind a service
- Scale the app
https://pivotal.io/platform/pcf-tutorials/getting-started-with-pivotal-cloud-
foundry/introduction

26. More Factors! (not covered in this
session)
- API First
- Monitoring
- Redundancy - prefer redundant code and data
- Authentication and Authorization
- Beyond the Twelve Factor App:

27. Redundancy (briefly..)
Anti-patterns
- Foreign key overuse
- Large domain models
https://www.slideshare.net/ewolff/microservices-redundancymaintainability

28. Redundancy - prefer smaller, context
bound domain models
https://www.slideshare.net/ewolff/microservices-redundancymaintainability

29. Products and Techniques for Twelve
Factor Apps
- Service discovery: Netflix Eureka, Consul, Zookeeper
- Circuit Breaker: Hysterix
- Config Server
- GraphQL
- Password management: Hashicorp Vault
- Use NoSQL - it is naturally horizontal scale and suits cloud applications
- Let the cloud manage your processes i.e., scaling, restart on crash etc. All cloud
providers have these features

30. References
The Twelve Factor App
Microservices: Redundancy=Maintainability
Beyond the Twelve-Factor App
Pivotal Walkthrough