Sun takes a leaf out of Apple’s book
Okay, boo hoo, Sun and MySQL got married with Jonathan wearing the oddest of wedding dresses and doing the oddest of post-wedding kisses. This has not drawn the warmest of bear hugs from the PostgreSQL fans (okay, I am one, shoot me!), newly uncertain in the fear of the loss of PostgreSQL’s status as Sun’s preferred OSS RDBMS mistress, now that MySQL has become the preferred OSS RDBMS partner.
The story, I am afraid, is not as simple as that. This move by Sun is not something that can be seen in isolation — it is a just piece of larger pie that Sun is chasing after, which is to recreate the Apple experience on open source software that scales seamlessly from one end of the market (the proof of concept) to the other extreme (enterprise-grade technology).
What Sun wants you to do is to get you started on OpenSolaris when you are a one-man start up, backed by a well integrated stack (they already have helped out the RoR community regarding their scaling woes) and watch you grow till the day you need the beefy servers and storage that is required by any reasonably large online business.
In the picture they are trying to patch together, the code and the components involved will work through this upgrade path without much change, resulting in near-zero disruption or refactoring on the code base. Essentially, what they are aiming for is to reproduce the Apple mantra “It just works” in a segment where such a feature would bring in considerable savings.
But why MySQL? Well, for one it is a proper company. Big companies and their boards love to buy things (especially when they are shelling out a billion dollars) which are a bit prim and propah. Moreover, it also makes it easier for them to integrate both operations. But, more than anything else, Sun needed a widely-used database to finish the stack — something it could own — and you can’t talk about ‘owning’ PostgreSQL without having a good laugh even while you are speaking about it.
Moving on, this is a play that is not meant for the current year. This is something that will only play out some two years down the line and these are the reasons why:
- There is nothing that stops the average start up from using the average $300 a pop dedicated server to flag off their operations and move into the monster servers and server farms at a later stage. But anyone who has done it will tell you that it is a painful experience for which there really is no manual you can look up and replicate.
- Software, by itself, is hard to tune. It is easy to write your first PHP script and run your website, but PHP itself can be tuned in different ways. There is a fair bit of learning that is repeated here with almost every start up and that is time and effort (translating into additional costs) that can be saved when cash is pretty sparse. The same is the case with HTTP servers, databases and application servers.
- A lot of software tuning is highly dependent on hardware. And at high performance levels, even marginal differences on every instance you run can result in significant savings. Moving from a 32 bit architecture to 64 bit architecture can result in significant heartache (let us not start into the ‘lib’ mess that Linux distros can get you into when moving from 32 bit to 64 bit), which is okay when you run about a dozen servers, but as you get closer to the three digit figure this can be a traumatic experience you’d not want to wish on even the worst of your enemies.
Now, imagine a vendor who can accomplish the same for you (also known as a very controlled environment), where things just work. If Sun can guarantee a pain-free seamless upgrade path from an OpenSolaris platform to Solaris proper that will run on Sun’s more expensive rigs, they would have a winner on their hands. And that is the sweet spot Sun is aiming to be in two years.
Related: Give Me a M: The MySQL/Sun Q&A