© Copyright KodeKloud

12 Factor App

© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 Fast forward to today!

© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 DEMO – Cloud Provisioning

© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 https://12factor.net/

© Copyright KodeKloud
So that's you, and that is your idea. You build an application to get your idea out to the world. Traditionally, you have to go through hoops
and hurdles to get your idea out to the world. It would take you days, weeks, or even months to order and receive a server to host your
application on.
And eventually once you get a server to host your application on, you were dependent on that server for the rest of your life. Your application
and your server were married for life. He wrote code that could only live on that server. It couldn't live on other servers, and if you had to
scale, you would scale resources on that server. You even
stored session information on that server. If the user was in the middle of something and your server crashes, everything that the user did
until that point was lost and they had to do all of that all over again.
Your app was tied to that server for life. Fast forward many decades to today. We're living in the world of high growth startups that see user
growth from zero to millions in a matter of few months.
Going from an idea to execution only takes as much time as you need to develop the code for it. Provisioning and hosting can be achieved in
a matter of hours, if not minutes. Most cloud platforms today can provision servers and other resources in a matter of minutes,
and most of the time, you don't even need to worry about provisioning a server. With PATH and serverless technologies, you can simply
write code and push and you're done. Today's platforms are expected to be up 99.999 percent of the time, meaning there is no time to take
down the application for any reason whatsoever, meaning there is no time to take down
the application for patching servers or adding additional resources or scaling. For this to happen, your application needs to break free from
the underlying infrastructure. This way, you can host your application anywhere you want, be it on-prem or GCP or AWS or Azure,
and that's known as portability to be able to run the same app on different environments without having to change the source code of the
application. When it comes to scaling. In the past, you had to take down your application to add additional resources to your server. That
was referred to as vertical scaling. Today you provision more servers and run more instances
of your application. To summarize, modern applications need to be portable and as such must not be tightly coupled with the underlying
infrastructure. They should have minimal divergence when deployed between dev test and prod environments to enable continuous
deployment and must be easily scalable by spending many instances at once and it must be suitable for deployment on modern cloud
platforms. In order
to achieve this, your application needs to be developed keeping certain principles in mind. About a decade ago, engineers from Heroku put
together 12 factors that needs to be considered when building modern applications, and these are known as the 12 Factor app, and that's
what we will see with examples in the rest of this video.
These are also documented at the 12 Factory dot net website.
© Copyright KodeKloud
© Copyright KodeKloud
 I VII
Codebase Port Binding
II VIII
Dependencies Concurrency
III IX
Config Disposability
IV X
Backing Services Dev/prod parity
V XI
Build, release, run Logs
VI XII
Processes Admin Processes
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 I
Codebase

© Copyright KodeKloud
 Git Github Gitlab Bitbucket

>_ >_

$ git pull $ git push

© Copyright KodeKloud
 ☝️ Multiple apps sharing the same code is a violation of twelve-factor.

© Copyright KodeKloud
© Copyright KodeKloud
 dev

staging

prod

© Copyright KodeKloud
The first rule is the 1.code base
When working on a application like you are working on this single flask applicaion which says a greeting message when open in browser.In feature
the requirment increases and with new features so you include more developers in this developing
so like multiple developers working on it the are copying the code to a central locaotion so it can create conflicts.Like every developer its on copy of
code make many copies of code
So there must be a centeral from where they can pull and push the code So the Git is the solution.
You can pull the code and puch the changes made by every develpery and it is marged after promiting
and if in feature You have multiple applicaion as part of the same application like payment and delivery serrvice
So
☝ Multiple apps sharing the same code is a violation of twelve-factor.
They mist be in sperate code base
© Copyright KodeKloud
 II
Explicitly declare and isolate
dependencies

© Copyright KodeKloud
 >_

$ pip install flask

© Copyright KodeKloud
 ☝️ A twelve-factor app never relies on implicit existence of system-wide packages.

II
Explicitly declare and isolate
dependencies

© Copyright KodeKloud
 >_

$ pip install flask

© Copyright KodeKloud
>_ >_

$ pip install flask $ pip install –r requirements.txt

© Copyright KodeKloud
 II
and isolate
dependencies

© Copyright KodeKloud
 flask==2.0.0 flask==1.9.0

>_

$ curl

© Copyright KodeKloud
 flask==2.0.0 flask==1.9.0

© Copyright KodeKloud
 >_

$ docker build ....

© Copyright KodeKloud
 >_

$ docker run ....

