Let's say one day, one of your IT teams (development, operations, sysadmins, whoever) realizes they could really use a tool to do "foo bar". "Foo bar" may be source control, issue tracking, etc. The tool itself is not important, but what is important is if it's any kind of client-server application (a web site, some sort of service with a thick-client, etc.). So one or more enterprising individuals on the team with the need decides to set up this tool themselves on their local workstation, or a spare server or VM they have laying around.
The tool they chose to do "foo bar" is a hit. The folks who set it up enjoy using it and it makes their job easier. They start telling other folks on the team about it. More people start using the tool and eventually its use spreads to other teams.
This sort of grassroots movement to introduce new tools into an organization is awesome because a need is clearly met by this tool, otherwise so many people wouldn't be using it. However, there is almost always one tiny detail that is glossed over when setting up this tool, and more importantly – when telling other people about this tool: the "connection details" of the tool's "server". Rather than ask for (or create) a DNS alias that has an actual meaning to it and that is related to the tool/application for which the host is being used, folks tend to pass out the actual underlying hostname of the computer running the tool.
This may seem like a small nit to pick on, but think about it: what happens if you need to move that tool to another computer? Maybe you need to get a more powerful server for it now that so many people are using it. Maybe you need to come up with a way to make a disaster recovery plan actually work. Maybe the dude who's workstation you used to first setup the prototype instance of the tool just got fired.
Whatever the reason is, you will inevitably need to put that tool's server component on another computer, and then what? If you just passed out the direct hostname to everyone, now umpteen people need to update their bookmarks, their thick-clients' connection details, etc. Your lack of planning on this superficially small detail just led to wasted time for a lot of people having to update something on their end because of a hostname change on the backend. This sounds a lot like a violation of one of our best practices: DRY – Don't Repeat Yourself.
All of this wasted time could've been avoided if you simply took a few minutes during the initial setup of this tool to get a DNS alias created that had meaning for your application. Setting up a web based issue tracker? Use an alias named after the product itself. Setting up your source control system? Use that as an alias: "sourcecontrol". Just pick a name with meaning. Then, when – not if – you need to move that service to another machine you do the move, then update the DNS alias to point to the new underlying hostname and your users won't have to update any "connection details" on their side.
Just like how you use a variable or constant in a programming language to avoid repeating the same value over and over again in source code, you should use aliases, not hostnames to avoid repeating hostnames over and over again in client application configuration.
Use Aliases, Not Hostnames is a post from: DevOps On Windows - Be awesome at Windows DevOps or Windows Sysadmin
The post Use Aliases, Not Hostnames appeared first on DevOps On Windows.
No comments:
Post a Comment