I have a real infatuation with Azure. I’m especially interested in the Platform as a Service (PaaS) offerings in and around the Data Platform. I truly believe that these are the subversive elements that are going to change how a lot of us get our jobs done with data. I’ve worked with Azure SQL Database within my organization and I do lots of experimentation and testing. Any chance I get, I like to present sessions on Azure. Funny thing though, my presentations are never as easy as work, and I think I ought to discuss why.
Connectivity, Connectivity, Connectivity
In case you can’t tell, I’m starting off talking about connectivity. However, this is an important topic. When I’m working on Azure, I’m usually hooked up to my home office or I’m in a real office. Connectivity in those environments is almost never a problem.
When I’m presenting Azure though, I’m in a conference center, a hotel, or even on a cruise ship. Connectivity in these environments is frequently an enormous issue. I get dropped connections. It’s slow. I find ports that have been blocked. In short, it’s a nightmare.
The connectivity nightmare makes Azure look unstable & weak. The fact is, the problems arise when I’m sharing bandwidth with all the attendees and half the hotel guests. It’s not Azure that’s problematic, it’s that hotel’s WIFI.
Web Apps vs. Demos
Another issue arises around the fact that I’m doing demonstrations, not working with an application. In the demos, I want to see the results of the PowerShell command from Azure. It’s not an issue where I’m simply setting up new automation and I only have to see it work. Instead, it’s the round trip that’s important, as much as the functionality. That round trip makes connectivity issues even worse.
Demos are also frequently contrived situations. I love showing off how to set up Geo-Replication on a database using just a few PowerShell commands (six is all you really need, the hard work is done by two). However, now I need connectivity to issue the command, get the results and then swap over to the Portal to show what the commands I issued have done. Not to mention if I mess up cleaning up from an earlier demo, my demo may fail.
Mitigation
It’s on me to figure out ways to ensure this doesn’t hurt my demonstrations (even though it frequently does). Here’s how I go about addressing the issue.
Practice
I run the demonstrations a lot. I like to know roughly how long they take in any venue where I’m attempting them. Also, if they’re not going to run, you want to know as soon as possible so you can go to plan B
Plan B: Video
I’ll record a run-through of the scripts at home. I’ll also edit that video to reduce or eliminate wait times (and yeah, I’ll tell you I’ve done that if I’m using a video). This ensures I can show you “what you would have seen” rather than describing it. I was born in Missouri. Show me.
MIFI
I also have a MIFI device that I use frequently instead of relying on saturated bandwidth. Unfortunately, when you get deep in the bowels of a hotel basement, the connectivity becomes an issue again. Another example happened to me last week. I switched from the WIFI of the event to the MIFI device and my VM networking got all confused. Not fun.
Conclusion
If all this sounds like whining. It’s not. I’m preparing to give sessions this week on Azure. I’ve got sessions on Azure I’m building for the next TechOutbound event. I’m just letting you know why you may occasionally see me tap dancing. Remember, I may not be connected to Azure is still running and all my databases are still online supporting the applications that they serve. I just may not always be able to connect to those applications.
My experience presenting Azure is so different from my experience managing and building Azure that I thought it merited an explanation.
The post Presenting Azure Vs. Working With Azure appeared first on Grant Fritchey.
