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!