Why I know DBA role survives the public cloud.

Hand zooming into tablet with overhanging cloud.
Survival in the clouds.

For the past 10 years or so, I’ve seen it occasionally come up in the discussions that DBA won’t be needed in the future. Originally, it started with the vendors claiming that their database systems are becoming self-tuning. Then the final nail in the coffin was to be the public cloud, which was also to be self-tuning. And it wouldn’t be just self-tuning, it would be infused with AI and tears of the DBAs to produce absolute magic.

While technology has definitely gone forward, nothing’s yet fully self-tuning, but cloud (especially the cloud bills) have certainly brought tears to the eyes of many DBAs, and occasional CFO. There are also signs, that rather clearly, point to the fact that the DBA role, and other IT specialist roles, aren’t dying away anytime soon either.

Let me tell you why.


Database Migration, Modernization, and R-strategies.

Arrow pointing to the cloud.
Applications go here!

Public cloud is a really great place to put your application and database workloads. However, it’s not always clear how, exactly, that should happen. Some people talk about migrating, others about modernizing, a few mix everything together, and then there is a bunch of words that all start with the letter R.

In this post, based on my own experience, I’ll attempt to provide a clear differentiation between migration and modernization approaches, and how they map to a mysterious thing called the R-strategies. I will also introduce you to the third option called Midernization, or Moigration. Yeah, I know. The naming is a work-in-progress. Anyway, this is the option that no one recognizes, but almost everyone ends up doing it.


AWS Purpose-Built Databases, Part 3 of 3.

All good things must come to an end, including this 3 part blog post series. In this post, we’ll dive into one of the database systems I am not hugely familiar with, Apache Cassandra, and it’s AWS counterpart, Keyspaces. What is Cassandra, then? It’s an open-source distributed, wide column data store that is capable of providing extreme read and write performance for massive datasets, and delivering scalability and high-availability by forming a cluster from multiple nodes.

Cassandra clusters are also notoriously difficult to manage, with complex scale out and even more complex rollback operations. There are also a bunch of horror stories about the error-prone restoration mechanism, and patching operations of clusters gone horribly wrong. Moreover, it’s lacking a few things, like encryption support, and you do need to learn a new query language (CQL) to make use of it.

Luckily for us, AWS has something for most of the Cassandra pains. Read on, to learn about AWS Keyspaces.


AWS Purpose-Built Databases, Part 2 of 3

Continuing with the topic of purpose-built database on AWS. This time, I’ll be diving into the wonderful world of Document stores. For a while now, MongoDB has been the gold standard for Document databases. However, as of late, I have come to think AWS DocumentDB as a solid alternative for MongoDB as a document store.

And that is one of the reasons I am focusing on AWS and DocumentDB on this post, it’s an actual purpose-built Document store, rather than a multi-model database, such as CosmosDB. CosmosDB offers a wide variety of APIs to use, Document, Graph, Column and Key-Value, making it a multi-purpose database. The reason I am not touching on DynamoDB is, that the migrations from MongoDB to DocumentDB are much easier.

Before reading further, I’d recommend that you check out the first post in this series titled: AWS Purpose-Built Databases, Part 1 of 3. If you already did that, read on.


AWS Purpose-Built Databases, Part 1 of 3

I have been looking, for various reasons, to purpose-built database space recently. Purpose-built databases, as you can imagine, are databases that are specialized to provide just a single (well, in some cases it’s two) type of data store. Purpose-built databases are also great when you’re building modern, cloud native applications, which has led to the birth of some interesting, fully managed purpose-built database offerings. AWS especially has done a good work on the area, so I figured I’d explore available options there.

Since there’s actually a bunch of these databases available from AWS, I’ve decided to split the post into 3 parts. In the first part, we’ll look into Amazon offering for Redis. Redis is an open-source, in-memory database, that is very popular with the developers. It is also one where AWS is providing us with two alternatives for it. These are Amazon ElasticCache and Amazon MemoryDB.

Why two? Read on, and I’ll tell you…


Database restore performance oddities of SQL Server RDS

One of the things I’ve learned over the years is, that sometimes the performance in cloud platforms can be unpredictable and you always need to expect the unexpected. Most of the times these issues are just minor annoyances, but they can certainly be confusing the first time you run into any of them.

A while back I had one of these experiences as I was working with moving databases from on premises datacenter to AWS using the native restore and backup capability in RDS. It’s a really nice feature giving you ability to easily move data in and out from the RDS, using familiar tools for DBAs. However this time I ran into a weirdest issue with the initial restore performance.


Comparing SQL Server deployment options between Azure and AWS

Lately I’ve been spending lot of time outside my natural habitat, Azure, and I’ve entered the AWS frontier. Because of this I decided to write down some of my experiences about how the SQL Server deployments between these two cloud platforms compare to each other. AWS has been around longer than Azure by few years and is the largest of all the public cloud platforms, and I believe, that even today it’s hosting greater number of Windows based VMs than Azure.

With Azure Microsoft had the opposite approach to hosting SQL Server databases, and rather than starting with VMs they first released Azure SQL Database and then later on Microsoft added support for SQL Servers in VMs to attract more of the existing workloads into Azure. Noting the different approaches, let’s then take a look at how they compare when it comes to SQL Server deployments.

The competition of the cloudy giants