|
| Featured Contents |
| Question of the Day |
| |
| The Voice of the DBA |
| The Managed Cloud Database Options There are many, many choices for cloud database services these days. I would hope everyone is aware of the various IaaS options in public clouds with EC2, Azure VMs, GCP Compute Engine, and others. These are often the easiest way to move your workload, but you've really just moved a VM from one place to another (likely more expensive) place. For managed databases, there are lots of choices, but you might not be aware of your options. I ran across an article that discusses the various flavors of managed databases in the big three public clouds for SQL Server. In the piece, there is a section that talks about when a managed database makes sense. I like that it discloses the development on a managed service is expensive. The problem I have is that I know lots of companies that struggle when they don't have a development environment that matches product. Invariably developers will use something in their local SQL Server/MySQL/Oracle/PostgreSQL database that doesn't work in a managed service and causes no shortage of pain. Containers can help, but they're not always available. I won't delve into details, but the article lightly looks at RDS (Amazon), Azure SQL DB and Managed Instance (Microsoft), and Cloud SQL (Google). There are pros and cons for all of them, but to me, the Google option is interesting. It gives you an instance (with SSIS/SSRS) and a proxy, but it does have limit you to instance restores. Same for RDS, which is a limitation I'd be worried about. Often I have an issue with a database, really often with just a table. Restoring a whole instance instead of a db might be a delay I wouldn't want to deal with. I hope this changes over time, as not recovering a database from an instance is a big hole to me. The comparison of hardware resources and performance seems to show Azure has the highest capacities, but as the article notes, if you approach the maximums, the cost is very high. I tend to agree there, and I think this is one of the things that gets lost when companies consider the cloud for workloads. They look at the maximums with an eye towards growth if they need it. Rarely, however, do they compute the increased cost if they've under-provisioned resources. There's also the concern that trying to match CPU/RAM/disk from on-premises to the cloud isn't easy. This often isn't the same type of comparison that most of are used to with local machines. The main thing I find too many people forgetting is that moving to the cloud is a new architecture. You likely need to rework/refactor/rewrite your application to work better. Part of that work is reducing the amount and frequency of data queries. Without changing those things, you likely will end up spending a lot more money than you expect. Possibly without getting the workload response you expect. The cloud can work well for your application and database, but it's not easy and it's not quick. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
| |
| Featured Contents |
