FreeNAS 10 Impacted by the Jurassic Park Effect
In the news today is the revelation that iX, the makers of FreeNAS, had to pull FreeNAS 10, also known as FreeNAS Coral, off of the market a month after it was first released due to widespread stability issues. This is a rather epic failure for the FreeNAS project that was already dramatically behind in their underlying code base and has been taking heat for this for quite some time. What is important here is that the underlying system on which FreeNAS is based, FreeBSD, does not share the instabilities that FreeNAS has. The problems that FreeNAS are facing are ones introduced by the extra, and unnecessary, FreeNAS layer on top of FreeBSD.
As discussed in my 2015 paper The Jurassic Park Effect there are dangers when you start tacking on third party products on top of your enterprise platforms, especially when we are talking about storage where stability matters more than anything. Adding additional software increases risk in several vectors. It means more code to maintain, more things to go wrong and more surface to attack.
In FreeNAS’ case, the extra layers of code are critical to the system working. They are not ancillary code bits that have little chance of impacting the production system like would be common with a small utility, but represent the total interface of the system and completely control of all functions. Any problems with the FreeNAS interface can turn into stability problems for the FreeBSD platform under the hood.
At the best of times we do not normally want to run a GUI on top of our servers, let alone our storage servers. And that is if we assume that the GUI is an enterprise one that is integrated by the OEM platform vendor and gets enterprise level support and integration like you might get from Gnome 3 on RHEL or KDE on SLES. But with FreeNAS the GUI that we work with is a small time third party add on product that is not included with, supported by or, most importantly, tested by the FreeBSD team. The resources available to projects such as FreeNAS are fractional compared to those of enterprise operating systems. And the scale of public beta testing is minuscule as well. Any risk existing in FreeBSD is not addressed by this extra layer, so any risk introduced by FreeNAS itself is additional and compounded with the previously existing risk. This risk is unnecessary as FreeNAS does not add new features or functionality, only overhead and risk.
In most cases this additional risk is not an issue, or at least we do not realize it. But risk is always a problem, that is the nature of risk. In the latest release however, FreeNAS’ risk proved to be more than “background noise” and has proven to be so significant that the product had to be recalled and demoted from a production release to a testing one. Rarely does any product have to go through such a recall and demotion. This is a blow to FreeNAS in many ways.
This demotion is a very public humiliation for FreeNAS, as a storage product it depends on a reputation of stability and reliability. It hits both at the product itself as well as at the processes for testing that FreeNAS have used. This will likely highlight for many potential users that there are concerns around having small, unnecessary critical path components in the “reliability chain” in such a dangerous way. Users of FreeNAS are currently forced to either remain on a known unstable platform, or move backwards to a quite old platform that would be unnecessary if using FreeBSD directly.
