In the past we would often treat a server as a machine which has a variety of roles. A single server may be responsible for serving web content, email, processing background jobs, and even hosting a database system. Your application is really only one of the many things that runs on that machine.

Scaling with a traditional server model is hard. Adding a new machine takes
time to provision. Those machines may store application data directly on their
storage devices, including log files. It becomes more difficult to manage as
your deployment infrastructure grows larger.

A more modern approach is to use many virtual machines, containers, or even
physical machines that serve a single purpose. This architecture will allow an
application to scale horizontally without requiring lots of extra effort. If
your application follows the 12 factor principles then scaling will be much
easier and your app will be ready to run in a modern infrastructure.

12 Factor Apps

The Twelve-Factor App is a set of guidelines which
provide an outline of factors for application architecture which will allow a
modern web application to scale with minimal friction and extra effort.

The Twelve Factors

1. Codebase
One codebase tracked in revision control, many deploys
2. Dependencies
Explicitly declare and isolate dependencies
3. Config
Store config in the environment
4. Backing Services
Treat backing services as attached resources
5. Build, release, run
Strictly separate build and run stages
6. Processes
Execute the app as one or more stateless processes
7. Port binding
Export services via port binding
8. Concurrency
Scale out via the process model
9. Disposability
Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity
Keep development, staging, and production as similar as possible
11. Logs
Treat logs as event streams
12. Admin processes
Run admin/management tasks as one-off processes

Containers!

Using containers can be a great way to package, distribute, and run your
12 Factor application.

Why use a container? The analogy frequently used is to compare your application
to the shipping industry. It is complicated to ship objects of varying size and
shape — same with software. Wrapping your application up in a container is
similar to putting all kinds of items into the large metal shipping containers
that are loaded onto ocean freighters. To the ship it doesn’t matter what is
in a container: they just load up with containers and do their thing. The same
goes for running software containers!

Docker

Docker is the most popular container solution. It initially built on top of
LXC but now uses its own libcontainer. Docker
focuses on being a standard format for linux-like containers. The Dockerfile
makes it super easy to define a container for your application. This removes
much of the pain typically associated with building a script or image to
provision a new machine or instance for a specific role. Builds happen
incrementally so that the image building process only needs to run the steps
which changed.

A basic Dockerfile for a Ruby on Rails application may look something like
this:

[code lang=text]
FROM ruby:2.2.2
MKDIR /app
WORKDIR /app
ADD Gemfile Gemfile.lock /app/
RUN bundle install
ADD . /app
CMD bundle exec rails s
[/code]

Each line can be considered a step. A snapshot image of each step is cached
so that they only need to run if there was a change in the prior step. The
reason we add the Gemfile before the rest of the app is so that your gems
don’t need to be reinstalled for application code changes, only changes to the
Gemfile itself.

Conclusion

This was a brief overview of the ideas that are used for building modern web
applications to ensure their scalability. Lightweight containers can help us
package our applications and their dependencies for easy deployment to cloud
platforms, physical servers, and even developer machines. Containers help
insure dev/prod parity so we can focus on building high-performance software
rather than worrying about the nuances in different environments.