refining the cloud stack

8/2/2019 Refining the Cloud Stack

1/5

Refining the cloud stackA whitepaper on first lessons learned in the NEON project

March 12, 2010

Maarten [email protected]

http://necloud.org

The NEON (Northern European Cloud Computing) project aims at reviewing the promises ofcloud computing and summarize the overall offering cloud computing could give to the NordiceScience community. The approach taken is a practical one - learning by doing - so NEONstays close to potential end users and current developments during the project. In preparingthe project and doing our first iterations we have learnt some valuable lessons that reframehow we look and talk about cloud offerings and their architecture. This whitepaper presentsthese insights to the scientific and cloud community at large. The main contribution of thiswhitepaper is the addition of a Middleware-as-aService (MaaS) layer to the cloud servicedelivery stack, easing comparison between different cloud offerings and allowing forintegration on a different layer in hybrid cloud scenarios.

1. Introduction

Cloud computing has gained a lot of interest.In fact, it has gained so much interest thatsimply noting that it has gained much

interest already has become a cliche. Thesubject of clouds is foggy too: the impact ofdifferent pricing models on short term andlong term operations is still developing - asare the pricing models. There are variouskinds of vendors for various kinds of clouds:public, private, hybrid and communityclouds. There is a growing interest inmanaging all this in a cloud-independentmanner.

In researching the current offerings and

getting our feet wet with actually usingvarious combinations, we have come to theconclusion that we need to add one conceptto the cloud stack in order to gain thenecessary clarity in oder to define properusage of the cloud flavors for our end users.

The rest of the whitepaper is organized asfollowed: we will look at existing definitionsinside the cloud stack first. Then, we will addour refinement of the cloud stack - MaaS,Middleware as a Service - in a structuredway and discuss the impact on the variouscloud types. Well end with some examplesof both custom and of the shelf MaaS.

2. Current definitions

In this section we will take a look at thevarious definitions to establish a commonground. That way, we can introduce MaaS in

a structured manner in the next session.

We will take a look at both the kinds of clouddeployment models and the cloud servicedelivery models one can distinguish within acloud. These concepts are orthogonal, i.e.any combination of cloud service deliverymodels can be built on top of anycombination of cloud deployment models.

2.1. Privat e, public, hybrid andcommunity clouds

In general we distinguish four types of clouddeployment models:

Private clouds. These are cloudinf rastructures wi th in the phys ica lboundaries of an organization. Private cloudstypical ly runs c loud middleware forprovisioning services on an internal network- and often in a private datacenter.

Public clouds. These clouds are offering

utility computing on the Internet as aservice, often on a purely pay-as-you-gobasis.

1
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/5

Hybrid clouds. Hybrid clouds are acombination of private and public clouds.Hybrid clouds often are build to scale outfrom a private to a public cloud (also calledsurge computing) or grow inwards frompublic to private clouds as applications growand thus the minimum required base

capacity is better known.

Community clouds. A community cloudmay be estab l i she d wher e sever a lorganizations have similar requirements andseek to share infrastructure so as to realizesome of the benefits of cloud computing.With the costs spread over fewer users thana public cloud (but more than a singletenant) this option is more expensive butmay offer a higher level of privacy, securityand/or policy compliance [1].

Lets look into these different flavors of cloudwith a bit more detail.

There is both a quant i tat ively andqualitatively difference between private andpublic clouds. Private clouds require a largerupfront investment - at least some hardwareis needed, and often licenses for cloudprovisioning software are needed as well.Private clouds may be tuned more towardsthe needs of specific applications, whereaspublic clouds have a few sizes fits all

approach. Metering and billing can be donein a variety of ways, and often needs tomatch specific financial organizationalstructures.

Public clouds are mostly based on pay-as-you-go models, although discounts cansometimes be received when one makes anupfront commitment against a fixed fee for afixed period, typically 1-3 years. The maincost components are:

bandwidth in bandwidth out computing hour GB/month storage space cloud service request

Qualitatively, public clouds are morecommon, and the huge economy of scalemay actually slow the average performanceof a utility computing hour. On the otherhand, better virtual hardware often comesavailable as new, higher-end possibilities.

Hybrid clouds consist of a combination ofprivate and public clouds. They are oftenused to scale out for applications that have

peak performance in a private cloud thathugely exceeds the capacity during a shorttime frame. In other words: one wants tohandle the load, but cant justify buying thehardware for say, two weeks of full-timepeak load, or 1 hour per day.

Hybrid clouds also grow when a revenuedriven application starts in a public cloudbased on a pay-as-you-go model. Assuminga positive revenue, at some point theminimum base load of the application maystabilize, at which point it will be cheaper to

scale into a private cloud. Note that theprivate cloud may grow conservatively asthe minimum base load grows.

