Cloud Infrastructure Services: Enterprise-wide Distribution via a Marketplace

This is a comprehensive overview of provisioning cloud infrastructure services in 2021.

If you work as an Enterprise Architect, in a Cloud Foundation Team, in DevOps — or you’re just interested in cloud infrastructure services — this story is for you.

Photo by Mike Petrucci on Unsplash

In this story you will learn:

• What cloud infrastructure services are
• What benefits you can expect from them
• Who the stakeholders are — service user and owner
• About the role of Cloud Foundation Teams
• About the challenges posed by provisioning of services
• How a service marketplace helps you offering and using infrastructure services

If you want to dive deeper, this guide will go into more detail on:

• The Open Service Broker API
• How service owners can move from cost to profit center
• Platform service model classification

Chapter 1: Fundamentals of Cloud Infrastructure Services

Let’s get started with a quick intro to cloud infrastructure services.

Specifically, we will define what cloud infrastructure services are, what kinds there are, and what they are good for.

What is a Cloud Infrastructure Service?

Any service needed to actually run a workload in the cloud is a cloud infrastructure service: These services are provided by AWS, Azure, or GCP for their platforms but can also be provided by third-party vendors or by the developers using the cloud.

Here are a few examples to get a quick and intuitive understanding of what cloud infrastructure services are: A database is such a service or a monitoring stack or the backend connectivity you need to run your application in the cloud.

You can think of cloud services as infrastructure building blocks, that are standardized and reusable, for any imaginable purpose.

What are Cloud Infrastructure Services good for?

Platform services play an increasingly important role in cloud infrastructures. They enable application operators to quickly stick together the dependencies they need to run their applications. For example, when deploying your application and you need a database, you just request a service instance of the database of your choice and connect it to your application. Done.

Managed services especially — we’ll get to that in the next section — enable developers to focus on their application code and not on operations and dependencies or ordering processes.

The basis is the IaaC services provided natively by the cloud service providers: You can create any other — more complex — service on top of them. Organizations thrive for higher-level services, because it’s less effort, accelerates time-to-market, and leverages existing knowledge.

What kinds of Cloud Infrastructure Services are there?

Now for a brief dive into the categories that cloud infrastructure services come in.

The first thing we can ask ourselves is by whom the services are provided:

On the one hand, the cloud service providers (CSPs) offer first-hand services for their platforms.

Then, a large number of third-party providers bring their services to users via the corresponding cloud provider marketplaces.

Very often, however, services are also provided in-house to meet very specific requirements.

We can also categorize cloud services by their operating model:

First, there is the dimension and the level of management of services.

They come as

• unmanaged,
• operated, and
• managed services.

Unmanaged services are provisioned by the vendor and from there on the service user is on his own.

Operated services are monitored by the vendor and recovered if anything goes wrong. The effects of the service on the users’ applications and data are still out of the vendor’s scope in this case.

Managed services are basically run by the vendor: The responsibility of keeping the service available, providing data backups, recovery, and continuous updates makes this the most comfortable and most expensive way of consuming services.

There is a second dimension to service classification:

Is the service a white or a black box to the user?

Whitebox: Details of the service deployment are visible to the user.

Blackbox: The service only offers a defined interface to control your service instance, but no insight where or how this service is deployed or operated.

Chapter 2: Stakeholders of Service Provisioning

First of all: It is important to know who is responsible for what aspect of a cloud infrastructure service:

The service owner and the service user are the two parties that share interest and responsibility in the service.

The Service Owner

Services can be owned by CSPs like AWS, Azure, and GCP, by third-party companies that offer special monitoring or connectivity services and services can be owned by corporate IT or DevOps-Teams. The owner usually charges for the usage of the service.

The Service User

Service users are usually developers and operators who work on applications in the cloud. The user is usually charged with the cost of the service instance.

The Role of In-house Cloud Service Owners

