At SQLRally, we brought along an iPad to demonstrate that monitoring doesn't have to be web-based to be mobile. We fielded a lot of questions about this, the most common one being, "Whoa, is that native?" No, it was not native… we were using remote desktop (RDP). While yes, it can be an extra step (or two, if you need to VPN) to go into an RDP session to launch your monitoring tool – regardless of which monitoring tool you use – there are three big advantages to this:

1. Avoiding the "What Now?" question.

If you are already in an RDP session when you spot a problem, then you're already equipped to fix it, because you're *in* the environment. You probably have SSMS right there on the same workstation running the console, and can simply Alt+Tab to dig in and investigate if you need to. If all you have is a web browser, and you aren't equipped to connect to the environment, what good does the monitoring do for you? It's perfectly fine when you're just confirming that "all's well." But when there is an actual issue afoot, it's not that much better than getting an e-mail alert on your phone.

2. Feeling more secure.

While you can go to great lengths to build and secure a web page, why not simply leverage the security infrastructure you already have in place? You can use RDP to connect to your environment without opening any new web ports that are directly or indirectly connected to your database. If you need to authenticate into a VPN before viewing a web page, or it can only be accessed from inside the domain, then you're certainly not much further ahead at all.

3. No sacrifices in functionality.

Once you're in an RDP session, other than dealing with a smaller screen size and learning some "creative" mouse functionality, you may as well be sitting at your desk. Even though you might be at your daughter's softball game or visiting your cousin out of state, you get the full experience of all of the Windows applications you would be using on a typical day at the office.

You may have noticed that most vendors are not rushing out and building an iOS or Windows Phone 7 or Android app to try and replicate what they have on the desktop. Part of the reason is right there in the previous sentence: DBAs use a variety of mobile devices, and programming for each one is different (and this landscape changes rapidly – not just the number and types of devices, but even the rules within programming for a specific device). So, even if you go with the 80/20 rule and program for the top 3 devices, not only are you leaving a good chunk of DBAs out, you are also at least tripling your efforts in producing a similar experience across devices. (And if you just pick one device, you're leaving a lot of people out in the cold.) On top of that, it may be difficult or impossible to get all of the functionality you want into the various form factors, in spite of Robert Wahbe's assertions at TechEd NA this week. He said we need applications on all of our devices, but really what we need is data and the ability to act.

Take all that back to the web-based solution – even that can be cumbersome, as you will find that different devices will not be able to handle the technology you're likely going to want to use to make a more appealing UI experience, and one that is consistent with your application(s) – things like Flash, SilverLight, Ajax, and charting will have different levels of support (often none) on different platforms. This will ultimately lead to either a lot more work to get the same effect across devices, or a lowest common denominator approach; this is the sacrifice in functionality I am talking about.

Even taking mobile out of the picture and focusing on the desktop browsers, the days of having to check your stuff in every single browser are far from over. Just look at the differences in rendering between IE8 and IE9, they're astounding, never mind if you have to add Firefox for Windows, Firefox for Mac, and Safari for Mac to the mix. Based on my exposure to the community (and maybe partly because of it :-)), there is a significant uptick in SQL Server professionals opting for Apple hardware, but I'm not noticing an equivalent uptick in enabling tooling for those folks on the Mac. That's okay; I, for one, do not expect to see Management Studio or Profiler running natively on my Mac – that's what virtual machines and RDP sessions are for. But if you give me something web-based, I expect to be able to consume it in whatever browser I happen to be using at the time – in Windows, on my Mac, on my MacBook, or in iOS. Even with HTML5 it is going to be a real challenge to build a web-based experience that matches the richness of a Windows application, and obviously it would be a significant division of labor to develop and maintain both. If you've tried to use a platform like Community Server in both Safari and Firefox for Mac, you'll know quite well the outcome of not exactly hitting the mark on consistent behavior.

 
The only sacrifice you really end up making here is screen real estate. But you're doing that anyway if you're using a mobile device, right? In the following picture, you can see how the iPad and iPhone stack up against a cinema display. It's not quite the same as having a full-sized monitor dedicated to a dashboard (which I know is quite common), but you can still see what's going on if, for example, you wanted to focus on work on your main screen(s) and have the monitoring tool off to the side, on a tablet like the iPad, or even an iPhone:

The iPad and iPhone have small screens, but can still be quite useful. Click to embiggen.

And here is a screen shot from the iPad itself. Note that different RDP/VNC clients for the iPad will have different display settings and capabilities, so it can take some tinkering to get the screen resolution looking just right.  This one is using Jump Desktop, and I can assure you it looks better on the screen than it ever will in a compressed-for-web-download format. You can see it has a nice big target circle so you can control the mouse without having to pinpoint its location, and it also supports several gestures that you might expect (but don't always find easily), such as click+drag and right-click.

Life-size monitoring on the iPad. Click to embiggen.

[I plan to do a round-up soon of the three RDP clients I've tried out so far.]

One final point that can't be ignored is that you are repeatedly reminded, "you don't need to install a client when you use a web-based interface." Ask yourself this: how many different workstations do you actually connect to where you would need a client installed? In every environment I work in, I connect to a single "jump" box, and that's where I install all of the tools I need – so the benefit of not having to install a client doesn't matter for a lot of folks. And what is the perceived barrier to installing a client on multiple workstations anyway? Is it a licensing issue? Just the time it takes to perform an installation? Something else? With a solution that isn't licensed per client or user, I think I'll take the security and full functionality of a one-time install over the likely limitations I'll face in a web-based version that is trying to achieve the same functionality as the application. (As an aside, have you tried managing a SQL Azure instance through the web-based portal yet? Curious how you have found that experience compared to Management Studio.)

I've had several discussions about all of this with colleagues at SQLRally and elsewhere, and these thoughts seem to ring true for all of them. Now, I'm not trying to knock the web-based monitoring offerings out there; they certainly have their niche and they can definitely be useful in specific scenarios. But in terms of practicality, security and functionality, exposing this information in a browser isn't always going to make you better equipped to solve issues on your SQL Server instances.

Do your customers care about all of these technical problems? Of course not. They just want you to provide a solution. Many want to be able to check up on their servers using their iPhones, iPads, and other devices because they're no longer tethered to a desk (and because problems don't always occur between 9 and 5). In some cases, a web browser can be more convenient. It's when your check-up reveals an issue, and you need to respond immediately, that HTML loses its charm – and when RDP is going to become a necessity anyway.