When Windows Server 2012 came out with Core, I heard some rather suspicious things at conferences like:
- “I’ll be able to take way less patching outages!”
- “It’ll be so much faster because it has less overhead!”
- “Everyone will learn automation and be more powerful!”
- “It’s the way of the future! Learn it or your career is doomed!”
As you know today, the promise didn’t match the reality. Most people don’t use Windows because it’s hard – they use it because it’s easy, and because working on their servers feels just like working on their desktops. Having a Windows GUI solves their administration problems, whereas learning a new language to do basic troubleshooting causes problems. There just wasn’t a big enough base of DBA staff who knew both SQL Server and PowerShell.
The market has spoken: I see SQL Server running on Windows Core less often than I see hairy men walking city streets wearing nothing but shock collars. (I live in a weird neighborhood.)
This year, the buzz will be back.
SQL Server 2017 runs on Linux, and the similarities between that and Windows Core are eerie:
- Both present big stumbling blocks for traditional Windows DBAs
- Both work mostly the same, but not exactly, as you can see in the SQL Server on Linux release notes
- Both solved perceived problems for sysadmins
- Neither solved a problem for database administrators
So why will you hear so much more about Linux support? Because this time around, it also solves a sales problem for Microsoft. Somebody, somewhere, has a spreadsheet showing that there will be a return on investment if they spend the development, marketing, and support resources necessary. (And I bet they’re right – if you compare this feature’s ROI against, say Hekaton or Polybase, surely Linux is going to produce a lot more new licenses sold.)
There’s just one missing piece: database administrators in the field with the unique combination of both SQL Server and Linux experience. Just like SQL Server on Windows Core, the most challenging problem isn’t technical – it’s a staff availability. But this time around, Microsoft has money riding on this bet (as opposed to Core), so they’re going to be extra-loud about how much they need you, dear reader, to learn to manage SQL Server on Linux.
So should DBAs learn Linux?
In large shops, I find that the Windows team tends to manage day-to-day Windows activities (server setup, hardware repair, patching) and then hands built servers over to the DBAs. As long as the SQL Server service starts, the DBAs take over from there. Heck, in large shops, the DBA team may not even have the rights to log into Windows via RDP.
If your shop is eager to run SQL Server on Linux, it’s probably because you’ve already got an experienced team of sysadmins who know and love Linux. They don’t need your help with the Linux part. In fact, I bet you’ve even already got Oracle running on Linux – so go talk to the Oracle DBAs about the kinds of day-to-day Linux administration tasks they do. You should expect a similar level of involvement.
But just because you don’t have to learn Linux doesn’t mean you shouldn’t. If you have the luxury of a current employer who decides to take the plunge to run SQL Server on Linux, you’ve got a killer opportunity. Take the chance to learn some basics from your Linux sysadmin team – sit with them while they build the servers for your deployments. It won’t make you a worse DBA.
31 Comments. Leave new
Can’t the question be reversed? “Can Linux admins learn SQL Server?” This seems like a more plausible route, because as you know, SQL Server isn’t hard 🙂
Especially if they’re migrating from another database platform that they already know well, like, say, Oracle. I’ve had several Oracle DBAs in classes recently who were transitioning over.
Agreed!
I started looking into the Windows Core just to see what the hype was all about when Windows Server 2012 R2 hit the market. Just like you state in this post Windows Core doesn’t seem to solve any real world problems.
Only time will tell if engaging into the Linux segment will be a home runner for MSFT or not. I’m looking forward to meet the first customer that demands that we run the new SQL Server 2017 on Linux.
I’d rather see an opportunity for MSFT to convince existing Linux shops with Oracle or MySQL to move to SQL Server. (because of costs or features or whatever)
Mötz – I’ve seen companies expressing interest, and then they’ve confessed to me privately, “It’s more of a licensing negotiation trick with Oracle. If we tell them we’re considering SQL Server on Linux, they’ll just cut our licensing fees to get us to stay.”
I do imagine that it’ll work for ISVs though. Say you’ve got an ISV app with a SQL Server back end, and you want to sell it into a Linux-only shop – now you can.
Brent – I believe that there is some market for a SQL Server on Linux just like the ISV example you give. But as you explain in the post it might not be the new holy grail that will swift through the market.
Don’t you think that some current MSFT customers has been using the other RDMS on linux as a way to push for some discount from MSFT? I would guess that they have the same upper hand now as they did 😉
I’m not that interested in SQL Server running on Linux, but I am really interested in SQL Server running in a Linux Docker container. We have hundreds of tiny apps that use SQL Server. We try to shoe horn them into our “consolidated” SQL Server environment (can’t always be done), but it would be way easier to spin up an isolated Docker container for that app where we can grant it whatever permissions the vendor says it “needs.”
I feel pretty comfortable in Linux, but when I can pull down a Docker image created and maintained by Microsoft, there’s almost no Linux administration needed if we already have Docker running for other stuff.
I see this as a play towards the cloud for Microsoft. We’ve been trying to move more towards MySQL, Postgres, and cloud-only or PaaS database offerings, but vendor support isn’t there. SQL Server has the vendor support. The main question left for us is, what is licensing going to look like.
Elijah – the licensing has already been answered: it’s the same price as SQL Server on Windows. Your license works on any OS.
If you were thinking about saving money, think again.
Also starting October 2nd until June 30th, 2018, we are launching a SQL Server on Red Hat Enterprise Linux offer to help with upgrades and migrations. This offer provides up to 30% off SQL Server 2017 through an annual subscription. When customers purchase a new Red Hat Enterprise Linux subscription to support their SQL Server, they will be eligible for another 30% off their Red Hat Enterprise Linux subscription price.
Ref – https://blogs.technet.microsoft.com/dataplatforminsider/2017/09/25/sql-server-2017-and-red-hat-enterprise-linux-offer/
Licensing for Windows Server vs Linux?
Yes, because when you’re paying thousands of dollars PER CORE for SQL Server, that few hundred bucks for the entire server OS is such a big deal, and you would never pay support costs for Linux OS’s, would you?
Bang goes Red Hat’s business model
Elijah – If your tiny apps doesn’t require to much data and stuff from the SQL Server and the Express edition survives in the 2017 release, it could be a way to go.
Brent is on to something regarding license – you would need to license the full physical server and only use that for all your docker containers for this to be feasible way to go. Or just license all physical server – just in case, that would make MSFT very happy 🙂
I work in higher ed and we have a site license (at a pretty reasonable price). I’m hoping that our site license will cover this.
Well Docker is in Windows Server 2016 I believe? So maybe that would help. I hear you about : grant it whatever permissions the vendor says it “needs.” I also thought that may be cleaner than a bunch of named instances piled onto a windows server.
You may however save the windows license cost when running SQL Server on Linux.
I heard there is interest in running SQL Server in the cloud and that a lot of Linux is used so customers want the choice available to run SQL Server on Linux. Seems to make some sense. And depending on the needs using Docker to run SQL Server 2017 on Linux could be useful in this case.
Not sure about licensing for SQL Server costs but historically there have been some savings running multiple instances of SQL Server on the same server as opposed to multiple servers. Perhaps not anymore?
“Because this time around, it also solves a sales problem for Microsoft. Somebody, somewhere, has a spreadsheet showing that there will be a return on investment if they spend the development, marketing, and support resources necessary”
There may be other reasons than sales. For instance, features are being rolled out on Azure SQL before the box product, does Azure SQL run on Linux or Windows? Could it be that Linux-on-Azure is somehow “cheaper” for MSFT than Windows? Better performance on the service fabric? Runs cooler/less resource utilization = better density?
Or maybe it’s that database manager choice is no longer being dictated by central IT at most places? mysql and postgres grew by winning developer hearts and minds. I doubt a DBA had much say in those choices for smaller, departmental apps that grew out of LAMP or MEAN adoption. Remember when young coders learned the msft stack because someone gave them a copy of MSDN disks? Younger guys like coding on Linux, maybe SQL-on-Linux is another way that shows “Microsoft hearts Linux”?
Lastly, could Linux simply be a strategic direction for MSFT? .net is (partially) OSS and you don’t need mono anymore. vscode is an awesome editor, mostly platform-agnostic. WSL (windows bash shell) is a viable “Linux sandbox” without something kludgey like Cygwin. “Container tech” in Azure is always geared to LInux first. Even azure cli tooling is “bash first, PoSh second”…today.
I wouldn’t overthink this. Frankly, I doubt it was a big deal to port to Linux, which is why file formats, etc are identical. Virtualization has gotten better over the years. First it was VMs, then containers. My guess is if you get down to process virtualization it wouldn’t be terrible to have a few core kernel components and a modified “windows” to run on top of it. And since SQL 2005(?) SQL Server bypasses a lot of core OS functions for its own implementation (ie, unbuffered IO, thread mgmt). Suddenly, a “port” isn’t really a “port”. My guess is this is how they got us the ubuntu version of WSL and I’ll bet we’ll get the “red hat” version soon.
Perhaps sales is NOT the primary motivator?
Dave – you wrote:
> Frankly, I doubt it was a big deal to port to Linux,
Make sure to click on the links in the post about the things that still don’t work on Linux. Then, think about the support training & workloads that are going to be required, the marketing material to build, the documentation to write, the additional testing requirements, translating things into multiple languages, etc. Overall, this is probably in the tens of millions of dollars.
To learn more about the work required, check out this Ars post on Drawbridge:
https://arstechnica.com/information-technology/2016/12/how-an-old-drawbridge-helped-microsoft-bring-sql-server-to-linux/
plenty of companies run mixture of databases on various platforms. and not that uncommon to see DBAs do both Oracle/Sybase/DB2 (on Linux) and MS SQL on Windows. I think it will be an easy step for those types of outfits to also adopt MS SQL on Linux.
You are really missing the point of Server core / Nano Server.
The point is not to take the GUI away, but to take the GUI off the server.
You manage the server using a GUI with RSAT on a workstation not the server.
Jeffrey Snover is the chief architect of PowerShell and in charge of Windows Server, he is a Unix guy, so Windows Core and Nano Server aren’t going away. They are made for DevOps.
Don – you’re missing the point of the blog post. I’m not saying Windows Core is going away – it just hasn’t achieved a significant market penetration for SQL Servers. We both agree that they’re made for DevOps.
This is a SQL Server blog. Thanks for stopping by!
It would be interesting to see if there are any performance differences between Windows and LINUX SQL Server implementations, given the same hardware. Also, the possibility of running SQL Server on IBM Power servers running LINUX is also quite interesting, since IBM Power 8 processors are significantly faster than Intel ones. I suspect ORACLE will be facing severe competition in the near future, if SQL Server run as reliably and productively as ORACLE does on LINUX. https://www.nextplatform.com/2015/10/13/how-ibm-stacks-up-power8-against-xeon-servers/
Besides there could be another reason to run SQL on Linux if OS based storage mirroring also works when running SQL. This could save a lot of money because storage mirroring or other technologies like VPlex for example are expensive.
I’m probably one of the few DBAs who would love this, but then I started by administering Sybase on Solaris using just isql – I’m tempted to add a Monty Python reference here about living int’ hole int’ road 🙂
I’m already a polyglot DBA – SQL, Oracle, MySQL, Sybase. Changing technologies does present a learning challenge, but its adds so many options to you both in job opportunities and also in just in being able to recommend the appropriate technology solution. Some DBAs might cry about losing the GUI, but then you’d hope that most decent DBAs could write TSQL on a command line in an emergency too (although they might have to google the syntax from their phone) 😉
At the (small) company I work in the sysadmins are responsible for Linux servers and Windows servers. Some choose Linux over Windows for imho dubious arguments like “I don’t like the GUI of Windows 10 and all that app things”. For myself SQL Server on Linux is great for learning purposes. Finally you can set up a VM with SQL Server which does not expire after x days due to Windows licensing reasons. I manage to make my way around Linux mostly by searching and copy/pasting but those skills are not meant to be used on a production system whatsoever.
I predict that you will hear some of the same grandiose statements about Linux you heard about Windows Core. I’ve already heard comments about less patching in Linux.
I was excited about Windows Core when it was introduced. It is my preference for SQL Server. Because command line is intimidating to many people, it keeps them from opening RDP to the server. It prevents IE from being opened on the server because there is no IE. It prevents people from installing all kinds of extensions and little pet applications on the server. It prevents SSMS from being opened on the server because it cannot be installed on core.
All the commands necessary for setup and configuration of Core have been around since NT4. If you are not familiar with them, it is a bit of a learning curve. Many of the commands are rather cryptic. I found that I can configure Windows faster from the command line than through the GUI. With the enhancements that have been made to PowerShell in Windows Server 2012 and 2016, it is even easier to configure Windows Core. It’s also much easier to learn.
I am excited about SQL on Linux. It has many of the advantages that Windows Core has. It has many of the same challenges. The biggest challenge I face with adopting SQL on Linux is the tools to centrally manage the OS layer and patches. For now, I am sticking with Windows Core.
Yes I know this is a database blog. Nevertheless I’m a C# developer and here I am. Microsoft has made some interesting choices over the years, web forms, silverlight, dcom, and on and on. I’ve suffered through Windows 3.1, 95, Vista and all the while in parallel I’ve used a Mac at home. Right now my Mac is also my work computer and I’m building C# microservices using aspnet core in Visual Studio Code and deploying and debugging in docker containers. And it is awesome. We’re using containerised Postgres for development but could equally have used SQL Server. I haven’t turned on my Windows VM in months. It’s apparent that containers are going to be massive and docker containers run Linux. It’s been a long time since I’ve felt enthusiastic about Microsoft despite developers developers developers but right now it is delivering some fantastic innovation and I’m feeling very optimistic about the course it is charting.
If management are buying into the hype and are offering training then say YES. It will look good on your CV.
It probably doesn’t solve many DBA problems. For me it made source control of RedShift and Vertica really easy.
If you like to have everything scripted then Linux helps to keep your back straight with the required disciplines.
I’m not so keen on the Jurassic editors. Vi for those of you who have warm memories of edlin.
I thought the idea of running production databases in Docker containers was strongly discouraged by Docker themselves due to the perishable nature of a container?
Dave – you can point apps at data that resides in network shares, for example. SQL Server’s been able to do that for years:
https://www.brentozar.com/archive/2012/01/sql-server-databases-on-network-shares-nas/
Now, is it a good idea…that’s a separate conversation, heh. But Docker containers can make sense for, say, automated deployment tests. Spin up a new SQL Server, simulate the installation of your app and your database & schema.
What about today with Sql-Server on Linux ? Anyone has updated info of it adoption or not ? I read some articles that informed that it has a lot of features like replication, etc. But my question is: If a client wants to migrate his aplication from Sql-Server 2017 on windows to Linux what do you recommend ?
Given that SQL Server 2017 only has about 1% market adoption:
https://app.spotlightcloud.io/public/collectiveiq
And that by definition, SQL Server on Linux adoption has to be lower than that…
…as my organization, a very large government agency with a couple thousand instances, has decided that EVERY new install and replacement will be on core. I’m one of the FOUR people on the DB Team with extensive PowerShell skills. 75% of the team has no PS experience at all.