Cloud-Native Infrastructure Schema v1.0 Best Practices Guide

Overview

This guide provides comprehensive best practices for implementing and managing the Cloud-Native Infrastructure Schema v1.0 in Jira Service Management Assets. This domain schema extends the Core Schema to provide platform engineering and cloud operations teams with complete visibility across multi-cloud environments, Kubernetes clusters, serverless workloads, and managed services.

Who should read this guide:

• Platform Engineers managing Kubernetes clusters and containerized workloads
• Cloud Architects designing multi-cloud infrastructure strategies
• FinOps Teams tracking cloud costs and optimizing resource utilization
• DevOps Engineers implementing GitOps workflows and CI/CD pipelines
• Security Teams monitoring cloud security posture and compliance
• SRE Teams maintaining service reliability and incident response
• IT Leadership requiring visibility into cloud infrastructure investments

What you will learn:

• How to effectively use each of the ten object types in the Cloud-Native schema
• The purpose and significance of every attribute across all object types
• Multi-cloud visibility patterns for AWS, Azure, and GCP resources
• Kubernetes resource hierarchy and relationship management
• FinOps integration for cost tracking and optimization
• GitOps alignment strategies for infrastructure-as-code
• Common implementation patterns and anti-patterns specific to cloud-native operations
• Troubleshooting guidance for frequent cloud data issues

Prerequisites:

• JSM Premium or Enterprise license (Assets requires Premium tier minimum)
• Object Schema Manager or Jira Admin permissions
• Core Schema v1.1 deployed with Person, Team, Application, Vendor, and Location object types populated
• Familiarity with basic JSM Assets concepts (object types, attributes, references)
• Understanding of cloud-native fundamentals (Kubernetes, containers, managed services)

Schema Architecture

How This Schema Extends Core

The Cloud-Native Infrastructure Schema follows the Schema-Forge principle of referencing Core Schema objects rather than duplicating master data. This design ensures that cloud resource ownership, team assignments, vendor relationships, and organizational data remain synchronized across your entire CMDB ecosystem.

Core Schema Objects Referenced:

Benefits of Extension Architecture:

• Update a person's role or team assignment once in Core, and it reflects across all cloud resources
• Query cross-schema: find all clusters owned by a specific team, or all resources in a specific cloud account
• Eliminate duplicate data entry for organizational information
• Enable consistent reporting across cloud and on-premises infrastructure

Reference Types in This Schema

The Cloud-Native schema defines three custom reference types that describe cloud infrastructure relationships. These reference types provide semantic meaning and visual organization through color-coding in the JSM Assets interface.

Schema Hierarchy Overview

Cloud Account (AWS/Azure/GCP)
│
+-- Kubernetes Cluster (EKS/AKS/GKE)
│   │
│   +-- Namespace
│   │   │
│   │   +-- Deployment (workloads)
│   │
│   +-- Service Mesh (Istio/Linkerd)
│
+-- Container Registry (ECR/ACR/GCR)
│
+-- Serverless Function (Lambda/Cloud Functions)
│
+-- Managed Database (RDS/Cloud SQL)
│
+-- Object Storage (S3/GCS/Blob)
│
+-- CDN Distribution (CloudFront/CloudFlare)

Object Types (Summary)

The Cloud-Native schema includes 10 object types designed for cloud infrastructure management:

1. Cloud Account - AWS accounts, Azure subscriptions, GCP projects (foundational)
2. Kubernetes Cluster - Managed and self-managed Kubernetes clusters
3. Namespace - Kubernetes namespaces for workload isolation
4. Deployment - Kubernetes deployments and workload controllers
5. Container Registry - Container image registries (ECR, ACR, GCR)
6. Serverless Function - Cloud functions (Lambda, Functions, Cloud Functions)
7. Managed Database - Cloud database services (RDS, Cloud SQL, Cosmos DB)
8. Object Storage - Cloud object storage (S3, GCS, Azure Blob)
9. CDN Distribution - Content delivery networks (CloudFront, CloudFlare)
10. Service Mesh - Service mesh implementations (Istio, Linkerd)

Integration Patterns

Multi-Cloud Inventory Synchronization

Maintaining accurate cloud inventory requires integration with cloud provider APIs:

