Refining the cloud stack

A whitepaper on first lessons learned in the NEON project

March 12, 2010 Maarten Koopmans maarten@vrijheid.net http://necloud.org
The NEON (Northern European Cloud Computing) project aims at reviewing the promises of cloud computing and summarize the overall offering cloud computing could give to the Nordic eScience community. The approach taken is a practical one - learning by doing - so NEON stays close to potential end users and current developments during the project. In preparing the project and doing our first iterations we have learnt some valuable lessons that reframe how we look and talk about cloud offerings and their architecture. This whitepaper presents these insights to the scientific and cloud community at large. The main contribution of this whitepaper is the addition of a Middleware-as-aService (MaaS) layer to the cloud service delivery stack, easing comparison between different cloud offerings and allowing for integration on a different layer in hybrid cloud scenarios.

1.

Introduction

2.

Current definitions

Cloud computing has gained a lot of interest. In fact, it has gained so much interest that simply noting that it has gained much interest already has become a cliche. The subject of clouds is foggy too: the impact of different pricing models on short term and long term operations is still developing - as are the pricing models. There are various kinds of vendors for various kinds of clouds: public, private, hybrid and community clouds. There is a growing interest in managing all this in a cloud-independent manner. In researching the current offerings and getting our feet wet with actually using various combinations, we have come to the conclusion that we need to add one concept to the cloud stack in order to gain the necessary clarity in oder to define proper usage of the cloud flavors for our end users. The rest of the whitepaper is organized as followed: we will look at existing definitions inside the cloud stack first. Then, we will add our refinement of the cloud stack - MaaS, Middleware as a Service - in a structured way and discuss the impact on the various cloud types. Well end with some examples of both custom and of the shelf MaaS. 1

In this section we will take a look at the various definitions to establish a common ground. That way, we can introduce MaaS in a structured manner in the next session. We will take a look at both the kinds of cloud deployment models and the cloud service delivery models one can distinguish within a cloud. These concepts are orthogonal, i.e. any combination of cloud service delivery models can be built on top of any combination of cloud deployment models.

2.1. P r i v a t e , p u b l i c , h y b r i d a n d community clouds

In general we distinguish four types of cloud deployment models: Private clouds. These are cloud infrastructures within the physical boundaries of an organization. Private clouds typically runs cloud middleware for provisioning services on an internal network - and often in a private datacenter. Public clouds. These clouds are offering utility computing on the Internet as a service, often on a purely pay-as-you-go basis.

 Hybrid clouds. Hybrid clouds are a combination of private and public clouds. Hybrid clouds often are build to scale out from a private to a public cloud (also called surge computing) or grow inwards from public to private clouds as applications grow and thus the minimum required base capacity is better known. Community clouds. A community cloud may be established where several organizations have similar requirements and seek to share infrastructure so as to realize some of the benefits of cloud computing. With the costs spread over fewer users than a public cloud (but more than a single tenant) this option is more expensive but may offer a higher level of privacy, security and/or policy compliance [1]. Lets look into these different flavors of cloud with a bit more detail. There is both a quantitatively and qualitatively difference between private and public clouds. Private clouds require a larger upfront investment - at least some hardware is needed, and often licenses for cloud provisioning software are needed as well. Private clouds may be tuned more towards the needs of specific applications, whereas public clouds have a few sizes fits all approach. Metering and billing can be done in a variety of ways, and often needs to match specific financial organizational structures. Public clouds are mostly based on pay-asyou-go models, although discounts can sometimes be received when one makes an upfront commitment against a fixed fee for a fixed period, typically 1-3 years. The main cost components are: bandwidth in bandwidth out computing hour GB/month storage space cloud service request

