Imagine your development team is working on an application. The code works perfectly on the developer’s machine, but every time he needs to test the application he has to set it up on every machine of the testing team. With Docker, developers can ensure that their code in production does not fail during testing and works exactly the same as it did during development. This means that developers can focus on writing code without worrying about the system on which their code will run. This blog will explore Docker from a developer’s perspective and discusses how it can help them during development and deployment.

What is Docker?

Docker is an open-source and lightweight platform that helps to simplify the application building process and allows developers to run them in different environments such as development, production and any in-between. Docker packages and runs containers. A container packages the application’s functions and services with all the dependencies, libraries, configurations and other necessary files to run the application successfully. Containers shares resources of an underlying operating system. A Docker image contains one or more containers with the necessary dependencies needed to execute code that resides in a container. This helps developers move the same container between different docker environments that run on the same operating systems without making any changes to the code.

Benefits and challenges of using Docker for development

There are many advantages of using Docker for development, however, this blog focuses on the top five:

1. Simplifies working with different configurations and package versions
The most common phrase we come across during agile development is, “It works on my computer. It cannot be a bug.” This is mainly due to differences in configurations and package versions which are complex and time-consuming to identify. Earlier, environment stabilization was achieved using virtual machines, but we had to manually repeat configurations on each new environment or machine. If the applications are configured through environment variables and are stateless, containers will also have the same environment variables. Any container built from the same image will also have the same configurations, and we can be sure they will behave the way we expect. Similarly, if we encounter a bug in production and we need to reproduce it and debug the application, all we have to do is build a container based on the production image.

2. Makes onboarding easier and less time-consuming
If a new team member joins a project, all they need to do is install Docker and start a container based on the latest code version. It will install the same versions of the packages and tools as the rest of the team members, regardless of the operating system being used.

3. Makes development efficient
Developers work on various projects, hence accumulating different tools over time. They may also have different versions of the same tool. This will pollute the computers and might cause some projects to run incorrectly. And these issues are time-consuming to identify. If we use containers, it is easy to install and use and we can be certain that once we destroy the container, it will delete all the tools with it as well.
Containers are not dependent on operating systems. Developers like to work with the same tools once they get accustomed to them. If they have to switch to a different operating system, they do not have to find tools that have the same functionality and work on that operating system, they can run the tools on docker containers.

4. Availability of off-the-shelf solutions
One of the advantages of containers is that you can get help from off-the-shelf solutions from different registries such as Docker Hub. This saves time as we do not have to write code from scratch to address a problem. In addition, most of the images are open source and we can contribute to improving them or host our own images in registries so that it would be helpful to other developers.

5. Saves Time
Earlier, in order to test an application in the production environment, we had to request a virtual machine or a dedicated server from the client. This process could take weeks and if we make an error in configuration, we have to start from the beginning and time could be lost. Using containers, we could simulate the production environment, eliminating the need for client’s resources and testing the application properly, saving time.

Even though Docker brings many advantages for developers, there are also some challenges to keep in mind.

1. Docker does not have a Graphical User Interface and all Docker commands are command-line dependent. This adds an extra layer of complexity for users.
2. It can be less productive to apply Docker to smaller projects since it introduces extra complexity. Before creating complex topologies, we must experiment with docker functionalities such as networking between containers, storage, security and the reliability of 3rd party applications.
3. Lack of cross-platform compatibility may be an issue as containers are based on Operating System’s Kernel. If we use specific features of our base kernel and build an image, it might not be compatible with another operating system. For example, an image that is built for Windows will not work in Linux. Hence, containers may not work effectively in heterogeneous environments with different operating systems.
4. Docker advances quickly. However, documentation and related help aids don’t update at the same pace, resulting in fewer resources for developers.
5. Persistent data storage is complicated since the data in a container disappears when we shut it down. Even though there are methods to save data persistently in Docker using Data Volumes, there is no seamless way to carry out data persistence.

Docker is a great tool in the right circumstance. It can help teams save on both infrastructure overheads and labour. However, the decision to use Docker should be based on an in-depth and holistic analysis of the application and business needs, as it will introduce a high complexity layer that would require developers to address before developing the application.

Written by:

Dasun Perera
Senior Software Engineer, Fortude