Cloud Foundation Teams, network or database teams are usually in the role of a service provider: They offer Databases-as-a-Service or monitoring services to the developers in the company. They focus on cross-sectional topics that are relevant for many cloud applications. Inhouse service owners can more often than not charge for the services provided — missing processes for billing are a major challenge here.

Chapter 3: The Challenges of Provisioning Services

Cloud Infrastructure Services arise from certain demands in the development teams that work with cloud infrastructure. They need monitoring, databases, connectivity, and so on, to do their job.

Where can developers find the right services?

Depending on the cloud technology they work with, developers have a catalog of 3rd party services to choose from: Google runs its Google Cloud Marketplace, Microsoft offers services in their Azure Marketplace and Amazon has its AWS Marketplace.

From operating systems to data analytics and machine learning services — there are solutions of every category.

Challenges for enterprise-wide service distribution

Even with the endless first and third party services in the marketplaces of the cloud providers, there is a massive need for customized solutions:

In a worst-case scenario, the developers can’t find a service that solves their problem and they build a solution themselves.

This leads us to the challenges that arise when offering and consuming services within an organization:

• every team reinvents the wheel
• intransparent and time-consuming processes
• manual provisioning, e.g. having to send a mail to the service owner
• no central overview of which services are available within the organization
• service delivery is resource and time-consuming when self-service is not available
• lack of billing

Supply and demand of services

This set of challenges leads to the fundamental issue of service development and consumption in an organization: Potential service owners are deterred from developing services. It makes them a cost center and every new service adds effort when it comes to provisioning it.

In the next chapter, we’ll see how a service marketplace addresses this issue by motivating service owners because they can offer services company-wide, gain visibility and charge for the usage of their services.

Chapter 4: The Service Marketplace

Many IT organizations choose to offer a Service Marketplace as part of their service portfolio. The Marketplace acts as an addition to the cloud infrastructure services provided by large cloud providers like AWS, GCP, or Azure.

The 4 components of a marketplace

Four components make up a cloud service marketplace: a service catalog, provisioning, billing, and service monitoring.

1. The catalog requires the service owners to create intuitive experiences to discover the right product and help developers choose the right solution. The marketplace will also need to have enough available inventory, which means continually incentivizing service owners to provide new services.
2. Provisioning acts as the backbone of the whole system. The marketplace has to manage which resources need to be created or deleted, it has to deliver the configuration and provision dedicated service instances.
3. Billing provides the system of record. This system needs to implement several different billing models, payment methods, and processing.
4. Lastly, service monitoring allows the service owner to check on running service instances and take care of failed services.

An active marketplace needs these critical systems to work smoothly together.

The major use case of a marketplace working like this is the possibility of offering services in a multi-cloud federation.

Benefits of a service marketplace

We learned that cloud services are the building blocks to a more complex cloud infrastructure. We also learned that there are several ways of offering and accessing services.

A service marketplace is the best option to go for and here is why:

• Self-service
• Chargeback
• Service monitoring

Marketplace implementation with Open Service Broker API

At meshcloud, we’ve implemented our Service Marketplace solution based on the Open Service Broker API.

The Open Service Broker API defines an interface between platforms and service brokers. Service owners can build a lightweight service broker to offer their service on the marketplace. The broker is independent of any implementations of the service itself.

With this technology services of every category can be offered: Managed or unmanaged, black box or white box.

This self-service, on-demand marketplace increases developer velocity and minimizes time to deliver value to the market.

This shows how we at meshcloud implemented a marketplace to bring both service owners and users together.

About the Open Service Broker API
The Open Service Broker API project allows independent software vendors, SaaS providers, and developers to easily provide backing services to workloads running on cloud-native platforms such as Cloud Foundry and Kubernetes. The specification, which has been adopted by many platforms and thousands of service providers, describes a simple set of API endpoints that can be used to provision, gain access to, and managing service offerings.
The project has contributors from Google, IBM, Pivotal, Red Hat, SAP, and many other leading cloud companies.