Use Linux, Even in Windows | by Marcin Kozak
Use the same operating system for development, testing and deployment
The six words below make today’s story:
Deploying in Linux? Develop in Linux.
This is more important than it may seem at first glance — for any software, and data-science products do not constitute an exception.
Some may think the development environment is not that important, particularly when a programming language used in the project can work under any operating system. But there’s more to it than that.
Even if your programming language can work in any operating system, it does not mean that it works the same way in all of them. Sometimes the differences may not be too big; sometimes they can be. It’s like saying that all cars work in quite a similar way. They do essentially, but does this mean that you would use a desert environment in order to develop a car to be used in Scandinavian countries? Of course not. In both cases, four-wheel drive is required, but a car constructed to work well in a desert may not work as well in strong winter conditions. Maybe it will, but you cannot be sure of that, can you?
With software, things work in a similar way. If you want to develop a good product to be deployed in a particular environment, you should develop it in as similar an environment as possible. In IT, it’s often impossible to recreate a production environment, especially when that environment been in service for quite some time and offers its clients a number of various software products. Still, often it is possible to create a similar environment, and the more similar to the production one, the better.
While the topic is quite general, this article will focus on one aspect of the story—but an essential one: the operating system. Even more precisely, I will focus on a developer’s modus operandi, with the following question on mind: Should I, or even can I, develop in Windows when the product is to be deployed in a Linux environment?
For the sake of simplicity, I will focus on these two OSes, for two reasons. First, in the industry, these two are frequently mixed in software projects. Second, I have experience in these two OSes, but have little experience with other operating systems. From my experience in the development of data-science software, it follows that it’s common to develop on a Windows machine and deploy to Linux. This is how I’ve been working for several years. And this is nothing to be afraid of, if only you know how to do it.
When referring to one of the three types of environments, I will use the following abbreviations:
- DEV for a development environment,
- TEST for a test environment, and
- PROD for a production environment.
I think you will agree with me that in IT, one of the most important aspects of development and production environments is the operating system. More often than not, it will be the most important aspect of the environment, making much of a difference when it comes to development, testing and deployment.
The unwritten rule is as follows:
Develop and test code in an environment as close to the production environment as possible.
Note that the rule is not strict. It does not say the same environment, but an environment as close to the production environment as possible. Thanks to this detail, this rule gives you a fairly wide margin of adjustment. You can use this margin depending on the situation, especially on the resources the project has. But try not to overuse this margin, if you do not want to risk the project to give you more headaches than you can accept. If you do overuse the margin, you will deserve the headache, unless you did so because you were made to by others. I’ve been there, and I’ve had huge headaches because of limited resources I was given for development, with no testing resources whatsoever.
I’d say the rule is not related only to programming or IT in general. It is quite a general rule, one that is similar to many similar rules we can find in the sciences — and in our lives, for that matter.
To make this point, let me show you an example from a completely different context. Imagine you’re developing a new plant herbicide. You should develop it in the context in which it will be applied. Let it be a herbicide to be used with cereal plants. If this is the case, then you should not want to conduct experiments (which constitute part of the development process) in orchards, but with cereals — and different cereal species, for that matter, not just one. Also, you should never test the herbicide by treating it as a fertilizer, a food ingredient, or aircraft fuel. No, you should both develop and test the product in the environment (and context) as close as possible to one in which the final product is to be used.
How should this be understood in the context of our comfort zone of software development? As you will see in the next sentence, we should understand it in a very similar way. When developing a software product — whatever that product is — you should develop and test it in an environment similar to the production environment.
Why can’t we just use the production environment itself to develop and test the product? Isn’t this the easiest approach when we already have this environment in use (which is often the case in the industry), and also the very best one? You can almost never re-create the production environment, unless it’s a fresh one. So, why not use it instead of re-creating it?
Indeed, this seems to be by far the best solution: the product would be developed in the same environment in which it will be deployed. That way, it is already known during development how the product will work in this very environment, what sorts of problems may happen (if any at all), and so on. No other environment can provide us with such confidence that the product will work well in production.
Even if this approach may be tempting… not only is it not the best, but also it can be very dangerous. In my opinion, you should opt for this solution only in rare situations, when you have absolutely no other option. When developing software, we can always make some changes to the development environment, or even break it. Sometimes, to recover the environment, you need to reinstall it from from scratch. This is the reason why we should not develop in a production environment: while breaking a development or a test environment is a risk everyone accepts, breaking a production environment entails unacceptable risk, especially when the production environment is already used by other software products.
This is why software is often developed in a development environment, checked in a test environment, and then deployed in a production environment. This gives us the natural sequence DEV → TEST → PROD, though most projects include steps that intermingle two of the three, usually DEV ↔ TEST and TEST ↔ PROD.
Unfortunately, reality often imposes limitations that force software developers to adapt to limited resources. We’re often forced to work in only two environments: DEV and PROD. If you are unlucky to find yourself in such a project, you have to choose which of them should become the test environment. Neither solution is good, unfortunately — and at the end of the day, the testing stage for such projects, to be honest, is not real testing. While some testing is involved, it’s not real testing of the product, unless you can perform it in the PROD environment. As I mentioned, this is, and should be, a very rare situation in the industry.
The availability of the three environments (including TEST) is especially useful for projects with significant time constraints. In one of my past projects, I had to check the reinstallation of an additional package. Unfortunately, when I did so, the new version of the package broke the test environment. To use it again, I would have to reinstall it completely, but this was impossible due to significant time constraints. So, here I used the DEV environment for both development and testing. But what if this happened in a project with only two environments, DEV and PROD? I would have to reinstall DEV, and there was no time for that; what option would I have other than to work days and nights to do it? Fortunately, I was a lucky developer with three environments to use. Thus, I was able to finish the product in the DEV environment, though I did not have a real possibility to test the product. I moved directly from DEV to PROD, which made me uncomfortable due to the complexity of the product. In addition, during development, the DEV environment underwent minor modifications that were not represented in the product environment; I wasn’t aware of that until the very moment I finished the installation on PROD and tried to run the app. Eventually, after additional work, all ended well, and I completed the project with some significant experience I’ve been using ever since. It’s always a good thing to have three environments: DEV, TEST and PROD; to develop on DEV, then test on TEST, and only after all is ready, deploy in PROD.
Let’s conclude the Why? section here by explaining why we should develop in as close an environment to production as possible. To this end, let’s use the more concrete scenario we used above, that is, Windows-versus-Linux development.
When a software product you’re working on is to be deployed on a Linux machine, in the cloud, or anywhere, for that matter, you should develop the code in Linux. I guess that in the industry, Linux is almost always the production operating system. Out of 20+ data science projects in which we created a software solution, I remember only one in which we had to deploy the solution to a Windows server machine. Not planned from the beginning, this was rather an unexpected result of a combination of events.
All in all, as a software developer, you should try your best to both develop and test software products in environments that are as close to the planned production environment as possible — but not the actual production environment in which the product is to be deployed.
This basically means that whenever you work in a project in which the solution is to be deployed in Linux, you should develop and test the code in Linux, too.
I suppose the previous section now makes perfect sense to you. Does it?
It should. This is how it should work. But way too often, it does not work this way — both in small and large companies, and even among the biggest ones.
Imagine that our small company hires 2–3 developers plus about 10 other people. It’s not an IT company, but one that uses IT a lot; say, it applies data science to support its research, and then presents its results to outsiders. Its software products are data science products, so they enable users to run some models for their data.
As commonly done, the company’s employees use laptops with the Windows operating system. However, being so small, the company does not have the resources to maintain its own servers in order to deploy and maintain their products. So instead, they rent servers and various cloud services.
I think you already see my point here. The developers work on Windows laptops, but deploy their products in Linux environments. This is not their choice; these are the only resources they have. They seldom can use their private resources, even if they wanted to (I wouldn’t), so they’re forced to use what they have. For development, that resource is a Windows laptop — and this laptop is what we should consider a DEV environment.
How should they proceed?
We could list quite a few approaches to follow, but I will stress two of them. One uses a popular tool these days, containerization. It’s not the standard containerization you usually think of, however. When I envision containers, I usually see them implemented in the PROD environment. Here, we will talk about containers used for development, and they are different from those used in PROD. Remember this when we discuss development containers.
A second approach offers convenience of work that I don’t think is found in the first approach. This is available when using Linux on your Windows machine — but not using a virtual machine, as this approach, at least in my eyes, is far from convenient. Instead, this approach uses Windows Subsystem for Linux (WSL). I use it all the time, in almost all my projects — and I value it a lot.
Between the two, it is containerization that enables you to use a similar environment to PROD. Since WSL uses the Linux subsystem installed on your machine, simulating the PROD operating system is very difficult, often impossible, especially for several projects. The WSL’s main benefit is that it can be used in most projects, but this advantage can easily turn into a liability. We’ll return to this approach as soon as we’re done with development containers.
Development containers
As already mentioned, these are not the same as production containers: the former are used to develop product in the DEV environment while the latter are used to install the product (and its environment) in the PROD environment.
Development containers offer a dedicated development environment. Here, you may have unit tests, which are not needed in production containers. Likewise, you may need some additional packages that you do not need in production. Usually, development containers are organized differently than production ones. Simply put, you organize them just as you would have developed the code on your local machine, without containers.
Consider the following example. You develop your code so that it can be packaged once the code is ready. So, your development container will contain a folder in which you will keep the code to be packaged. Your production container, on the other hand, will not contain this raw code. Instead, this package will be installed inside the production container from a package registry. This causes the two types of containers to have very different organizational structures.
Usually, your development container will offer a similar environment to the production container environment. It can, however, contain other tools that are not needed in PROD. Hence, code that works just fine in the DEV environment does not have to work the same way in PROD — you need to check this. You can then test the production container, and for this, it’s great to have a TEST environment.
In my eyes, development containers make clear sense and can be very helpful. They do have one significant downside, however: Using them is difficult. On one hand, containers should behave the same way on various machines. On the other hand, they can pose some difficulties, especially when used on several Windows machines; the more machines, the greater the risk that something unexpected will happen. Sometimes it can be something really small, but finding a solution can be far more difficult than it can seem.
Windows Subsystem for Linux (WSL)
WSL offers a great way to emulate Linux in the Windows operating system. I’ve been using it for several years, and I appreciate it a lot.
When you choose a Windows machine with WSL installed on it, you can use both Windows and Linux. In many projects, you may need to be able to use Windows. When you have no choice and must use a Windows machine (which can be due to company resources), WSL is a great choice for developers, because as I mentioned before, most software products are deployed in Linux.
Many users do not have a choice, but I do: I could have chosen a Linux machine. Instead, I chose a Windows machine, and I did it for a reason. I did it because sometimes I simply have to be able to use Windows, for a variety of reasons. A Linux machine would be no help in such situations. So, I have Windows — and thanks to WSL, I also have Linux. Had I not had the possibility of using WSL, I would prefer to use a Linux machine. But ever since I can use WSL, I am totally fine with a Windows laptop.
I know, it makes a difference. WSL is not Linux. It isn’t as fast as real Linux. There can be differences, some less significant than others. But all of that does not pose any significant problem for me, as someone who develops code. For instance, WSL isn’t as fast as Linux? I develop code, not run it; so, that’s not a problem for me whatsoever. Other problems? Yes, I’ve had some minor issues (e.g., with line endings), but they were so easy to solve that I don’t even remember them well. And frankly, I did encounter one big issue with line endings, but it was in… a development container!
There is one more advantage of using a Windows machine with WSL. When you develop a product to be used in both OSes, you should check your product in both. While of course WSL is not really Linux (though WSL 2 does have a Linux kernel), when something works in WSL, it will most likely work in Linux. For example, I have authored or co-authored four open-source packages (easycheck, makepackage, perftester and rounder); I worked on each of them in WSL and then checked each in Windows.
All in all, when you develop in WSL, you can develop in an operating system in which the product will be developed (unless there is no WSL version with this OS). Once you’re done with installing WSL, all becomes simple. The most important IDEs cooperate with WSL. I use Visual Studio Code, and it works perfectly fine with it, thanks to a dedicated WSL extension. When I develop in WSL, I feel the same vibe of developing in Linux.
To be honest, now that I haven’t really developed anything significant in Windows for several years, I feel like a Linux guy. And whenever I move to a production environment, which is almost always in Linux, everything feels natural. If you have ever attempted to develop a product in Windows to be deployed in Linux, you know what I mean. I’ve been there, and it was not a nice feeling. It was like something deep inside the product seemed wrong, something that could lead to big problems. WSL is a nice painkiller, one that has changed my life as a developer for the better; actually, for the much, much better.
I’ve worked with both. Although it’s difficult to say which is better, I know which I prefer. This is why I will focus on my preferences and explain them. Then you can decide for yourself what you think will be better for your project.
To be honest, I would not choose development containers without a DevOps I trust. I wouldn’t know even how to start! With a good DevOps, development containers can be the best solution — but one that can, from time to time, slow down your coding work. In such situations, unless you know how to solve such problems, you may feel quite frustrated, as simple things do not seem to be solvable with simple solutions that you are almost sure should work.
I remember a project in which our DevOps orchestrated development containers in a two-person data science team, plus himself as a third member. While he did not have problems with this (kudos to him!), we did have some problems, and he had to help us from time to time. Once or twice I had to rebuild the whole container, as things stopped working, for no particular reason, and only reinstallation seemed to help. For me, it was difficult work. All of us had to use Visual Studio Code (not a problem for me, as I had used it before), with some container-related extensions.
I do remember a significant and unusual problem I encountered during that project. The DevOps eventually found the source of the problem, and it was Git. I used Git installed in WSL, the way I always do. Clearly, this Git tool did not cooperate well with our development container. Instead, I should have worked with Git bash. After I started using that, all such problems disappeared. I do not like such strange problems. To me, this example shows that development containers can be delicate — too delicate for my developer’s taste.
All in all, I think development containers offer a good solution, but can be too difficult for someone without strong DevOps knowledge. Without it, any installation and changes can seem difficult. And if you encounter a bigger problem, you may feel yourself helpless, the way I did several times during the project I described above.
WSL, on the other hand, offers a much simpler solution. You do not need to be a DevOps to install it on your machine. During the last several years, I have not encountered any problem in WSL that I could not solve myself. This suggests that the WSL-based solution is much simpler to use than development containers.
WSL does not come without cost, however. It offers you a Linux substitute, and that’s all. You have many packages installed there, and the chance that you will have the very same environment in your WSL and the production container is minimal. So, using WSL means working in Linux, not in the same — or even a quite similar — environment.
So, whether WSL will work for you or not depends on various factors, the two most important being your skills and the project itself. In many situations, it can be your solution, when minor details do not count that much. But if they do, development containers can offer you a greater chance that your product will work just fine.
We discussed two approaches to development software products in the DEV → TEST → PROD chain, but there are other approaches. I described two that I know and have used. If you know and have used other methods to develop a software product in a DEV environment under Windows, but which will be deployed in a PROD environment under Linux, then please describe it in the comments.
You may also have a different opinion on using development containers and WSL. Please, share it in the comments, too. This article aims to collect knowledge and opinion and convey it to others, but this topic is quite prone to subjectivity — what works for me does not have to work for you.
Use the same operating system for development, testing and deployment
The six words below make today’s story:
Deploying in Linux? Develop in Linux.
This is more important than it may seem at first glance — for any software, and data-science products do not constitute an exception.
Some may think the development environment is not that important, particularly when a programming language used in the project can work under any operating system. But there’s more to it than that.
Even if your programming language can work in any operating system, it does not mean that it works the same way in all of them. Sometimes the differences may not be too big; sometimes they can be. It’s like saying that all cars work in quite a similar way. They do essentially, but does this mean that you would use a desert environment in order to develop a car to be used in Scandinavian countries? Of course not. In both cases, four-wheel drive is required, but a car constructed to work well in a desert may not work as well in strong winter conditions. Maybe it will, but you cannot be sure of that, can you?
With software, things work in a similar way. If you want to develop a good product to be deployed in a particular environment, you should develop it in as similar an environment as possible. In IT, it’s often impossible to recreate a production environment, especially when that environment been in service for quite some time and offers its clients a number of various software products. Still, often it is possible to create a similar environment, and the more similar to the production one, the better.
While the topic is quite general, this article will focus on one aspect of the story—but an essential one: the operating system. Even more precisely, I will focus on a developer’s modus operandi, with the following question on mind: Should I, or even can I, develop in Windows when the product is to be deployed in a Linux environment?
For the sake of simplicity, I will focus on these two OSes, for two reasons. First, in the industry, these two are frequently mixed in software projects. Second, I have experience in these two OSes, but have little experience with other operating systems. From my experience in the development of data-science software, it follows that it’s common to develop on a Windows machine and deploy to Linux. This is how I’ve been working for several years. And this is nothing to be afraid of, if only you know how to do it.
When referring to one of the three types of environments, I will use the following abbreviations:
- DEV for a development environment,
- TEST for a test environment, and
- PROD for a production environment.
I think you will agree with me that in IT, one of the most important aspects of development and production environments is the operating system. More often than not, it will be the most important aspect of the environment, making much of a difference when it comes to development, testing and deployment.
The unwritten rule is as follows:
Develop and test code in an environment as close to the production environment as possible.
Note that the rule is not strict. It does not say the same environment, but an environment as close to the production environment as possible. Thanks to this detail, this rule gives you a fairly wide margin of adjustment. You can use this margin depending on the situation, especially on the resources the project has. But try not to overuse this margin, if you do not want to risk the project to give you more headaches than you can accept. If you do overuse the margin, you will deserve the headache, unless you did so because you were made to by others. I’ve been there, and I’ve had huge headaches because of limited resources I was given for development, with no testing resources whatsoever.
I’d say the rule is not related only to programming or IT in general. It is quite a general rule, one that is similar to many similar rules we can find in the sciences — and in our lives, for that matter.
To make this point, let me show you an example from a completely different context. Imagine you’re developing a new plant herbicide. You should develop it in the context in which it will be applied. Let it be a herbicide to be used with cereal plants. If this is the case, then you should not want to conduct experiments (which constitute part of the development process) in orchards, but with cereals — and different cereal species, for that matter, not just one. Also, you should never test the herbicide by treating it as a fertilizer, a food ingredient, or aircraft fuel. No, you should both develop and test the product in the environment (and context) as close as possible to one in which the final product is to be used.
How should this be understood in the context of our comfort zone of software development? As you will see in the next sentence, we should understand it in a very similar way. When developing a software product — whatever that product is — you should develop and test it in an environment similar to the production environment.
Why can’t we just use the production environment itself to develop and test the product? Isn’t this the easiest approach when we already have this environment in use (which is often the case in the industry), and also the very best one? You can almost never re-create the production environment, unless it’s a fresh one. So, why not use it instead of re-creating it?
Indeed, this seems to be by far the best solution: the product would be developed in the same environment in which it will be deployed. That way, it is already known during development how the product will work in this very environment, what sorts of problems may happen (if any at all), and so on. No other environment can provide us with such confidence that the product will work well in production.
Even if this approach may be tempting… not only is it not the best, but also it can be very dangerous. In my opinion, you should opt for this solution only in rare situations, when you have absolutely no other option. When developing software, we can always make some changes to the development environment, or even break it. Sometimes, to recover the environment, you need to reinstall it from from scratch. This is the reason why we should not develop in a production environment: while breaking a development or a test environment is a risk everyone accepts, breaking a production environment entails unacceptable risk, especially when the production environment is already used by other software products.
This is why software is often developed in a development environment, checked in a test environment, and then deployed in a production environment. This gives us the natural sequence DEV → TEST → PROD, though most projects include steps that intermingle two of the three, usually DEV ↔ TEST and TEST ↔ PROD.
Unfortunately, reality often imposes limitations that force software developers to adapt to limited resources. We’re often forced to work in only two environments: DEV and PROD. If you are unlucky to find yourself in such a project, you have to choose which of them should become the test environment. Neither solution is good, unfortunately — and at the end of the day, the testing stage for such projects, to be honest, is not real testing. While some testing is involved, it’s not real testing of the product, unless you can perform it in the PROD environment. As I mentioned, this is, and should be, a very rare situation in the industry.
The availability of the three environments (including TEST) is especially useful for projects with significant time constraints. In one of my past projects, I had to check the reinstallation of an additional package. Unfortunately, when I did so, the new version of the package broke the test environment. To use it again, I would have to reinstall it completely, but this was impossible due to significant time constraints. So, here I used the DEV environment for both development and testing. But what if this happened in a project with only two environments, DEV and PROD? I would have to reinstall DEV, and there was no time for that; what option would I have other than to work days and nights to do it? Fortunately, I was a lucky developer with three environments to use. Thus, I was able to finish the product in the DEV environment, though I did not have a real possibility to test the product. I moved directly from DEV to PROD, which made me uncomfortable due to the complexity of the product. In addition, during development, the DEV environment underwent minor modifications that were not represented in the product environment; I wasn’t aware of that until the very moment I finished the installation on PROD and tried to run the app. Eventually, after additional work, all ended well, and I completed the project with some significant experience I’ve been using ever since. It’s always a good thing to have three environments: DEV, TEST and PROD; to develop on DEV, then test on TEST, and only after all is ready, deploy in PROD.
Let’s conclude the Why? section here by explaining why we should develop in as close an environment to production as possible. To this end, let’s use the more concrete scenario we used above, that is, Windows-versus-Linux development.
When a software product you’re working on is to be deployed on a Linux machine, in the cloud, or anywhere, for that matter, you should develop the code in Linux. I guess that in the industry, Linux is almost always the production operating system. Out of 20+ data science projects in which we created a software solution, I remember only one in which we had to deploy the solution to a Windows server machine. Not planned from the beginning, this was rather an unexpected result of a combination of events.
All in all, as a software developer, you should try your best to both develop and test software products in environments that are as close to the planned production environment as possible — but not the actual production environment in which the product is to be deployed.
This basically means that whenever you work in a project in which the solution is to be deployed in Linux, you should develop and test the code in Linux, too.
I suppose the previous section now makes perfect sense to you. Does it?
It should. This is how it should work. But way too often, it does not work this way — both in small and large companies, and even among the biggest ones.
Imagine that our small company hires 2–3 developers plus about 10 other people. It’s not an IT company, but one that uses IT a lot; say, it applies data science to support its research, and then presents its results to outsiders. Its software products are data science products, so they enable users to run some models for their data.
As commonly done, the company’s employees use laptops with the Windows operating system. However, being so small, the company does not have the resources to maintain its own servers in order to deploy and maintain their products. So instead, they rent servers and various cloud services.
I think you already see my point here. The developers work on Windows laptops, but deploy their products in Linux environments. This is not their choice; these are the only resources they have. They seldom can use their private resources, even if they wanted to (I wouldn’t), so they’re forced to use what they have. For development, that resource is a Windows laptop — and this laptop is what we should consider a DEV environment.
How should they proceed?
We could list quite a few approaches to follow, but I will stress two of them. One uses a popular tool these days, containerization. It’s not the standard containerization you usually think of, however. When I envision containers, I usually see them implemented in the PROD environment. Here, we will talk about containers used for development, and they are different from those used in PROD. Remember this when we discuss development containers.
A second approach offers convenience of work that I don’t think is found in the first approach. This is available when using Linux on your Windows machine — but not using a virtual machine, as this approach, at least in my eyes, is far from convenient. Instead, this approach uses Windows Subsystem for Linux (WSL). I use it all the time, in almost all my projects — and I value it a lot.
Between the two, it is containerization that enables you to use a similar environment to PROD. Since WSL uses the Linux subsystem installed on your machine, simulating the PROD operating system is very difficult, often impossible, especially for several projects. The WSL’s main benefit is that it can be used in most projects, but this advantage can easily turn into a liability. We’ll return to this approach as soon as we’re done with development containers.
Development containers
As already mentioned, these are not the same as production containers: the former are used to develop product in the DEV environment while the latter are used to install the product (and its environment) in the PROD environment.
Development containers offer a dedicated development environment. Here, you may have unit tests, which are not needed in production containers. Likewise, you may need some additional packages that you do not need in production. Usually, development containers are organized differently than production ones. Simply put, you organize them just as you would have developed the code on your local machine, without containers.
Consider the following example. You develop your code so that it can be packaged once the code is ready. So, your development container will contain a folder in which you will keep the code to be packaged. Your production container, on the other hand, will not contain this raw code. Instead, this package will be installed inside the production container from a package registry. This causes the two types of containers to have very different organizational structures.
Usually, your development container will offer a similar environment to the production container environment. It can, however, contain other tools that are not needed in PROD. Hence, code that works just fine in the DEV environment does not have to work the same way in PROD — you need to check this. You can then test the production container, and for this, it’s great to have a TEST environment.
In my eyes, development containers make clear sense and can be very helpful. They do have one significant downside, however: Using them is difficult. On one hand, containers should behave the same way on various machines. On the other hand, they can pose some difficulties, especially when used on several Windows machines; the more machines, the greater the risk that something unexpected will happen. Sometimes it can be something really small, but finding a solution can be far more difficult than it can seem.
Windows Subsystem for Linux (WSL)
WSL offers a great way to emulate Linux in the Windows operating system. I’ve been using it for several years, and I appreciate it a lot.
When you choose a Windows machine with WSL installed on it, you can use both Windows and Linux. In many projects, you may need to be able to use Windows. When you have no choice and must use a Windows machine (which can be due to company resources), WSL is a great choice for developers, because as I mentioned before, most software products are deployed in Linux.
Many users do not have a choice, but I do: I could have chosen a Linux machine. Instead, I chose a Windows machine, and I did it for a reason. I did it because sometimes I simply have to be able to use Windows, for a variety of reasons. A Linux machine would be no help in such situations. So, I have Windows — and thanks to WSL, I also have Linux. Had I not had the possibility of using WSL, I would prefer to use a Linux machine. But ever since I can use WSL, I am totally fine with a Windows laptop.
I know, it makes a difference. WSL is not Linux. It isn’t as fast as real Linux. There can be differences, some less significant than others. But all of that does not pose any significant problem for me, as someone who develops code. For instance, WSL isn’t as fast as Linux? I develop code, not run it; so, that’s not a problem for me whatsoever. Other problems? Yes, I’ve had some minor issues (e.g., with line endings), but they were so easy to solve that I don’t even remember them well. And frankly, I did encounter one big issue with line endings, but it was in… a development container!
There is one more advantage of using a Windows machine with WSL. When you develop a product to be used in both OSes, you should check your product in both. While of course WSL is not really Linux (though WSL 2 does have a Linux kernel), when something works in WSL, it will most likely work in Linux. For example, I have authored or co-authored four open-source packages (easycheck, makepackage, perftester and rounder); I worked on each of them in WSL and then checked each in Windows.
All in all, when you develop in WSL, you can develop in an operating system in which the product will be developed (unless there is no WSL version with this OS). Once you’re done with installing WSL, all becomes simple. The most important IDEs cooperate with WSL. I use Visual Studio Code, and it works perfectly fine with it, thanks to a dedicated WSL extension. When I develop in WSL, I feel the same vibe of developing in Linux.
To be honest, now that I haven’t really developed anything significant in Windows for several years, I feel like a Linux guy. And whenever I move to a production environment, which is almost always in Linux, everything feels natural. If you have ever attempted to develop a product in Windows to be deployed in Linux, you know what I mean. I’ve been there, and it was not a nice feeling. It was like something deep inside the product seemed wrong, something that could lead to big problems. WSL is a nice painkiller, one that has changed my life as a developer for the better; actually, for the much, much better.
I’ve worked with both. Although it’s difficult to say which is better, I know which I prefer. This is why I will focus on my preferences and explain them. Then you can decide for yourself what you think will be better for your project.
To be honest, I would not choose development containers without a DevOps I trust. I wouldn’t know even how to start! With a good DevOps, development containers can be the best solution — but one that can, from time to time, slow down your coding work. In such situations, unless you know how to solve such problems, you may feel quite frustrated, as simple things do not seem to be solvable with simple solutions that you are almost sure should work.
I remember a project in which our DevOps orchestrated development containers in a two-person data science team, plus himself as a third member. While he did not have problems with this (kudos to him!), we did have some problems, and he had to help us from time to time. Once or twice I had to rebuild the whole container, as things stopped working, for no particular reason, and only reinstallation seemed to help. For me, it was difficult work. All of us had to use Visual Studio Code (not a problem for me, as I had used it before), with some container-related extensions.
I do remember a significant and unusual problem I encountered during that project. The DevOps eventually found the source of the problem, and it was Git. I used Git installed in WSL, the way I always do. Clearly, this Git tool did not cooperate well with our development container. Instead, I should have worked with Git bash. After I started using that, all such problems disappeared. I do not like such strange problems. To me, this example shows that development containers can be delicate — too delicate for my developer’s taste.
All in all, I think development containers offer a good solution, but can be too difficult for someone without strong DevOps knowledge. Without it, any installation and changes can seem difficult. And if you encounter a bigger problem, you may feel yourself helpless, the way I did several times during the project I described above.
WSL, on the other hand, offers a much simpler solution. You do not need to be a DevOps to install it on your machine. During the last several years, I have not encountered any problem in WSL that I could not solve myself. This suggests that the WSL-based solution is much simpler to use than development containers.
WSL does not come without cost, however. It offers you a Linux substitute, and that’s all. You have many packages installed there, and the chance that you will have the very same environment in your WSL and the production container is minimal. So, using WSL means working in Linux, not in the same — or even a quite similar — environment.
So, whether WSL will work for you or not depends on various factors, the two most important being your skills and the project itself. In many situations, it can be your solution, when minor details do not count that much. But if they do, development containers can offer you a greater chance that your product will work just fine.
We discussed two approaches to development software products in the DEV → TEST → PROD chain, but there are other approaches. I described two that I know and have used. If you know and have used other methods to develop a software product in a DEV environment under Windows, but which will be deployed in a PROD environment under Linux, then please describe it in the comments.
You may also have a different opinion on using development containers and WSL. Please, share it in the comments, too. This article aims to collect knowledge and opinion and convey it to others, but this topic is quite prone to subjectivity — what works for me does not have to work for you.
Denial of responsibility! Techno Blender is an automatic aggregator of the all world’s media. In each content, the hyperlink to the primary source is specified. All trademarks belong to their rightful owners, all materials to their authors. If you are the owner of the content and do not want us to publish your materials, please contact us by email – [email protected]. The content will be deleted within 24 hours.