What’s in a (Host) Name?

Dale Carnegie taught our grandparents 80 years ago that a “person’s name is to that person the sweetest sound in any language.” For IT organizations the sweetest sound is often…a hostname.

Of all the transformative concepts that moving to a hybrid cloud can facilitate, it’s the little things that we as cloud enablers hear from customers that can catch us off guard. When we at SovLabs embarked on building Cloud Management Platforms about five years ago, we assumed the ability to automate Oracle deployments from the VM to the IP addresses, DNS names, load balancers, firewalls, and application code would be gold for those teams engaged in manual deployments. What we found was that the first question IT pros asked when automating builds was, “How do I provision machines using my organization’s custom hostnaming standard?”

Every IT department has its own naming standard that is simultaneously simple yet incredibly convoluted. Maybe your hostname contains the city of the datacenter, the operating system, the application identifier, the business unit, and an incrementing digit. Or maybe it maps to the name of the hypervisor, the location in the datacenter, and the chargeback identifier. Some organizations use octal number systems while others use hexadecimal. The challenge when extending vRealize Automation to handle hostnaming standards is to create an interface that can handle absolutely any hostname.

Of course, the real question is … why do you overload your hostname with all this crazy metadata? With most customers this is due to using “legacy” concepts. See, in the old days most IT departments didn’t have a reliable CMDB or a reliable way to get data into that CMDB. Also, servers lasted forever. You could get a monitoring alert and say definitively, “That is a web server for our biggest financial services client that runs Apache and is in the Atlanta datacenter!”

As technology moved forward, hosts can be seamlessly moved from coast to coast with little or no warning. New servers can be deployed or destroyed based on customer demand. Servers no longer live forever nor do they even have to live in the same place for too long. The sheer fleeting nature of the cloud has made such nomenclature largely either irrelevant or something that goes stale quickly.

We recommend integrating your cloud with a CMDB (our customers have found ServiceNow’s easiest because of its rich APIs) and the SovLabs vRealize Automation module for CI creation. Then you can name your servers whatever you like because you’ll always know whatever you need to know without overloading a hostname.

Like Dom Perignon popping the first cork of champagne in his monastery, this “accidental” discovery in vRealize Automation has led many IT departments to pop a cork or two. The bubbly fluid of easy naming standard adherence is, however, only the beginning of vRealize Automation extensibility with SovLabs. Once your VM is provisioned with a custom hostname, automating all the complicated stuff is pretty slick too. Feel free to reach out if you need any help extending vRealize Automation’s capabilities so that you can use your brain power for more important tasks…like remembering your co-workers names.

See how CloudBolt can help you with your VMware instance.