© Copyright KodeKloud
Explicity Declare and isolate dependencies
What that mean?
As your applicaion build in flase it needs the flask python dependencies and a specific version of flask like version 2.0.0 and it is installed on Your compuer
according to 12 factor
☝ A twelve-factor app never relies on implicit existence of system-wide packages
.Explicity Declare and isolate dependencies
Like delcrae all the dependencies in a seprate file so it can cause any problem and developer must able to install all the dependencies using this file not its self in
case of Python it can be declared in a file 'requirment.txt' and can install using the command
ok but what is isolate dependencies?
Lets say You have two applicaion like payment and also delivery the one applicaion both developed in flask but in different versions so how can you run these
applicaion on the server ot on you single laptop THis can be achived using 'Python ven' where You can install both dependencies in a isolated envirnoment
but what like we wants a specifice version of curl for bith applicaion?
So containerizing come into picture where YOu can run as many applicaion as You wants with its own dependencies and own operating software and with the
specific
os software
 Docker Course & Labs Demo

© Copyright KodeKloud
© Copyright KodeKloud
 III
Config

© Copyright KodeKloud
 VIII
Concurrency

© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 Load Balancer

© Copyright KodeKloud
 VIII
Concurrency

© Copyright KodeKloud
Now our applicaion is running in a deocker container but what when the load increses on the applicaion
as we discussed we can scale up our application so we can scale up but for this we have t down our
applcation and it cause no user can access our applicaion
So we can run many instances of our applicaion and shift the load to the other instances before
upgrading one this can be done gracefully using Load balancers
So the processes are the first class citizen in 12 factore you can scalse up your applicaion horizantaly
not vertically
So you can scale up your applicaion concurrently
processes:Every instance of application running in a docker container is a process
© Copyright KodeKloud
 ☝️ Twelve-factor processes are stateless and share-nothing.

VI
Processes

© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 visitCount=0 visitCount=2 visitCount=1

© Copyright KodeKloud
 Sticky Sessions

visitCount=0 visitCount=2 visitCount=1

sessionInfo

© Copyright KodeKloud
 ☝️ Twelve-factor processes are stateless and share-nothing.

☝️ Sticky sessions are a violation of twelve-factor and should never be used or relied
upon.

VI
Processes

© Copyright KodeKloud
 visitCount=0 visitCount=2 visitCount=1

sessionInfo

© Copyright KodeKloud
 visitCount=0 visitCount=2 visitCount=1

sessionInfo

© Copyright KodeKloud
© Copyright KodeKloud
12-factor processes are stateless and share nothing. Let's see what that means. We have decided to add a new feature to our app
to show visitor count on our website. Every time a new visitor visits our page, we'd like to show the total visitor count like this.
For this, we update our code to include a visit count global variable and increment it each time a request comes in. And that
works well when we have one process running. Because the visit count is stored in the memory of that process.
When we run multiple processes, they all have their own version of this variable stored in them. And as such, it displays
different numbers for different users depending on which process serves those users.
The same is true for other details as well, such as user session information. When a user logs into our website, we store certain
session information about that user, such as where that user logged in from, when the user's login expires, etc.
This session information is needed on the server to keep that user logged in. But if this is stored in the process memory or locally
in the file system of that process, then when a future request of that user is directed to another process, the user may be
considered logged out as the session information isn't available there.
Now, there are load balancers that are session aware and can redirect users to the same process each time. And this is called
sticky sessions. However, that is still going to be an issue if for some reason the process crashes and all locally stored data will
be lost then.
Which is why 12-factor processes are stateless and share nothing, and sticky sessions are a violation of 12-factor and should
never be used or relied upon. Which is why we must not store anything in these processes.
Instead, it should all be stored in an external backing service. This way, all data and session information is stored in a place that
can be easily accessed by all processes. And it doesn't matter which process a user is routed to, it's as if all requests are handled
by the same process as all processes now have access to the same set of data.
The external service could be a database or caching service like Redis. So we modify our code to store visit count to a Redis DB.
This change now allows us to run as many instances of our application as required, while ensuring store nothing locally and
enabling all instances to point to the same count.
© Copyright KodeKloud
 IV
Backing Services

© Copyright KodeKloud
 ☝️ Treat backing services as attached resources.

© Copyright KodeKloud
© Copyright KodeKloud
THe backend services are always trated as a attached resoure
Means it does matter where the backend services hosted lije redis on cloud or on prem they must be trated as
attached resource
© Copyright KodeKloud
 III
Config

© Copyright KodeKloud
© Copyright KodeKloud
© Copyright KodeKloud
 ☝️ The twelve-factor app stores config in environment variables.

III
Config

© Copyright KodeKloud
 dev

staging

prod

© Copyright KodeKloud
As you noticed the redis data base name redis-db and port is hardcoded in the app coed.We
should have to keep them seprate in the env files py.eny the python interpretter auto matically
loads it as and envirment variable file the benefit is that you can set configiurration seprate
fo each deb prod staging envirnoment with out changing the code
© Copyright KodeKloud
 V
Build, release, run

© Copyright KodeKloud
 🤦‍♀️

© Copyright KodeKloud
 🤦‍♀️

© Copyright KodeKloud
 ☝️The twelve-factor app uses strict separation between the build, release, and run
stages.

V
Build, release, run

© Copyright KodeKloud
 flask-app-test:v1

flask-app-test:v2

flask-app-test:v3

