Scaling App
Future Proof Application 101
First, there was chaos
Application, back in the day
Massive sized (thousands of LOC), built to run on edge stations under specific configuration, with manual deployments that take hours, come with huge risk and require tons of man-hour for manual testing and bug fixing
The tale of the wise-man summit
Aka: The Agile Manifesto
All hail SaaS, our saviour
with his loyal friend, Open-Source
- Deploy changes without downtime
- Reliably roll back changes if they’re buggy
- If a server fails (which they will do) replace them before your customers notice
Our Goals
The Twelve Factor App
Originaly by:
An outline for building well structured and scalable applications
described as
I. Codebase
- Codebase must be tracked in version control
- One codebase per app
- Extract libraries for common code used in different codebases
One codebase tracked in revision control, many deploys
No toe walking within the repository
II. Dependencies
- Never rely on system wide package
- Declare and isolate dependency
Explicitly declare and isolate dependencies
It simplifies setup for developers new to the app, as for the deployment setup
III. Config
- Config which is varries across deploys
- Config should be separate from app
- Use environment variables for that
Store config in the environment
Allows using the same deployment process for all environment, demanding only different configs
IV. Backing services
- Resources which your app consumes (MySQL, RabbitMQ, Twitter API)
- Both local and remote should be treated the same
- Can be attached and dettached any any point of time
Treat backing services as attached resources
Allows using the same deployment process for all environment, demanding only different configs
V. Build, release, run
- Build: a transform which converts a code repo into an executable bundle known as a build.
- Release: takes the build produced and combines it with the deploy’s current config.
- Run: Runs the app in the execution environment.
Strictly separate build and run stages
Separation of concerns for a shared understanding of the pipeline
V. Processes
- Make runtime environment stateless
- Use filesystem/localhost cache only for temprary store (single transaction)
- Store persistance data in a stateful backing storage service (e.g. database/ message queue...)
Execute the app as one or more stateless processes
Treat the instance of your app as desposable
VI. Port Binding
- Expose the app through a port (http/ xmpp...).
- Treat your app as a backing service for another app.
- Usually easy to acheive
Export services via port binding
Make your app reachable
VII. Concurrency
- Isolate the thread in the application
- Allows fanning out the application if more scale is required.
- Make small part independent
Scale out via the process model
Do it the linux way
IX. Disposability
- Aim for starting fast.
- Shutdown gracefully. Be robust to crushing.
Maximize robustness with fast startup and graceful shutdown
Like the mushrooms after the rain
X. Dev/prod parity
- Keep a developer’s local environment as similar as possible to production
Keep development, staging, and production as similar as possible
Make developers know how to deploy
XI. Logs
- Stream of events that we need to combine to single location so that we can index and analyse later.
Treat logs as event streams
Know your data!
XII. Admin Processes
- Any administrative thing (such as database evolotions) should be treated as a one-off processes occurring during the deploy.
Run admin/management tasks as one-off processes
No manual processes!
Scaling App
By Boaz Berman
Scaling App
Future Proof Applications 101 (or 12-factor app overview)
