T
he cloud abstraction model delivers a shared pool of configurable computing resources (processors, storage, and so on) that can be dynamically and automatically pro-visioned and released. Cloud capabilities include three levels of service offerings — software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) — letting users focus on what the services provide rather than how they’re implemented or hosted.Current cloud research places substantive emphasis on low-level technological trajec-tories. For instance, cloud scalability is heav-ily researched with efforts focusing on service horizontal scaling (that is, adding new server replicas and load balancers to distribute the load) or vertical scaling (on-the-fly changing of the assigned resources to an already running instance) and associated issues such as load bal-ancing.1–3 However, we observe far less concen-tration on other aspects of the cloud, such as cloud application development.
A clear need exists for emphasizing the development of enhanced composite service offerings at the application (or SaaS) level and assigning or reassigning different virtual and physical resources dynamically and elasti-cally. This leads to forming service syndica-tions on demand at any level of the cloud stack that might potentially involve various SaaS/ PaaS/IaaS providers by breaking up the current monolithic approach.
Here, we examine such concerns, shedding light on some serious shortcomings in cur-rent cloud delivery models and management approaches. We also explain how to achieve holistic cloud solutions on the basis of the cloud
blueprinting concept.
The Cloud Delivery Model Landscape
Examining the three cloud delivery models, we observe a recurrent theme. They’re all con-strained by the capabilities available via the provider at the delivery level and don’t allow for easy extensibility or customization options. Cloud service developers need better ways to orchestrate a cohesive solution that assembles virtual services when each cloud-stack services tier is possibly provisioned from different cloud providers. To realize this vision, we must tackle several key challenges.
At the IaaS level, it currently isn’t pos-sible to cross-configure the virtual machines comprising a specific cloud service. Moreover, cross-machine configurations must be inferred at deployment time rather than being statically allocated, as is the norm with IaaS solutions today.
Similar problems permeate the PaaS solution space. PaaS offerings are constrained by provid-ers’ capabilities and don’t allow easy extensi-bility, mashup, or customization options at the consumer or developer levels. The underlying PaaS middleware and the applications built on
Blueprinting the Cloud
Michael P. Papazoglou and Willem-Jan van den Heuvel • Tilburg University
Current cloud solutions are fraught with problems. They introduce a monolithic cloud stack that imposes vendor lock-in and don’t let developers mix and match services freely from diverse cloud service tiers to configure them dynamically to address application needs. Cloud blueprinting is a novel approach that lets developers easily syndicate, configure, and deploy virtual service-based application payloads on virtual machine and resource pools in the cloud.
it aren’t portable across many dif-ferent public and private clouds and cloud providers. Furthermore, many hosted middleware solutions aren’t integrated with any IaaS manage-ment and thus lack elasticity and scaling benefits.
SaaS is also predominantly teth-ered to proprietary application plat-forms in which the cloud provider runs all elements of the service and presents a complete application to the client. Cloud solution developers can’t easily customize SaaS applica-tions at the process level or simply combine them with external ser-vices from other providers to offer improved functionality to the client or to other developers.
From the preceding discussion, we can see that current cloud solu-tions are fraught with problems. First, they introduce a monolithic SaaS/PaaS/IaaS stack architecture in which a one-size-fits-all mental-ity and vendor lock-in prevails. They don’t let developers mix and match services from diverse cloud service tiers and configure them dynami-cally to address client and applica-tion needs. Second, they introduce rigid service orchestration practices tied to a specific resource/infrastruc-ture configuration for cloud services at the application level. These issues hamper the (re)configuration and customization of cloud applications on demand to reflect evolving inter-organizational collaborations.
Clearly, developers must be able to mashup services from a variety of cloud providers to create a cloud ecosystem. This type of integration lets developers tailor services to spe-cific business needs using a mix-ture of SaaS, PaaS, and IaaS. Cloud ecosystems have been termed
busi-ness process as a service, or BPaaS,
emphasizing the focus on enterprise-specific services. BPaaS lets develop-ers create unique end-to-end business processes that are usually syndicated with other external services (possibly
provided by diverse SaaS providers). BPaaS requires effective manage-ment of cloud resources.
Managing the Cloud
To represent and manage cloud re sources, developers usually rely on a metadata or model-driven approach. Metadata constructs, called templates, provide an understanding of the fea-tures used to deliver reliable and scal-able cloud deployments and achieve better interconnection between vir-tual and physical infrastructures.
The Distributed Management Task Force (DMTF) uses templates to manage cloud resources of various types and support the cloud service life cycle by, for instance, describ-ing how a cloud offerdescrib-ing is presented and consumed.4 The service offering is abstracted from the specific type of cloud resources offered, and the provider (or developer) uses service templates to describe in a general form what a cloud service can offer. The provider (or developer) then cus-tomizes the cloud service template to reflect the fact that the application must create a service offering for one or more specific consumers by including such information as which machines, IP address ranges, and storage requirements are necessary.
Experts have suggested that provid-ers employ model-driven approaches to automate the deployment of com-plex IaaS services on cloud infra-structure. For instance, researchers have proposed a virtual appliance model that treats virtual images as building blocks for IaaS compos-ite solutions.5 Virtual appliances are composed into a virtual solu-tion model which then helps devel-opers determine deployment-time requirements in a cloud-independent manner using a parameterized deployment plan. Similarly, other research describes a solution-based provisioning mechanism using composite appliances to auto-mate the deployment of complex
application services on a cloud infrastructure.6
The aforementioned approaches concentrate mainly on IaaS cloud services. In addition, templates cap-ture static information while being notoriously hard to combine with other compatible templates to render composite offerings.
The blueprint model solution that we describe next, takes into account and furthers such considerations to address cloud solutions that intermix SaaS-, PaaS-, and IaaS-layer service offerings.
The Blueprint Model
Vendor lock-in is viewed as one potential drawback to cloud com-puting. Analysts recently conducted studies that reveal that vendor lock-in and immature cloud lock- interoperabil-ity standards surpass even securinteroperabil-ity concerns as the biggest objection to moving to the cloud.7 Seen from the perspective of developing new SaaS (or BPaaS)-style applications, this means that if a client (or devel-oper) leases an SaaS application — for example, order management or tax and tariff administration — the client receives a monolithic SaaS stack with little ability to change or customize the application with-out the original provider interven-ing. The provider uses its own PaaS/ IaaS functionality, or relies on third-party offerings, which are opaque to the client, who has absolutely no control over the PaaS/IaaS offerings that underlie the SaaS application.
The only way to address this seri-ous limitation is to break the cloud monolith and let a client (or devel-oper) who leases an SaaS applica-tion freely choose and intermix the lowest-cost and best quality PaaS/ IaaS-layer offerings (which different providers might supply) to service it. This approach, which we refer to as cloud blueprinting, converts all cloud-stack layers into general- purpose commodities to attract
partners and build a true cloud ecosystem.
Cloud blueprinting promotes autonomous services (at all levels of the cloud stack) and lets clients or developers combine or swap any ser-vice at any layer with a serser-vice at the same layer without having to stop and modify components elsewhere in the stack. Such considerations lead to the syndicated, multichannel cloud delivery model illustrated in Figure 1, where we contrast it with the monolithic cloud-stack solutions that permeate the cloud today. The monolithic solutions enforce one-way vertical deployment “channels.” Blueprinting is a novel, power-ful solution that lets BPaaS (or SaaS) applications dynamically run on fully virtualized clouds. It abstracts
cloud-stack components to provide a simplified method for provision-ing and automatprovision-ing cloud services. It also correlates application-level deci-sions regarding virtualized end-to-end SaaS services (the BPaaS layer in Figure 1) in a top-down fashion and uses them to drive resource provi-sioning. These decisions can also help adjust the workload and traffic to auto-mate the dynamic configuration and deployment of application instances onto available cloud resources.
Blueprinting promotes service virtualization — by accommodat-ing a service-oriented-architecture (SOA)-enabled approach — and inde-pendent layering for all cloud-stack layers. It also achieves interoperabil-ity by exercising a finer level of con-trol over cloud services.
To realize the blueprint model, we must interlace several interrelated components:
• a declarative blueprint definition language (BDL), which provides the necessary abstraction con-structs to describe cloud services’ operational, performance, and capacity requirements;
• a blueprint constraint language (BCL), which specifies explicitly stated rules that prescribe any aspect of cloud service including policies, performance, and capac-ity requirements; and
• a blueprint manipulation lan-guage (BML), which provides a set of operators for manipulat-ing, comparmanipulat-ing, and achieving mappings between blueprints Figure 1. Conventional vs. syndicated multichannel cloud delivery model. The conventional, monolithic cloud solutions enforce one-way vertical deployment “channels.”
Cloud service applications
Infrastructure as a service (IaaS) • Virtualized servers
• Storage • Networking
Platform as a service (PaaS) • Middleware—application servers • Process automation middleware • Database servers
• Enterprise portal servers, and so on. Software as a service (SaaS) • Applications (ERP, SCM, CRM) • Processes • Information Client 2 Client n Virtualized applications comprising end-to-end processes (BPaaS layer) Client 1
Client 1 Client 2 Client 3 Client n
SaaS 1 SaaS 2 SaaS 3 SaaS n
PaaS 1 PaaS 2 PaaS 3 PaaS n
IaaS 1 IaaS 2 IaaS 3
Application (a) (b)
...
...
...
...
defined in BDL. This item also includes a simple blueprint query language for querying blueprint collections.
Let’s briefly examine these three ele-ments of the blueprint model.
The Blueprint Definition Language
To understand blueprinting, con-sider an external developer (for instance, a virtual service operator or provider) that offers mashup solu-tions bundling together different types of interactive SaaS telecom-munications services (wireless home broadband and multichannel video programming services, including video-on-demand) and enterprise-grade backend services (rating and broadband billing for cable TV or fixed broadband services, bill-ing processes, invoicbill-ing, accounts receivable, and so on). The developer implements the turnkey service solu-tions (BPaaS), which might involve services from multiple providers, in an end-to-end fashion.
Service providers publish their offerings — in this case, video-on- demand or interactive TV/open cable applications — using a blue-print model specified in BDL for a tele communications marketplace. Developers, such as a virtual service provider, can then choose offerings and compose, extend, and customize this blueprint model to develop full-featured service-based applications.
A blueprint model defined in BDL is based on a clear separation of service processing concerns and is minimally distilled in the following interrelated templates:
• Operational service description contains the functional charac-teristics of a service, such as ser-vice types, messages, interfaces and operations.
• Performance-oriented service
capabilities include quantifiable
key performance indicators (KPIs) associated with services. Typi-cal examples are response-time ranges, throughput, deliver y, latency, bandwidth, mean time between failure, mean time to restore service, and so on.
• Resource utilization describes the physical infrastructure and resources required to run a spe-cific service. In general, this template expresses the workload profile, including average and peak workload requirements. For instance, a service provider might declare specific technical features that it must take into account for its service to operate properly, such as the server (disk I/O and network) bandwidth required for true on-demand delivery of streaming media. This template can express information pack-aged using the DMFT’s Open Vir-tualization Format (OVF).4
• The policies template prescribes, limits, or specifies any aspect of a business agreement necessary to use a particular service, and includes security, privacy, and compliance requirements.
Information contained in these templates must be cross-correlated to deliver sound cloud application solu-tions on the basis of the blueprinting approach.
The Blueprint Constraint Language
BCL refines and expresses formally diverse types of policies, such as service-level agreement (SLA) and deployment terms, data residency, auditing, and security constraints, which the BDL policy template cap-tures. It is the set of constraints on which the consumer or developer and provider agree that will gov-ern how the provider’s services will act.
The BCL is based on a formal foundation to facilitate reasoning
and verification by ensuring that services comply with regulations and rules that demarcate their oper-ational behavior. For this purpose, we can use linear temporal logic as the formal foundation of BCL and associated compliance patterns.8 This enables the automated detection of compliance violations and pro-vides compliance support for cloud configurations.
BCL could, for instance, express that interactive telecommunications services involve high-traffic spikes that require automatic provisioning of service instances to accommodate seasonal peaks in demand. Com-bining information from the policy and resource utilization templates results in a cloud application claiming resources in advance to accommo-date such high-traffic spikes. Similar concerns are addressed elsewhere.9
The Blueprint
Manipulation Language
The blueprint model exposes its information in a manner that facili-tates comparison and the simple composition of blueprints to express end-to-end offerings from various providers. BML is based on model-management algebraic operators, such as match, merge, compose, extract, delete, and so on. These operators accept source blueprint templates as input and return a new blueprint tem-plate as result.
To exemplify BML’s use, consider using the merging operator on four blueprints describing high-definition IPTV, video on demand, broadband Internet, and voice-over-IP services to create an end-to-end triple-play service. This operator will yield a target blueprint model that aggre-gates all four blueprint models by defining mappings between them. The operator will ascertain that it can match the four models to each other and that the target blueprint model doesn’t violate constraints or capacity requirements.
Supporting the
Cloud-Service Life Cycle
Cloud services are available via a cloud marketplace, an efficient online platform that manages ser-vice distribution and bid manage-ment, in which providers store their offerings and clients can discover and deploy third-party cloud appli-cations that they can integrate with their own. The concept is similar to that of the Google Apps Marketplace. To understand how the cloud blue-print model facilitates this process, consider Figure 2.
After a provider (or developer) has created all the components of
a discrete service, it uses BDL to describe all its relevant aspects in a structure called a source blueprint, which it stores in the marketplace. The provider or developer also cus-tomizes the source blueprint tem-plates to create a service offering for different types of consumers. Each such offering is accompanied by an SLA to delimit the range of service instances defined in the offering. This happens during the blueprint model’s design phase.
Now consider a virtual ser-vice operator who wishes to bundle together several interactive telecom-munications services to produce a
turnkey application. This developer must first discover these discrete services’ source blueprint models. This happens during the selection phase Figure 2 shows. Subsequently, the developer creates an interim
tar-get blueprint model by combining
the set of source blueprint models it selected. For this purpose, it uses the BML operators. At this point, the interim blueprint model generates a deployment plan, which might drive PaaS resources and determine virtual machine placement and network con-figuration. The developer could, for instance, choose to deploy different PaaS options to address customization Figure 2. Blueprint support for the cloud service life cycle. We can see how the elements of the blueprint model (the blueprint definition language, blueprint constraint language, and blueprint manipulation language), the marketplace repository, and blueprint templates are connected and work in tandem to address application needs.
Application developer End user Service provider AD AD SP Customized source blueprints Source blueprint model Customized source blueprints Blueprint query engine Blueprint manipulation language + Source blueprint models Interim target blueprint model Deployment plans and configuration options Testing and monitoring Cloud resources Optimized target blueprint model SP SP SP Blueprint definition language Blueprint definition language Blueprint definition language User User AD User Design Design Selection Marketplace repository
...
...
...
requirements. The application might deliver the same content over diverse devices, such as TVs, PCs, and smart phones, and provide discounts to cer-tain customers during low network-utilization periods. PaaS services for this type of application could involve workflow facilities, event-processing functionality, deployment, and host-ing. As usual, not all these services must come from the same third-party PaaS provider.
The deployment plan matches the service-based application’s demands, addresses scalability estimates, and, in general, tries to optimize the service assembly’s performance according to quality-of-service requirements in the interim target blueprint model. This helps to provision resources and adjust the workload and traf-fic during the deployment phase. It also provides upstream and down-stream alternatives to automate the dynamic configuration and deploy-ment of application instances onto available cloud resources.
Finally, during the testing and monitoring phase, the developer gradually refines the abstract infor-mation contained in the interim tar-get blueprint to reach the level of rigor and concreteness required for a production-ready cloud applica-tion. This results in an optimized
target blueprint model describing the
integrated application. The developer then publishes this blueprint model in the marketplace repository for potential clients to discover and use.
O
ne of the greatest challenges fac-ing longer-term adoption of cloud computing is the ability to automati-cally provision services, effectively manage work load segmentation and portability (that is, the seam-less movement of workloads across many platforms and clouds), and manage virtual service instances, all while optimizing the use of cloud resources and acceleratingthe deployment of new services. Within such a cloud environment, it’s also important to equip develop-ers with a unified approach that lets them develop cloud applications on top of existing applications at any layer of the cloud stack from multiple cloud providers. The cloud blueprint-ing approach we present here greatly helps cloud application developers deal with such challenges.
Acknowledgments
We’re grateful to Luis M. Vaquero of HP Labs for his valuable comments and suggestions. The research leading to these results has received partial funding from the European Community’s 7th Framework Program under the Integrated Project 4CaaST, grant agree-ment number 258862.
References
1. S. Olivier and J. Prins, “Scalable Dynamic Load Balancing using UPC,” Proc. 37th
Int’l Conf. Parallel Processing, IEEE CS
Press, 2008, pp. 23–131.
2. L. Rodero-Merino et al., “From Infra-structure Delivery to Service Manage-ment in Clouds,” Future Generation
Computer Systems, vol. 26, Oct. 2010,
pp. 226–1240.
3. H. Wu and B. Kemme, “A Unified Frame-work for Load Distribution and Fault- Tolerance of Application Servers,” Proc.
15th Int’l Euro-Par Conf. Parallel Process-ing, Springer, 2009, pp. 178–190.
4. “Interoperable Clouds,” white paper CIM version 1.0, document DSP-IS010, Dis-tributed Management Task Force, Nov. 2009; www.dmtf.org/standards/cloud. 5. A.V. Konstantinou et al., “An
Architec-ture for Virtual Solution Composition and Deployment in Infrastructure Clouds,”
Proc. 3rd Int’l Workshop Virtualization Technologies in Distributed Computing,
ACM Press, 2009, pp. 9–18.
6. T.C. Chieu et al., “Solution-Based Deploy-ment of Complex Application Services on a Cloud,” Int’l Conf. Service Operations
and Logistics and Informatics, IEEE CS
Press, 2010, pp. 282–287.
7. D. Chakraborti, “Cloud Computing Sce-narios: 2010 and Beyond,” Information
Week, 28 June 2010;
www.information-week.in/Cloud_Computing/10-06-28/ Cloud_computing_scenarios_2010_and_ beyond.aspx.
8. A. Elgammal et al., “Root-Cause Analysis of Design-Time Compliance Violations on the Basis of Property Patterns,” Proc. 8th
Int’l Conf. Service-Oriented Computing,
vol. 6470, Springer, 2010, pp. 17–31. 9. D. Moran, L.M. Vaquero, and F. Galan,
“Elastically Ruling the Cloud: Specify-ing Application’s Behavior in Federated Clouds,” Proc. 4th IEEE Int’l Conf. Cloud
Computing, IEEE CS Press, 2011, pp. 89–96. Michael P. Papazoglou is the chair of the Com-puter Science Department at Tilburg Uni-versity, and the scientific director of the European Research Institute in Service Science and the EC’s Network of Excel-lence in Services, S-Cube. His research interests include service-oriented com-puting, cloud comcom-puting, distributed computing, business process manage-ment, and large-scale data sharing. Papazoglou has a PhD in microcomputer systems engineering from the University of Dundee, Scotland. He’s a Golden Core Member and a Distinguished Visitor of the IEEE Computer Society. Contact him at [email protected].
Willem-Jan van den Heuvel is a full profes-sor in computer science at the Department of Information Systems, Tilburg Univer-sity, managing director of the European Research Institute in Service Science, and program director of the Erasmus Mundus Joint-Degree Master Program on Service Science. His main research interests revolve around (cloud) service engineering, performance analytics of software-enabled service networks, and business transaction management. Van den Heuvel is author of Aligning Modern
Busi-ness Applications and Legacy Systems: A Component-Based Perspective (MIT
Press, 2007). Contact him at wjheuvel@ uvt.nl.
Selected CS articles and columns are also available for free at http:// ComputingNow.computer.org.