flask-app-test:2023-02-25-09-52

flask-app-test

flask-app-test

app.exe

./app

>_

$ docker build

1. Build 2. Release

© Copyright KodeKloud
 flask-app-test:v1

flask-app-test:v2

flask-app-test:v3

flask-app-test:2023-02-25-09-52

flask-app-test

flask-app-test

app.exe

./app

>_

$ docker build

1. Build 2. Release 3. Run

© Copyright KodeKloud
 ☝️The twelve-factor app uses strict separation between the build, release, and run
stages.

V
Build, release, run

© Copyright KodeKloud
here is a typo in the code KodKloud.this is because of the last canges in the code which are commited in.But this is a
small typo but in large envirnoment it is not esay likee you commit the code and then it comes to other stages like
testing,building and others
When you write a code like in vs code it should be converted first in extuable form like ..exe and docker developed
image can be build using docker run this is called build

Release= Configfile + .exec file(docle image) called Release

when run the application this is calledrun phase
So there is a speration betwaenn every stage this isthe 12 factor 5 rule
© Copyright KodeKloud
 VII
Port Binding

© Copyright KodeKloud
© Copyright KodeKloud
 5001 5000 5002 6379

© Copyright KodeKloud
 ☝️The twelve-factor app is completely self-contained

VII
Port Binding

© Copyright KodeKloud
As we access our application by typing the url and the port number in the browser it is sample our app is running on http
and running on the default port 5000.
in container we can bind seprate port to each container so the 12 factor rule say not to rely on the server default port
© Copyright KodeKloud
 ☝️ The twelve-factor app's processes are disposable, meaning they can be started or
stopped at a moment's notice.

IX
Disposability

© Copyright KodeKloud
 >_ >_
$ docker stop .... $ docker stop ....

© Copyright KodeKloud
 ☝️ The twelve-factor app's processes are disposable, meaning they can be started or
stopped at a moment's notice.

☝️ The twelve-factor app's processes should shutdown gracefully when they receive a
SIGTERM signal from the process manager.

IX
Disposability

© Copyright KodeKloud
 >_

$ docker stop ....

SIGTERM

SIGKILL

© Copyright KodeKloud
As when the load increases the applicaion can be sacle up in metter of seconds same when the load decreases the application
stop the instances as like that.
Like whne a docker Container stops a container it sends two signals SIG-Term SIG-Kill
why two signals
The first signal if the container completing the request iof the users who requested and due too sig-term signal it not takes
more requests
and if the applicaion not stops then it forcefully stoped by Sig-Kill signal
© Copyright KodeKloud
 X
Dev/prod parity

© Copyright KodeKloud
 dev

staging

prod

© Copyright KodeKloud
 Time Gap Personnel Tools Gap
Gap

dev
Developer

staging

prod
Days Operations
Weeks

© Copyright KodeKloud
 ☝️ The twelve-factor app is designed for continuous deployment by keeping the gap
between development and production small.

☝️ The twelve-factor developer resists the urge to use different backing services
between development and production.

X
Dev/prod parity

© Copyright KodeKloud
 Time Gap Personnel Tools Gap
Gap

dev
Developer

staging

prod
Hours
Days Developer
Operations
Minutes
Weeks +
Operations

© Copyright KodeKloud
As the application is build and deployed in different env
Dev:Applicaion tested after making
Staging:prod like env
Prod:the env where the user can access the application
So theer is a huge gap the application takes so much time to come in prod in the mean while the additional changes made by
developer so it can csuse conflicts and also may be tools are different used in env os it is a hard task to deploy the
applicaaiot on Prod

But todays with the tools like docker these taks are simple and with the tools of CI/CD these task are easy and the
applicaion live much faster then before
© Copyright KodeKloud
 XI
Logs

© Copyright KodeKloud
© Copyright KodeKloud
 LogFile.txt LogFile.txt LogFile.txt

© Copyright KodeKloud
 ☝️ A twelve-factor app never concerns itself with routing or storage of its output
stream.

☝️ Store logs in a centralized location in a structured format.

XI
Logs

© Copyright KodeKloud
 STDOUT STDOUT STDOUT

Logs Agent Logs Agent Logs Agent

© Copyright KodeKloud
Applicaion output certain logs abut the errors and also user requests so the logs are important but when the container killed
theses logs also removed so we can attach a solution like fluentd to store the ;logs to the centrel location but our app is stuck
to a single solution and it is tightly couples with our app so it in dis courged
so the logs first converted into standard output then sent to a servi e like fluend
© Copyright KodeKloud
 XII
Admin Processes

© Copyright KodeKloud
 visitCount=8K

© Copyright KodeKloud
 visitCount=8K
visitCount=0

© Copyright KodeKloud
As our applicaiont use redis data base and count the number of user lets say we come to know
that this number is not correst so we have to reset the app.So the 12 rule state that the admin
tasks are run as a seprate processes.
© Copyright KodeKloud