Problems with the local development environment: Is containerisation the solution?

Docker and containers in general have become indispensable in modern software development. Containers are also often used locally to avoid problems with the local development environment and the operation of the software to be developed.

However, this brings new challenges: Is the knowledge even available to work with containers? Is everything configured correctly? Does the local use of containers bring any advantage at all to running the software to be developed locally?

Or is it more like Micah Adams describes: “Probably the biggest pitfall in going down the road of a containerized development enviroment is assuming that the benefits you’re getting in deployments are the same benefits a developer will experience locally.“

In this blog post we describe why containers are a first step in the right direction, but don’t solve all the problems.

Tabel of Contents

What is containerisation?

Let’s take a quick look at what containerisation actually means. Containerisation is a technology that makes it possible to run applications in isolated and portable environments. Containers are virtual runtime environments that contain all the necessary software components, libraries and dependencies for applications. Applications can thus be quickly deployed, scaled and managed.

What is the advantage of containerisation?

The best way to see the benefits is to look at the differences between working without and with containers:

Without Containers	With Containers
Dependencies are installed and managed manually.	Dependencies are installed and managed in the container environment.
Different system configurations can cause problems.	Containers provide a consistent environment for applications.
Applications need to be adapted for different environments.	Containers can be run on different systems without having to make adjustments.
Scaling is often laborious and requires manual intervention.	Containers can be scaled quickly and easily.
Deployment can be time-consuming and error-prone.	Containers can be provided quickly and easily.

Containers offer an effective way to deploy applications quickly. They allow services to work the same way, regardless of where they are deployed. They are easily scalable and can run different versions of an application side by side.

The problem with local development environments & containers

The problem with local development environments is that they can take hours, if not days, to set up. The biggest challenge is often getting the software to run. This is the only way developers can quickly check whether code changes lead to the desired result. Another problem is that maintenance is time-consuming because each development environment requires an individual solution to the problem.

Fortunately, there are containers. And it is precisely this solution that many companies resort to when the problems just described have a negative impact on daily work and productivity.

But are containers also a good solution to tackle the everyday problems with the local development environment?

In a nutshell: No. Why?

Complexity: Developers first need to know how to work with containers. If the knowledge is not there, a training period is necessary. That takes time. And it costs money.
Configuration: Most applications run on a specific port. Port forwarding can be used to connect to the container. But the devil is in the detail, because everything must be configured correctly for this. If not, network problems are inevitable. Incorrect configuration can also lead to security problems.
Troubleshooting and debugging are made more difficult because logs can often be distributed across several containers.
Running containers can be resource intensive. It must be ensured that the computer has the appropriate power.

Micah Adams, mentioned at the beginning, describes the challenges in detail. Among other things, he describes peculiarities of Docker that he did not consider when using it:

A considerable amount of configuration was required to make the environment actually work.
Adams spent a lot of time wracking his brains over some simple database connection issues, only to find that the database container was not configured properly

Guillaume Briday even says in his blogpost “Why I stopped using Docker for local development”: “I’ve been using Docker for almost 5 years now. […], it solved many of my problems and simplified my life as a developer, but I’m done with it. Why? The problems that Docker solved are not worth the amount of effort needed to use it. I don’t want to deal with it’s complexity and workflow management.“

And further:

“[…] You have to know so many concepts to be really effective with Docker.

Why and how to release ports.
How to deal with permissions.
How named volumes work.
How entry points work.
How networks work and how Docker internal DNS works.
And so on…

Maintaining hundreds of lines of YML files is not something that will make you more productive.“

Of course, this is only one side of the coin. If your team is familiar with containers, the difficulties – running in-house software locally and maintaining development environments – can be better dealt with. For some companies, this is already enough. Others continue to struggle through the container jungle, have major problems running the software locally and struggle with configuration errors.

Why remote development environments are the better alternative

“If you’re interested in moving to a containerised development environment, I think you should spend a lot of time developing simple alternatives for running applications locally.” – Micah Adams

One alternative to save time, money and energy are Remote Development Environments (RDEs). With Cloudomation Remote Development Environments, developers can create self-service remote environments that are available in seconds and are as close to the production environment as possible. The software to be developed and all the necessary developer tools run in the RDE. However, developers can continue to work with their local IDE and their individual tools.

Since RDEs are available on servers and equipped with the required resources compared to laptops, the waiting time for builds and tests is reduced. Problems with weak CPU or low RAM are a thing of the past. RDEs are managed centrally, e.g. by the DevOps team. The environments are standardised and errors during operation are always solved for all developers. Developers no longer have to deal with problems and configuration errors individually.

And what about containers and RDEs? It is also possible to run containerised applications. Since the RDEs are configured centrally, developers can simply access them and work with them – without spending a lot of time on the local configuration of Docker, for example.

Take the productivity of your IT team to the next level. With Cloud Development Environments

In this whitepaper, you'll learn how Cloud Development Environments (CDEs) help reduce the burden of maintaining the Local Development Environment and increase the productivity of your IT team.

Download now

Conclusion

Local operation of containers such as Docker is often an attempt to make the initial set-up of the development environment more efficient, to be able to run the software to be developed more easily and to reduce the effort required to maintain the local development environment.
Containerisation of the software to be developed solves some problems, but leads to new challenges: Knowledge needs to be available internally, configuration can be laborious, security and network issues can arise, and operation can affect the performance of the computer. Troubleshooting and debugging are made more difficult as logs can often be distributed across multiple containers.
Remote development environments are an alternative: in self-service, the right environment is immediately available to developers. They can continue to use their local IDE and work as usual. The software to be developed is run in the RDE. If, for example, another version has to be changed, the appropriate RDE is simply called up. All dependencies are already configured. Build times are reduced because RDEs run on a server that can be scaled as required. Containerised applications can also be run in RDEs – without individual configuration work for each developer.