• AWS: AWS Config, Resource Groups Tagging API, service-specific APIs
• Azure: Azure Resource Graph API for unified resource querying
• GCP: Cloud Asset Inventory for resource discovery

Kubernetes Resource Synchronization

Kubernetes resources can be synchronized via the Kubernetes API or GitOps repositories. Recommended approach:

• Use GitOps-based synchronization for declared resources (deployments, namespaces)
• Use API-based synchronization for runtime state (replica count, status)
• Reconcile both sources for complete visibility

FinOps Integration

Cloud cost data integration enables FinOps practices within the CMDB:

Common Implementation Patterns

Account Naming Convention

Recommended pattern: {env}-{team/project}-{purpose}
Examples:
prod-payments-api     Production payment API services
dev-platform-sandbox  Development sandbox for platform team
staging-mobile-app    Staging for mobile application

Cluster Naming Convention

Recommended pattern: {provider}-{env}-{purpose}-{region}
Examples:
eks-prod-payments-useast1     Production EKS for payments
gke-staging-platform-uswest1  Staging GKE for platform
aks-dev-mobile-westeurope     Development AKS for mobile

Useful AQL Queries

-- Find clusters with outdated versions
objectType = "Kubernetes Cluster" AND Version < "1.27" AND Status = "Active"

-- Find namespaces without team ownership
objectType = "Namespace" AND "Team Owner" IS EMPTY AND Status = "Active"

-- Find all resources in a specific account
objectType = "Kubernetes Cluster" AND "Cloud Account".Name = "prod-payments-us"

-- Find storage buckets with public access
objectType = "Object Storage" AND "Public Access" = "Allowed" AND Status = "Active"

-- Find production databases without Multi-AZ
objectType = "Managed Database" AND "Multi-AZ" = "No" AND "Cloud Account".Environment = "Production"

Troubleshooting Guide

Resource Discovery Issues

Symptom: Cloud resources not appearing in JSM Assets.

Diagnosis:

1. Check API permissions (Config:Get*, ResourceGroupsTagging:GetResources for AWS)
2. Verify region filtering includes all active regions
3. Verify resource type filters include required types
4. Check import schedule frequency

Reference Resolution Issues

Symptom: Cluster or Account references show "Unknown" or empty.

Diagnosis:

1. Verify parent objects imported before child resources
2. Check key field matching (Account ID format)
3. Ensure Core Schema objects (Person, Team) exist

Cost Data Issues

Symptom: Monthly Spend showing incorrect or stale values.

Diagnosis:

1. Cloud billing data has 24-48 hour delay
2. Verify account ID format matches billing system
3. Standardize on USD for Monthly Spend
4. Implement tagging strategy for cost allocation

FAQ

Q: How do I handle multi-cloud environments with the same application deployed in multiple clouds?

Answer: Create separate deployment records for each cloud instance, linking each to its respective Kubernetes Cluster and Cloud Account. Use the Application reference from Core Schema to link all deployments to the same business application. This enables per-cloud resource tracking and application-level aggregate reporting.

Q: Should I track ephemeral resources like pods or auto-scaled nodes?

Answer: Generally, no. Track deployments (the desired state) rather than pods (the actual state). Pods are ephemeral and can be replaced automatically. For auto-scaled resources, document the scaling configuration (min/max) rather than current count, or update periodically via automation.

Q: How do I track Kubernetes resources managed by Helm or GitOps?

Answer: Link deployments to their GitOps repository by documenting the GitOps Repo URL on the Kubernetes Cluster object. Add deployment-specific notes indicating the Helm chart or Kustomize path. Consider adding a "Source of Truth" field indicating "Helm", "Kustomize", "ArgoCD", or "Flux".

Q: How frequently should I synchronize cloud inventory with JSM Assets?

Answer: Frequency depends on change velocity:

Related Resources

This guide is part of the Cloud-Native Infrastructure Schema v1.0 documentation suite:

• Governance Playbook: Enterprise governance framework including roles, review cadences, FinOps integration, and cloud cost management
• JSM Forms Specification: Detailed form configurations for each object type, including cloud-specific validation
• Automation Examples: Automation rule patterns for cost alerts, orphan detection, and version tracking
• Core Schema v1.1 Best Practices Guide: Reference for Person, Team, Application, Vendor, and Location object types