It has taken us a little more than two years and a half to bring an official version of Sql Server to Linux. Over the course of our work we have been surrounded by lots of supporters, bystanders, skeptics and pessimists. Quite of few things had to turn our way for us to succeed. However, on engineering side, we have cooked a secrete sauce that has played 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. It is a fascinating read. It provides very good, in depth perspective on the matter.
First time I ran across this article right after rejoining SQL Server team, late winter of 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 matters, Hal's article highlights key drawbacks which 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 compare to the additional work that the journey would require. Indeed, in order for the project to be successful the team would have to:
- Bring other SQL Server inbox products such as SSAS along
- Implement platform specific features such as CLR, AGs, and much more
- Guarantee adequate performance and scalability
- Create new ecosystem around product support, engineering systems and more.
So throughout the course of the work, 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 inbox products to Linux such as SSIS.
- 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.
This post first appeared on MSDN Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The MSDN Blogs., please read the originial post: here