Fighting the “But it works for me!” syndrome

Even though TenTwentyFour¹⁰²⁴ is nowadays just as well using containers in staging and production environments, it all started out in development. Having previously used HashiCorp’s Vagrant in combination with Puppet to easily spin up and provision virtual machines for development use, we quickly switched out the still heavy-weight virtual machines for much more lightweight containers.

While the premise “Having the same environment in production, staging and on each developer’s workstation” stayed the same, the switch to containers has allowed us to start, stop and modify our development environments in mere seconds instead of several minutes. And even though we work with Puppet on a day to day basis at TenTwentyFour¹⁰²⁴, not everyone is equally at ease defining how their development environment should be provisioned.

The switch to docker containers and their Dockerfiles have allowed us to make defining and building, not only development but also staging and production environments, a breeze for our developers, empowering them to not only specify their code, but equally the entire eco-system in which it will run.

Avoiding dependency hell

If you have ever worked in Ruby or Python environments before the advent of tools like rvm, bundler, pip and virtualenv, you certainly experienced the pain of dependency hell. Some of your projects would be using incompatible versions of gems or eggs and while some of them would be available from your OS’ package manager, others had to be installed directly through the gem tool or Python’s easy_install.

While virtual environments, bundles or application-specific vendor directories changed the situation to the better in pretty much any programming language in use at TenTwentyFour¹⁰²⁴, containers allow us to go a step further, not only encapsulating library dependencies, but also services and their run-times, and even entire environments using virtual private networks.

Spinning up supporting services and applications inside of containers, instead of running them on the developers’ workstations allows us to keep a clean and stable environment, uncluttered by a myriad of different versions of databases, key-value stores, message brokers, web-servers, and so on…

The same goes for our staging environments. Quickly spinning up a service for demonstration purposes and bringing it back down without any remaining traces on the system has never been easier. You would like to see if tool X or application Y is the right thing for you? Let us compose a set of containers for you in a matter of minutes!

Micro-service architectures

Rather than monolithic megaliths, applications are increasingly build from several inter-connected micro-services. Load-balancers, databases, key-value stores, search-indexes, and the central application, all neatly wrapped up and communicating with one-another. Containers are the perfect environment for such architectures, as they allow to encapsulate each service in their own container while spinning up a virtual private network to link only those that need to talk to each other. All the while, individual containers can be easily swapped out for new versions or their number dynamically scaled up or down, depending on the current load.

Orchestration tools such as Kubernetes, deis or even swarm mode since version 1.12 of docker allow to quite easily spawn and automatically distribute your containers throughout several virtual machines or bare-metal servers – even across distinct data-centres, including automated service discovery and load balancing.

Dockerizing your infrastructure

Whether you’re a development company looking at migrating away from running heavy-weight virtual machines as development environments or a business running web services and applications, we can consult and support you in shedding weight, un-cluttering your servers, and containerizing your services. Get in touch with us to get started!