What is an IDE?
Frequent problems
If you used IDEs before, you probably faced at least some of the following:
- The error-prone and time-consuming setup process
- Tools are hardcoded into IDEs
- More instances of the same tool
- Difficult IDE and tool version management
- The IDEs enforce the use of their UI
One of the biggest disadvantages of IDEs
From the list above the second is a crucial problem if you want to create a well-managed infrastructure. When working with IDEs, you cannot easily use the underlying integrated tools separately. They usually depend on the IDE or each other, so standalone usage can be problematic and the whole IDE installation is required.
Problem #1: When navigating multiple projects
Let's say at your company the developers have to work on different projects simultaneously, switching between tools even daily.
If they want to keep all the needed tools on their PCs at the same time, more issues can occur:
- A lot of duplications - storage-consuming
- Tools can interfere
- Version management of the tools is crazy
Re-installing an IDE every time to switch tools is time-consuming and let's face it: most developers don't like operational tasks.
To avoid the re-installation of whole IDEs somehow we have to reduce the dependencies between the tools and provide the possibility of standalone usage.
Problem #2: "It works on MY PC!"
Even if you are not project-based, you probably heard your co-worker say, "I don't know what's wrong with your installation. It works on my PC!"
When setting up your Development Environment the process is unpredictable. Two of the annoying scenarios:
- Everything works smoothly on the first try. (But you already sense something will go wrong and the worst is you don't even see what. You start praying to the gods of tech.)
- Random errors during development. It can be painful to discover after days of debugging that an environment variable had a different value for some obscure reason.
Isolating tools: Containerization
Virtual Machine vs. Container
- A VM runs as a standalone OS on top of the host OS
- The container uses the shared resources of the host OS
- Different lifetime: a VM is persistent, a container only exists while needed
Unveiling the Advantages
Now that we have all the tools in containers on our PC, after setting up the communication between them we have an optimized Development Environment. The advantages of an optimized DevEnv:
- Easy and quick setup process
- Tools are not hardcoded into IDEs anymore, standalone usage is possible
- Keeping one instance of a tool is enough
- The same tool with different versions can be present on our host
- The developer is free to choose her favorite editor
- No interference between the tools
- Communication between the tool and the host can be controlled
Containerization gives flexibility, portability, reproducibility, and scalability to embedded software development and is a key when creating optimized Development Environments.
A little extra: Optimized Hybrid Development Environment
What is a Hybrid Development Environment?
We call a Development Environment Hybrid when the tools part of the DevEnv are not running in the same place. For example, a debugger is running on an SBC, or a build system is running in a cloud environment.
Containerization in a Hybrid Development Environment
In this case, the client side of the chosen editor is running on the developer's PC, while the editor's server side, the build system, and the toolchain are deployed in the cloud. The project also has a Debugger or Flasher running on an SBC, depending on the state of development.
This example makes one of the greatest advantages of containerization clear: Containerized tools can move across physical and cloud environments easily. As the embedded development landscape continues to evolve, containerization is likely to become an even more significant player in enabling efficient and effective development practices for embedded systems.
Top comments (0)