August 29, 2017 | Updated: July 27, 2022
The Brown University Computer Science Department was a Sun Microsystems shop when I was an undergraduate there in the late 90s. When I took the operating systems lab class, CS-169, we implemented a toy version of Sun’s research operating system Spring OS. Several of my contemporaries in the CS Department went on to work at Sun, and developed or advanced many of the technologies that made Solaris great, like ZFS, dtrace, libumem, mdb, doors, and zones. The Solaris Linkers and Libraries Guide remains one of the best ways to develop an understanding of shared library internals. The first startup I worked for developed on Solaris x86, because the team knew Solaris well. Today, many of my co-workers on the server engineering team here at MongoDB share that formative experience with Solaris. We have a great deal of collective nostalgia and appreciation for Solaris and the amazing engineering effort that went into its development.
So it is, for many of us at MongoDB, bittersweet to announce that MongoDB is terminating support for Solaris.
Effective immediately, we plan to cease production of new builds of MongoDB for Solaris, across all supported versions of MongoDB. Existing release artifacts for Solaris will continue to be made available, but no new releases will be issued, barring a critical issue raised under an existing support contract covering MongoDB versions 3.0 through 3.4 running on Solaris. We will continue to fix critical flaws for the community, regardless of where found or how reported. Anyone can report a security vulnerability by using our Security project to create an account, then a ticket, describing the vulnerability.
This was not an easy decision for us to make, and we feel that it is important to provide some background on why we have made what may seem at first to be a capricious decision.
The principal reason for us to drop Solaris support is simply a lack of adoption among our user base. Of our commercial users, we knew of only a handful who had ever been running on Solaris, and all confirmed that they had migrated away, or were in the process of doing so. Our download numbers for our Solaris builds confirmed this lack of interest, as did stats gathered from our managed operations tools — we find about 0.06% (and decreasing) of MongoDB users are running on Solaris.
Additionally, we found that the cost to continue to support Solaris was very high, and that it was increasingly becoming an obstacle to developer productivity. Among the difficulties we experienced:
The ecosystem is fragmented: You say you want to run on “Solaris”. OK, fine, but which one? Illumos? OpenSolaris? OpenIndiana? SmartOS? Oracle Solaris? OmniOS? Do we release for one of those? If so, which one? All? How do versions relate across them? What is the level of binary compatibility? Which versions do we need to support, on which variants? How do we certify that we support all of them? Linux suffers (or even benefits) from a similar profusion of flavors, but we have a significant population of users on each of the major different flavors, so it makes sense to explicitly support them all. Not so for the numerous Solaris variants.
Our development tools work poorly on Solaris: Clang doesn’t support Solaris at all, as far as we can tell. Golang doesn’t consider it a first-class platform. GDB seems unable to handle the simplest of tasks when confronted with threads on Solaris. GCC appears to not fully support important C++11 features like the thread_local keyword, due to missing support in the Solaris C library, at least on the versions we used. Obviously, all of those could be fixed if there were a pressing commercial upside to doing so, but we don’t see that to be the case.
Lack of developer familiarity: While several of our senior developers know their way around Solaris well, our junior devs have never touched it. Investing in teaching them is of questionable value. Sometimes, though we try hard to scrub them out, we find that some tests are flaky. Sometimes a failure exhibits on Solaris, but the issue isn’t specific to that platform. Should we be investing the time of our most seasoned engineers to track these down to prove that they aren’t Solaris specific?
Operational difficulties: Most of our CI testing is done in AWS. On multiple occasions, our Solaris images have simply stopped working, and repairing them took significant engineering work. The most recent outage was particularly troublesome and time consuming. The engineering effort required to sustain the platform does not seem warranted.
The future of Oracle Solaris, perhaps the one true Solaris if you had to pick one, is murky at best.
While no single one of these issues seems sufficient on its own to argue for terminating support for Solaris, when combined with the observed lack of interest or use, it makes for a compelling case. We would rather invest our time and effort developing for the platforms that our users actually use. So, with some real sadness and fond memories, we have decided to say goodbye to Solaris.
We will miss you, Solaris, but it is time we parted ways.