Alternatives to a functional local environment

In my opinion, environments based on Docker engines are the most efficient way to work. The biggest advantage of this is that, in the end, it does not matter what operating system you use – you can use the same tools.

Of course, there are other ways of setting up a local environment, so let’s try to summarize them in a few words:

• Bare-metal: In this approach, you configure everything on your local machine manually without using any virtual machines and containers. While some backend developers think that this is the best way to work in terms of performance, there are a few issues you might face:
  • Errors when upgrading or changing the version of the database or scripting language. With Docker Engine, you simply specify a new machine and specify the version; in a bare-metal setup, you have to install everything manually, and it is not always possible to run multiple instances of ES (for example) on the same machine without some issues.
  • Let’s say that you have taken on a project with a very outdated software and technology stack (AC/Magento 2 in version 2.1.x or, even worse, 2.0.x). If you keep your software up to date on your local machine, it might be hard to install the old version of the software required to run the platform. With Docker or a virtualized environment, this is not an issue.
  • You might need to install additional services on the computer to match and run multiple domains for one store. Keep in mind that AC can run multiple stores with different domain names at the same time. In the “bare-metal” setup, you can either edit the /etc/hosts (Linux/macOS) file and map the domains locally, or you can try installing tools such as dnsmasq, but it’s much more advanced than this.
  • In my opinion, the biggest issue with a bare-metal solution is the fact that multiple developers working on the same project might have different versions of the required services. This might cause conflicts or even break the code once it is pushed to the production environment.
• Vagrant: I’ll use a giant simplification again, but Vagrant is very similar to Docker-based environments. However, in my humble opinion, Vagrant is slower than Docker. Some backend developers might argue that Vagrant is a better solution, and they have very good points about it, but I’ve run into a lot of performance issues in the past and decided not to use Vagrant for my daily work.

  If I were to describe the differences between these two options, I would summarize it like this: Vagrant is primarily used to create and manage virtual machines, while Docker is used to create and manage containerized applications. Vagrant is useful when you need a complete virtual machine with a specific operating system and software stack, while Docker is best when you need to deploy lightweight and portable applications or services.