Application teams can register, update and remove tenant metadata in a central multi-cloud tenant database in self service.

Organizations embarking on their cloud journey often start implementing a first cloud platform or provider, later followed by a second (see Approaches to building a Cloud Foundation). As the organization’s cloud strategy evolves towards embracing a multi-cloud approach, individual “platform silos” make it difficult to establish visibility and control over the organization’s multi-cloud adoption.

The lack of a central cloud tenant database makes it difficult to establish a consistent level of governance across multiple cloud providers and platform technologies. There is also a lot of redundant effort for data integration with each platform’s cloud tenant database, especially when considering capabilities like Link Cloud Tenants to CMDB/EAM or Multi-Cloud Tagging Policy.

Empowering Application Teams with Self-Service

Cloud foundation teams supporting multi-cloud strategies typically also start experiencing growing pains serving a growing number of application teams. As you onboard more and more teams, maintaining up to date metadata about each cloud tenant (see Cloud Tenant Database for more details) becomes a daunting task. For example, one key piece of information you want to store in a cloud tenant database is the security contact responsible for the tenant. This is the technical person that you will contact about any incidents or security issues detected for that cloud tenant. It’s critical that this contact information is always up to date so that your organization is capable of reacting quickly to security incidents (see Incident Management Process).

💡 Self-service enables the cloud foundation team to shift the responsibility for maintaining up to date tenant metadata to application teams.

Unfortunately, application teams can decide at any point to change the responsibilities within their team. Chances are, they won’t inform the cloud foundation team about this change. Even if they do, it’s a manual step for the cloud foundation team to update the information in the tenant database. All of this back-and-forth to maintain up to date metadata is not very efficient for application teams either.

Best Practices for Building a Self-Service Multi-Cloud Tenant Database

Here’s a set of best practices to consider to implement a multi-cloud tenant database that serves both the needs of the Cloud Foundation Team as well as application teams.

Standardize Tenant Management Processes across Platforms

If your organization has historically managed cloud platforms as separate silos, chances are high that platform teams have implemented processes like Tenant Provisioning, Tenant Deprovisioning / Decommissioning or Cloud Tenant Tagging individually. When building a multi-cloud tenant database, you will also have to consider how to align these processes across clouds so they can be integrated with a single multi-cloud tenant database. A natural next step in this process could be implementing the capability Multi-cloud tenant database integrated with lifecycle management.

Creating this alignment between different platform implementations and functional stakeholders (IAM, Compliance, Finance) can be challenging. Establishing a Cloud Foundation team empowered with a clear-cut mission is the best approach to overcome these challenges.

Start your Multi-Cloud Journey

Implementing a multi-cloud strategy has its pitfalls. Read these 6 tips to start your multi-cloud journey.

Start your Cloud Journey →

Design Authorization Concept around Responsibilities

Managers responsible for multiple IT systems should be able to edit the metadata for these IT systems only. This establishes clear responsibilities and ensures that data quality is maintained at a high level

Notify Stakeholders about Missing Metadata

When your metadata schema evolves, for example by including a new field, this data will be initially missing from the majority of your existing cloud tenants. Your tenant database should thus have a process to contact your application teams and ask them to fill out the additional metadata.

Provide an Administrative Interface

While self-service will free up a lot of time for the cloud foundation team, there will be exceptions to the regular process. Having an administrative interface to override tenant data is thus a useful capability for your cloud foundation team. It’s also useful in case your cloud foundation starts out with a manual cloud onboarding process and there’s certain metadata that your team needs to vet and authoritatively enter into the system before accepting a new customer. Your team can later consider automating some of these manual vetting processes with a Guided Cloud Onboarding process.

Maintain a Cloud Service Register to Meet Regulatory Requirements

Industry-specific regulation can require your organization to maintain a register of all cloud outsourcing activities. A multi-cloud tenant database can help meet these requirements. One example of this is the “Cloud Service Register” in the financial industry as recommended by the European Banking Authority’s Recommendations on Cloud Outsourcing.

Related Tools

• collie-cli

  Open-source Collie CLI can give you a list of all active tenants in your organization across AWS, Azure & GCP in minutes. This includes metadata and costs per month.

  Learn More
• meshStack

  meshStack allows internal customers to create and manage cloud tenants in self-service. This includes automated tenant creation as well as self-service metadata management for project owners as well as tenant administration for cloud foundation teams.

  Learn More

Did this page help you?