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.