1

I am struggling on a question that nobody seems to answer in detail on the Internet.

"Standardizing service infrastructure across the entire pipeline allows every team member to work in a production parity environment"

This is a key benefit of Docker : it allows everybody to develop, test or whatever in a production-like environment. Because the container that is passed through the pipeline is always the same. I get that. I understand that this is necessary and that Docker allows this easily. But what I don't understand, is why was it so hard before Docker ? If I have a production machine and a testing machine, I won't have any problem building a script that installs the right dependencies, no matter what the machine is. So my environment in terms of libraries or frameworks will be the same.

The only thing that I understand with this whole environment-related benefit, is that Docker allows a developer to choose his OS without fear of the platform-related bugs. I've already run into features that worked on Windows and not on Mac. Worst kind of bugs in my opinion. So yeah if I had Docker at the time, I wouldn't have had this problem. But I don't understand why Docker was such a miracle for other environment-related stuff.

I think I am not understanding this because I've only worked on small scale projects. Maybe I also don't realize the full meaning of the word "environment".

What am I missing here ? Why containers were a breakthrough for standardizing environments, whereas scripts can achieve that ?

  • It' ok, at the moment you see a small part of the picture. It's not just about writing a script, taking care of dependencies... Docker brings a big change on how teams work together, how an app is designed and implemented, how we make use of infrastructure. Read about concepts like: monolith apps Vs micro-services, why deployment time is important, horizontal Vs vertical scaling, serverless. Some pieces of the puzzle can be found if you read [history](https://loige.co/from-bare-metal-to-serverless/). – tgogos Mar 30 '18 at 08:36
  • To get the same level of environment isolation, you'd need a machine/VM per service. – Oliver Charlesworth Mar 30 '18 at 08:38
  • 1
    @tgogos Yes I understand very well the benefits of micro-services, and I understand every other benefits of Docker. I love Docker. But I just don't understand this particular point : why was it so hard to have prod-like environments anywhere before containers ? – AndroidLover Mar 30 '18 at 08:42

1 Answers1

0

The following list is not exhaustive, it represents only three important advantages of docker. Please note that docker is not a magical solution and may not be adapted in specific contexts.


Firstly, with containers you don't have conflicts between dependencies.

If you have two programs using the same library at different version you'll have to manually install both versions and specify custom environment variables before executing your programs. (For example LD_LIBRARY_PATH). Please note that some tools exists to address this issue but only in specific cases (virtualenvs in python for example).

Secondly, with containers you don't have persistence.

For example if you write a little bash script to install your development environment based on Nginx and PHP and by mistake I install Apache, my package will still be present even if you run again your script. The thing is Apache will sometimes starts before Nginx and block the 80 port, breaking your development environment.

To sum up, without docker you're not sure about the state of untracked elements and they may break your environment.

Thirdly, docker allows you to reduce the gap between development and production.

The close environment is "everything needed for your code to run". For example libraries, config files, your interpreter (python, php, ...). Docker packages the application with its close environment so you don't have mismatches between what your app needs and the environment you provided.

This is especially important when you update dependencies during development and may forget to update them in production.


A false argument is security and isolation. The security process starts with defining your threat model and then choosing countermeasures. Adding docker because it increases security in a risky environment won't be enough (there is no kernelspace isolation) and adding docker for security if you don't need more is called paranoïa. Docker adds userspace isolation and default seccomp profiles, but this is not a reason to use it, except if it matches your threat model.

hugoShaka
  • 4,977
  • 3
  • 17
  • 29