When I got started with computer programming, I immediately jumped into database programming. I wanted the application that I am writing to interact with a database so I can create, update and delete (CRUD) records. Every database developer knows that the first thing they need to learn is how to connect to a database – specifying a server name, a database name and credentials. That’s where the concept of a connection string gets introduced. And I bet that ConnectionStrings.com is a website that all database developers have used as a reference at some point in their career.

Once you start getting comfortable with using connection strings, it becomes second nature and you start to ignore it. That’s because majority of your time writing code is spent on application functionality, not on database connectivity (unless, of course, you are a programmer that writes database connectivity drivers.) And this is where it becomes a trap.

But how many database developers think about upgrading and/or migrating the databases that their application interacts with? Not too many, I guess. Besides, why would they even care? Once the application is finished, all they need to worry about are bug fixes and feature updates. Isn’t that where the revenue comes from? That’s why you are smarter than the average database developer because you are reading this blog post. So, what, you may ask, do smart database developers know about database connectivity? 

Smart Database Developers Use Aliases

When I worked as a data center engineer, the very first thing that my manager mentioned in the orientation was the way they refer to their servers. They don’t refer to them by name, they refer to them using aliases, specifically, DNS aliases. For example, we used a multi-part naming convention to refer to the servers using this format:

• Name of application running on the server, such as HR, sales, CRM or SharePoint-DB for SharePoint database server
• Department or division using the application, such as sales, marketing or public
• Environment, such as development, staging, production or disaster recovery (DR)
• Network Domain, such as the Active Directory domain or internet domain

Using this naming convention to refer to a server with hostname TDCA027 (even the server hostnames have naming conventions) running a SharePoint database server in the development environment for the legal department,

SharePoint-DB.legal.development.testdomain.com

At first, I find it cumbersome to refer to the servers this way. Why not just refer to them using the standard hostnames? Wouldn’t that be easier? Here are some of the reasons why it made sense to use aliases to refer to servers.

1. They provide a standard naming convention. I like this definition about what standards are, emphasis mine.”Standards are published documents that establish specifications and procedures designed to ensure the reliability of the materials, products, methods, and/or services people use every day. ” Because we have a standard naming convention, everyone is expected to follow those naming conventions. Our database developers configure their connection strings to use the aliases instead of the server hostname to connect to the databases. And because its a standard, every individual – server administrator, network engineer, database developer, etc. – joining the team is expected to use the aliases.
2. They provide abstraction for any future changes. This is the main reason why I like using aliases. Like anything else, database servers (or servers, in general) do not last forever. They will be upgraded, migrated, moved to a different hardware or location, etc. When we move a database server to a different hardware or platform, we try to minimize the perceived change as much as we possibly can. We can change the server hostname, the IP address, the hardware, location, etc. but once we’re ready to go live in production, all we needed to do is to point the alias to the new server. The application doesn’t even know that an upgrade or migration happened because it is still talking to the same name – the alias.
3. They allow for increased availability. You probably suspected that this is the real, main, primary reason why I like using aliases since I’m a high availability and disaster recovery expert. But, for me, it’s just a natural side effect. I can have my existing database server working as usual and my target ready to take over the load when we go live in the new production environment. I can cutover as quickly as I possibly can, redirect the alias to the new database server, resulting in minimized downtime for the application.  If things didn’t go as planned, I can always go back to the older version by simply redirecting the alias back to it.
4. They make applying changes easier. As a database developer, have you ever tried changing the connection string for hundreds, even thousands of client applications during a migration? I bet you wrote scripts to automate the process because you sure don’t want to be changing every single one of them by hand. Or maybe asked somebody else to do it because “you’ve got better things to do.” Using aliases eliminate the need to change connection strings because the network layer takes care of that for you. Just be sure you thank the network engineers after a successful migration.

When I learned how aliases worked, I started using them in the applications I wrote afterwards. Even if the database server is running in my own laptop, I still create an alias – be it a DNS alias, an entry in the hosts file or a SQL Server Client Alias – and use that to connect to my databases. It changed the way I think about writing code and looking at the whole network infrastructure. It actually helped me become better at high availability and disaster recovery.

Question: Do you use aliases to connect to your databases? If not, what other approaches do you use? You can share your experiences in the comments section below.