Posted on 1 Comment

Quick Thoughts on Cloud Cost and Cloud FinOps Tagging

One of the tactical problems I get asked about most often is how to manage cloud Infrastructure as a Service within an IT cost management environment. As someone who recommends boh telecom expense management and cloud cost management solutions, I’ve seen that the paradigm typically used for telecom, servers, on-prem software, and other traditional IT assets and services doesn’t work as well for cloud both because of the transient nature of cloud services and that public cloud is often purchased solely by technical buyers, with professional sourcing and finance professionals being left out entirely.

This has led to a new practice that has been called Cloud Cost Management or, alternatively, FinOps (even though the abbreviation FinOps does not refer to the Operations of Finance or the CFO office, but that’s a debate for another time…)

In practice, this means that even the most basic general ledger or Active Directory taxonomy used for the vast majority of business costs is not used for the cloud because the people involved don’t know where to start. From a practical perspective, this means that cloud buyers often don’t get to take advantage of the business structure that most of the rest of IT purchasing has and end up having to recreate basic business categories from scratch.

As you start managing cloud services, you will most likely have to tag your resources within your management solution of choice because of the relative financial immaturity of cloud management solutions.

(There are exceptions: Apptio Cloudability, Calero-MDSL, CloudHealth by VMware, and Tangoe being the best examples)

The basic starting point for tagging is to look both at financial management and operational management.

For financial management, ask your controller or accounting team how they break down IT costs, then use the same categories for your tags. It’s usually some combo of employee ID, cost center, profit center, geography, project ID, General Ledger ID, but every company does its books a little differently.

Then the operational management is based on your IT org’s view of technology management, which could include applications, projects, technologies, staging environments and software supported, cloud service categories, functional IT tasks. This process is well-aligned to an IT Finance or Technology Business Management approach where technology is aligned to specific operational and functional tasks and responsibilities. But you may also need more granular tags that assign each resource to automated governance, security, data transfer or architecturally defined tasks. Each task or function should roll up to a functional manager, project manager, or stakeholder.

In thinking about the operational side of tagging, we recommend looking at Apptio Cloudability, CloudHealth by VMware, CloudCheckr, and Replex as starting points.

These tags end up being the taxonomy for your cloud environment and should ideally match up with existing IT taxonomies across IT asset management, project management, service management, and financial management. Otherwise, you risk reinventing the wheel and using up tags on categorization that only makes sense for yourself or your immediate team.

In addition, after creating these tags, you may also want to group these tags into larger dimensions that are associated with a specific use case, solution, or output with the goal of having shortcuts to manage what can be an intimidating number of services, resources, and tag combinations.

Over the next couple of months, Amalgam Insights will be providing more guidance in this space both with our SmartLists on Kubernetes Cost Management and Market Leaders in Technology Expense as well as releasing our videos on managing cloud costs from our recently completed Technology Expense Management Expo. If you have any suggestions for key issues we should include in these reports, please let us know at

And in case you missed it, here’s our recommendations for managing cloud cost from earlier this year.

Posted on

Why Tom Petrocelli Thinks Google Is Forming the Open Usage Commons (OUC)

by Tom Petrocelli

On July 9, 2020 there was an announcement that Google had formed an organization called the Open Usage Commons, or OUC. In a previous blog I laid out the case that this organization was a horrible idea from an intellectual property (IP) management and licensing perspective. In a nutshell, this new organization is holding the trademarks, and only the trademarks, from open source projects. Copyright would continue to be managed through the current open-source licenses and organizations.

