The future of managed cloud services

At the very beginning, there were unmanaged virtual machines as a service. These services were mainly used for development and test purposes or to host horizontal, born on the web workloads. For more traditional production workloads another type of cloud service is required. This new service needs to be more fault tolerant to provide the required availability for so called cloud enabled workloads, but also provide a certain management capability to ensure a stable operation. Managed infrastructure as a service (IaaS) solutions such as IBM’s SmartCloud Enterprise+ provide these service levels and capabilities.

But is this the future of managed cloud services?

I don’t think so, although this model fits for some workloads, it is just the start of the journey.

The ultimate goal of managed cloud services is to receive higher value services out of the cloud. In my opinion, the future of managed cloud services are platform as a service (PaaS) offerings.

Todays managed IaaS offerings cause some challenges, both for the service provider as well as for the service receiver. One reason for that is the higher complexity due to the shared responsibility of an IaaS managed virtual machine (VM). In this scenario the service provider manages the VM up to the operating system level, but the client is responsible for the middleware and application on top. In such a setup it is extremely hard to make a clear separation of the operating system (OS) from its higher services. Many applications require OS settings to be set or access to operating system resources.

A managed PaaS overcomes these challenges by providing a consistent software stack out of one hand. All components are designed for the purpose of this platform. If the PaaS service is a database, OS settings, IO subsystem and storage are designed and configured to provide a robust service with decent performance. The client can rely on the service providers expertise and does not need to support a database – or any other middleware – on an operating system platform he has no real insight on its configuration and not full control over its settings.

In one of my previous blog posts on how Middleware topology changes because of cloud, I discussed the change in middleware and database architecture. This is exactly where PaaS comes into play. By moving away from the consolidated database and middleware clusters, clients require agile, elastic and managed databases and middleware as a service to be able to handle the higher number of instances.

Summary

Due to the complexity and limitations, managed IaaS will become a niche offering for accommodating non standard software. For middle-ware and database with a certain market share, managed PaaS offerings will become commodity.

Active Directory on a managed IaaS

In a hybrid cloud environment, parts of the infrastructure are located in a public or shared cloud environment whereas other parts are in a different environment, either on a private cloud or on a traditional infrastructure. As long as this is all managed by one service provider, there is not much of a problem. But usually that’s not the case.

While servers located in the traditional infrastructure are often managed by the client himself, the servers that are hosted in a managed shared-cloud environment are operated by the service provider of that cloud. As long as we are talking about a managed infrastructure as a service (IaaS), that is up to the operating system level. Everything beyond the operating system is normally in the responsibility of the client himself because he knows the combination of middleware and application best.

This setup leads to all sorts of challenges. For all servers in the cloud we have a strict responsibility boundary, however, the layers above the OS are highly dependent on the OS settings and it is indeed very hard to isolate impacts of changes done in one layer to the other layer. The situation gets even more challenging when we talk about services which span not only the responsibility boundaries of a single host, but also over different environments (public/shared cloud and private cloud/traditional IT).

Microsoft Active Directory currently gives clients and service providers some headaches.

Lets briefly scan the interests of the different parties:

The service provider wants to maintain exclusive administrative rights on OS level for the servers in his responsibility. Otherwise it would be impossible to guarantee any service level agreements (SLAs) and/or a certain contracted level of security.

The client requires servers belonging to him in a single, or at least in a consistent environment. This starts with a certain server naming convention, but also includes dns suffixes and namespaces.

On first sight, these requirements sound reasonable, but in respect of Microsoft Active Directory, they are somehow conflicting.

When we talk about exclusive administrative rights on OS level in an MS ADS environment, we need to separate the environments based on responsibility in different ADS forests. Otherwise, the owner of the root domain of the forest automatically holds the Enterprise Admin rights and can create domain and server admin user ids in all subdomains of the forest at will.

ADS trust relationship

ADS trust relationship

However, if we would split the servers in two different ADS forests, they would also live in different name spaces. Furthermore, we would need to find a solution on how users and services of one forest can access resources on the other forest. Well, this can be handled by trusts, but this would introduce a lot of complexity and would be a perfect source for all kind of problems.

And, there is another limitation about the two forest solution: There could be no domain controllers of the forest the client owns hosted in the cloud environment. And that is a real problem, especially when we consider that most clients would like to move most of their easy Windows workloads (like domain controllers) in the cloud.

There are no easy answers on that.

Another solution could be to reduce complexity by moving all Windows servers in the cloud and let the cloud provider manage not only the pure server OS but also the Active Directory Service. However, this would require the service provider to offer ADS management as a service, including all tasks that come along with that (like OUs, user ids, certificates, public keys).

Another possibility could be if one party does not insist on its exclusive administrative rights and accepts this as a risk. If ownership of the domains is with the service provider, the client can have the rights to operate his ADS settings and probably local server admin ids for the servers not in the cloud.

ADS single domain

ADS single domain

Summary

There is currently not a single solution for that problem. The client’s requirements and the service providers’ capabilities need to be considered when designing the future environment. In any case, this needs to be done carefully and well in advance to limit later surprises!