3 ms·

Virtualization is very good at handling consolidation of legacy systems. Which means that your 10 old servers, running various unix and windows versions and har

by ithkuil 12y ago

Virtualization is very good at handling consolidation of legacy systems. Which means that your 10 old servers, running various unix and windows versions and hardware whose spare parts are difficult to find, can be easily replaced by a single modern machine, usually not even particularly beefy by modern standards. It solves a lot of problems in small to medium companies; it's an answer to a desperate call for help of sysadmins too tired to hunt 15 years old cpu fans on ebay, and managers hearing always the same infernal stories about what it's like to do anything down in the basement. It solves the problem of the same small to medium companies having to buy new hardware for each application they buy, usually because the vendor tells them to do so. Many software started to get shipped as a whole OS stack, because that was easier for the vendor to support. It solves many other problems, but let's stop here. These problems are going to stay, and so will virtualization. However containers offer a way to isolate your environment so that they can survive longer and coexist better with other apps. If you build your environments using those building blocks, then after 10 years, you'll have a slightly smaller mess (which you can still handle with virtualization). If you really have a lot of machines then, you need to have a good system for managing your hardware, for bulk installation etc. You have to manage new kernel and container management software rollouts in more or less the same way you'd need to manage hypervisor rollouts. But since you have a lot machines, which means that you encounter hardware failure more often, the relatively higher frequency of kernel and container management software updates has still a smaller cost than virtualization overhead (provided you have enough machines). Or put in another way, virtualization overhead is negligible if you're a small fish. It's cheaper for you to buy more machines or a stronger machines if all you need is to cover for that overhead.

KaiserPro 12y ago
As someone who battles legacy at scale everyday, Its rarely the platform that is the trouble. For example, I have a nasty little calendar script that I have to move. The rest of the app is long dead, but this one little worm keeps on biting. It uses regex to parse XML. (insert cuthulu joke here) its based on php5.old I need to move it to 5.new+secure. The OS has an update function that is know, tested, documented and works. I can install a new RPM/deb and be fairly sure it'll work if it installs Standalone apps, in the way that people are building them wont. Conatainers rely on the underlying operating system for various things. Any exceptions are bundled with the app. a true VM is free to be moved to a new host, a container is not. You are hamstrung to that machine and possibly that config. So If you built the farm on docker, you're stuck with it, on that hardware. unless you want down time, or was to re-engineer things
- ithkuil 12y ago
  > Standalone apps, in the way that people are building them wont. Conatainers rely on the underlying operating system for various things. Any exceptions are bundled with the app. I don't understand. I assume that for "underlying operating system" you mean the OS that hosts containers. Unless you depend on some OS specific things like iptables or stuff like that, it should be trivial to rebuild a container (e.g. make a new docker image with a new php) and test it. Containers are not so great if you migrate into container software that has not been packaged for containers in the first place. It's not that it won't work, but it's easy to find example where you could run into troubles. The whole point of solutions like docker is to give you the consistent environment that will help you to test your changes in isolation. > [...] The OS has an update function that is know, tested, documented and works. I can install a new RPM/deb and be fairly sure it'll work if it installs Until you have a distro that's too out of date for that to work properly. The same thing happens if you use containers with too much of an "OS" in it. There is currently a lot of debate about what's the right balance between microcontainers or full fledged mini-OS inside a container. On one end of the spectrum you move your problem to container orchestration, while on the other you risk breaking the isolation abstraction provided by the container by running an OS that doesn't have full control on it's environment (e.g. kernel, disks etc) and thus breaking the guarantee that existing upgrade tooling will work flawlessly. > a true VM is free to be moved to a new host, a container is not. You are hamstrung to that machine and possibly that config. > So If you built the farm on docker, you're stuck with it, on that hardware. unless you want down time, or was to re-engineer things That's true, only a VM will guarantee that an arbitrary legacy application can be moved to a different physical machine in face of arbitrary incompatible developments in the underlying hardware. Well, if you want to stretch that to the extreme, only a full emulator can guarantee that you will be able to run your legacy things on a completely different CPU architecture. However, you must be aware that VM offer you a way to acquire a technical debt, which is great in that it allows you to decouple your immediate hardware upgrade needs from your software reengineering, but you must be aware that you'd have to pay off this debt. I have a 15 years old mandrake linux VM with some legacy software. It's well known, tested and documented update system won't help me maintain the mess that's inside that VM.

by ithkuil 12y ago

KaiserPro 12y ago

As someone who battles legacy at scale everyday, Its rarely the platform that is the trouble. For example, I have a nasty little calendar script that I have to move. The rest of the app is long dead, but this one little worm keeps on biting. It uses regex to parse XML. (insert cuthulu joke here) its based on php5.old I need to move it to 5.new+secure. The OS has an update function that is know, tested, documented and works. I can install a new RPM/deb and be fairly sure it'll work if it installs Standalone apps, in the way that people are building them wont. Conatainers rely on the underlying operating system for various things. Any exceptions are bundled with the app. a true VM is free to be moved to a new host, a container is not. You are hamstrung to that machine and possibly that config. So If you built the farm on docker, you're stuck with it, on that hardware. unless you want down time, or was to re-engineer things

ithkuil 12y ago
> Standalone apps, in the way that people are building them wont. Conatainers rely on the underlying operating system for various things. Any exceptions are bundled with the app. I don't understand. I assume that for "underlying operating system" you mean the OS that hosts containers. Unless you depend on some OS specific things like iptables or stuff like that, it should be trivial to rebuild a container (e.g. make a new docker image with a new php) and test it. Containers are not so great if you migrate into container software that has not been packaged for containers in the first place. It's not that it won't work, but it's easy to find example where you could run into troubles. The whole point of solutions like docker is to give you the consistent environment that will help you to test your changes in isolation. > [...] The OS has an update function that is know, tested, documented and works. I can install a new RPM/deb and be fairly sure it'll work if it installs Until you have a distro that's too out of date for that to work properly. The same thing happens if you use containers with too much of an "OS" in it. There is currently a lot of debate about what's the right balance between microcontainers or full fledged mini-OS inside a container. On one end of the spectrum you move your problem to container orchestration, while on the other you risk breaking the isolation abstraction provided by the container by running an OS that doesn't have full control on it's environment (e.g. kernel, disks etc) and thus breaking the guarantee that existing upgrade tooling will work flawlessly. > a true VM is free to be moved to a new host, a container is not. You are hamstrung to that machine and possibly that config. > So If you built the farm on docker, you're stuck with it, on that hardware. unless you want down time, or was to re-engineer things That's true, only a VM will guarantee that an arbitrary legacy application can be moved to a different physical machine in face of arbitrary incompatible developments in the underlying hardware. Well, if you want to stretch that to the extreme, only a full emulator can guarantee that you will be able to run your legacy things on a completely different CPU architecture. However, you must be aware that VM offer you a way to acquire a technical debt, which is great in that it allows you to decouple your immediate hardware upgrade needs from your software reengineering, but you must be aware that you'd have to pay off this debt. I have a 15 years old mandrake linux VM with some legacy software. It's well known, tested and documented update system won't help me maintain the mess that's inside that VM.