As hybrid clouds consist of at least two typeof clouds, the need for sophisticatedmanagement software for metering andprovisioning has arisen. And indeed, a wholemarket of management applications is slowlytaking shape - the obvious problem beingthat the cloud vendors (both public andprivate) are still moving rather fast and inslightly different directions.

Finally, community clouds may turn out tobe very important for scientific communitieswhen e.g. collaborating on the nationalresearch network or national HPC level. Interms of features and cost a community

cloud will be most likely based on a privateor a hybrid cloud - hence all the sameobservations apply.

This section described the various types ofclouds. The next sections will describe howthese various types of clouds may be usedon different layers.

2.2. IaaS

The first level of a cloud service delivery

model is recognized as Infrastructure-as-a-Service, or IaaS. At this level, the serviceoffered consists mostly of raw storage andcomputing capacity. The capacity is typicallyavailable on demand, metered by thecomputer hour or GB data in/out/stored permonth, and conceptually it provides anextension of virtual private servers.

A simple way to think about this is:

Virtual servers + storage + API + ondemand = IaaS

IAASs are targeted at organizations thatwant to virtualize their raw computing and

2


3/5

storage infrastructure. This is mostly doneby outsourcing to a public cloud or by settingup a centralized private cloud. It is notuncommon to see the private cloud beingused as internal buffer capacity to providemore flexibility internally; used this way aprivate cloud acts in a similar way to the

real computing infrastructure of anorganization as the public cloud acts to theprivate cloud in a hybrid cloud. Bothscenarios add extra flexibility to theinfrastructure.

Examples of vendors that offer IaaS cloudservices are Amazon Web Services,Rackspace Cloud, Eucalyptus, VMWare,Ubuntu Enterprise Cloud (based onEucalyptus), GoGrid and Flexiscale.

2.3. PaaS

On the next level of the cloud servicedelivery stack we find Platform-as-a-Service,or PaaS. This is a less raw environmentand typically provides a full fledgedapplication runtime environment.

Services included may be database services,file system services, dynamic web pages, butalso higher lever services, such as workflowservices.

PaaS can be seen as the natural evolution ofapplication servers: they provide magicalscalability for applications built within theframework of a given PaaS. The downside ist ha t app l i c a t i on deve l opmen t anddeployment is limited to the supportedframeworks(s). Organizations that haveexpertise in developing or deployingapplications within frameworks that aresupported, e.g. Microsoft .NET and Azure,will benefit the most.

Well known examples of PaaS vendors areMicrosoft Azure and Google AppEngine.

2.4. SaaS

Software as a service, or SaaS, is anyservice that can be licensed from vendors toclients and run over the Internet (thoughtypically limited to the web). This does notimply that all SaaS requires the user to pay -many consumer oriented Saas offerings frome.g. Google are free.

It is probably best to give a better feel forSaaS by listing some examples:

Google Apps is a paid SaaS targetedtowards the Enterprise Google Maps is a free SaaS providing mapdata Basecamp is a paid SaaS for projectmanagement

Wikipedia is a SaaS that provides an onlineencyclopedia

Combining all of the above, we get thefollowing image for a cloud service stack:

There is a problem with the image above

though; some components exist both on thePaaS and IaaS layer. In the following sectionwe will refine this image by grouping thesecomponents in an additional layer calledMaaS: Middleware-as-a-Service.

3. Refining the cloud stack

There is a need for a refinement of the cloudstack. There is an elephant in the room withregards to the the current service deliverydefinitions as some components dont have

a place in the previously described cloudservice stack.

These services tend to be infrastructuralwithout being a full platform - a bit of both.When we take a closer look at thesecomponents, they resemble what we call

middleware in more traditional computing.So we can group these components quitenaturally in a new layer: Middleware-as-a-Service, or MaaS.

3.1. MaaSMiddleware-as-a-Service, or MaaS, can beviewed as components that are needed to

3

SaaS

PaaS

IaaS

Server


4/5

develop or orchestrate large scale cloudbased applications above the infrastructurelayer, but not visible to the end users. Partsof the PaaS will be using these middlewarecomponents, but some SaaS will use thesecomponents directly as well.

These are some components that can beviewed as MaaS components:

Queues Databases, both relational and non-relational Locking services Map-reduce execution engines Payment services

MaaS components all have the characteristicthat they are available on-demand (utilitycomputing), are metered and billed foractual usage. They can often be launchedand managed via simple HTTP based APIs.

This leads us to the following figure for acloud service stack when we include MaaS:

Examples of already available MaaS servicesand components are:

Amazon Simple Queue Service Amazon SimpleDb Amazon RDS (Relational Database Service) Hadoop Amazon Elastic MapReduce -based on

