Recently at Outlandish there has been a push to introduce containerisation technologies into our projects, both old and new. The main reason for this shift was a desire to reduce the time spent getting setup on a project for the first time, which, as experience has taught us, usually takes a few hours but can often take over a day. While on-boarding is a hassle for many projects at Outlandish, as well as for companies the world over, it is just one of many reasons for the decision to start using Docker as a core software.
Docker is one of the newest and most widely implemented containerisation software packages currently available, and has therefore become the software of choice for Outlandish. For those who are unfamiliar with containers, they essentially work as a series of lightweight virtual machines that can be created on demand using pre-defined images. The containers then work together to run an application. In the case of Docker, these images and how they are built are defined by a set of Dockerfiles, each one encapsulating a different area of the project, for instance the web server, database, redis, etc. A tool called docker-compose then allows users to define how these containers work together, using a YAML docker-compose file.
The result of our pursuit is an easy to replicate, easily scalable development environment containing no more than the required software that can be spun up on any machine that can run Docker. The benefits of this are not just for the developers at Outlandish, but also have potential implications for the wider development community, including our collaborators in CoTech and the wider open source community, as well as our designers, our project managers, and, by extension, our clients.
“It’s taking me ages to get this project up and running!”
The most immediate benefits of the move to containerisation are seen by new developers to a project. If you consider that our work sprints are usually 2 weeks in length, losing a day just getting a project setup for new developers means potentially losing 10% of the development time if they are they only developer for that sprint. (In practice it often also involves input from a more senior dev, thus increasing their workload and/or reducing their output.) If you are as unlucky as I have been in the last year and your computer has had a catastrophic breakdown on multiple occasions requiring a fresh OS reinstall, or if your company makes use of hot-desking with fixed desktop computers that don’t have the same core setup, this same issue can be repeated multiple times throughout the project life cycle.
Here, the onus is usually on the development team to take meticulous notes whenever specific problems are spotted and can then be documented, and then that documentation must be very closely followed by those same (or new) team members – while developers often have the best intention and know the frustration of documentation that is lacking, these jobs add more non-development work to the existing workload and often slip through the net.
Ensuring that the start-up process is as simple as possible also has benefits when it comes to introducing external workers to projects. Since the CoTech network was started at the end of last year, Outlandish has collaborated with many other co-ops on a wide range of projects. This has involved on-boarding a large number of new developers all at once, or (as in the case of the CoTech website) ensuring that any new contributors can pick up tickets as they wish. The former case is an upscaling of the new developer on-boarding issue just discussed, whereas the latter case can have huge negative impact on the development of collaborative projects, which is at the heart of the open-source software community. If a developer sees an issue that they will be able to fix in 20 minutes, they may be put off contributing to the project if it takes significantly longer to get the project to a state in which they can actually start developing.
More working, less “hmmm, why aren’t you working…”
By making setup as simple as possible, this also opens up the doors for designers to become more directly involved in the later stages of the project. When getting a product ready for launch we often give our designers a QA hat to help the developers find inconsistencies and places where the designs are not quite met and then create more tickets. But if the designers could more easily make changes to the styling in the source code then it reduces the work load on developers as well as reducing the back-and-forth between designers and developers before fixes can be made.
The benefits of Docker also extend to project managers. Being able to spin up an instance of the project as soon as the source code has been updated means that PMs no longer need to wait for developers to update the test environment before checking through tasks (thus reducing or even negating the requirement for a test environment, again saving developer time). Closing the feedback loop between developers and PMs therefore helps to close the feedback loop between PMs and clients.
While economising the development time of a project is hugely beneficial, both to our developers and clients, there is another way in which Docker promises to improve the pipeline for Outlandish, especially in the area of DevOps.
“It works on my machine but not on production (or vice versa)!”
This is a problem seen beyond the world programming and is something I’m sure anyone who has ever given a presentation can attest: all is well until it comes to running the program where it matters. One common issue when it comes to preparing projects for go-live is ensuring that the correct parameters for the production server are set, especially in the case where the client wishes to host their own website. Since Docker containers are machine agnostic a new project can be setup with the details of the production server in mind. As a result this makes it easier to introduce continuous integration and automated testing, and move us closer to the holy grail of one-click deployment.
One-click deployment, so elusive, so glorious…
Another implication for the development process is data. Working with dummy data, while integral to early stages of development, often results in certain issues not being spotted until the project is pushed to the staging (or, even worse, production) environment and has to deal with prod-like data. Fixing these bugs then becomes time consuming as the developer has to either replicate the data that was causing the issue in the development environment, or, if that is not possible, push an assumed bug fix to staging before it can be effectively tested.
The solution that Docker can provide is to have multiple images from locations containing both dummy and prod-like data in order to cover different use-cases. For significantly large projects, this idea can be broken down even further by separating prod-like data relevant to specific areas of the website, resulting in faster spin-up time as users are not trying to load data superfluous for the task at hand.
Potential Issues
While Docker is a great bit of kit and has so far been a great addition to Outlandish’s utility belt, it is not without the odd hurdle for the user:
-
Not all OSes are created equal: As of the time of writing this blog, Docker Community Edition (CE) cannot run on any Windows machine that doesn’t have Hyper-V installed and won’t work with Windows Virtual PC. It can, however, be used with VirtualBox with the use of Docker Machine (rather than Docker Native), and works well with macOS and most Linux distros.
-
Beware the BIOS: While this is not strictly a Docker issue, getting it to work could require users to enter their computer’s BIOS in order to turn on virtualisation, which can be a daunting prospect for those who aren’t entirely sure what they’re doing and don’t want to brick their machines.
Happy Days
Ultimately, these improvements in the way Outlandish will be able to work on projects will feed back to the client as they will be able to get the most out of the development time that they pay for. In closing the feedback loop, better tracking of tasks means that sprints can be made even more agile and potential issues with desired functionality can be spotted sooner rather than later. It is still early days yet, but our current aim is for all new projects to be setup with Docker from inception. Moving forward we hope to push containerisation further so that we can offer cloud-compatible platform-as-a-service on top of our existing services.