But as these digital systems are for producing value, organisations need to rationalise them into profit and loss (P&L) structures. The challenge now is how to rationalise portfolios without slowing things down.
To provide a unified view of digital and IT portfolios for governance and rationalisation, IT professionals must update their application portfolio management practices with modern cloud-native labelling and tagging approaches.
Application tagging
It’s hard to gain agreement on what an application actually is. One of the most important tag concepts is the basic idea of “application”. But what does this word mean? It’s always been an imprecise term.
Is it merely the software? Or something greater? What about other imprecise concepts, such as “service”, “platform”, “product” and “capability”? IT too often gets wrapped up in such definitional questions and, unfortunately, industry guidance has been contradictory and divorced from reality.
This confusion carries into the cloud-native world. To quote official documentation for Kubernetes, that platform “doesn’t have or enforce a formal notion of an application. Instead, applications are informal and described with metadata. The definition of what an application contains is loose.”
Cloud implementations are increasingly complex. Cloud hyperscalers offer hundreds of billable services that go far beyond virtual machines (VMs). To assist in accounting for such charges, cloud providers have built-in transparency mechanisms; in particular, tagging. However, organisations must carry out tagging in a consistent and governed manner – too many don’t enforce it as policy.
Approach to tagging
A well-maintained portfolio is a critical resource for governance, planning and operational response. Tracing back from current cloud tagging practices, the idea of the application ID goes back decades into mainframe history, with two-character IDs embedded in the names of batch jobs, job control language, screens and reports. Similar codes have also served as a basis for server naming; systems may consume the portfolio data.
In particular, if possible, you should maintain a unitary system of record. Challenge any notion that DevOps and cloud-native are different. They’re not. Mainframe, distributed, bare metal, virtual, on-premise/off-premise, waterfall, agile – whether you’re talking about technology, location or method, you have a lot of technical “stuff” that you’re trying to align to a smaller number of more business-meaningful “things” (for example, investments). This smaller number of things should be mutually exclusive, comprehensive and tightly managed.
Read more about IT portfolio management
Without a thorough asset management plan that accounts for the complexities of today’s IT environments, organisations risk cost inefficiencies and suboptimal support for the business.
Knowing what is deployed is the first step in any transformation exercise, and a strong IT asset management practice lowers risk.
Cloud doesn’t mean you need an additional system of record. One unfortunate – and unnecessary – stage that some organisations suffer through is the creation of multiple portfolios. In the worst case, this leads to outright competition over whose dataset is correct – is it that of the configuration management database (CMDB) team, the enterprise architecture (EA) team, or the cloud management team?
Sree Subramaniam, ServiceNow director of product management, IT operations management, notes: “In the decentralised DevOps world, teams are creating their own nomenclature, and this is a big problem.”
With infrastructure-as-code (IaC), you can enforce tagging via policy, as part of a policy check automated via a continuous delivery automation platform. However, there are lots of things to tag. You need a careful strategy; again, seek the guidance of a data architect familiar with reference and master data. CloudZero sees current practice as covering between 20% and 60% of infrastructure, with tag definition and compliance largely up to individual engineers.
Forrester recommends customers of public cloud services explore the policy enforcement capabilities of Amazon Web Services (AWS) Config and Microsoft Azure Policy to ensure that resources are, and remain, properly tagged. Consider a formal tagging policy for your organisation.
Dave McCann, vice-president for AWS migration, marketplaces and control services, states: “We encourage customers to tag individual resources and also collections of resources – compute, network, storage, database and third-party software – that can be easily tagged as an application to a project, a budget and a team.”
Include on-premise resources
Forrester warns that VM-level tagging is insufficient, as multiple services may run on one machine. Even newer, cloud-native companies will provision a large virtual machine and add various workloads to it. And bare-metal machines can be associated with their applications.
“In distributed systems,” says Datadog director of product strategy Michael Yamnitsky, “software is abstracted from infrastructure, so IT service management [ITSM] professionals must collaborate with developers to implement a tagging model that identifies relationships between services and underlying infrastructure bits.”
You can set a standard for doing this and make things easy on your discovery tools, for example, by putting things into a specific configuration file at a given location.
ServiceNow’s Subramaniam observes that “during virtual machine creation, every customer adds tags, often based on the CSDM [common service data model] entity application service”.
ServiceNow discovery tools can then populate such tags into common configuration management database (CMDB) key/value pair tables to create valuable artifacts such as dependency maps, and ServiceNow’s cloud provisioning governance solution can enforce tagging standards at the time of provisioning the cloud resources.
BMC principal product manager Antonio Varga says it uses tagging to support a variety of operational processes and governance outcomes: “From a security perspective, we see a lot of tags being used, or for cost control; for example, to spin virtual machines down if no one is assigned to them.”
Kubernetes labels
Forrester also recommends that organisations take advantage of Kubernetes label-based management.
“With containers and their orchestration completely managed by Kubernetes, labels are now the only way we have to interact with pods and containers. Defining your labels with a logical and easy-to-understand schema is essential so your metrics will be as useful as possible”
Kubernetes documentation
Kubernetes documentation states: “With containers and their orchestration completely managed by Kubernetes, labels are now the only way we have to interact with pods and containers. That’s why they’re absolutely crucial for monitoring, as all metrics and events will be sliced and diced using labels across the different layers of your infrastructure. Defining your labels with a logical and easy-to-understand schema is essential so your metrics will be as useful as possible.”
Furthermore, Kubernetes recommends creating labels for applications.
“Kubernetes supports tags, and we discover those, whether against pods or deployments,” says BMC’s Vargas. “Use your Kubernetes tags; they’re available. Where there’s room for improvement is in solving the master data problem.”
Automating tagging
Organisations have misplaced faith in automation. Many discovery tool suppliers sell fiercely against manual processes. Cloud-native and DevOps advocates similarly dislike processes that necessarily involve humans. Forrester agrees that, in general, if you can effectively automate something, you should. CloudZero, for example, offers the ability to analyse and group previously untagged cloud resources.
But applications and service, as we’re defining them here, are logical concepts requiring a registration process. Discovery tools can play a role, especially at the more technical layer (for example, application programming interfaces and microservices).
However, Chip Kalfaian, global consulting lead, application portfolio optimisation, at Dell Technologies, emphasises that identifying the “applications” is a manual, forensic process. Dell uses a survey tool and interviews to help establish the portfolio.
Benefits of tag visibility
Improving visibility adds value in many ways. Tag visibility enables automated service map creation using application tag data.
ServiceNow notes that you can use service maps created from tags for various outcomes. Maps from tags help site reliability engineering teams in retrospective analysis and event noise reduction.
Technology refresh, software compliance, security and operational incident response, and change management may all benefit from improving your data completeness and accuracy and using tags pervasively throughout your digital infrastructure.
