Docker Containers and the Nanobox Development Platform

People new to Nanobox often ask us questions similar to this, “How does Nanobox differ from Docker?

tldr;####

  • Docker is hard to use; Nanobox is easy
  • Nanobox uses Docker, so you don’t have to

If you're a web developer, and that's all you wanted to know....off you go to our getting started guides, where you can choose your language of choice and get started!

The rest of this article addresses the Docker/Nanobox question, including historical and technical context pertaining to the evolution of both Docker and Nanobox. It also addresses various aspects of the current state of the industry through the lens of our experience at Nanobox.

First, A Simple Analogy####

Docker is a transmission.

Nanobox's runtime is an engine.

The Nanobox platform is a car you can drive, one that uses a power train (transmission and engine) that you don't have to worry about because it's rock solid.

How are Docker and Nanobox Different?####

The short answer to the question about how Nanobox differs from Docker is this: Nanobox was built to allow developers to accomplish things they simply can’t do with Docker alone, at least not without extensive training and lots of manual work. Nanobox is intended to be used by that group of engineers focused mostly on web development (a segment that constitutes almost 73% of developers according to the 2017 Stack Overflow Developer Survey). These developers are not usually trained to be infrastructure experts. Instead, these are people who simply want to write code that efficiently makes its way from development to a healthy production setup.

2017 Stack Overflow Survey - Developer Types######

In addition to what it does for organizing and streamlining the local dev environment, Nanobox essentially turns developers into devops experts by automating what usually looks to them like infrastructure overhead.

Docker is much more commonly used by people who have spent considerable time developing devops experience, and whose primary focus does not involve coding applications.

Docker’s Rise to Prominence####

Docker’s arrival on the virtualization scene four years ago with its magically mature container paradigm brought a degree of portability to development and other application environments (testing, production, etc.) that attracted the web development world en masse, much of whom came together to use and contribute to Dockers' open source solution for the ultimate benefit of the entire community.

Docker quickly became the world’s leading software container platform, solving many of the environment portability problems for developers facing the ever-present “it works on my machine” collaboration dilemma, as well as providing a way for devops to run apps side by side in testing and production environments with more efficiency.

Nanobox’s Relationship with Docker####

At Nanobox, we have followed the Docker story closely. Our own story has lots of overlap with the technical landscape out of which Docker was born. In fact, Nanobox uses Docker under the hood for container implementation, not because we engineered our development platform to be simply an extension of Docker, but because the containerization workflow standardized by Docker has come to represent what is generally accepted as the most practical way of organizing dev, testing and production resources. Instead of reinventing what Docker does, we plugged Docker into our own development platform.
Native Docker container installation for Nanobox

During the years that the current Docker containerization workflow was forming out of the collective knowledge base of developers, devops, Linux system admins, and other IT contributors, the Nanobox team was working to address efficiency limitations that have consistently slowed web application development over the past decade. Our approach to empowering developers considers both technical elements as well as the less technical ones, such as the work relationships between developers and their peers and managers and their dev team members. We’ve been fortunate to piggyback some of our platform on the powerful container workflow created by Docker and its collaborators - including companies such as Cisco, Google, IBM, Microsoft, and Red Hat.

Before Docker####

Before Docker came along, application environments were as unique as the myriad options for setting up a Linux installation. Everything needed to run an application would be setup on a Linux installation. Variation among the popular Linux flavors (e.g. Ubuntu versus Red Hat) added more inconsistency. The processes for installing everything needed for any particular web apps was always different. There was no consistency.

As the need increased for web apps resource efficiency, the development of the containerization concept happened rapidly. The movement towards containerization made it so that it would be possible to isolate resources to avoid collisions and conflicts among processes running on a server.

Before Docker, the workflow for implementing containerization was far from standardized.

Before Docker, developers and IT team members (especially designated infrastructure engineers) used various approaches to containerization and virtualization that have all (to a large extent) been replaced by Docker. Over the past several years, discussion about container technology has shifted from how to use LXC, OpenVZ, RKT, BSD Jails, Solaris Zones, and cgroups to increasing understanding and use of Docker’s solution. Docker has obviously helped that trend by providing several training programs to assist its growing audience with adoption.

The Nanobox team was using many of these containerization technologies long before Docker officially existed. When we created our development platform, we ultimately chose Docker because it’s the most advanced container management system on Linux, and because Docker image distribution is stellar. The Nanobox platform implemented our plan to empower developers, and Docker fit right in to that plan.

