First, let’s begin with what containers are. There are a number of mature container technologies in use today, but Docker has been the long time leader. To many, the name “Docker” is synonymous with “container,” so looking at their explanation would be a good idea.
“A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.”
Even among IT professionals, there seems to be some confusion for people who haven’t actually used this technology. Most of us have heard of containers. We may have them powering applications in the workplace, yet still don’t really understand them. People that have mostly wrapped their heads around what virtual machines are, might still have trouble understanding container technology.
Virtual machines run on virtualized hardware, which can cause a pretty significant performance hit for RAM/CPU/Disk/ and other virtualized resources. An operating system needs to be installed on the virtual machine. This can take up a large amount of disk space and system resources used by the operating system. This adds up quickly, especially with a lot of virtual machines.
Operating systems also need to boot up before they can run applications. This can introduce quite a bit of delay. Containers simply put just run applications on a virtual operating system. They don’t need to boot up, and can be spun up in seconds.
This still may be about as clear as mud for some, so I’ll break this down to a very basic level. A container is just a portable application. That might be a bit basic of an explanation, but it is still pretty accurate in my opinion.
Designing microservices, that run on multiple clouds, at scale, and orchestrated by something like Kubernetes is outside the scope of what I’d like to cover in a blog post. There is also a lot of material out there on this topic. Instead, I’ll propose a more obscure use case – running legacy software.
It isn’t pretty, but the reality is that sometimes legacy systems are still a thing. Some easy examples to pick on are legacy PBX(phone system) applications or building control applications. Those don’t normally generate revenue, but losing control of your phone system or HVAC system could definitely be an issue.
A more extreme example would be revenue generating, line of business applications that just have no suitable replacement. Maybe there is a suitable replacement, but the cost is just too prohibitively expensive when your old system still works great. Perhaps there are licensing cost changes, or having to buy large quantities of new IP phones to run on a modern PBX just isn’t in the budget. Some of these just cannot run on anything past End Of Life Windows versions such as Windows 2003, 2000, or even NT(YIKES!!!). The software vendor that designed these might have gone out of business, and these systems just never got around to being replaced because they just work and generate revenue.
Among many other problems, running end of life software, on end of life operating systems, is a HUGE security issue. It is difficult, if not impossible to prevent an attack using known exploits that are simply un-patchable.
What is a better way? You can run Windows applications using WINE (originally a backronym for “Wine Is Not an Emulator”), in a Linux container! This solves a lot of security issues related to the operating system. The “What happens if my 15 year old server dies?” also is solved. If you really wanted to, you could even put that antiquated application in the cloud.
Configuring WINE is also out of scope for what I’d like to cover in this post, but there is plenty information out there. Rather than pick on out of business software vendors, I “containerized” a few Windows applications that are freely available which I have actually encountered being used for actual business use. We can just pretend that they are no longer supported, and have no suitable replacement for demo purposes.
PingInfoView (a ping monitoring tool)
notepad++ (a text editor used by some systems/network/software engineers)
To tie it all together visually, here is a screenshot demonstrating these running on my CentOS Linux laptop:
To demonstrate that these are actually running as containers, please take notice of the container ID listed at the top of the application window(8b5f36fff598 and 5cd664be8a7b). These are listed in the output of “docker ps” and shown in the filtered output of the Linux process monitor “top.” These could be easily moved to another machine running different distribution of Linux, and perhaps into a random server on your favorite cloud host.
I hope you enjoyed this example of a fun, not so common container use case. Need help designing your infrastructure to power your applications? The friendly engineers at Zunesis have the expertise to help. Contact us today!