Stef De Waele
This article answers the question which local development solution we use at Calibrate and why this solution is called lokal.host. In a number of steps we look at the criteria a local development solution must meet and what solutions already exist. We make our choice and argue why this solution is best for us.
A first criterion that we use is the support of host platforms. By this we mean whether the solution works on everyone's favourite operating system. Web development is common on Mac or Linux. In very recent history, more and more developers are also appearing who want to work on Windows.
As a second criterion we look at control and compatibility. As a (seasoned) developer you want full control over your local development solution. After all, it is very important to test or investigate new features or any errors as correctly as possible. By fine-tuning locally to lean as close to the production environment as possible, you also avoid a lot of potential problems.
The third criterion is flexibility. In the current IT landscape there is a very wide range of technologies that you want to use. The versions of those technologies follow each other more and more quickly. As a developer you want to be able to switch between all these possibilities very quickly. This is also very important for agencies that offer long-term support because they need to be able to switch quickly between existing websites.
Finally, we have development speed. Once your website is running locally you don't want it to take dozens of seconds for your web page to load. Also, the execution of commands in your terminal window is ideally limited in time. For the sake of simplicity, this duration is directly proportional to the turnaround time of a website.
To consider the full range of existing solutions, we first divide them into three groups.
We choose the group that best suits what we are looking for and go deeper into it.
For a long time, this way of development was the only way in which local development was possible. All the necessary technologies were installed directly on the development machine. This way of working is still the fastest because there is no extra complexity (overhead) when running the website. However, this way of working can't keep up with the speed of use at all. Due to the countless number of technologies and underlying versions, it is practically unfeasible to foresee them all and constantly switch between them. The difference between Operating Systems (OS) is also decisive here. Each OS has to provide its own setup because these are totally different. Your control and flexibility are therefore limited because you are bound to your OS. The last sledgehammer blow is the fact that if you introduce a structural error in your setup, your computer has to be reset. So this is completely outdated.
By virtual machine we mean in concrete terms that a virtual computer exists within your real computer. On this virtual computer all the necessary technologies are installed to run your website. The big advantage compared to the previous way is that you can provide several of these virtual computers. You will have one virtual computer for each website you want to run. The advantage is that you can switch between virtual computers and make adjustments within the virtual computer. This makes switching between different technologies a lot easier and more manageable. In the event of critical errors in your setup, you can throw away the virtual computer and have it generated again. The disadvantage is the large overhead of the virtual computer, which can initially take tens of minutes before your website can be reached locally. Once the virtual computer is built it will take much less time to run the website. However, a small adjustment to the installation means that this whole process has to run again, which reduces the speed of use considerably. In terms of support for host platforms this solution scores super because all your settings are done within the virtual computer and it is independent of the host OS! So no matter if you have a Mac, Linux or Windows, you can share the settings of the virtual computer without any problems. Your website itself can run quickly if you set up the virtual computer correctly. The degree of control and flexibility is high because you have full control within the virtual computer.
This is an advanced form of virtual machine based. Instead of one virtual computer per website, a very minimal virtual computer per technology version is provided. Running a website then consists of having a number of these mini-computers work together. The great time gain is that these mini-computers are built and available and accept configuration. So if you want to make a non-structural change to a technology, it can be done very quickly because the whole environment does not need to be rebuilt. This was the case with the previous section. Even if a structural change should be made to a technology, only its mini-computer needs to be rebuilt. That takes significantly less time than was the case with virtual machine based. A disadvantage of this way of working is that these mini-computers have to work together. So this is the overhead that is introduced by Docker itself. As a result, the speed of development will be lower than with the other solutions. In concrete terms, we therefore have all the advantages of virtual machine based without the disadvantages, provided that the development speed is slightly slower and the user-friendliness is reduced because of the knowledge you need to use Docker. In the meantime, docker itself has been further developed and there are more and more answers to these last two problems. So it is within this category that we find our solution.
Wrapper solutions introduce abstraction layers in order to be more user-friendly on the one hand and more efficient on the other hand. The cost you pay for these abstraction layers is that you are also bound to them and do not always know what is happening behind them. They also cause a discrepancy with the production environment because the wrapper solution will not exist there.
Examples of such a wrapper solution are Lando, Docksal and DDEV. One solution has fewer layers of abstraction and is therefore less expensive than the other. A comparison between these platforms can be found several times online.
Pure solutions work directly with docker without an intermediate abstraction layer. In itself, this requires more knowledge of docker but allows more control because you are not bound to any layers of abstraction. For the pure solution we only need the mini-computers (images). Practically all common technologies are offered in the form of an image by official publishers of that technology. In principle, this gives us enough to run the website. There are also optimised images for specific frameworks or CMSs such as Drupal. An example of this is Docker4drupal. This group of images is optimised for Drupal and although Calibrate works a lot with Drupal, we also use other technologies that do not benefit from these optimisations. Therefore, we choose to use our own optimised images.
The choice was made for pure docker with its own images because we want to have the full control and flexibility of working directly with docker. How you work with docker can be done in countless ways. So we need to make agreements around this, keeping the following points in mind:
We want full control so that power users are not restricted in their use. So it is very important to bundle agreements without introducing abstraction layers. In this way, we avoid ending up in the wrapper solution category. This avoids the cost of abstraction layers and mimics the local production environment as precisely as possible.
It is also important that we do not make the setup complex so that use remains relatively obvious and new people can quickly set up a website. We offer optional tools and templates to speed up local development.
Our setup needs to be maintained. Technologies that go end-of-life (EOL) must be removed from the setup if not the setup cannot be maintained. In this way we can separate legacy and introduce new functionalities.
Old projects with EOL technologies should always be able to get started. You should therefore be able to switch versions of the setup itself. In this way you can return to older versions where specific EOL technologies were supported.
With all that in mind we ended up at lokal.host. This setup itself is maintained in a version control system so users can easily switch between different versions. If you want to make use of the latest gadgets you are advised to update your project. This benefits both the client and yourself. The setup contains templates to start from in order to set up sites quickly. You don't have to use these templates, if you feel like you have enough confidence, you can start using them in your own way.
In our search for a local development environment that is fast in use and development, works on the current operating systems and gives total control and flexibility to the developer, we came up with a pure Docker solution where clear agreements are made. Even though other solutions may be slightly more efficient and our approach requires regular maintenance, these disadvantages do not outweigh the control we have, the possibility of mimicking the production environment locally and avoiding abstraction layers.
PS: The reason lokal.host is not a spelling error: We support HTTPS through a purchased certificate and lokal.host was still free 😊 . The punch line is in the tail!
