4. Criteria
• Maintainability
• How easy is it to maintain
the code?
• How easy is it to fix a bug?
• Monitoring
• How easy is it to monitor
solution health?
• Scalability
• How easy is it to add new
computin power and
handle heavier load?
• Updates
• How easy is it to update
solution to the newest
version?
• Onboarding
• How easy is it to get
onboard a new team
member?
6. - Application is built as a single unit.
- Components are interconnected and dependent on each ot
- Deploy all the app incase of any small change.
- Application is too large and complex to understand.
- Impact of any change is very high because it lead to test the
- If specific feature not working, the entire system goes dow
- Difficult to use new technology stack.
- Can’t scale specific component independently, entire app
A monolithic architecture is a model of software
structure that is created as one piece.
8. - Micro-service architecture is an approach to developing
- Each service is self contained and loosely coupled.
- Each service implement single business domain.
In other words, these services are small, highly decou
10. - Better testability.
- Easier to build, maintain and enhance the micro-servi
- Better team organization.
- Independent deployment.
- Better fault isolation (failure in one service does not impac
- Flexibility in using technologies.
- Easy to understand since they represent a small piece of fu
- Better scalability.
14. What is 12 factor App?
- The 12-factor app methodology specifically created for building scala
- This is derived by Heroku.
- Read More @http://12factor.net/
Why 12 factor App?
- Good code fails if you don’t have a process, complexity increase if yo
15. 1-Codebase
- One code base many deploys (deploy is running instance of the
app).
- Single root repo , don’t share your code with another app.
- Shared code between multiple apps should be separated in
another codebase.
16. 2-Dependencies
- Explicitly declare and isolate dependencies.
- Never relies on implicit existence of system packages.
- All app dependencies should be declared in dependency declaration m
- Dependency declaration manifest in PHP is composer.json
And the dependency management tool is Composer.
- Twelve-factor apps also do not rely on the implicit existence of any sys
17. 3-Config
- Config is everything that vary between deploys(dev, stage, production
- Config belongs to the environment not the App.
- Config should be stored in the environment variables.
- Apps sometimes store config as constants in the code. This is a violatio
- You should can make your app open source at any moment without co
18. 4-Backing Services
- Any service the app consumes over the network as part of its normal o
- Examples: messaging/queueing systems, Database store, cache system
- Treat backing services as attached resources.
- Should be accessed via URL in the config.
- Make no distinct between local and third parity services.
- A deploy of the twelve-factor app should be able to swap out a local M
19. 5-Build, release, run
- A codebase is transformed into a deployment in 3 stages:
1-Build: convert the code to executable bundle known as build
(In Golang build results binary executeble file)
2-Release:take the build and combines it with deploy config.
3- Run : runs the app in the execution environment (also known as “run
20. 6-Processes
- Processes should be stateless and share no thing.
- Any data that needs to persist must be stored in a stateful baking serv
- For example, downloading a large file, operating on it, and storing the
- Session are a violation of twelve-factor.
21. 7-Port Binding
- Export services via port binding.
- One app can become a backing service for another app.
22. 8-Concurrency
- There are two types of scaling vertical )adding more resources( and h
- You should be able to scale out(horizontally) and distribute the load b
23. 9-Disposability
- Your app should be quick to Strat up and graceful to shout down.
- Quick to start up means app ideally take few seconds to startup.
- Graceful to shut down means when the app receive a SIGTERM (term
- If server die we should replace it and start another one quickly.
24. 10-Dev/prod parity
- Keep dev, stage and production as similar as possible.
- Historically, there have been substantial gaps between development a
- • Make the personnel gap small: developers who wrote code are closely involved in deploying it and w
• Make the tools gap small: keep development and production as sim
25. 11-Logs
- Logs provide visibility into the behavior of a running app.
- Treat logs as event streams.
- It should not attempt to write to or manage log files. Instead, each ru
- each process stream will be captured by the execution environment, a
26. 12-Admin processes
- Admin processes such as db migration and cron jobs should be run a
- Run in another container (not the same container that handles user r