Hadoop Apache Cassandra - column orienteddatabase

Apache ZooKeeper - configurationmanagement and locking SQLAzure - Microsoft Database as a service

Note that for the MaaS componentsgenerally holds:

deployed on IaaS + automatic scaling =MaaS

An example would be deploying Hadoop on acloud, using the IaaS layer to scale. Anotherexample being researched in the NEONproject is that of cloud backed storage,building on MaaS components such asApache ZooKeeper [4].

3.2. MaaS, IaaS, PaaS and SaaS

How does MaaS relate to IaaS and PaaS asthey are both builder-focused layers? Ingeneral MaaS should be able to run on IaaS- though for performance reasons it wontalways be the case. This implies that a MaaScan be set up on top of a private IaaS usingcomponents - e.g. Hadoop - and clever auto-scaling techniques inside the IaaS.

As with regards to PaaS - it is obvious thatparts of a platform will be built on top ofMaaS, or have been built using MaaSalready. But more importantly, MaaS and

PaaS are often mistakenly offered as a PaaSonly for developing and deployingappl icat ions. This prevents a c learcomparison between various solutions!

An example will illustrate the case. MicrosoftAzure is a great example of a PaaS. But viaits relational SQLAzure component it doesoffer a MaaS component! And in that respectit suddenly becomes comparable to a moreIaaS like provider such as Amazon WebServices that is offering RDS: a Relational

Database Service. In the short term it mightbe easier to mix middleware components -either within a Paas or on top of an IaaS -then it is to get a complete cloud-neutraldeployment scenario on the IaaS or PaaSlevel, precisely because of the correspondingofferings on the middleware layer.

Whats the implication of MaaS for SaaS?

Well, some middleware is being used to hookend user services directly together. Thereare some good examples in the identitymanagement space, i.e. Facebook connectand OpenID. These are end useroriented.

4

SaaS

IaaS

Server

! MaaSPaaS


5/5

The other implication is that the way thatSaaSs are being developed is actuallydifferent than is often depicted. Most SaaSsuse a PaaS built on top of a MaaS, and useMaaS sometimes directly (see the orangeshape in the picture above). One can argueabout the cleanness of that design; it is

however obvious that there is demand forthis kind of use - see the product roadmapsof the larger vendors and the alreadyavailable services.

3.3. Impact on cloud types

We have defined MaaS and the impact onthe various other layers of a cloud stack, butwhat is the consequence on the differentcloud types?

For one, public clouds on the IaaS and PaaSlevel can be more easily compared if theyboth actually offer MaaS components as partof their offering - see the SQLAzure/RDSexample in the previous section. Anotherimplication is that it might be beneficial tooffer MaaS in private cloud or communityclouds as well. This can be done using theelasticity of the computing part of theprivate IaaS mostly.

There is one other use case for using MaaSwith hybrid clouds: some components can be

used rather easily to scale and synchronizebe tw ee n pr iva te an d pu bl i c c lo udcomponents, abstracting away cloud flavorsand runtime configuration management. Soit may very well be the case that a simpledatabase component running in the publiccloud is used for orchestrating hybrid cloudbehavior. Examples of components that canbe used this way are queues and databases.

4. Conclusion

We hope to have shown that by defining anadditional middleware layer in the cloudstack the difference between variousofferings can be better understood. We havealso mentioned that orchestration betweendifferent cloud types in a hybrid cloudapproach might be achieved by using any ofthe available middleware components.

Finally, we have shown that MaaS might be

a usable offering in a private or communitycloud environment on its own.

5. References

[ 1 ] h t t p : / / e n . w i k i p e d i a . o r g / w i k i /IaaS#Community_cloud[2] http://was.amazon.com[ 3 ] h t t p : / / w w w . m i c r o s o f t . c o m /windowsazure/

[4] http://hadoop.apache.org/zookeeper/[5]Above the Clouds: A Berkeley View ofCloud Computing", Michael Armbrust,Armando Fox, Rean Griffith, Anthony D.Joseph, Randy Katz, Andy Konwinski, GunhoLee, David Patterson, Ariel Rabkin, IonStoica, and Matei Zaharia, http://radlab.cs.berkeley.edu, February 10, 2009

5
http://radlab.cs.berkeley.edu/http://radlab.cs.berkeley.edu/http://radlab.cs.berkeley.edu/http://radlab.cs.berkeley.edu/http://hadoop.apache.org/zookeeper/http://hadoop.apache.org/zookeeper/http://www.microsoft.com/windowsazure/http://www.microsoft.com/windowsazure/http://www.microsoft.com/windowsazure/http://www.microsoft.com/windowsazure/http://was.amazon.com/http://was.amazon.com/

refining the cloud stack

Documents