What Can You Do With Docker?####

Those who want to know how Nanobox differs from Docker are typically familiar enough with Docker to understand at least at a high level what Docker does. To draw a comparison between Nanobox and Docker, I will quickly summarize what people use Docker for.

Obviously, the Docker product offering is consistently evolving to meet the dynamic needs of the community it serves. Fundamentally though, here is what Docker gives you:

Portability: the ability to create an image that can be run on any Linux distribution

Process isolation: processes run in isolation from other processes to avoid collisions, which cause weird, unexpected behavior

Simplified workflow: Docker simplifies workflow that would otherwise be cumbersome and time consuming

These core value propositions make Docker appealing enough that it’s been adopted by 94% of companies surveyed by DevOps.com and ClusterHQ. It’s safe to say that if a company is using containers for creating production environments, it is almost always using Docker.
Docker Container Use Survey Devops.com and ClusterHQ

The Docker Way and the Nanopack Manifesto####

Here's how Docker and Nanobox differ, both ideologically and in practical use.

Ideology

There is an ideological difference between Nanobox and the Docker way that must be understand, although it may seem subtle and possibly not relevant to the practical differences.

Nanobox’s own Nanopack manifesto varies a bit from the Docker way, which is very opinionated, especially on these points:

  • 1 process per container
  • this single process running within the container handles logging to stdout
  • a container’s life should only be as long as the process within it
  • the Docker daemon should be the process supervisor - don’t run a process manager like runit/upstart/systemd/etc within a container
  • if data needs to persist, put it in a volume

The Docker way forces the larger system (platform, provisioning engine, distribution, hypervisor, etc) to adhere to a very strict specification that breaks down quickly when doing anything within containers that isn’t a simple, straight-forward “compute” process. In our decade of experience running real, large-scale production infrastructures and mission-critical apps, the Nanopack manifesto is much more suiting. In fact, the Nanopack manifesto was created directly from our experience taking on and solving those practical, real-world problems.

Here is an example that illustrates why Nanobox departs from the Docker way.

Databases often have multiple logs for various functions: a general log, an error log, a slow query log, a replication log, etc. Piping all of those log files to stdout forces us to run another process inside the container for tailing those files and piping them to stdout, thus violated the single process per container rule in the first place.

Not to mention, munging all of those logs into a single stream is messy.

Also, most databases will spawn multiple child processes to handle the work, and without a process manager, there is nothing to reap those children when they break away from the parent.

This is one of multiple example scenarios that demonstrate the necessity by Nanobox to split from the strict path understood to be "the Docker way".

Practical Differences####

The simplest way to describe the difference between Docker and Nanobox is point out that since Docker acts as simply the container component (not downplaying its role in any way) of Nanobox, there is additional functionality provided by Nanobox that goes beyond what Docker provides.

Docker is a container methodology. Nanobox is a local dev environment, an automated deploy solution, and a production monitoring and management platform that makes use of Docker containers.

The differences between Docker and Nanobox can also be understood by looking at what technology roles normally use Docker versus those that use Nanobox

What roles normally use Docker?

  • Devops
  • Other IT personnel responsible responsible primarily for infrastructure

What roles normally use Nanobox?

  • Web developers who want to spend their time coding
  • Devops and infrastructure specialists who want to be more productive by automating routine aspects of infrastructure

Nanobox Functionality Not Provided by Docker####

The following list highlights just a few of Nanobox’s capabilities that distinguish our platform from Docker.

With Nanobox:

  • Run an application inside of multiple containers locally
  • Easily add DNS aliases for convenience
  • Bind Docker network to host network so you can access app running on your local machine
  • Use automatic environment variables that represent the various components of your app
  • The environment shuts down when you’re not using it.
  • You can deploy to any cloud
  • It’s easy to resize servers
  • Simple migration of data from one server to another
  • Get aggregated logs collated into a single location
  • Team management
  • Automated deployment rollbacks

In addition to the items on this list, we have published a collection of value propositions that highlight many of the other differences between Docker and Nanobox.

Conclusion####

We’ve looked at the ways in which Docker and Nanobox are clearly different. For some organizations, it makes sense to interface at a low level with Docker directly and employ devops personnel to take advantage of elements of the power and flexibility provided by Docker, using orchestration tools like Kubernetes to accomplish what their application infrastructure requires.

Nanobox is intended to be used in organizations who are more inclined to automate as much as they can of environment configuration and devops activities for the sake of being lean and efficient.

Posted in Nanobox, Docker, Containers