refining the cloud stack
Post on 06-Apr-2018
Embed Size (px)
8/2/2019 Refining the Cloud Stack
Refining the cloud stackA whitepaper on first lessons learned in the NEON project
March 12, 2010
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.
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.
8/2/2019 Refining the Cloud Stack
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 .
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.
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
8/2/2019 Refining the Cloud Stack
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.
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.
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 sec