peak performance in a private cloud that hugely exceeds the capacity during a short time frame. In other words: one wants to handle the load, but cant justify buying the hardware for say, two weeks of full-time peak load, or 1 hour per day. Hybrid clouds also grow when a revenue driven application starts in a public cloud based on a pay-as-you-go model. Assuming a positive revenue, at some point the minimum base load of the application may stabilize, at which point it will be cheaper to scale into a private cloud. Note that the private cloud may grow conservatively as the minimum base load grows. As hybrid clouds consist of at least two type of clouds, the need for sophisticated management software for metering and provisioning has arisen. And indeed, a whole market of management applications is slowly taking shape - the obvious problem being that the cloud vendors (both public and private) are still moving rather fast and in slightly different directions. Finally, community clouds may turn out to be very important for scientific communities when e.g. collaborating on the national research network or national HPC level. In terms of features and cost a community cloud will be most likely based on a private or a hybrid cloud - hence all the same observations apply. This section described the various types of clouds. The next sections will describe how these various types of clouds may be used on different layers.

2.2. IaaS
The first level of a cloud service delivery model is recognized as Infrastructure-as-aService, or IaaS. At this level, the service offered consists mostly of raw storage and computing capacity. The capacity is typically available on demand, metered by the computer hour or GB data in/out/stored per month, and conceptually it provides an extension of virtual private servers. A simple way to think about this is: Virtual servers + storage + API + on demand = IaaS IAASs are targeted at organizations that want to virtualize their raw computing and 2

Qualitatively, public clouds are more common, and the huge economy of scale may actually slow the average performance of a utility computing hour. On the other hand, better virtual hardware often comes available as new, higher-end possibilities. Hybrid clouds consist of a combination of private and public clouds. They are often used to scale out for applications that have

storage infrastructure. This is mostly done by outsourcing to a public cloud or by setting up a centralized private cloud. It is not uncommon to see the private cloud being used as internal buffer capacity to provide more flexibility internally; used this way a private cloud acts in a similar way to the real computing infrastructure of an organization as the public cloud acts to the private cloud in a hybrid cloud. Both scenarios add extra flexibility to the infrastructure. Examples of vendors that offer IaaS cloud services are Amazon Web Services, Rackspace Cloud, Eucalyptus, VMWare, Ubuntu Enterprise Cloud (based on Eucalyptus), GoGrid and Flexiscale.

Google Apps is a paid SaaS targeted towards the Enterprise Google Maps is a free SaaS providing map data Basecamp is a paid SaaS for project management Wikipedia is a SaaS that provides an online encyclopedia Combining all of the above, we get the following image for a cloud service stack:

SaaS

PaaS

2.3. PaaS
On the next level of the cloud service delivery stack we find Platform-as-a-Service, or PaaS. This is a less raw environment and typically provides a full fledged application runtime environment. Services included may be database services, file system services, dynamic web pages, but also higher lever services, such as workflow services. PaaS can be seen as the natural evolution of application servers: they provide magical scalability for applications built within the framework of a given PaaS. The downside is that application development and deployment is limited to the supported frameworks(s). Organizations that have expertise in developing or deploying applications within frameworks that are supported, e.g. Microsoft .NET and Azure, will benefit the most. Well known examples of PaaS vendors are Microsoft Azure and Google AppEngine.

IaaS

Server

There is a problem with the image above though; some components exist both on the PaaS and IaaS layer. In the following section we will refine this image by grouping these components in an additional layer called MaaS: Middleware-as-a-Service.

3.

Refining the cloud stack

There is a need for a refinement of the cloud stack. There is an elephant in the room with regards to the the current service delivery definitions as some components dont have a place in the previously described cloud service stack. These services tend to be infrastructural without being a full platform - a bit of both. When we take a closer look at these components, they resemble what we call middleware in more traditional computing. So we can group these components quite naturally in a new layer: Middleware-as-aService, or MaaS.

2.4. SaaS
Software as a service, or SaaS, is any service that can be licensed from vendors to clients and run over the Internet (though typically limited to the web). This does not imply that all SaaS requires the user to pay many consumer oriented Saas offerings from e.g. Google are free. It is probably best to give a better feel for SaaS by listing some examples: 3

3.1. MaaS
Middleware-as-a-Service, or MaaS, can be viewed as components that are needed to

develop or orchestrate large scale cloud based applications above the infrastructure layer, but not visible to the end users. Parts of the PaaS will be using these middleware components, but some SaaS will use these components directly as well.

