Share via

What made Porting Microsoft SQL Server to Linux to be the right move after all

  • Article

It has taken us a little more than two and a half years to bring an official version of SQL Server to Linux. Over the course of our work, we encountered many supporters, bystanders, skeptics, and pessimists. Quite of few things had to turn our way for us to succeed. Notably, on the engineering side, we have cooked a secret sauce that has played an essential role and proven to be the game changer.

In July of 2011, Hal Berenson published this very insightful article of why MSFT had decided not to bring SQL Server to *nix platform back in times. This article is a fascinating read and provides an excellent and in-depth perspective on the matter.

The first time I came across this article was right after rejoining the SQL Server team in late 2015. It did catch my attention, especially since I did come back to do what Hal's in-depth analysis urges us from doing. In the last couple of years, I reread the article multiple times. I have used it as a guide, checklist, to make sure we address the key points.

In addition to business concerns, Hal's article highlights key drawbacks that would additionally need to be addressed around engineering as well as product supportability for the endeavor to be successful. The article affirms that bringing SQL Server to *nix platform is not the hardest task compared to the additional work that the journey would require. Indeed, for the project to be successful the team would have to:

  • Bring other SQL Server inbox products such as SSAS, SSIS, and SSRS along
  • Implement platform-specific features such as CLR, AGs, and much more
  • Guarantee adequate performance and scalability
  • Create a new ecosystem around product support, engineering systems, and more.

So throughout the project, I have continued to question the path we have been on and if we succeed at the end or not. Every time I would go back, reread the article and every time I would come to the same favorable conclusion. But why?

The answer is rather simple. It is due to our secret sauce: SQLPAL, aka SQL Platform Abstraction Layer.  SQLPAL has enabled us to address and overcome all the engineering difficulties the article uncovers. With SQLPAL at hand, we have managed to address all drawbacks Hal's article touches upon and much more:

  • It enabled us to bring other SQL Server products like SSIS to Linux
  • It enabled majority of the SQL Server team to continue focusing  on core  features;  operating with cloud first mentality; delivering  SQL Azure and SQL DW m0nthly. At the same time a team that has been responsible for brining SQL Server to Linux remained small and focused on system level work rather than porting other teams changes.
  • It helped us to bring SQL Server scalability and performance to Linux. Over the years we have tuned SQL Server to run efficiently on enterprise grade hardware. With only few changes in SQLPAL and no changes to the core engine, we have unleashed SQL Server's beast mode on Linux.
  • It simplified investments around supportability.  Few people know that while running on Linux, SQL Server generates the same supportability artifacts as on Windows. The approach significantly simplifies supportability story on multiple platforms.  And magically, SQL Server engineers continue leveraging the same tools for debugging even if core-dumps come from Linux.

SQLPAL is the essential technological piece that, at the end, made porting SQL Server to Linux to be the right move. Sometimes, I wonder if Hal and the team had had the technology in their possession back then if they would have proceeded with the work or not.  Fortunately for us, they hadn't.

Comments

  • Anonymous
    September 25, 2017
    The comment has been removed
    • Anonymous
      September 25, 2017
      We will do our best to make sure history doesn't repeat itself. Thank you!