As someone who spent several years as part of the intellectual property management industry (at a company literally called and as an advocate of open source for 30 years, this struck me as unusual, unnecessary, and suspicious. Ultimately, my experience told me that the OUC added unnecessary complexity and confusion to otherwise straightforward open-source projects. I finished the blog with a call to fork the projects. Pretty harsh words from an analyst who’s usually a pretty positive guy and a big fan of open source.

The follow-up question to the “why this is bad” blog has been “why then is Google doing this?”

I think the reason is much simpler than complex IP problems alluded to by the OUC website. Simply, Google wants to benefit from open-source development but not lose all control over the IP. It’s hard to maximize software revenue when the IP and brand are controlled elsewhere. There are a few organizations – Red Hat and Canonical are good examples – that can generate revenue from open source effectively. Google, on the other hand, has been a reliable and good actor in the open-source cloud-native community while consistently remaining in the third position for cloud services, behind Amazon Web Services and Microsoft Azure.

The fact is that piece of software that Google developed is making lots of money for many other companies while Google remains stuck in the number three slot in the cloud market. The software in question is, of course, Kubernetes.

If you rewind three years ago, Kubernetes was only one of many orchestrators. There was Apache Mesos, Rancher Cattle, Docker Swarm, Cloud Foundry Diego, and others in addition to Kubernetes. At the time, there were few large deployments of container architectures and the need for orchestration was just emerging. Fast forward to today, all of those competitors to Kubernetes are more or less gone and Kubernetes dominates the orchestrator market. Even more important, Kubernetes has become the base for the emerging next-generation IT platform. It will form the core for new architectures moving forward for years, perhaps decades, to come. Neither Google nor anyone else could have predicted that Kubernetes would be the powerhouse that it has become. In the meantime, many large rivals have entered the Kubernetes market including VMWare, Rancher (recently purchased by SUSE), Canonical, Microsoft Azure, Amazon Web Services, and HPE.

Kubernetes has become a massive, open governance, open-source, platform play that Google can’t monetize any more than anyone else. Red Hat was acquired by IBM with a $3B+ valuation, much of it because of OpenShift which is based on Kubernetes. Red Hat is now central to IBM cloud and platform strategy and their primary cloud growth engine. Rancher was acquired by SUSE (for a rumored $600M to $700M) because of its Kubernetes platform. Kubernetes is to Google, what the Docker Engine was to Docker – a key piece of heavily adopted IP that they make less money with than their rivals.

Meanwhile, Google is invested in other homegrown open source projects in the Kubernetes ecosystem, especially Istio and Knative. Istio, one of the projects whose trademarks are under the OUC aegis, is used to implement a service mesh control plane for Kubernetes. It has shown an almost Kubernetes-like uptake in the market and is included in a number of key Kubernetes distributions including Red Hat, Rancher/SUSE, HPE, and IBM. It has long been expected by the cloud-native community that the Istio project, including the trademarks, would become part of the Cloud Native Computing Foundation (CNCF) just like Linkerd and Envoy, two other service mesh projects. Google has instead launched the OUC to take ownership of the Istio trademark.

The head of Google Cloud Services, Thomas Kurian, came from Oracle and is steeped in Oracle’s software business practices. It is easy to imagine that, to him, Google is giving away valuable IP while rivals make all the money. The OUC is a way to retain control of the IP while not appearing to abandon the open-source movement. The board of the OUC consists of two Google employees, one ex-Googler, and, according to Google, a long-time collaborator alongside two others. That doesn’t suggest independence from Google. Even if the project is transferred to the CNCF in the future, Google can still call the shots on branding and messaging through the OUC.

The key problem for Google is that the software industry doesn’t work like it used to.

You can’t be half in and half out of open-source.

In the end, this is more likely to drive vendors to other projects such as Linkerd or Consul and reduce support for Istio. Istio may also go the route of OpenOffice, Java EE, and MySQL. In all three of those projects, where Oracle asserted control over some or most of the intellectual property, disputes broke out over licensing and technical direction leading to forks. The OUC is a clever Google take on the Oracle playbook. Incidentally, each of those forks, LibreOffice, Jakarta EE, and MariaDB have thrived, often overtaking the mother project.

The OUC increases fear, uncertainty, and doubt. The only way for Google to fix this and regain the spirit of open source is to refocus the OUC on IP education and transfer all Istio IP, along with the project, to CNCF. They should find similar homes for the other projects in the OUC portfolio. That is how they can regain the confidence of the open-source community.

Google’s failure to monetize their IP and maximize cloud revenues will not be alleviated by this move. Instead, they will lose their open source credibility and make partners suspicious. Simply put, this is not how open source works. This looks too much like a misguided attempt to control popular open-source software such as Istio and Angular. There are real IP management and licensing problems that the OUC can help to fix. They need to work on fixing those problems and not controlling trademarks.