Apache ZooKeeper - configuration management and locking SQLAzure - Microsoft Database as a service Note that for the MaaS components generally holds: deployed on IaaS + automatic scaling = MaaS An example would be deploying Hadoop on a cloud, using the IaaS layer to scale. Another example being researched in the NEON project is that of cloud backed storage, building on MaaS components such as Apache ZooKeeper [4].

These are some components that can be viewed as MaaS components: Queues Databases, both relational and nonrelational Locking services Map-reduce execution engines Payment services MaaS components all have the characteristic that they are available on-demand (utility computing), are metered and billed for actual usage. They can often be launched and managed via simple HTTP based APIs. This leads us to the following figure for a cloud service stack when we include MaaS:

3.2. MaaS, IaaS, PaaS and SaaS

How does MaaS relate to IaaS and PaaS as they are both builder-focused layers? In general MaaS should be able to run on IaaS - though for performance reasons it wont always be the case. This implies that a MaaS can be set up on top of a private IaaS using components - e.g. Hadoop - and clever autoscaling techniques inside the IaaS. As with regards to PaaS - it is obvious that parts of a platform will be built on top of MaaS, or have been built using MaaS already. But more importantly, MaaS and PaaS are often mistakenly offered as a PaaS only for developing and deploying applications. This prevents a clear comparison between various solutions! An example will illustrate the case. Microsoft Azure is a great example of a PaaS. But via its relational SQLAzure component it does offer a MaaS component! And in that respect it suddenly becomes comparable to a more IaaS like provider such as Amazon Web Services that is offering RDS: a Relational Database Service. In the short term it might be easier to mix middleware components either within a Paas or on top of an IaaS then it is to get a complete cloud-neutral deployment scenario on the IaaS or PaaS level, precisely because of the corresponding offerings on the middleware layer. Whats the implication of MaaS for SaaS? Well, some middleware is being used to hook end user services directly together. There are some good examples in the identity management space, i.e. Facebook connect and OpenID. These are end user oriented. 4

SaaS

PaaS ! MaaS

IaaS Server

Examples of already available MaaS services and components are: Amazon Simple Queue Service Amazon SimpleDb Amazon RDS (Relational Database Service) Hadoop Amazon Elastic MapReduce -based on Hadoop Apache Cassandra - column oriented database

The other implication is that the way that SaaSs are being developed is actually different than is often depicted. Most SaaSs use a PaaS built on top of a MaaS, and use MaaS sometimes directly (see the orange shape in the picture above). One can argue about the cleanness of that design; it is however obvious that there is demand for this kind of use - see the product roadmaps of the larger vendors and the already available services.

5.

References

3.3. Impact on cloud types

We have defined MaaS and the impact on the various other layers of a cloud stack, but what is the consequence on the different cloud types? For one, public clouds on the IaaS and PaaS level can be more easily compared if they both actually offer MaaS components as part of their offering - see the SQLAzure/RDS example in the previous section. Another implication is that it might be beneficial to offer MaaS in private cloud or community clouds as well. This can be done using the elasticity of the computing part of the private IaaS mostly. There is one other use case for using MaaS with hybrid clouds: some components can be used rather easily to scale and synchronize between private and public cloud components, abstracting away cloud flavors and runtime configuration management. So it may very well be the case that a simple database component running in the public cloud is used for orchestrating hybrid cloud behavior. Examples of components that can be used this way are queues and databases.

[1] http://en.wikipedia.org/wiki/ IaaS#Community_cloud [2] http://was.amazon.com [3] http://www.microsoft.com/ windowsazure/ [4] http://hadoop.apache.org/zookeeper/ [5]Above the Clouds: A Berkeley View of Cloud Computing", Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia, http:// radlab.cs.berkeley.edu, February 10, 2009

4.

Conclusion

We hope to have shown that by defining an additional middleware layer in the cloud stack the difference between various offerings can be better understood. We have also mentioned that orchestration between different cloud types in a hybrid cloud approach might be achieved by using any of the available middleware components. Finally, we have shown that MaaS might be a usable offering in a private or community cloud environment on its own.