Voice of the DBA

Category: Editorial

  • Cloud Databases

    Most of us are used to a database that lives on a server somewhere. It might be in our data center or a VM that exists somewhere, but it’s really an on-premises type of infrastructure. Even if the VM is in AWS or Azure, this is a single system on a server that we control. We can add HA capabilities to this system, but the model is the same as if the database were on our development workstation.

    Note: this doesn’t matter if this is an RDBMS like SQL Server or PostgreSQL or a NoSQL type system, such as MongoDB or Neo4J.

    That’s a comfortable system, and it’s how we’ve built many applications over the years that support our business processes. Many of us default to architecting and thinking about our applications with this model.

    These days there are cloud databases, which can be used in this model, but which also have other capabilities. I ran across a piece that noted cloud databases ought to be a part of our modern tech stack, and I tend to agree. These days the need to be more flexible, available, and secure are important for applications. An on-premises database might not meet these needs.

    A cloud database is typically a system designed to be more of a PaaS service, with replication, built-in HA, scaling, and more. Azure SQL Database might be considered cloud-native, but I think it lacks some of the features that we might take advantage of in CosmosDB, Couchbase, or CockroachDB. Things like the availability from various types of connections, quick and easy failover and sync from different regions around the world, and low latency for users anywhere.

    A few examples are in the article, and I see these types of requirements coming about more and more often as our clients start connecting from different devices in different locales, and at scales that are harder to handle with a single on-premises (or clustered) database system. While you might be able to handle the workload, is it worth it for you to manage some of the infrastructure and administration that a cloud vendor can do instead?

    That is why I think you ought to learn about and understand where a cloud database might be useful. While not all of us have clients all over the world needing real-time access from various devices and applications, we might grow into that need. Whether it’s clients that are employees or customers, there are increasing demands for flexible ways to handle the growing workloads on our databases. You want to be prepared for when you might exceed the capabilities of the platform you’re used to,  that way you can decide when adopting a cloud database might make sense.

    Steve Jones

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

  • Republish: The Right Connection

    Today I am on holiday. My last day in Venice, Italy with my wife, so you get to re-read The Right Connection

  • The Communication Channels at Work

    Recently a friend started a new job that didn’t have Slack used as a communication vehicle. The new employer was considering Teams, but most of the communication among employees was done through email or a live meeting.

    At Redgate, we use Slack extensively. I also use Teams for some work with Microsoft, and in general, I find I prefer Slack. That might be because I don’t spend enough time in Teams, but regardless, I find myself preferring email for discussions with MS employees over Teams. That’s my preference, but really, what I value is the instantaneous, yet async, nature of using messaging tools over email.

    I think one of the reasons I like tools like Slack is the separation of topics into various threads based on some subject. We have more channels at Redgate than people, but this is because there are different needs. For example, there are a few different “ask” channels. One is for advocates (Grant and I), one for tech questions, one for licensing, one for each country, and one populated by queries coming in from customers. We have a public channel for each product, as well as one or more private team channels for their daily work. We have automated channels updated by releases and deployments, and we create quick channels when there is a sales discussion or internal issue to keep our conversations focused on an issue.

    Perhaps focus is the real reason that I find these messaging tools handy. If everyone is online, we can have a real-time discussion. If people are not available, we can leave a message and hope they see it later. The one downside I’ve learned is that I can’t assume someone has read a message if they don’t reply or leave a reaction. If I do need someone, I message them in some other way to ask them to look at something in Slack.

    I also extensively use messaging options on Linked In, Twitter, Facebook, and other platforms as well. While I do find email nice for many things, there are a lot of short exchanges that work well in another format. Email tends to work better for me when there is a need for more than a couple of replies and we need to keep track of the discussion. A fast-flowing stream of messages in Slack or Teams can be hard to sort through after a few days.

    In some sense, I miss the old days of walking to someone’s desk or calling a short meeting and having a discussion. I still take those opportunities when they present themselves, but most of my communication takes place electronically, and messaging dominates.

    Do you feel the same way? Does your company or team use messaging tools? Are they handy? How do you decide where to post things, and is there a good separation of topics and subjects for you? Let me know today.

    Steve Jones

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

  • Custom SQL Server on RDS

    One of the challenges in moving to the cloud is achieving a similar level of performance to what you would get with dedicated hardware on-premises. The cloud is someone else’s computer, and you are limited to the choices that the vendors allow you to rent. In many cases, you might even share the physical hardware resources with other customers, though many cloud providers have started to allow dedicated hardware reservations in the last few years.

    One of the challenges of choosing a PaaS cloud database platform is that there are often restrictions that differ from a similar platform on-premises. This is often to ensure that one customer doesn’t affect another, or that customers don’t make changes that might prevent the vendor from supporting the system. Azure SQL Database gives us a database only, no instance features, though we do see a virtual master database.

    AWS, however, is changing its RDS offering to allow customers to customize their database software. They started with Oracle and then added SQL Server. For the SQL Server offering, they will let you not only change the instance config with things like CLR and install drivers in the host OS. They’ll continue to manage the overall service, and handle backups, DR, etc. You can focus on your database, but if you have special configuration needs, you can set them up.

    This is a nice evolution of the cloud by giving customers more control and meeting their needs, but not forcing them to handle everything. While a lot of technologists don’t think the OS adds a burden to a DBA, I’d disagree. I think the popularity of RDS and Azure SQL Managed Instance show that a lot of customers feel the way I do. Paying for a service to be managed is valuable, and it allows your staff to focus on more helpful tasks, like performance tuning, finding data quality issues, etc.

    Of course, your staff has to take advantage of that extra time. I see plenty of companies that don’t culturally change how they work with their systems, and that means that a lot of the benefits the cloud offers aren’t being seen by the company.

    Steve Jones

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