Replify & Docker
As we have been working to dockerize our application stack, several features have captured our own attention as having significant value. Many of customers are familiar with our use of Erlang in much of our code base. This provides carrier grade resilience to application faults that can be restarted gracefully and this is mission critical for our partners. In a traditional Virtual Machine, other mechanisms were required for managing the health of the VM and restarting it if there were operating system or dependency issues.
With Docker, a fault can be detected, reported, and automatically restarted to mitigate issues of that nature. Docker comes with the ability to define restart policies and what action to take on subsequent failures. This increases the resilience that ships with our product.
The memory footprint of our stack can be heavily dependent on the number of clients and the cache supporting each. In a VM, there is not an easy way to contain the memory usage of processes in general. With Docker, a cap is defined and can be adjusted without re-provisioning. This contains the application to the allocated resources and allows for triage to occur at the application level, not the OS level.
There are many open source libraries that Replify leverages in order to best support user needs. One in particular is OpenSSL. The last couple of years has revealed some significant security issues that required immediate attention. While this makes sense for the community at large, a more methodical rollout during maintenance windows is expected in carrier environments. The community can rollout new libraries overnight. This has the potential to become service impacting where rollbacks aren’t ideal and both teams scramble to patch in new support. With Docker, the libraries on one image is contained from the next. No more dependency conflicts, no more unexpected incompatibilities, less midnight alerts, higher uptime!
The Operating System of choice for the Replify team has been Debian for some time. As our customer base has grown, we have expanded our efforts to support our software on FreeBSD, RHEL, CentOS, OpenWRT, Raspbian, and other Linux variants. For a Systems Administrator, the differences may seem trivial.
For a Developer, compiling software with the complexity of our own can be daunting and time consuming. This can be frustrating for new releases, library management, documentation management, etc. Likewise, customers that prefer and officially support one distribution have increase support costs and training to manage our software on Debian. Docker eliminates this altogether.
While yes, the Docker Image uses Debian as a base, the Docker Container can be spun up on a CentOS Docker Host with no differences. Delivering and supporting a Docker Image brings teams on both sides closer together and makes the promise of Continuous Integration much more achievable.
File System Expansion
As a customer grows, we hope they monitor resources like disk space accordingly. We have monitoring information available on our dashboard but the demands of a data center often distract Operations from the most basics aspects of running a healthy environment. It happens. The disk space allocation of a VM has to be rigidly defined. Using thick provisioning performs better when the cache grows, and thin provisioning can help prevent over allocation of the disk subsystem where one VM does not need to grow to its full capacity immediately.
Replify has addressed this in the past by requiring a second disk of the customers choosing for storing the variable data such as cache. The Docker storage driver does not require fixed disk space and Docker containers can grow as required and attention can be focused on the Docker Host.
Now in a Docker environment, the Replify software can take advantage of the Docker Host disk subsystem with minimal overhead and less maintenance.
When integrated into core service offerings, the Replify software can still benefit from other technologies residing locally. For instance, we see more providers leaning on Public DNS infrastructure from Google, Level 3, Verisign, OpenDNS, and many more. Sure, this has eliminated some maintenance and security obligations at the local ISP, but there is a cost. Users still have some latency to get to these Tier 1 Data Centers and 50ms adds up.
One micro service Replify has chosen to integrate with our Docker Image is dnsmasq. DNS caching is critical to a well-designed Wan Optimization solution. Now it’s included! Other micro services may be of value to you and now there is a framework to capture joint effort in code that we can help deploy.
On a traditional Virtual Machine, any one of many configuration files for basic Operating System functionality could be fat fingered. We’ve all done it. Open a file in vi and the lack of caffeine invokes a paste where you meant a copy. Before you can back out, the damage is done. Wouldn’t it be easier to just restart the application and restore the one file from a backup versus figuring out why the Virtual Machine won’t boot now? Yes it is! Docker’s architecture results in an Image that is made up of read-only layers. You can literally restart the container, and optionally purge your changes, to get back up and running in seconds, not minutes.