A Tale Of Two Approaches To The Platform Service Layer: Cloud Foundry And Solum

Getting an application designed, tested and running, then updating and improving it is no easy task — even in the best of times. There is a continuing quest for tooling that delivers automation of this work to allow more focus on what matters most: fast, efficient development. This automation is increasingly sought via a platform service layer that abstracts the compute, networking and storage details of the infrastructure service layer — offering simplification for application developers and the cloud operators who support them.

This tooling is often referred to as application “Platform-as-a-Service” or “PaaS.” Unfortunately, this term tends to mask a distinction we’ve found in two types of customer needs leading to different preferred approaches to use of a platform service layer.

Some customers value a platform service layer’s abstracting away the infrastructure service layer as much as possible. They are cloud operators comfortable with minimalist platform use of the infrastructure layer for the benefit of cross-cloud portability, which is the architectural approach of Cloud Foundry.

Warner Music Group, for example, has discussed this as a Cloud Foundry user where they’ve built an architecture decoupled from the underlying infrastructure. They build once and run the apps in their platform environment on any infrastructure they choose. Rackspace recently joined in forming the Cloud Foundry Foundation as a Platinum sponsor as we serve customers with needs aligned with this approach.

Other customers want to maximize leverage of their existing infrastructure service layer in deploying a platform service layer. They value deeper integration of the platform and infrastructure layers for more seamless control of apps from the platform layer down to the infrastructure resources and want to avoid the operator pain of running a platform layer that involves operating services overlapping their existing cloud capabilities (Orchestration, Monitoring, Logging, Routing / Load Balancing, Image Storage, etc.).

Subbu Allamaraju and Kamal Muralidharan of eBay, for example, have discussed this as Solum contributors: “For a cloud operator, this is operationally efficient because Solum becomes just one additional control plane component to support. For users this means an integrated user experience.” Rackspace, eBay, Red Hat and others in the OpenStack community announced project Solum last October and are actively developing with the goal of serving needs aligned with this approach. Solum is a componentized platform service layer designed for use in OpenStack deployments whether as a standalone platform layer or as a layer within a broader platform that allows for the elimination of this overlap and enables greater efficiency for operators — as Red Hat has explained in how they are interested in using Solum for OpenShift.

There’s sometimes a belief that every technology, given enough time, converges on a single “right” solution. This isn’t what we actually experience in the marketplace. Today we have data centers filled with machines running Windows sitting next to machines running one of a variety of Linux distributions. We run the world’s largest OpenStack public cloud using XEN hypervisors while we are also one of the biggest resellers of VMware.

It’s time to retire the idea of winner-take-all technology. Different kinds of customers need different kinds of technology to help them succeed. This is a reality we at Rackspace acknowledge at all times in our customer-centric approach as a leading cloud service provider.

Rackspace believes in open technologies and was very pleased when Pivotal announced its intent to put the Apache 2.0-licensed Cloud Foundry project into the hands of a new foundation. Many developers, indeed the majority of developers, may not need to concern themselves with the operational details of Heat Orchestrations or exactly how a Cinder block storage volume should be handled after removing it from a server, so Cloud Foundry could be the perfect platform service layer for them. We look forward to doing what we can to help bring our deep expertise in building open source community to support this new planned foundation.

Solum aims to make life easier for application developers and manage their work beyond the simple deployment available currently in OpenStack. We’ve mapped out functionality we hope will guide and support developers through the dev/test/release cycle by integrating measurement, rapid response and build automation. These are important features that benefit from deep integration with infrastructure-level cloud capabilities like those in OpenStack.

Platform approaches are not all the same — similar perhaps, but not the same. Each one may fit a particular use case better than another. Developers, and the cloud operators supporting them, have massively different needs and we do ourselves a disservice as a community to think otherwise. The truth is that there’s more than one type of platform approach because not every customer has the same needs.

Rackspace believes in meeting customer needs — that means staying fluent with multiple methods and relevant contributors in multiple communities. Some pure technology companies will focus on the “right way” of doing things. For Rackspace as a cloud service provider, the right way to do things is the way that best supports our customers. We’re seeing different needs from customers, so we’re pursuing multiple approaches today that meet those needs.

  • andrew boon

    Interesting article on cloud computing ! cloud computing offers a lot of benefits but the main concern in cloud is the security.

  • Would you say that the approach/design of one versus the next – OpenShift or Cloud Foundry – influences the design principles guiding development within Solum?

  • Lee Calcote,

    Solum’s design principles are complimentary to those of existing software. Some things that matter a lot to users of PaaS systems will not matter as much to users of OpenStack. For example, the ability to move an application from one cloud to another. With a PaaS system, an abstraction is placed right under the application to make it portable. With Solum, the same abstraction is redundant, because there are lower level abstractions in OpenStack and with Docker container images that allow equivalent portability among public and private clouds without the need for yet another abstraction layer for the application itself. This allows us the freedom to integrate deeper with the IaaS layer, and take advantage of more features of OpenStack.

    Going first requires that you make all your own mistakes. Starting a bit later means we can learn from the mistakes from those who went before you. We can also take advantage of new technology that was not mature at the time previous systems were developed, and are now becoming adopted more widely. Container technology with container images is one of these. Existing systems need to adapt considerably to embrace some of the new technology, whereas we can design for it to begin with.