🛠 Service Ecosystem
As an organization’s cloud adoption accelerates, internal cloud customers will start requesting additional services from Cloud Foundation teams like managed on-premise connectivity or managed DevOps toolchains. Providing a rich ecosystem of services can helps teams build on the cloud more successfully and can also be an important enabler of cloud adoption speed.
In the same way that cloud platforms are composed out of multiple services built on a single control plane, successful cloud foundation teams adopt a similar approach to develop an internal cloud service ecosystem for the organization. Leveraging the same “cloud foundation control plane” that already offers 🗂 Tenant Management, 🔐 IAM, 🔖 Security & Compliance and 💵 Cost Management for managing internal cloud customer’s access to cloud platforms, the cloud foundation offers additional services to teams. In general Cloud Foundation teams should focus on offering “value-added” services that solve problems that are too complex or too costly to solve for internal customer leveraging cloud-native services individually.
Key Activities for a Multi-Cloud Service Ecosystem
Building a strong multi-cloud service ecosystem needs to consider the unique demands of the internal cloud customers. The building blocks however represent common capabilities that many organizations implement along their cloud journey:
An Internal Service Marketplace is the foundation for offering internal services in a consistent way and enabling teams outside the cloud foundation to build and consume services as well
Managed DevOps Toolchain can simplify adopting DevOps practices by allowing DevOps teams to concentrate on “what” over “how”
Cloud Foundation teams should listen closely to the needs of internal cloud customers and evolve the service offering accordingly. For example:
As the cloud foundation approach is all about integrating the capabilities of its constituent pillars, the Service Ecosystem pillar has several important links to other cloud foundation capabilities
Internal cloud customers should be able to order services from the cloud foundation’s service ecosystem based on the organizational metadata they already used to register, e.g. recorded in a Cloud Tenant Database.
- Leverage existing IAM facilities such as Federated Identity and Authentication as well as the Authorization Concept to manage teams’ access to internal services.
- Encapsulating solutions commonly needed by cloud customers to run secure workloads in centrally managed and well-secured services can help raise the overall security of a cloud foundation. For example providing Managed bastion hosts or Managed Key Vault.
- Integrate metering and chargeback with cost management building blocks like Pay-per-Use for internal Services. These are an integral part of enabling an Internal Service Marketplace.
Designing a Multi-Cloud Service Ecosystem Strategy
Especially when adopting cloud at scale, cloud foundation teams can benefit tremendously from an internal service ecosystem strategy that enables the organization to build and offer additional services to internal cloud customers.
Building an Internal Cloud Service Ecosystem
Take a look at the comprehensive guide for building successful cloud service ecosystems leveraging an enterprise-wide marketplace for cloud infrastructure services.Read the Cloud Service Guide →
Key Stakeholders in a Multi-Cloud Service Ecosystem
The Cloud Foundation Maturity Model recommends building the cloud service ecosystem around the concept of an Internal Service Marketplace. Marketplaces naturally have three key-stakeholders: the marketplace provider, service providers and service customers.
The cloud foundation team should position itself as a marketplace provider. It is therefore responsible for aligning the marketplace with existing IT service management (ITSM) and governance processes like chargeback.
The cloud foundation team will also take on the role as one of the first service-providers on the marketplace. However, a successful service ecosystem requires that the marketplace provider also enables other providers to offer and “sell” services on its marketplace. This can be traditional infrastructure teams (e.g. offering a Shared VM Image Repository or On-Premise Network Connection) as well as teams manging 3rd party PaaS Service Integration or even In-house PaaS Service Integration.
The internal cloud customers are the service consumers. Cloud Foundation teams play a critical role here as a facilitator matching consumer demands with the supply-side. As a part of this role, cloud foundation teams should also involve management stakeholders and enterprise architects to provide feedback for the evolution of the IT service portfolio.
Finally, the cloud foundation team should also incentivize security & compliance stakeholders to view the marketplace as an opportunity to provide “secured out of the box” services. This can help improve the overall security level of cloud workloads by providing building blocks that are aligned with security and compliance requirements.
Did this page help you?
Internal Service Marketplace
Teams offer services to other teams and make them accessible on a marketplace that is integrated with 💵 Cost Management and 🔐 IAM .
Virtual Network Service
A virtual network service provides a pre-configured virtual network. It is a pre-requisite for higher-level services built on virtual networks.
3rd party PaaS Service Integration
Teams can leverage third-party PaaS providers for managed services like DBaaS, observability platforms or analytics. Teams can manage service-lifecycle and IAM in self-service and are transparently charged for all consumption cost incurred.
Managed Key Vault
Managed key management services that allow applications to securely store and retrieve credentials in the cloud. The key management service configuration is aligned with the organization's policies for cryptography and secret management.
On-Premise Network Connection
Provides managed IP (L3) connectivity to on-premises networks. This is commonly implemented using hub&spoke network architectures and a combination of VPNs or private network peerings.
Managed bastion hosts
Teams can use a managed service to access resources on private cloud networks using managed bastion hosts or gateway services. These gateways are hardened and centrally audited.
Managed DevOps Toolchain
Teams can use a DevOps tools that are integrated with the cloud tenants used by the team. Any required service account or automation user credentials are automatically maintained and rotated.
Kubernetes Cluster as a Service
Provides Kubernetes Clusters as a Service. These are deployed as workloads into the customer's cloud tenants.
Managed Data Lake access
Teams can get managed access to central data warehouses and data lakes to combine this data with processing and infrastructure in their own cloud tenants. Common usage scenarios are "analyst workbenches" for cloud-native DL/DW tools like BigQuery tha...
In-house PaaS Service Integration
In-house teams provide PaaS services for commonly needed infrastructure services like DBaaS, observability platforms or analytics. Teams can manage service-lifecycle and IAM in self-service and are transparently charged for all consumption cost incur...
API Gateway to on-premises APIs
Provide managed API (L7) connectivity to APIs running in on-premise environments.
Managed Cloud Provider Support Contracts
Cloud tenant owners can enroll their tenants in support contracts and/or enterprise support agreements from cloud providers. Owners can access support in self-service and are transparently charged for support fees incurred.
Managed Internet Egress
Cloud tenants can connect to internet egress using managed infrastructure that ensures compliance and cost efficiency (network separation, proxies etc.).
Tenant to Tenant Transit Networks
Provides managed connectivity between cloud tenants on the same cloud platform via centrally managed transit networks.