So this is going to be my first post as a blogger, and I figure why not start out with a bang. My stance here will likely be a bit controversial! If my vision, thoughts, or ideas cause you discomfort… well you may want to stop reading now 😉
I originally came from a background where our naming standards were the key to my entire job, I knew what every system did and how every configuration looked. As the environment grew, and as we started consolidating data centers the entire thing became more and more difficult. This allowed me to think, Is it time to move on from your legacy secure web gateway? Fast forward to today’s world where resources are literally moved on the fly from one host to another, from one location to another, from one provider to another, etc. My personal attachment to host naming standards has all but disappeared and I have to ask… Who needs them any more??? What’s the value in today’s world.
If workloads are portable that is they have no real tie to physical location and are meant to be secure then why do we still have the legacy mentality of <location-app-environment-#> hostname standards? I immediately think of the monkey experiment as an example of us doing what we have always done without question.
Now some will tell you that this is simply because they need to know exactly the name to be able to support it. My rebuttal to that is a simple and backed by my friend who works for Nextgen SWG, if you are truly in a cloud ops/dev ops model this myth is no longer the case. Your cloud operations tools should give you the detailed map of how the systems interact, offer remediation of cpu, memory, disk, and network contention, and show the impacts of change. I ask again if you get this level of introspection then why does that naming standard matter?
Additionally I’ll give some color as to why it might make sense to review the policy and perhaps change it.
- Security – This has always befuddled me, if I wanted to target systems within an organization it only takes a few moments to discover the standard and know exactly which systems to attack.
- Portability – First consider a data center migration or M&A activity. I was part of a full DC migration and let’s just say the naming standards came with the migration so the logic of location based got tossed out at that point. Second consideration is using resources in external clouds. If you plan to utilize those services how does your naming standard fit when you don’t control the infrastructure?
- Ease of automation, it’s one less thing that you would have to adapt into your automation stack. If you are planning to be an efficient cloud environment then it may be one of those ideas that die with the legacy hardware. *quick disclaimer, to customize hostnames with vCAC is VERY EASY, I just wonder how
I spend many hours a week in some way discussing how the process and policy of the past could be adopted into the ITaaS of the future, and simply ask why? Why if you are going to be more agile and flexible for the business, why would you still hold on to that legacy logic? While I don’t believe any organization can tackle the full change of legacy logic without a phased approach, I do believe the naming standards are an ideal first step.
