MSSQL on Linux May Not Be Right for the vCSA

Today our friends at Microsoft announced something very cool – MSSQL on Linux. I know customers have been asking for this
for a long, long time and it should open up a whole new world of possibilities when it launches sometime around mid-2017. Microsoft is doing some amazing things these days under the leadership of Satya Nadella. Kudos and congratulations to the MSSQL Teams!

The Reaction

Just moments after this announcement went live the Twittersphere erupted with questions about MSSQL support on the vCenter Server Appliance (vCSA). One such example is from Zach:

While the answer to this is not set in stone I personally believe that MSSQL on Linux may not be right for the vCSA. But before we get to that let’s take a look at why we currently don’t support MSSQL as a database for the vCSA today. An ODBC driver for SLES 11 (the operating system that is currently running on our vCSA) does exist. However, it has never left the “Preview” status. I’m told that our Engineers had been working with Microsoft to get full support for the ODBC driver on SLES 11 but that never happened. At some point we had to make a decision: move forward or sit, wait, and hope on Microsoft delivering a fully supported ODBC driver for SLES. We chose the former and decided to turn this into an opportunity. Microsoft SQL is a great database platform. If you look at the Gartner MQ’s you’ll see that they are a clear leader in the space.

vCSAThe vCSA Vision

Now let’s take a look at the VMware appliance strategy. One challenge up to this point is having 3rd party dependencies which slows down the development of new features and patches. We see this both on the OS side as well as the DB side. By investing in the proven open source database platform, PostgreSQL, VMware has been able to create something great – vPostgres. Essentially, VMware took a great platform and made some tweaks (specifics will be published soon on the vSphere Blog) to make it even better for many of the VMware appliances in our portfolio. So, the takeaway is, if you know the OS, the application, and the database one could argue that you can thoroughly optimize the stack to produce a purpose-built appliance that is the best for the workload it is designed to run. In this case that workload is vCenter Server.

The next point is the vision for the appliance model in general. As an appliance, the underlying OS and database platform should be invisible. What we care about is the application – again, in this case, vCenter Server. What if we didn’t need DBAs to provide care and feeding to a database (including backup and restore)? What if we didn’t need Linux Administrators to troubleshoot or write scripts to operate the application? What if there was an appliance that was self-managed and didn’t have external dependencies, e.g. super simple to deploy and manage, but is still open and accessible for those times you might need to open it up? What if there was a rich API to go along with a rich UI so that customers have complete flexibility in how they deploy, manage, and monitor the application? Do you see where I’m going with this? That’s the vision. We want customers to be able to care about the app not what it runs on. Are we 100% there today with vCenter Server 6.0? For many customers the answer is “Yes!” But we also recognize there is always room for improvement and I am certainly excited for what’s coming next. If you’re in the beta program you’ve probably seen some of what’s coming. If you’re not, you can sign up here.

With those thoughts in mind it should be clear as to why the embedded vPostgres DB makes sense for vCenter Server. We own the stack and can do things we couldn’t ordinarily do if we were relying on 3rd party databases. Can those same things (replication, recovery, resiliency, performance, etc) be done with other platforms such as MSSQL? Of course they can. But VMware believes it can integrate those features in the appliance so that there is little to no configuration and upkeep. This model drastically reduces the complexity and requirements. Again, I’m not saying MSSQL is inferior at all. Simply put, there are some amazing benefits to the appliance model when you treat it as a fully self-contained appliance – not as an appliance plus some 3rd party component(s).

Wrapping Up

How does this all circle back to MS SQL for Linux? Well, as I said above, nothing is set in stone. But, at the earliest, we wouldn’t be able to provide support until the product is released which would be Mid to Late 2017. We’re going to listen to customers and do what’s best for them. I personally believe, however, that we’ll be able to show customers that the appliance model with an embedded database makes the most sense. Look for some content to hit the vSphere Blog as well as from my colleague Emad Younis and his blog in the weeks and months to come that should enable customers to get more comfortable with vPostgres and the vCSA.

You may also like...

  • Andrew

    the problem is, vPostgres will never be a standalone DB application, VMware chooses to keep it embedded for the simplicity you describe. The true fact of the matter is the customer is then left with a very large appliance, running too many processes, requiring lots of resources that leave it with a lack luster performance.

    If you could run VCSA with the vPostrges separately you would get better performance and response as vCenter is such a beast these days.

    • Hi Andrew, thanks for the comment. The point here, is that requiring a standalone database is something we think is not required. There are always tradeoffs and I believe that trading a bit of performance is worth the gains in simplicity during deployment and day 2 operations.

      This is just my opinion, though. PM and Engineering will be listening to customers and as I said above, we’ll do what’s best for the customer. I stand by my argument, though, that the appliance model will be better long-term if we don’t rely on 3rd parties or external databases. I certainly could be wrong, though 😉

    • The database isn’t the performance bottleneck as far as I know.. And we aren’t sitting still on making the whole solution more performant.

%d bloggers like this: