3 things that slow down Enterprise SQL Server migrations | Data Exposed

Key Takeaways

Hi, I'm Anna Hoffman and welcome back to Data Exposed. Today I'm joined by Dhananjay. Dhananjay, thanks so much for coming back on Data Exposed. It's been a while but we're happy to have you back. >> Yeah, thanks Anna. Thanks for the welcome and yes for those who don't know me, I'm Dhananjay Mahajan. I'm a product manager on the SQL Server team and I've helped customers with their SQL which is outside of Azure as well as on Azure. Today I'm here to talk to Anna about what I'm doing which is which is what I love is help customers with SQL modernization and migration. >> Awesome. Well, it's great to have you on the show and I love this topic because everybody's hearing a lot of buzz about migration modernization. Before we get into the main topic, I want to ask like what are some of the reasons or triggers that you see most often with customers that lead them to think about migrating or modernizing? >> Yeah. Yeah, Anna. I mean we talked to hundreds of customers as the SQL Server team. Big, small, medium business, all of them. And many of them are so happy with SQL because the engine is so robust, enterprise ready, scalable that they're like I don't need to modernize. But when does that modernization step happen? When does that migration? Is when they need to do any kind of hardware refreshes, renewals, and they're looking at license renewals. The cash flow is a challenge for many customers in this environment or they they tend to have cybersecurity threats which worry them. I mean data is actually very very important for customers and so that is their business and they don't want any cybersecurity threats. That's when they start looking at the cloud. IT budgets as you know are shrinking and business may need more assets to be pushed into the business rather than doing hardware, software, or building teams to manage, that's when they can go to Azure and start using Azure as a service. Uh their ability to meet search demand. I have some customers who say, uh you know, whether they're in retail and shopping season, or now food uh you know, World Cup Soccer is going on, and that's that's a big season for many customers who are using SQL, uh and they don't want to provision based on that search demand. Uh and and then the most important things about uh Azure, as well as any cloud, is business continuity. The high availability, disaster recovery, almost elastic ability to go to unlimited compute and storage as as people want it. Uh so, rather than uh spending on their own data centers or giving a third party money to their data centers as their contracts become ready to expire, they want to use uh Azure whenever possible. >> Absolutely. Yeah, that makes a lot of sense. And of these these different uh areas that you mentioned kind of resonate with me, and I'm sure resonate with our viewers. Now, the maybe the the interesting thing that we're really going to talk about today is, you know, what are the three things that you're seeing slow enterprises down when it comes to their SQL Server migrations? And kind of let's help alleviate those, maybe. >> Yeah. Yeah, I mean, for some customers, cloud it their past the the decision making of whether they want to go to cloud or not. It's only when a matter of when. But especially what I saw, and I've been in the infrastructure cloud business before I came over to SQL, uh uh the the data folks are are more concerned about downtime fear. Because their businesses are running on this data, and there is a risk if something goes down. Uh so, they want those guarantees to still stay up and running with uh nines or five nines. Uh and if they're offered through migration, then what if they migrate and if they don't make the right uh choices? Number two is cost surprises. Many customers do not make the right decisions as they select their migration journey. Try to take the the fastest path or the easiest path, and then later on they find out that they had not budgeted for the migration cost. Uh there is a complexity in the licensing model in Azure cost model that does come into play, but it is for good reason to give our customers the choice. If they take the time to understand the various cost models and really make that predictability a a lot easier in terms of cost before migrating. And then the third thing is uh past compatibility. They're kind of concerned, am I going to get the same level of functionality as as I got in the past and then are there any gaps in functionality? So, those are the reasons. >> Yeah, this makes a ton of sense, and I'd love to now that we've figured out what slows them down, let's use the next couple minutes to speed them up. >> [laughter] >> Yeah, absolutely. >> So, let's look at the first one. The first one was downtime fear. How can we kind of alleviate this concern from customers? >> Yeah. Yeah, so uh so so the uh fun thing about cloud is cloud was made to have that high resilience and high availability and business continuity. Well, Azure SQL provides you a layered approach towards business continuity. And I'm going to talk about Azure SQL Managed Instance in this case, which is one of our more mature Azure SQL offerings. Uh and later on I'll also talk about Hyperscale, which also has some aspects of this. Uh the first layer of you know, there's kind of a three layers of business continuity that we offer. The first one is local redundancy. So, built into every SQL MI instance at no extra cost is handling node failures and providing planned maintenance. This almost gives 4 9 SLA and and recovery, you know, time of almost 0 seconds. So, it's it's really instant. The second layer is zone redundancy, which is for multiple availability zones. Your SQL MI resources are distributed across multiple availability zones within a region. And think of each zone being kind of its isolated data center in some such sense. So, it protects you against an entire data center failure within a region. It uses synchronous replication by zone redundant storage for general purpose or always on availability group replicas across these zones for business critical tier. So, depending on the tier you, which means zero data loss for business critical. There is a little bit potential data loss for the general purpose. And failover typically happens in under 30 seconds and your SLA jumps to 4 9s and 5s. A zone redundancy, treating it as another data center, imagine the entire data center within a region gone and you still can can get RTO recovery time objectives can take longer if that this is not planned appropriately. So, so that's those are the three options you have. And then the third layer is failover groups. This is cross-region disaster recovery. Imagine an entire like US West or one of the regions going down. What do you do in that case? In this case, if you set up that cross-region disaster recovery through failover groups, it asynchronously replicates all user database to a secondary SQL managed instance with the storage in a different Azure region region. Because it's async, there is potential small data loss that can happen while the sync is happening, but it protects you against the worst case, a full region outage. And with the license free standby benefit, you can get the secondary at no cost at all. So, the vCore licensing it's if it's purely for disaster recovery. >> Awesome. It seems like there's a lot of great options here. And by the way, for Hyperscale, uh all of these same options apply. I think the biggest difference is instead of failover groups, you use uh geo replicas. But it's great to know you have whether it's Azure SQL MI or Hyperscale, you're good on that front. Okay, the second thing that you mentioned, I think was cost. Uh so, how can how can you help us save money when we move to Azure? >> Absolutely. That's that's important and especially in cloud, I think it's important to understand how we can save costs. So, we have five different ways that you need to consider uh on how you can save costs. And it could be uh Anna, a combination of these things. Um assessment uh that you can get through, you know, some of our tooling that we have, whether it's Arc enabled migration assessment or it's uh data migration service. They all use the underlying same um uh underlying engine for assessment, but that can give you some recommendation, but it's important to understand the aspects behind it. So, if you look at Azure SQL DB, you get the same SQL Server engine compatibility HADR, but all bundled into one price, which is no separate cost for Azure license. So, that's your best option if you're worried about cost and paying licenses. Hyperscale separates compute and storage separately, so they can scale independently and does not force what we heard some customers say that, "Hey, because I want this level of storage, you're making me buy compute which doesn't work for us. It's serverless. You only pay for what you use both in compute and storage. So, when you have seasonal workloads like I was mentioning like well, FIFA World uh World Cup is going on, you only pay for as much as you use. You use it for Many of our customers use it for dev test, for SaaS applications. When they have a predictable data and trend on on how their workload changes, this is where they use it because it uses the cloud elasticity and gets 60% saving if they start using elastic pools. Uh does not charge anything for IO IO. So, so your best option if you're ready to replat is Azure SQL uh DB Hyperscale. Now, let's go to the left one, which is number one, which is Azure Hybrid Benefit. Why pay twice for SQL licenses? Azure Hybrid Benefit lets you use existing SQL Server investments to Azure and reduce your overall cost. So, do not wait for migrating or modernizing. Uh it accelerates your ROI for cloud migration while preserving all the investments you've made and benefits both on the technical side as well as uh the the commercial side. Then, uh we announced recently uh Azure SQL free offer. Uh you want to take advantage of that. It's the strongest product offering we have where you can get an entire capability of 10 Azure SQL uh free tier with 100,000 V core seconds of serverless compute, 32 GB of data storage, 32 GB of backup storage, serverless auto scaling, auto pause, all of those capabilities that you need. And you can set limits by saying, oh, if I start exceeding my my free for the month, you can pause auto pause your your your workload. So, run POCs, proof of concepts at no cost, evaluate how that works. Uh that's the number three. And then the reserved instances. When you combine that with Azure Hybrid Benefit, you're making uh a lot of uh savings based on reserving your instances up to 33% and put together with AHB, it's even 80%. And then on fifth, pay as you go gives you the cloud style licensing for your SQL servers that are running outside of SQL, on premises, at the edge, in the cloud. Instead of making a large upfront uh cost investment, you only pay a SQL server when it's running, while you're still gaining the capabilities of Arc management. And this comes with Azure Arc, so you have to enable Azure Arc for its security, monitoring, modernization. So use assessment, use your calculators before you make your modernization migration uh options. Number two, use cost governance levers and triggers so that you know that you're not exceeding cost. And then include, you know, included in this is all the services. So though open source software like like Postgres and MySQL look like they're free, they're not really free. The fact that you're getting all kinds of mana- database management service and database as a service with Azure SQL DB and even with Fabric, uh you want to take that into consideration and not just look at the price value on on the face from the assessment. So so keep all of these things in mind so you get a true picture of cost rather than trying to look at just what's being told to you. >> Awesome, that's great. I love this. I I think I learned a lot even just in this. I learned a couple things that I didn't know. Uh so thanks for sharing that. Okay, so we talked about um disasters and protecting against disasters. We talked about cost. And there's one more thing that slows enterprises down in their migrations. What was that last thing? >> The last thing was fast compatibility. Many customers think that if they go to pass, they're not going to be compatible. I know one of our uh you know, federal customers was worried that hey, if I move this to pass, will it break my application? You know, all of these things. Now, in certain cases, it makes sense and because if you have a third-party ISV who has built this app for you and they're not willing to support you. But, if this is your built-in app, I think you should totally consider and not have fears for pass pass deployment. Here are a few tips I'll I'll share with you because we in um in Azure SQL have multiple deployments mode uh deployment modes. Um actually, it's the same engine under the covers. It's available on AWS, GCP, if you're running on VMs, uh but it's the same engine, so you get the capability. The difference is how the manageability is done and how scaling is done where you can get the uh operational benefits. And if you want to go cloud-native, then Azure SQL database Hyperscale is the option that you should totally go to and modernize. That's where many of our customers have seen the benefit because they've modernized to their most demanding workloads, use the unlimited growth, virtually unlimited growth uh that they can see high performance, cloud-scale economics. We take that engine and build all of these capabilities for an enterprise-scale database as a service that can stay scale storage and compute independently, have multi-terabyte databases, accelerate the performance, give read scale replicas. All of those are al- allowed for cloud-native applications and full modernization with infrastructure, backups, patching, all included in that price. You can't beat that. But, if you can't, you want to go with SQL managed instance, one of our most uh backward compatible services that we we are offering where you can modernize the instance, apps will still work. You don't need to change the app, but the management of the infrastructure, the OS, you know, even the SQL Server is handled by Microsoft. So, all of that overhead is gone and you don't need to manage that infrastructure. Uh we with Postgres, you know, it makes no sense to go to Postgres because you don't want to pay the license because you'll have to replat. That's why you have the offerings and if if a customer comes and says that, "Hey, I do not I cannot just take this app. It's a huge monolith app. I can't move it." I would still say Azure SQL Server running on Azure SQL VM is a great option. It's a lift and shift and we have all kinds of tooling uh to to help you build that right approach. So, please do not work worry about past compatibility. We have pass and we have multiple pass solutions and paths to go along the way and if you absolutely cannot do it, still consider the IaaS options that we have. >> Awesome. Well, thanks so much to Han Jay. I learned a lot. If we look at the the three reasons that folks get slowed down, it's not having uh thinking there's not the right support for a disaster, thinking there's challenges with cost, and thinking that they're going to struggle with past compatibility and you enlightened us on a lot of the different options and flexibilities and ways that we can do this uh for SQL Server customers. Um so, thanks so much to Han Jay. I learned a lot on this episode. I'm sure viewers did as well. We're going to put some links in the description for you to learn more because uh folks aren't alone, right Han and Jay? There's folks to help. >> Yeah. We have a full migration guide. We're continuing to invest in that migration guide. We're going to give you tool kits, especially those who are partners helping customers. Come to us, talk to your partner manager. We're going to give you tool kits and we're going to give you all kinds of technical deep dive training so you can help your customers make the best choices and not worry about those three things Anna you were just summarizing. >> Awesome. Great. Well, Dhananjay thanks again so much. Our viewers give us a like and let us know what you think and we hope to see you next time on Data Exposed.