Multi-Cloud Asset
Management Platform
A platform for discovering, enriching and synchronizing cloud infrastructure data across multiple providers.
The goal was to bring cloud infrastructure information from different environments and internal systems into one consistent view, making it easier to understand what existed, who owned it and how it related to the wider organization.
Data sources
- 01Discovery and enrichment
Collect infrastructure data and add the ownership and business context that makes it useful.
- 02Transformation
Validate, clean and map the data to fit the existing enterprise data model.
- 03Synchronization
Validate the proposed changes through dry runs, then synchronize the data.
The challenge
As cloud infrastructure grew, maintaining an accurate and useful inventory of resources became increasingly important.
The enterprise ServiceNow Configuration Management Database (CMDB) had no automated process for maintaining cloud resource information. Data was spread across cloud environments and internal systems, making it difficult to establish a consistent view of infrastructure, ownership and configuration.
There was another gap too: project ownership and business classification were not always complete. Knowing which team owned a project, which business family it belonged to and what services it supported was just as important as discovering the resources themselves.
The challenge was to bring these pieces together and establish a reliable way to discover, enrich and synchronize cloud infrastructure information.
The approach
I took ownership of the initial solution, from technical evaluation and proof of concept through architecture, development and deployment.
The platform was designed around three stages.
- 01. Discovery and enrichment
Infrastructure information was collected from cloud APIs, asset inventory exports and internal data sources. Resource details were combined with ownership, team and business information to create a more complete picture of each asset.
- 02. Transformation
The collected data was validated, cleaned and enriched. This stage also handled mapping cloud resources to the existing ServiceNow CMDB classes and relationships. Working within an established CMDB structure presented its own challenges. Cloud resources did not always have a direct equivalent in the existing data model, so the mappings had to account for both the available fields and the relationships expected by the CMDB.
- 03. Synchronization
The transformed data was synchronized with the appropriate CMDB classes. Dry-run execution allowed proposed changes to be validated before they were applied.
Architecture
The first implementation focused on GCP. As the platform evolved, the same underlying processing approach was extended to Azure, OCI and AWS.
A few architectural decisions helped keep the platform manageable as its scope grew.
- Independent cloud integrations
Each provider had its own collection package, keeping cloud-specific discovery logic separate and preventing implementations from interfering with one another.
- A shared processing approach
Discovery, transformation and synchronization followed the same overall pattern across providers, even though the way data was collected differed between cloud environments.
- Service-level execution
Each cloud service had dedicated Kubernetes CronJobs for collection, synchronization and dry-run operations. This allowed individual services to be managed and executed independently.
- Dependency-aware scheduling
Jobs followed a deliberate sequence, starting with reference data synchronization and cloud hierarchy before moving on to compute, networking and other resource categories. Different schedules helped avoid overwhelming cloud APIs and databases.
- Flexible data modelling
Resource types were mapped to the appropriate existing CMDB classes and relationships, working within the constraints of an established enterprise data model.
Deployment and operations
The application ran on Google Kubernetes Engine (GKE), with cloud-specific workloads separated into their own namespaces. Deployment configurations were maintained in a Helm directory and initially released using Helm 3.
As organizational deployment standards evolved, I helped transition the release workflow to Argo CD. We introduced a one-click deployment approach that synchronized Helm configurations from designated Git branches with Argo CD-managed releases.
Operational reliability was just as important as the initial implementation.
- Automatic retries
Failed jobs had an automatic retry to account for intermittent issues.
- Slack notifications
Alerts included error details and the location of the failed job, making investigation easier.
- Execution history
Detailed execution records helped with troubleshooting and tracking previous runs.
- Targeted recovery
Individual failed operations could be rerun without restarting the entire pipeline.
- Controlled scheduling
Services ran on different schedules to manage API usage, database load and processing dependencies.
Strengthening cloud governance
Building automated asset discovery also highlighted a broader governance problem: the organization did not always have complete or accurate information about project ownership and business classification.
As part of the cloud governance team, we helped address this by making ownership, business family and service information mandatory for newly created projects.
For existing projects, we worked with engineering teams, stakeholders and leadership to identify the appropriate owners and populate missing records.
This improved the quality of the information associated with cloud infrastructure and made it easier to track ownership and business alignment. It also benefited downstream systems, including the internal budgeting platform, which relied on accurate project information for cost attribution and reporting.
This was a complementary governance initiative rather than simply another feature of the asset management platform, but both efforts contributed to a more reliable view of the cloud environment.
My contribution
I owned the initial solution architecture, technical evaluation, proof of concept and end-to-end GCP implementation. I also took responsibility for deployment workflows, job management and the operational aspects of the platform.
As the platform expanded, I led and mentored two engineers, helping them understand the architecture, contribute to the implementation and extend resource coverage. The solution grew beyond its original GCP scope to support Azure, OCI and AWS.
The work involved much more than building an integration. It meant turning an ambiguous business requirement into a working platform, navigating the constraints of an existing enterprise data model, coordinating with the asset management team and making sure the architecture could grow without becoming difficult to maintain.
The outcome
The platform established an automated process for discovering, enriching and synchronizing cloud infrastructure information into the enterprise CMDB, across GCP, Azure, OCI and AWS.
What began as a solution for a single cloud environment evolved into a multi-cloud platform with independent collection workflows, shared processing stages and operational recovery capabilities.
Alongside the technical work, improvements to project ownership and business classification helped strengthen the quality of information used across cloud governance and budgeting processes.
One of the most rewarding parts was seeing an idea move from an initial proof of concept into a working platform that other engineers could build on, extend and operate.