How To Design An Effective Naming Convention A short guideline to name server in data center

While recording my VMware vSphere 5 Training course this past summer, I made mention that I developed a process for building an effective naming convention for enterprises. Server and desktop virtualization significantly increases the number of named objects within our enterprises, so an effective naming convention that describes what an object is, its location, function and purpose is critical. Doing so allows us to identify objects in a speedy way, but it also provides a structured way of searching for objects using keywords in a logical manner.
Even as I developed these guidelines, I did not think it would interest folks very much. But I started receiving near daily tweets and e-mails requesting a copy of the document. So, I’ve decided to publish it and share it with everyone in today’s blog.
Here are my basic guidelines for the object naming convention:

  • A name should identify the device’s location and its purpose/function/service.
  • A name should be simple yet still be meaningful to system administrators, system support, and operations.
  • The standard needs to be consistent. Once set, the name should not change.
  • Avoid special characters; only use alphanumeric characters.
  • Avoid using numeric digits, except for the ending sequence number.
  • Avoid the use of specific product or vendor names, as those can be subject to change. (There are some generally accepted exceptions: Oracle, SMS, SQL, CTX, VMW)

Here are some basic recommendations:

  • The name should begin with a rigid header portion that identifies the location and optionally a type identifier. These should be followed by a delimiter to signify the end of the header portion. This delimiter shall be a ” – ” (dash) unless the system does not recognize a “-“. In this case, substitute the dash for another suitable agreed-upon character (i.e. $ or #).
  • Allow for a variable section that completes the identification (function, service, purpose, application).
  • End the name with a unique ID, a sequence number, which can be multi-purpose.
  • Allow for flexibility. Since technology is constantly evolving, this standard must also be able to evolve. When necessary, this standard can be modified to account for technological, infrastructure, and or business changes.
  • There must be enforcement, along with accurate and current documentation for all devices.Here is an example of the proposed naming convention standard

Structure:

Naming Convention
Naming Convention

Header portion

  • GG — Geographical location
  • L — Location should be generic and not vendor- or building-specific to facilitate moves, building name changes due to mergers, acquisitions or dissolution of business, etc.
  • T — Type – — Dash is a required delimiter to signify the end of the header portion

Variable portion:

  • AAA — Function /Service/Purpose
  • BBB — Application(Unique ID)
  • ## — 2 digit sequence #

Values Defined:

Geographic:

  • CH — Chicago
  • NY — New York
  • LN — London
  • SY — Sydney
  • MA — Madrid
  • SI — Singapore
  • MU — Mumbai

Location:

  • D — Main Data Center
  • C — COLO Data Center
  • T — Test Area (should be used for test machines that are to permanently stay in the test area)

Type (optional):

  • V — Virtual
  • C — Cluster server
  • P — Physical
  • O — Outsourced or vendor supported system

Delimiter (required):

  • – A “-” (dash) will be used unless the system does not recognize a “-” at which point an agreed upon character can be substituted. This could be a $ or # or other character.

Variable portion – AAA Identify the primary purpose of the device:

  • DC — Domain Controller
  • FS — File Server
  • PS — Print Server
  • ORA — Oracle database
  • SQL — SQL database
  • DB — other database(s)
  • EXH — Microsoft Exchange
  • CTX — Citrix Server
  • ESX — VMware ESX Server

Variable portion BBB Identify the Application on this server.

If the server is for a specific application, then an application identifier should be the second part of this portion of the name, preceded by the service:

  • JDE — JDEdwards
  • DYN — Dyna
  • EPC — Epic

This area of the name offers a lot of flexibility to handle identifiers for specific purposes, functions, and/or applications. There are many challenges to select identifiers that are meaningful and consistent and are not subject to frequent change. Here are some examples based on th guidelines I propose above:

  • CHD-DC01 — Chicago Office, Data Center, Domain Controller, sequence # 1
  • CHD-FS01 — Chicago Office, Data Center, File Server, sequence # 1
  • CHD-EXH01 — Chicago Office, Data Center, Microsoft Exchange, sequence # 1
  • CHD-ESX01 — Chicago Office, Data Center, VMware ESX Server, sequence # 1
  • CHC-CTXJDE01 — Chicago Office, Data Center, Citrix Server,JDEdwards Application, sequence # 1
  • CHC-WEB01 — Chicago Office, Data Center, Web Server, sequence # 1

Unique ID / sequence number

## This is a 2 digit sequence number

I would love to hear your comments on this naming convention and if you have ideas to improve it.

Related Article: Link

AWS named as a leader in the Infrastructure as a Service (IaaS) Magic Quadrant report for the 7th consecutive year The 2017 Magic Quadrant for Cloud Infrastructure as a Service, Worldwide. Difference with 2016

At AWS, we invest in customer success through an accelerating pace of innovation with a focus on operating efficiently at massive scale, and growing a partner ecosystem already tens of thousands strong. We have worked closely with industry leaders from Salesforce to McDonald’s, Comcast to Capital One, to help them transform their businesses by migrating and rethinking existing applications, as well as pursuing new solutions in areas like artificial intelligence, IoT, and big data.

In the image the last year quadrant (2016) vs the 2017 quadrand.

IAAS GARTNER 2016 vs 2017
IAAS GARTNER 2016 vs 2017

I 6 freni che bloccano il Cloud

Fonte: http://www.businessmagazine.it/articoli/3689/i-6-freni-che-bloccano-il-cloud_index.html

Una delle parole del momento è certamente “Cloud”: tutti ne parlano, ma l’adozione di questo tipo di approccio prosegue più lentamente di quanto inizialmente sperato. Non solo in Italia, dai nostri incontri e dalle interviste effettuati durante l’evento HP Discover 2013 abbiamo scoperto che anche in altri paesi europei le cose vanno a rilento e che anche negli Stati Uniti la situazione non è così avanzata come si potrebbe pensare di primo acchito.

Ne abbiamo parlato ad esempio com Margaret Dawson, Vice President Product Marketing & Cloud Evangelist di HP Cloud Services, la quale identifica in 6 istanze ben precise i freni che attualmente bloccano la diffusione delle tecnologie cloud: Costi, Complessità, Integrazione, Sicurezza, Conformità. Ecco come possono essere sintetizzate le parolre di Margaret:

Costi – Agli albori delle tecnologie cloud in molti sono rimasti abbagliati dal miraggio del cloud low cost: eliminare server, tecnici, manutenzioni e avere applicazioni, servizi, database in modalità SaaS a costo praticamente pari a zero. La riduzione dei costi è certamente una delle leve per il passaggio al cloud, ma non ci si pò aspettare di azzerare i costi: tutto quello che non si ha più ‘in casa’ e che è gestito dal proprio partner ha certamente un costo, magari più ridotto grazie all’economia di scala, ma che non può diventare troppo ridotto. Il prezzo non deve essere l’unico metro di giudizio in base al quale scegliere il cloud.

Complessità – Passare al cloud può semplificare le cose, magari sollevando dall’incombenza della gestione dell’hardware necessario a supportare i servizi necessari a un’azienda, ma le prime fasi di passaggio dalla gestione tradizionale a quella cloud possono avere un grado di complessità elevato. Alcune aziende sono rimaste ‘scottate’ per non aver trovato il giusto grado di competenza nella gestione della complessità: in alcuni casi il lavoro da fare è quello di recuperare la fiducia dei clienti nel cloud.

Integrazione – Un discorso che va di pari passo con quanto sopra: per ottenere il meglio dal cloud è necessario che sia costruito tenendo ben presente tutti i servizi con cui l’infrastruttura deve andare ad integrarsi: sottovalutare il discorso dell’integrazione con i servizi e l’infrastruttura già esistente può portare da un lato a un netto rallentamento nella fase di setup del cloud, dall’altro a un netto sotto sfruttamento delle potenzialità delle tecnologie. I programmi di gestione della forza lavoro, gli eventuali database Oracle e SAP, tutto deve rientrare in una strategia globale affinché di possa beneficiare al meglio dei vantaggi del cloud.

Sicurezza – Dalle ricerche di mercato effettuate da HP e dai propri partner emerge come una fetta molto consistente degli IT manager (75%) sia convinta che il cloud sia imprescindibile per il futuro ma più della metà di essi è preoccupata da istanze come la sicurezza. Sicurezza che riguarda i propri dati, ma anche quella dei propri clienti.

Conformità – Le nuove tecnologie spesso presentano nuove istanze al legislatore e in una fase iniziale di sviluppo si trovano a dover rientrare nelle maglie di un sistema legislativo e di regolamentazione non specifico o aggiornato. Da questa discrespanza possono emergere istanze che frenano la diffusione dei nuovi servizi. Un esempio è la conformità alle policy di trattamento dei dati personali come quelli generati dai pagamenti con le carte di credito: per affidare a terzi questo tipo di dati sensibili è necessario che il servizio garantisca la massima conformità alle regole vigenti nel paese.

Mancanza di Standard – Anche la mancanza di standard rallenta la diffusione del cloud nelle tessuto produttivo, sia a livello italiano sia a livello mondiale: inutili complicanze nel passaggio da un sistema all’altro, necessità di riprogettare da zero la struttura se si decide di cambiare vendor con impossibilità per i diversi player di fare interessanti proposte concorrenziali di passaggio ai propri servizi a causa di quello che comporta in termini di costi.