PostGetting Into The “Dating Phase” with the Cloud

This blog post is the first in a series that covers designing and implementing hybrid SQL Server high availability and disaster recovery solutions with Microsoft Azure.


I’m sure you’ve seen a lot of status updates on your social media feeds this past Valentine’s Day. Whether you’re searching for a new partner or in an on-going relationship, I’m sure you would agree that the dating phase often sets the tone for your relationship. Now, I don’t claim to be an expert on relationships but bear with me for a moment here.

I just finished a whole-day workshop on designing and implementing a hybrid SQL Server high availability and disaster recovery (HA/DR) solution with Microsoft Azure for SQLSaturday Melbourne. Whenever I do these workshops, I always ask the attendees where they are at in their journey to the cloud – be it with Amazon, Microsoft or even Google. Here are the most common response that I get:

  • currently evaluating
  • deployed dev-test environments
  • new projects/applications
  • disaster recovery
  • some mission-critical production workload

A small fraction of the attendees in my workshops have deployed mission-critical production workloads on the cloud. Now, I would assume it’s because the workshop is very specific to hybrid SQL Server HA/DR solutions with Microsoft Azure that it only attracts a specific segment of the IT professionals population.

One of the things that I highlight in the workshop is understanding what I call the “dating phase” of their journey to the cloud. What I mean by this is that their journey to the cloud is in the early stages of the relationship. And whether we like it or not, majority of the customers will be in the “dating phase” with the cloud within the next five (5) years. Why do I say that? The fact that Azure (formerly known as Windows Azure before it was renamed to Microsoft Azure) is almost 10 years old now (it was announced in 2008 and made publicly available in 2010) and customers still have not fully adopted it makes the case.

Early Stages in a Relationship

We go thru different stages in a relationship. I bet you can relate to this in one way or another. As you go thru your journey to the cloud, keep the following in mind:

  1. Attraction. You met somebody at work, in school, at church, at a social event. You got attracted. The beautiful smile (it’s what got me attracted to my wife). Those lovely eyes. Maybe the dress. Or the way he talked. Similarly, your CTO/CIO/IT manager might have seen an advertisement on a magazine as he’s on his way to a meeting. Or maybe the keynote speaker at a conference mentioned it briefly. There’s something about the cloud that could reduce your company’s IT operational costs. Or maybe lower IT acquisition costs. He or she got attracted to the idea. It’s time to explore.
  2. Introduction. Depending on your personality type, you can walk up to the person and introduce yourself. Or ask somebody else to get introduced. Taking your phone out, you look up his or her social media profile – works in finance, loves the outdoors, volunteers at the local children’s hospital, is health conscious. Looks like an ideal “prospect.” Now, you have a bit of an idea about the person even without talking to them. It’s no different when exploring the different cloud providers. You read the documentation (assuming it’s not convoluted and complex), you watch a webinar, you attend a workshop or a technical presentation. Sure, you “know” what the cloud is capable of and what it has to offer. You “know” the difference between an A-series and a DS-series VM on Microsoft Azure. You “have an idea” on how you can store your SQL Server database files or backups on Azure blob storage and potentially save money on archived backups. “Currently evaluating” might still be in this stage.
  3. Dating. You finally had the courage to ask the person out. You set the date, the time and the place. It could just be a coffee date or at a fancy restaurant. At this stage, you start making small commitments. That schedule on your calendar is a commitment. The choice to go outside of your normal routine to spend some time with this person is a commitment. And with these commitments come expectations – even if it’s only the first date. You expect that the person will show up on the agreed upon time and place. You expect to have a face-to-face conversation. At the end of the date, you can expect whether or not you’ll get a chance to have a second or a third or a fourth date.This is where most customers are at in their journey to the cloud. They start deploying dev-test environments. While not mission-critical, it’s an opportunity to “test the waters.” The fact that they are running some type of workload on the cloud is already a type of commitment.This is also where “getting to know each other” becomes real. You notice some mannerisms that slightly annoy you. You realize that their social media profiles do not really reflect who they really are. Some people under-promise yet over-deliver (that person you thought was so boring made you laugh the whole time you were together). Some were just really good at creating an “ideal social media profile” you assume that they are just really good at marketing.

    And about the cloud? You thought moving an Azure VM from one region to another (or from classic to resource manager deployment model) was just a matter of a few mouse clicks on the portal. Or the set of deployment scripts that you wrote a few weeks ago would still work today (don’t get me started with this.) But that new project costs a lot cheaper on the cloud than it will be on-premises.

    How you treat the dating phase sets the tone for the success or failure of the relationship. Maybe it’s just a miscommunication. Or a misunderstanding. Maybe you should spend more time together to get to know each other better. Just because you didn’t get that cost savings or that IOPS requirements you have for your new database project doesn’t mean the cloud cannot deliver. Maybe you should explore other design alternatives. Like maybe combining scaling up the Azure VM with adding a few premium storage accounts. Be creative. You’ll be surprised at the outcome if you just put in more effort.

    But sometimes…as IT professionals, we act like we’re parents of a young adult who is considering a serious relationship with another fine human being. We’re afraid. We hold back to the past, thinking that we can stop time. We think that this new relationship will rob us of the opportunity to be parents. We don’t realize that it actually creates an opportunity for us to redefine our role. We’re not just parents anymore, we can be advisers and mentors.

    We look at the cloud as if it’s going to rob us of our jobs. Sure, we will no longer do the boring, repetitive tasks of patching servers, taking backups, managing user accounts – unless you find these tasks enjoyable. We ignore the endless opportunities that the cloud provides – becoming a data strategist for moving workloads to the cloud, a solutions architect for designing hybrid SQL Server HA/DR solutions, analysts for identifying data patterns that can improve business operations, even a BI professional. The possibilities are infinite, as my former employer would claim.

  4. Commitment. At this stage, you are now serious with the relationship. After a few dates, you decide to  go steady. Boyfriend/girlfriend/partner. Call it whatever you want, all I know is that you are serious with the relationship at this stage. You make commitments. You go out every weekend or so. You spend the holidays with family. Maybe you start planning for the future, who knows.

One of my customers considered getting serious with Microsoft Azure. They were required by their stakeholders to have a DR strategy for their mission-critical applications. They asked me to create an action plan for them to use Microsoft Azure as their DR strategy. They currently have a SQL Server failover clustered instance for their database high availability solution. They have database backups. That was their DR strategy.

As always, I ask for their recovery objectives (RPO/RTO) and service level agreements (SLA) to understand whether or not the cloud would meet their needs without spending too much. It seems like a perfect fit. The idea was to create an automation framework that uses the Azure PowerShell modules to (1) copy their database backups to an Azure blob storage, (2) create a SQL Server VM from the available Azure VM templates that matches their on-premises version and (3) restore the database backups after the SQL Server VM was created. The database was running on SQL Server 2014 and I could have used the Backup to URL feature to store their database backups directly to Azure blob storage. But I’m not a fan of NOT having local copies of database backups. Besides, you would be paying for egress/outbound data. That means additional cost just to download your backups from Azure blob storage in case you need to recover a corrupted data page.

The project achieved two main goals: it gave them the opportunity to cost-effectively (1) test their database backups regularly and (2) create a DR strategy for their mission-critical applications. The customer has gone thru the different stages in their journey to the cloud until they’re ready to make the commitment.

Question: Where are you at in your journey to the cloud? Or are you even considering moving some of your workloads to the cloud? Share your story in the Comments section below.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.