Cloud and Infrastructure: 'There Is No Easy Button'
SQL Server expert Allan Hirt shares what database pros need to know about their core infrastructure.
SQL Server holds the top spot in the database arena, serving as the backbone for both large corporations and small businesses alike. Yet, as cloud technology increasingly defines the future of database management, some IT professionals find themselves grappling with new challenges and a steep learning curve.
Allan Hirt, a Microsoft MVP and the founder of SQLHA, delves into the complexities of cloud-based infrastructure, highlighting the obstacles and misunderstandings that DBAs and IT experts often face.
Additionally, Hirt provides a preview of what attendees can expect from his forthcoming Live! 360 session in Orlando, Fla. this November. The session, "Modern Infrastructure Fundamentals for SQL Server," aims to equip professionals with the essential knowledge they need to effectively navigate the intricate domain of today's database management.
Redmond: Do you think DBAs (or IT pros in general) underestimate how much the cloud changes the way underlying database infrastructure functions? If so, why?
Hirt: The concepts are the same. Networking, storage, compute and security are still relevant. But how you plan, implement, configure and administer them could be completely different than on premises. Companies often underestimate the effort needed to get their core infrastructure elements (networking and security especially) implemented correctly in the cloud. Each cloud providers has "quirks," which is something that can make life challenging if you want to do multi-cloud deployments. Hybrid also adds complexity since you need to bridge on premises and the cloud so it feels seamless to end users. There is no easy button.
What's the risk in not adapting how we approach infrastructure for SQL Server for today's deployments? Any disaster stories you can share? (Of course, you don't have to name names.)
One of the things I see the most is people are still applying how they did things in a physical world to virtual and cloud-based deployments. Some best practices and approaches are the same while others are not.
Disaster is always relative. One of the biggest challenges I see and will be discussed in my session is understanding how performance works and is gated in the cloud. The costs of cloud-based resources becomes a factor because sizing improperly is expensive not only in monetary terms but also any downtime associated with fixing the problem.
What do you think is the biggest misunderstanding that DBAs have when it comes to understanding SQL Server infrastructure?
The biggest misunderstanding is that infrastructure is someone else's problem or they blindly trust what is underneath has been implemented correctly. As someone who has worked with many customers over the years and had to be the intermediary between DBAs and the infrastructure teams, this is not the case. For example, in a virtualized environment, how will you determine if a problem is coming from outside of the VM running SQL Server? If you do not understand some virtualization concepts and have some access to the underlying hypervisor hosts, how do you know where the issue is stemming from? The cloud has many of the same issues. More layers equals more abstraction, so you need a plan to deal with that.
How much would you say SQL Server has changed to keep up with a cloud-first world? And do you think DBAs have, by and large, kept up?
SQL Server has some cloud-enabled features, but if it's just a traditional SQL Server instance deployed on top of an operating system running in a VM (on premises or IaaS). The differences are mainly at the underlying hypervisor or cloud platform -- not inside the VM with the OS and SQL Server.
If you are talking Amazon RDS for SQL Server, Cloud SQL for SQL Server (Google), Azure SQL Database or Azure SQL Managed Instance, those are different in many ways from traditional installations of SQL Server.
Some DBAs do a good job keeping up, but the reality is that everyone is busy. One thing some never talk about is that SQL Server is not just a RDBMS; it has many components that are not tied to SQL Server directly. What do you use when? That's outside the scope of this session, but an important consideration when choosing what to do. Add to that companies are not always quick to adapt to new versions of products let alone how fast things change in the cloud. All of that is challenging for the best of us and leads to tech debt -- including day-to-day skills.
What's the biggest takeaway you hope your attendees will get from your session?
Everyone responsible for SQL Server needs fundamental infrastructure knowledge. If someone attending the session is not the one tasked to configure networking, storage, etc., my goal is to provide the right information to be able to speak the same language and have effective conversations with the person that will be doing the infrastructure work.