Building a Global Hosting Naming Standard

More than two dozen companies, like Marketo, Magento, and Fotolia, have joined the Adobe family in the last 10 years. They have brought great people and great products, plus a lot of hosted infrastructure in a lot of locations. As many of these acquired products and services become more tightly coupled, the complexity of the internal systems increases. Adobe has migrated more than 35 hosting locations in our portfolio, but we’re still left with more than 70. These are spread across Azure, AWS, Equinix, our own data center, and more. These new teams, combined with the existing, have confusingly different naming strategies, slowing collaboration and increasing risks of misunderstanding. Adobe needed a unified, global hosting naming standard. This is how we did it.

What we wanted

Based on the frustrations we had with current names, we wanted something simple and intuitive. The requirements became:

  • Brevity
  • Somewhat human-readable
  • Programmatic — anyone should be able to determine the next logical name
  • Unique names
  • Unified across Adobe

What we considered

We explored a variety of options based on what we saw our providers use, past employment experience, and brainstorming. We explored:

  • Airport codes
  • 2-letter country codes
  • Cardinal direction + the supplier name
  • Some amalgamation of the above + the supplier name

What we chose: The “2–3”

All hosting locations shall be named with two or three letters, based on location, followed by and auto-incrementing number.

Given Adobe’s global presence, the teams discussed why the US should have a different naming system than the rest of the world. Here’s the rationale:

  • More than a third of Adobe’s hosting locations are in the US. If we went with two-letter country code, we could end up with “US21” and “US22” thousands of miles apart, and no straightforward way to know which was where.
  • The US is large in several ways — as a percentage of our revenue, customers, and geographically. Knowing “CA” and “VA” have more latency than “GBR” and “NLD” is useful information when making service placement decisions.

Adobe has a rich, internal configuration management database that stores metadata for just about everything, including locations. It was agreed that instead of trying to capture too many details in the name (like provider), they would be made available via the configuration management system’s API (rather than trying to parse names).

Abbreviated sample table of proposed, vendor, and selected standard location names

Potential shortcomings

  • Countries can change names
  • Lack of fixed length (this was desired by some teams)
  • Misalignment with providers’ names


Like any change, this takes time and energy:

  1. Communication: Email, chat, wikis, and team meetings have all been used to raise awareness of the new names.
  2. Tooling updates: A few tools had to have new fields added to ensure continued smooth operation like “alias” or “legacy name”. Once complete, the new names were implemented. We still have areas that have not transitioned, and will continue to align.
  3. DNS: Changes have been much slower due to the embedded nature of URLs. All new locations are deployed with the new names, aliases are used where possible, but this will take many years to complete and will be done so opportunistically.
  4. Continued diligence: As the legacy names appear in documentation or conversations, we remind people about the new names and ask they take time to address it.


I dream of a bygone Internet era when companies like HP drove massive data center consolidation projects (from 85 locations to 6), but with today’s privacy, trust, sovereignty, and latency requirements, that simplicity is much harder to find. Supporting a global, multi-cloud solution is our reality, hopefully made a little more manageable with a hosting naming standard.

In parting, may I leave you with an old Irish blessing:
“May your business be blessed with growth, but not so much you need a hosting naming strategy.”