In the past seven years, digital transformation and the pressure to create compelling customer experiences have meant prioritizing everything.
However, because these digital systems are used to create value, organizations need to rationalize them into a profit and loss (P&L) structure. The challenge now is how to rationalize the investment portfolio without slowing down.
In order to provide a unified view of the digital and IT product portfolio for governance and rationalization, IT professionals must update their application portfolio management practices using modern cloud-native labeling and marking methods.
Application mark
It is difficult to reach consensus on actual applications. One of the most important label concepts is the basic concept of “application”. But what does this word mean? This has always been an imprecise term.
Is it just software? Or something bigger? What about other inaccurate concepts such as “service”, “platform”, “product” and “function”? IT is often plagued by these defining problems. Unfortunately, industry guidance has always been contradictory and runs counter to reality.
This chaos will bring into the cloud-native world. In order to quote the official Kubernetes documentation, the platform “has no or no formal concept of an application. Instead, applications are informal and described using metadata. The definition of what the application contains is loose.
Cloud implementation is becoming more and more complex. Cloud hyperscale service providers provide hundreds of billing services that go far beyond virtual machines (VM). To help resolve such costs, cloud providers provide built-in transparency mechanisms; especially tags. However, organizations must label them in a consistent and managed manner-too many labels do not implement it as a policy.
Marking method
A well-maintained product portfolio is a key resource for governance, planning, and operational response. Tracing back to current cloud tagging practices, the idea of application ID can be traced back to decades of mainframe history, with two-character IDs embedded in the names of batch jobs, job control languages, screens and reports. Similar code is also used as the basis for server naming. The system may use portfolio data.
In particular, if possible, you should maintain a uniform system of record. Challenge any concept that DevOps and cloud native are different. they are not. Mainframe, distributed, bare metal, virtual, internal/internal, waterfall, agile-whether you are talking about technology, location, or method, you are trying to adjust many technical “materials” and a small part of the “things with more business meaning” “(For example, investment). Things with a small number should be mutually exclusive, comprehensive and strictly managed.
Cloud does not mean you need an additional system of record. An unfortunate and unnecessary stage that some organizations suffer is the creation of multiple investment portfolios. In the worst case, this will lead to competition for the right data set—is it the configuration management database (CMDB) team, the enterprise architecture (EA) team, or the cloud management team?
ServiceNow Product Management, IT Operations Management Director Sree Subramaniam pointed out: “In the decentralized DevOps world, teams are creating their own terminology, which is a big problem.”
Using code-based infrastructure (IaC), you can implement tagging through policies, which are part of policy checks that are automated through continuous delivery automation platforms. However, there are many things to mark. You need a prudent strategy; again, seek guidance from a data architect familiar with references and master data. CloudZero believes that current practices cover 20% to 60% of the infrastructure, and label definition and compliance largely depend on individual engineers.
Forrester recommends that customers of public cloud services explore the policy enforcement functions of Amazon Web Services (AWS) Config and Microsoft Azure Policy to ensure correct and correct labeling of resources. Consider establishing a formal labeling policy for your organization.
Dave McCann, Vice President of AWS Migration, Marketing and Control Services, said: “We encourage customers to mark individual resources and collections of resources-computing, networking, storage, databases and third-party software-which can be easily marked as applications for projects, budgets, and teams. .”
Include local resources
Forrester warns that VM-level marking is not enough, because multiple services may be running on a computer. Even new cloud-native companies will provide large virtual machines and add various workloads to them. Bare metal can be associated with its application.
Michael Yamnitsky, director of product strategy at Datadog, said: “In a distributed system, software is abstracted from the infrastructure, so IT service management [ITSM] Professionals must work with developers to implement markup models to identify the relationship between services and infrastructure bits. “
You can set the criteria for doing this and make things easy on the discovery tool, for example, putting things in a specific configuration file in a given location.
ServiceNow’s Subramaniam observed, “During the creation of a virtual machine, each customer usually adds tags based on CSDM. [common service data model] Entity Application Service”.
Then, ServiceNow discovery tools can populate these tags into the public configuration management database (CMDB) key/value pair table to create valuable artifacts (such as dependency graphs), and ServiceNow’s cloud supply management solution can be used in the supply cloud Enforce marking standards when resources.
Antonio Varga, chief product manager of BMC, said that it uses tags to support various operational processes and governance results: “From a security perspective, we see that many tags are being used or used for cost control; for example, if no one allocates virtual machines, Turn it down.”
Kubernetes tags
Forrester also recommends that organizations use Kubernetes for label-based management.
“Because containers and their orchestration are completely managed by Kubernetes, labels are the only way we have to interact with containers and containers now. It is important to define labels with a logical and easy-to-understand architecture, so your metrics will be as useful as possible.”
Kubernetes documentation
The Kubernetes documentation states: “Because containers and their orchestration are completely managed by Kubernetes, labels are the only way we must interact with containers and containers now. This is why they are absolutely essential for monitoring, because all metrics and events are Labels in different layers of the infrastructure will be used for slicing and dicing. Using logical and easy-to-understand architecture to define labels is essential, so your metrics will be as useful as possible.”
In addition, Kubernetes recommends creating labels for applications.
Vargas of BMC said: “Kubernetes supports tags, whether it is for Pod or deployment, we will find them.” “Use your Kubernetes tags; they are available. What needs to be solved is to solve the master data problem.”
Automatic marking
Organizations’ beliefs about automation are misplaced. Many discovery tool vendors strongly object to manual processes for selling. Cloud Native and DevOps advocate similarly dislike processes that necessarily involve humans. Forrester agrees that, generally speaking, if you can automate something effectively, you should. For example, CloudZero provides the ability to analyze and group previously unmarked cloud resources.
However, as we defined here, applications and services are logical concepts that require a registration process. Discovery tools can play a role, especially at higher technical levels (for example, application programming interfaces and microservices).
However, Chip Kalfaian, head of global consulting for application portfolio optimization at Dell Technologies, emphasized that identifying “applications” is a manual forensic process. Dell uses survey tools and interviews to help build a product portfolio.
The benefits of label visibility
Increasing visibility can add value in many ways. Label visibility can automatically create service maps using application label data.
ServiceNow note that you can use the service mapping created from the tag for various results. The map from the label can help the site reliability engineering team perform retrospective analysis and reduce incident noise.
Technology updates, software compliance, security and operational incident response, and change management can all benefit from improved data integrity and accuracy, as well as the widespread use of tags throughout the digital infrastructure.
This article is based on Forrester’s Unify application portfolio management and cloud tag excerpts-hybrid systems require joint management reports by Charles Betz and George Lawrie.
