Voice of the DBA

Category: Editorial

  • Managed Instance Impressions

    Several years ago, I heard about a new product coming in Azure that would provide an IaaS (infrastructure as a service) VM to run SQL Server, with Microsoft managing most of the admin tasks for the instance, like patching and backups. That didn’t seem like a big load to me, and I wondered if anyone would actually pay for this product. After all, don’t most companies find managing patches and backups fairly easy to manage?

    That product became Azure SQL Managed Instance, and I’ve been surprised at the adoption. Quite a few clients have adopted this as a way to lift and shift (mostly) to the cloud in an easy fashion without the restrictions of Azure SQL Database. This looks like a “normal” on-premises SQL Server, and there are both high-performance (Business Critical tier) and average-performance (General Purpose tier) versions of the product that let you choose what level of price/performance you need to achieve.

    I’m curious today, and I have a question. What are your impressions of Managed Instance (MI)? Whether you use it, you have heard of it, or if you just read this description. Give me a few thoughts on whether this makes sense, performs well, or has issues you need (or wish would be) addressed.

    I’ve heard there are some issues with I/O, but I also have clients who find it performs very well for them. I hear similar things from on-premises SQL Server instances, so I often think that either the software is designed well or the hardware architecture doesn’t match the workload. There have been a lot of enhancements to MI since its release, including the ability to backup and restore to/from SQL Server 2022.

    There is even an offer from Microsoft that lets you try out MI for free (for a period of time). This is a way for you to test migrate a database to the cloud and measure the performance. You might need to do some work to measure your current performance in a way that lets you determine how MI stacks up. You will also need to do some financial number crunching to decide whether there is an ROI that makes sense. If you do that, be sure you reach out to your internal finance people to understand the differences between CapEx and OpEx expenditures for your analysis. Paying $50k a year for an MI license isn’t the same as spending $50k for a server and hosting.

    I’m not sure what I think of MI. Like many offerings, I think there are places where it makes sense and places where it doesn’t. It’s not a simple decision for me as an abstract question. For specific situations, I might lean one way or the other, but I’d want to do some workload analysis to justify or discard my initial thoughts.

    Share your thoughts and impressions today. You might help some of us learn more about why we might or might not use MI. You might even help clarify your own thoughts by writing them down.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The Costs and Rewards of Speaking

    Most of the people I know who speak at a SQL Saturday or user group aren’t paid for their efforts. At many of the community events, the speakers are volunteering their time. Many are also paying for their own way to those events not located in their area. A few, such as me, might get a company to cover their travel expenses, but often this doesn’t include time. If I attend a SQL Saturday, I still have a bunch of work on M-F that needs to be done. No comp time for these events. That being said, I’m happy to donate some time and money to community events.

    Some speakers build and teach full-day sessions, usually called pre-conference sessions, for which they are paid. There can be competition at large events like the PASS Data Community Summit and SQL Bits to get a session since the payment can be rewarding. I’ve seen some speakers make USD$1k or so, which can cover travel expenses, and others make over USD$10k, which is a nice payday.

    Most of us don’t want to teach a full day of sessions, usually because it’s a lot of work to build a day of training. It’s also very nerve-wracking to try and teach people who have paid you. A lot of speakers don’t really want to deal with that stress. I’ve done it, and it is hard work. I don’t deliver pre-cons at events because I get expenses covered at lots of events and prefer not to compete with others who might want to earn some money while growing their careers.

    However, lots of people want to share their knowledge and teach others something useful. It’s been amazing to me how many people have stepped up to submit sessions and present them at events all over the world. I’ve been lucky and honored to meet many of these volunteers and call them friends.

    When Andy, Brian, and I started SQL Saturday, we weren’t sure there would be enough speakers to run 10 events in a year in 10 cities. At the time, the PASS Summit and a few other conferences were the only places to speak outside of user groups and we weren’t sure there would actually be enough people in a community willing to speak to run a conference. We also weren’t sure that many people would travel outside their home area to speak.

    I’m thrilled we were wrong. So many people have volunteered their time and energy to build a session and then deliver it at user groups and local events that there are often more speakers than spaces available for them. I’m also glad that so many of you attend and support local events.

    Speaking can be intimidating, but I know many of you can do it. It’s scary, and it’s something I never thought I’d do when I left university. It is a lot of work, it interrupts your free time, and it doesn’t pay you any hard currency after a session. However, it’s also thrilling to help others, exciting to have them listen to you, it hones your communication skills, and it is impressive to employers. On balance, I’d say that even delivering a presentation at your local user group is a profitable endeavor and a memorable experience.

    I hope we continue to see more of you willing to deliver a session for your peers, share some of your knowledge. I also hope that we see more of you stepping up to help organize a SQL Saturday or another local event in your community.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Invisible Downtime

    This article has a concept I’ve never heard about: invisible downtime. This is the idea that there are problems in your application that the customer sees. Your servers are running, but the application doesn’t work correctly or is pausing with a delay that impacts customers. From an IT perspective, the SLA is being met and there aren’t any problems. From a customer viewpoint, they’re ready to start looking at a competitor’s offering.

    Lots of developers and operations people know there are issues in our systems. We know networks go down or connectivity to some service is delayed. We also know the database gets slow, or at least, slower than we’d like. We know there are poor-performing code and under-sized hardware, running with storage that doesn’t produce as many IOPs as our workload demands. We would also like time to fix these issues, but often we aren’t given any resources.

    The current buzzword among executives and senior IT leaders is observability. It’s the goal of looking at how our entire system, application, database, and network, are linked and performing with an eye on improving performance. Not because they want to spend time or money here, but because customers are becoming more fickle and quick to move to another offering. Leaders know that degraded application performance (another phrase for invisible downtime) can have real bottom-line impacts on revenue.

    There are a lot of products in this space, application performance monitoring (APM), designed to look at lines of code and determine how well each is performing. They can help you spot issues in application code, but they lack insight into database and network details, at least at a level that the experts need. As a result, digging into performance issues and root cause analysis of problems usually means pulling data from multiple sources and correlating log entries.

    This is likely an area where AI/ML technologies can help, especially across large estates, though I think in many cases, what we need is just a pointer to poor-performing code. C#, Java, SQL, whatever. We need to know where the bad code is and then we need to train developers to write more efficient code. That might be the best way to improve application and database performance.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Kubernetes is Cool, But …

    Kubernetes is cool, and I think it’s really useful in helping us scale and manage multiple systems easily in a fault-tolerant way. Actually, I don’t think Kubernetes per se is important itself; more it seems that the idea of some orchestration engine to manage containers and systems is what really matters. As a side note, there are other orchestrators such as Mesos, OpenShift, and Nomad.

    However, do we need to know Kubernetes to use it for databases? This is a data platform newsletter, and most of us work with databases in some way. I do see more databases moving to the cloud, and a few moving to containers. I was thinking about this when I saw a Simple Talk article on Kubernetes for Complete Beginners. It’s a basic article that looks at what the platform consists of, how it works, and how to set up a mini Kubernetes platform on your system. It’s well written and interesting, but …

    Do we need to know anything about it? Are we running databases in containers, or will we? I think it’s possible that we might run any of our databases in containers. They are like lightweight VMs and there isn’t a reason why we wouldn’t run a database in a container. With external storage, of course, which gives you a cluster-like environment where your storage moves to a new node if the first one fails. That’s a good use case. Deploying consistent environments quickly is a good use case. Using Kubernetes to manage the containers is great, but …

    I don’t think we need to know much about Kubernetes. I don’t think most of us should run it and should outsource any container orchestration to the cloud if we decide to implement database containers. These orchestration engines are quite complex today, and there is a lot of expertise needed to manage them. I don’t know that expertise is worth trying to find, train, and retain for most organizations. We should just outsource the container management to someone else.

    We might need to know how we change the configuration of some resources, but that’s minor knowledge, and really, I suspect that outsourced K8S (shorthand for Kubernetes) will have GUI tools that let you easily pick and choose the CPUs, memory, etc. and then an export of the JSON or YAML or whatever is needed for the config. Most of us likely need the skills to export, save (in a VCS) the files, and then submit them to the cluster.

    A few years ago I went through a bunch of courses and reading material on Kubernetes. I set up some small clusters, I experimented with pods, I even was excited to think about managing containers for various services. What I discovered is that Kubernetes is complex, hard, and something I want someone else to run. Once I set up a cluster in Azure I thought I’d never want to do this on-premises again.

    Much like email. I have run email servers, but …

    I’d like to never run one again, which is how I feel about Kubernetes.

    I think containers have proven more complex and harder to work with than many people thought. I know there are plenty of people using them, but it’s a minority. I see many more organizations still building monoliths, or microservices that run as processes, or client-server apps. Not that many people are excited and using containers. That may change, and if you go to the cloud, containers give you portability that many other solutions don’t, so I’d recommend them there. However, they are still a bit immature, and hard to manage. I think it will be a while before we see lots of databases on containers.

    Even if we do, I’m not sure we need to learn Kubernetes as database people.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.