Today I'd like to talk to you about isolation. Not, as some of you might expect given the topics of my more recent ramblings, about personal isolation - but about software isolation.

Software isolation means different things to different people; from something as common as process isolation which happens on almost every computing platform in the modern world, to something less common such virtual machines provided by hypervisors. For today, let's focus on stuff closer to the latter than the former.

Isolating software has, as in all things, both pros and cons. Briefly, some of the reasons you might want to not consider software isolation may include:

1. It's generally harder work to write software to be isolated easily.
2. Each isolation point is "yet more" software which either has to be written or at least has to be managed by your operations team.
3. If you take a complex system, and distribute it among isolated systems, then you have a more complex system than before.

But, since I'm not going to be a Danny Downer today, let's think more about the benefits. Here are three benefits to counter the detractions I listed above.

1. An isolated software system must have well defined inputs and outputs which can be more effectively documented, mocked, and tested. Leading to:
   1. More easily tested and verified
   2. Easier to debug
   3. Easier to properly document
2. An isolated software system cannot interfere indirectly with any other software system sharing the same hardware or other infrastructure.
3. A system comprised of multiple isolated intercommunicating software systems can be more effectively distributed and thus horizontally scaled.

There are any number of different ways to isolate your software systems from one another. These range in "weight" and "completeness of isolation":

• At the "lightest weight" end of things, we're looking at software written in languages which support virtual environments. This might be Python's venv, Ruby's rvm, or something like luaenv for Lua. These give you only as much isolation as the language's virtual environment support extends to (typically just for the dependencies provided in the language itself).

• Next we might consider chroots which give you filesystem isolation but very little else. This lets you keep the non-language-specific dependencies isolated too, since effectively a chroot is able to be anything from "just enough to run your app" up to a full install of the "user space" of your operating system.

• Building from the chroot context, we can reach for a little more isolation in the form of containers. On Linux, these can be managed by such tools as Docker, LXC, systemd-nspawn, or rkt. This approach uses the Linux kernel namespacing facilities to provide further isolation between containers than the above options can do.

• If containers don't provide enough isolation for you, then you might proceed to hypervisors such as kvm via libvirt, or if you're in a desktop situation then perhaps virtualbox. There're plenty more hypervisors out there though. Hypervisors isolate at the "hardware" level. They effectively provide independently operating virtual hardware elements in the form of emulated hard drives, video cards, etc. Such that the kernel and underlying operating system run just as though they were on real hardware.

• The final isolation option if not even hypervisors cut it for you, is, of course, simply to have more than one computer and run each piece of your software system on a different machine.

There are any number of software packages out there to help you manage your isolated software environments. From schroot for chroots, through the container providers linked above, and on to hypervisor options. But what's even more exciting, as you start to think about scaling your software horizontally, is that there's also any number of providers out there offering services where they look after the hardware and the management layer, and you get to deploy isolated software elements onto their platform (usually for a fee). These might be hypervisor based virtualisation on Amazon AWS, or any number of providers using Openstack. Where it gets taken to the next level though is that those providers are starting to offer a range of isolation techniques, from containers upward, so whatever your needs, there will be software and providers out there to help you with software isolation.

Your homework… (What? You surely didn't think that just because it's a new year you wouldn't get any homework on the first day?) …is to think about any software systems you're responsible for, and whether they might benefit from having their elements isolated from one another more effectively, so that you might glean some of the benefits of isolation.