Environment Naming and the Revenge of Asset Management
If naming things is the hardest problem in computer science, then we should all expect getting consensus on environment names will be difficult. I can’t tell you how many times I have heard, “Just pick something and be done with it!”; except that we were never really done with it. Environments have purposes and names should reflect those purposes. We would inevitably come back to asking the purpose/location/access requirements of the environment in question because the naming standard across the organization was not consistent. This article doesn’t attempt to solve the semantics of the problem (prd01 vs prod01), but will offer a few suggestions on how to consider the relevant parameters when defining an environment’s purpose.
Let’s first define environment as the collection of assets which software depends upon to deliver some business functionality to some set of customers; internal or external. Assets can be any object necessary to deliver that piece of business functionality including obvious ones such as virtual machines or less obvious ones such as public cloud accounts, email addresses, or domain names.
The first distinction we will make is on the maturity of the environment. Is it production or is it not production? There are two things that make production special: 1) The operation of that environment produces business value by customers interacting with it. 2) The data in that environment is integral to the production of that business value. The confidentiality, integrity, and availability of the data matters in varying degrees. In other words, we care about the security of production. In some organizations, staging environments will fall into the category of production. This is because they are part of a blue/green deployment scenario that regularly “trades-off” with the current production environments. Beta environments can fall into the category of production as well due to their generation of business value for a subset of beta customers and storing data of which the security matters.
For many organizations, not all production environments are created equal. Even after cleanly separating our environments into production and not-production, we have to consider several other axises of distinction. One that is growing in relevance is data residency. All of the major public cloud providers are increasing the number of regions they support. This is no coincidence. For a variety of reasons such as contractual, legal or regulatory, it is becoming less common to have a single production environment in a single geopolitical domain. Instead, applications are expected to operate with data segmentation in North America, Europe, and Asia. Furthermore, within the major continents it is not uncommon for segmentation expectations to be at the country level as well.
Related to data residency, but not synonymous, is data access. For the same reasons outlined above, (contractual, legal, regulatory), customers take interest in who can access their data, in addition to where it resides. Those requirements can be in the form of a limitation, such as only U.S. citizens can access the data in question. They can also be in the form of an addition, such as the organization providing the service plus agents of the state where it resides.
This is why identity governance is a major part of the modern Operations role. Thinking through segmentation is an incredibly difficult problem. It requires a deep understanding of the business requirements and a deep understanding of the technical operations of the products; especially system dependence throughout the entire stack. The skill set of the Operations Engineer has to increase to support understanding of the technical abstractions and the business nuisances. If we are doing our job well, representatives from Development, Product Management, Security, Legal and Sales will all be interested in our perspective.
Practically speaking we should have a mental model (and a documented one as well) of all the assets we support. Since environments are nothing but groupings of assets, we should be placing an overlay of common asset attributes per environment. For example, metadata about environment ‘abc01’ might be represented in the schema below:
{
"environment_name": "abc01",
"production": "TRUE",
"residency": "Germany",
"data_access_restrictions": "none",
"data_access_additions": "none"
}This is the practice of Asset Management for the modern, DevOps aspiring organization. Many assets are ephemeral and there are a growing number of them. Moreover, there are dependency dimensions that go well beyond technical to the compliance, legal and contractual. Of course one could argue those dependencies have always been the case. That is a fair point. However, the ephemeral nature of assets interacting with an exponentially increasing number of components necessary to deliver the modern SAAS software application, change Asset Management qualitatively from previous generations of software delivery. While this can be a serious challenge to Operations Engineering teams, it is also a new opportunity to deliver business value through coordination with other parts of the organization.
Note: I use Operations Engineer as the generic term from those individuals whose job it is to shepherd production; Site Reliability Engineers, Production Engineers, or good ole’ System Administrators all fall under this category.