In today’s “AWS re:Invent” keynote, Andy Jassy, Senior VP of AWS (Amazon Web Services), said that 90% of their roadmap is driven directly by client feedback. For the other 10%, they listen to what the clients say but have to think about what the client really wants and invent on their behalf to solve the problem. Is server name convention one such scenario where those of us in the cloud space need to innovate?
One of my clients is so invested in their DNS naming convention that their applications and security protocols expect servers to follow a specific convention. They have requested that an IaaS (Infrastructure-as-a-Service) solution needs to conform to their DNS naming standard because it would be so difficult to move away from their convention.
Can we build clouds that scale and meet existing DNS naming conventions? Do we want to? In the long-term, when enterprises have fully embraced cloud, my belief is that we will move away from server naming conventions to server tagging and search. Such a transition will neither be quick nor easy. As Mark Twain wrote in The Adventures of Tom Sawyer, “the less there is to justify a traditional custom, the harder it is to get rid of it”. We will need interim solutions.
About DNS naming conventions
Many enterprises have meaningful and easier to remember hostnames and/or domain names schemes, where one could have a server named like:
Cloud instances, however, often have long and hard-to-remember names. For example, a typical Amazon EC2 public DNS name looks something like:
The DNS names need to be long in order for each name to remain unique. A good analogy for the difference in naming conventions is pets vs. cattle. Pets have meaningful names and cattle have identification numbers. For more information on this analogy, see “Is OpenStack and VMware like Cattle and Pets?”.
An analogy: server naming conventions to e-mail folders
Let us consider a topic we are more familiar with, e-mail. Compare a server naming convention to creating folders for e-mail. A post titled “e-mail folders are the worst, as proven by math and science” cites a study by the University of Santa Cruz. The author states, “there are two types of people in the world. Those who create folders and those who use search”. The study quantifies the difference, stating “When trying to retrieve messages, a folder person spends 59 seconds, on average, looking for said email. A search person spends 17 seconds.” Those using search typically save hundreds of hours a year over those who use folders. Yet, there are generations of people who still use folders.
Tools exist that allow us to search for servers. Consider, for example, the configuration management tool chef. With chef, one can search for servers based on roles. To search for all web servers, one could execute a command like this:
knife search node "role:webserver"
One could even search on an id, which is almost like having a server name.
knife search node "id:zeus"
So what do we do with server hostnames in the cloud? Searching for servers in a cloud, like searching for e-mail, is more efficient but adoption is slowed by a traditional approach. We need an interim solution. We want to provide a way for users to use both search and a traditional approach. Even gmail, with its “Search, don’t sort” philosophy allows users to categorize e-mail using labels, which can be used liked folders.
Solutions as we transition to Cloud
What are the options? AWS allows users to integrate instances with public Dynamic DNS services. Beyond this, I did some experimentation with OpenStack clouds. I created my own dynamic DNS and was able to setup all instances in an OpenStack cloud to use my own custom server name scheme. Furthermore, I was able to setup a server name scheme for just the servers in one OpenStack project. So it is possible to use custom server name schemes for part or all of a cloud.
So if the long-term strategy is server search versus naming conventions, there are short-term ways to help with the transition. Subsets of a cloud can still be customized to use a server convention by leveraging cloud APIs like OpenStack with DNS servers dedicated to a subset of a cloud. In a future post, I will explain how to integrate parts or all of an OpenStack cloud with a custom DNS server.