Joey on SQL Server

Q&A: The State of SQL Server Tools Development

• By Joey D'Antoni
• 07/10/2018

Microsoft's SQL Server toolbox is a morass of acronyms, from SMO to SSMS to SOS, and differentiating one from the other can be a challenge.

I recently caught up with Vicky Harp, lead program manager of the SQL Server tools team, who helped clarify Microsoft's vision for each of its database tools, as well as provided a general roadmap of the SQL Server tools landscape in this cloud-centric, open source-friendly era at Microsoft.

D'Antoni: What is your title and what do you really do at Microsoft?
Harp: My title is "principal program manager lead," and I am the program manager leader for the SQL Server tools team. Our team is responsible for most of the tools that a user installs on their machines to interact with the SQL data platform.

We have responsibility across the spectrum, from low-level drivers up through the big GUI tools: SMO [SQL Server Management Objects], DacFX [Data-Tier Application Framework], SQL PowerShell, SSDT [SQL Server Data Tools], mssql-cli [a command-line tool], SSMS [SQL Server Management Studio], SQL Operations Studio [SOS] and several other initiatives.

Many folks are confused around the differences between the tools -- SSMS, SOS and SQLCLI. What is the vision for each of the tools?
One thing to consider when looking at the tools roadmap is that we've had a major change to the platform relatively recently, and that's the addition of cross-platform support for SQL Server. That's a monumental shift, and a continuing one, and it presents both a challenge and an opportunity for the tools team. SSMS is a powerful toolset for SQL Server, but it's a purely Windows application, and its future remains purely Windows. SQL Operations Studio, on the other hand, is cross-platform from the beginning, which both allows us to reach out to those new users of SQL Server and gives us the chance to do some things a little differently than they were done in SSMS.            

For example, with SSMS, most everyone has the same experience, because every scenario the tool tries to solve for is in the base install. This leads to a lot of feedback along the lines of "Why should I have X feature in here if I never use it?" and the sensation that the product is overwhelming, both in user experience and in the actual download size. So for SQL Operations Studio, we are using an extensibility model, where certain core functionality like the ability to connect to servers and run queries is built-in, but other features like management of SQL Agent Jobs are opt-in through an extension. This creates a smaller download and allows users to have a more tailored experience. And because SOS is open source, that also lets others add their own experiences into the product, which is good for everyone.

That doesn't mean that we're not investing at all in SSMS. We've done significant work to move SSMS to its own code branch to allow more frequent, independent releases. We're going to keep working on it. For users who feel like they are mostly hearing about new work in SQL Operations Studio, it's because, for one thing, it's an open source tool so it's just innately easier to track what is going on as an external observer, but also because SQL Operations Studio has a tremendous backlog of experiences to light up for cross-platform users. In SSMS, the mainline scenarios are already covered and the work is more incremental. If you think of watching a house being built, it's just a lot more dramatic when there are bulldozers driving around and walls being erected than when someone is, say, adding solar panels to an otherwise finished structure.

When it comes to CLI tools, we have a similar story but with, if anything, more intricacies. The cross-platform story for scripting and for the command-line tools is tightly coupled with the availability of cross-platform libraries in .NET, as well as driver support, which we will continue to drive forward on. And in addition to cross-platform considerations, for scripting and CLI tools, we need to consider container use cases, which we believe will be critical scenarios for the data platform going into the next few years.

Moving to open source has been a big shift for Microsoft, but we've seen it across many product lines. How does this affect development and new feature additions?
Working out in the open has been wonderful for the tools team. We're able to solicit feedback in a much more direct and iterative way, and bug reports and feature requests with voting data are entered right into our usual stream of work -- not into some secondary stream that needs to be triaged, de-duplicated and prioritized into the "real" work list. We've seen the value of that with the SQL Agent extension for SQL Operations Studio, where Alan, one of our PMs [program managers], was able to solicit community feedback on an issue in GitHub and we were able to iterate on the feature immediately. We're doing the same now with the new profiler extension, and we'll continue to do so moving forward.

Working in open source has also allowed us to crowdsource the effort of translating the product into new languages, which has been really cool to watch unfold. We're able to have coverage of far more languages than we might otherwise have had for a preview application, which is great for our user community.

How has the cloud and telemetry affected the product?
We view telemetry data as being mostly useful for broad trend information. For example, recently we were able to identify that startup time for SQL Operations Studio was not as fast as we'd like, so a change was made and we were able to validate the trend that yes, the product was opening more quickly than the previous month's release.

How do you envision the SOS platform working with the third-party providers in the SQL Server space?
It's very much our hope that third-party providers will choose to offer extensions for SQL Operations Studio. Redgate has already created an extension for SQL Search, and we are working hard to make it a straightforward, well-documented process for both ISVs and for community members to create their own extensions. No matter how rich the SQL Server platform tools become, there will always be value add scenarios.

I know it's not your decision or say, but how could you envision the GitHub acquisition changing the Microsoft tools landscape?
Our group already uses GitHub very actively and with full support from our management and so, like all users of the platform, we look forward to seeing where they go next.