The decision to support anything new in the enterprise infrastructure space, given that you'll often be asked to support it for (literally) decades, is non-trivial even when you only have one platform to worry about. But especially when the second (or nth) platform in question has very different end-user expectations for usage conventions, documentation, scriptability, etc...it takes a very special partner opportunity (or end-customer so huge that it might as well be a partner opportunity) to make it worth pulling the trigger.
Databases in particular strike me as poor candidates, because the space is so hotly contested by organizations capable of research-class CS and deep optimization. So of all the things you might port to a new platform, MS SQL Server (a platform in itself) represents an enormous risk.
Red Hat (the company I work for) sells quite narrow products. For example, we'll sell you and support PostgreSQL but only on Red Hat Enterprise Linux, or KVM but only on x86-64. Upstream, PostgreSQL runs on BSD, Windows and a zillion other platforms. KVM supports i386, S/390, PPC and a few others.
You can either be a customer, or you can port yourself / find another partner to make the code work on other platforms. This only works because it's open source software.
I don't doubt the author is reliably recalling what happened but I do doubt that Microsoft would have ever released an enterprise product for *nix. This would have eventually had to be decided at the Gates level and I don't think he would have ever undermined Windows with a tacit admission that it could not meet every customer need.
>> The first order engineering of making that happen, assuming you disable some Windows-specific functionality, was rather small (on the order of a few manweeks).
I have a hard time believing that. I used to write to the Windows internals API a lot (the kind of stuff you see on sysinternals), and I can't imagine the sql server team not doing the same. That stuff was not easily ported to Linux, at least in the late 90's / early 00's.
The guts of SQL Server were (and as far as I know still are) a RDBMS named Sybase that MS bought sometime in the mid '90s. Sybase ran perfectly fine on Unix, just without all the GUI crap.
That had the ring of truth to me, and I've done a significant amount of porting to IBM z/OS and IBM System i (each of which have a lot higher 'weirdness' quotient than NT --> Unix.
If there is a compiler on the platform for the language in which the product is authored, getting core functionality standing up and walking can often be accomplished in a shockingly short timeframe. Getting things to run well, properly documented, interfacing as desired with other components on the system, and effectively marketed to a different audience...much harder and time/resource intensive.
Exactly what i thought. Plus, from a marketing point of view, porting sqlserver to unix would have been suicide for Microsoft given their primary objective (for what concernes the server market) since XP is to enlarge their market to the server world. sqlserver is the main reason to have a windows machine at all if your team develops with .NET.
I disagree. The main reasons I develop in .NET (as opposed to Mono) are tooling and performance. SQL Server is helpful in the cases where I need a RDBMS, but connecting to one's database of choice is generally painless.
Slightly tangential - I didn't realize that this was Hal Berenson's blog. This is an individual who carried serious clout within MSFT. All his other posts are great reading too for an insider perspective on lots of things Microsoft.
Could someone pleae correct the title to read "Why Microsoft SQL Server was never ported to Unix" rather than the more general term SQL server (which Microsoft would no doubt be delighted to assume as its own...)
The most interesting part of this article to me was the description of the problem with sales. I think it provides a great insight into the thinking of large companies like Microsoft and why they're decisions are sometimes baffling to those of us not working at huge corporations. He mentions that a sales person going after $100k contracts would not make their quota and lose money for MS. I guess I shouldn't have been surprised but it seems pretty crazy.
It also kinda confirms what we already know - that every department of MS is geared towards pushing their whole software stack and to change would be like trying to redirect an iceberg.
Isn't the answer to that question trivial? Microsoft needed Windows monoculture to succeed and the way to do that is to completely and totally strangle any Windows customers so they could not move to something else without basically starting over.
Aw c'mon, at least read the article and don't trot out a knee-jerk argument. It makes many valid points about how well Microsoft could really succeed in selling a Unix-hosted product when their heart was in Windows. Just by flipping the question around I think it buries the issue pretty well: If your Unix enterprise app needed a SQL server, why would you look to Microsoft?
Why wouldn't you? Microsoft is a major software vendor. If they make a solid DB for Unix, why not consider it alongside Oracle and other major software vendor's offerings? You would consider it on the merits of the product.
None of the reasons in the article make much sense to me except for the one left for last, that it just doesn't make overall strategic sense for Microsoft: Microsoft's model is pushing Windows, and selling SQL Server for an alternative OS is a bad idea (it's a good idea for SQL Server revenue, but bad for overall Microsoft revenue).
As others said, Gates would have veto'd SQL Server for Unix, that's the bottom line.
>I had full executive support in investigating a port, but had I brought forth a proposal to proceed I would have faced arguments from many that I was undermining Microsoft’s entire business plan.
Yes, you're right. That's what it was actually about. MS was (and still is) trying to kill all competition. Building products for the competition is a sort of approval and a confirmation that the particular product is worth using.
Interesting exploration of the business issues, and, for Microsoft, I can understand this.
It does contrast rather strongly, though, with the experience of Oracle and Informix trialing their first Linux ports. "We just typed 'make'" was the quote out of Oracle at the time. While I'm reasonably confident that there has been a bit of platform-specific tuning since then, the point is that writing code for a standards-based platform (UNIX and POSIX) made porting to a new target pretty straightforward.
This is just sugar coating for the crap they're covering.
I'd reduce it all down to: we didn't want people to use SQL Server on *NIX because we wanted to sell them expensive OS licenses & licenses for other products.
>environment no one really knows nor cares what the underlying OS is. SQL Azure thus becomes Microsoft’s answer for those who don’t want to run an in-house Windows Server just so they can run SQL Server.
Nope, not really, I do care about the database and about the underlying OS. I don't like to use Windows for web hosting mainly due to its unpredictable HDD space usage (Windows folder growth vs number of installed updates over time).
Also, in Microsoft land, it's pretty difficult to be "up to date" with everything. You install hundreds of updates for the OS, the database and other components and there are some extra hotfixes you normally get when you have a support contract with them.
There's also the issue of the performance. You need more hardware for Windows than for other OSes. I had an "enterprise" CRM we will not name which had low performance on a Windows 2008 R1 Standard. I tried to upgrade it to R2 and the CRM stopped working completely. Of course, this wasn't done on the production box.
"""This is just sugar coating for the crap they're covering."""
Yes, please, do reduce an elaborate article discussing technical and business trade-offs into a silly anti-MS rant that wouldn't be out of place in Slashdot circa 1999 for us.
>I had full executive support in investigating a port, but had I brought forth a proposal to proceed I would have faced arguments from many that I was undermining Microsoft’s entire business plan.
See? Read that part "I was undermining Microsoft's entire business plan", please. That also includes the monoculture and the perfect vendor lock in.
The main issue is that you can't easily move to another platform when your entire app / system runs on MS software. If you use Oracle's DB or something else for an app with a DB, you could move away from Windows if you decided to, provided you are ready to and can make the required changes to your app's code.
As for "my rant", it looks like the porting to *NIX was just an idea, not something they were seriously considering. I never expected them to do it because some people would choose not to buy Windows licenses and just buy SQL Server licenses, not both.
That's hardly a rant. It's just the long story of MS vs. the "viral" open source / free software.
I could have sworn that way way way back when MS-SQLServer just started out it was a "fork" of Sybase Unix code??? I kinda remember that happening in like the 90's and then like usual Microsloth screwed it's partner (Then Sybase that did a lot of the work on the initial windows port)
Of course I maybe having some sort of strange drug induced flashback but kinda remember this?
TFA states as much: When someone says Microsoft SQL Server you could think of two things. One is the relational server(sqlservr.exe) that has its origins at Sybase and was re-written by Microsoft to produce Microsoft SQL Server 7.0 and later versions.
At least in my community, when you talk about "sql server" it's obvious that you're talking about MS SQL Server. In the same way, postgreSQL is "postgres" and Oracle Database is just "oracle".
That community being people who already know about the brand. I say it every day at work, too, but the OP still has a valid point for public discussion.
I don't know about your culture, but I've never heard anyone use 'sql server' when they meant 'the database server'. You just don't call it that. I also think it's a pretty dumb product name. You might as well call a web server 'html server'.
People not familiar is Microsoft are probably not taking part in a discussion on HackerNews, let alone a discussion of why their SQL Server product was not ported to *nix.
The decision to support anything new in the enterprise infrastructure space, given that you'll often be asked to support it for (literally) decades, is non-trivial even when you only have one platform to worry about. But especially when the second (or nth) platform in question has very different end-user expectations for usage conventions, documentation, scriptability, etc...it takes a very special partner opportunity (or end-customer so huge that it might as well be a partner opportunity) to make it worth pulling the trigger.
Databases in particular strike me as poor candidates, because the space is so hotly contested by organizations capable of research-class CS and deep optimization. So of all the things you might port to a new platform, MS SQL Server (a platform in itself) represents an enormous risk.