cloud service provider blueprint en

8/6/2019 Cloud Service Provider Blueprint En

1/22

2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited

CLOUD SERVICE PROVIDERBLUEPRINT

A Service Providers Blueprint for

Managing Cloud Services

November 2010


2/22


Cloud Services Provider Blueprint

The Cloud Services Opportunity ................................................................................1

The Unique Requirements of Delivering Cloud Services ...........................................1

Tens of Thousands of Components .......................................................................1

Relationships Between Components .................................................................... 3

Heterogeneous Technologies Involved ..................................................................3

Local or Remote/Syndicated .................................................................................3

Traditional Delivery Platforms ................................................................................ 3

Self Service ............................................................................................................3

Storefronts .............................................................................................................4

Business Models ....................................................................................................4

An Integrated, Protable Cloud Service Delivery Platform ........................................4

The Big Picture .......................................................................................................4

Infrastructure Management ....................................................................................6

Provisioning & Orchestration and Billing Automation ............................................7

Customer Self-Service ...........................................................................................9Integration into Front- and Back-Ofce Systems .................................................11

Services Integration ..............................................................................................12

Storefront and Marketplace .................................................................................13

Conclusion The Detailed Picture ...........................................................................15

Appendix A: Components Required for Shared Web Hosting ................................17

Appendix B: Components Required for Messaging and Collaboration ..................19

Table of Contents

ii


3/22


1


The Cloud Services OpportunityThere can be no doubt that Cloud computing has arrived and will dene the IT

landscape for at least the next decade. According to IDC1, spending on public IT Cloud

offerings in 2014 will be almost one-third of the net new growth in IT spending. Andaccording to a recent survey by Gartner2, 10% of IT spending on external services

already comes from Cloud providers, and roughly half of the respondents indicated their

budgets for Cloud services are growing next year. The future demand for Cloud services

is all but ensured by exponential growth of data volume (60%-70% per year, according

to recent data from research rm Telegeography3), together with an increasing appetite

for computing power to process that data.

This growth in demand has led to an increase in the number and types of Cloud services

providers. Amazon is seeing signicant competition emerge from the likes of Microsoft,

Rackspace, and Verizon. In fact, nearly all telecommunications providers, as well as

large value-added resellers and distributors, have Cloud services strategies under way.

Additionally, traditional software vendors are moving to Cloud delivery models orSoftware-as-a-Service (SaaS), led by the likes of Salesforce.com and Intuit Quickbooks.

So how can current and future providers of Cloud services best prot from this industry-

wide shift? What are the key capabilities service providers need from their Cloud

service delivery platform? What does the coming of the Cloud mean for traditional

vertical service delivery platforms? And how can providers enhance the protability of

their Cloud services offerings? These are the topics explored in this document.

What are the key

capabilities service

providers need rom

their Cloud service

delivery platorm?

How can providersenhance the

proftability o their

Cloud services

oerings?

1 http://blogs.idc.com/ie/?p=92222 http://www.gartner.com/it/page.jsp?id=14388133 http://www.ptc.org/ptc09/images/papers/PTC09_TeleGeography_Slides.pdf

The Unique Requirements of Delivering Cloud ServicesWhile this paper focuses on the key capabilities service providers need to successfully

deliver Cloud services, it is worth noting that there are some foundational requirements,

such as reliability and scalability, that are common to all large-scale automation systems.For the purposes of this paper, these capabilities are considered as a given and are

therefore not specically addressed. Additionally, from a business model perspective,

the Cloud service providers with the highest margins, highest ARPU, lowest operating

costs, and lowest churn will have a signicant competitive advantage in the long run. To

achieve this advantage, they will need a comprehensive Cloud service delivery

platformand the cost of developing such a platform is a factor they will need to take

into account.

Tens of Thousands of ComponentsTraditional vertical service delivery platforms are typically built to deliver one or a few

types of service only, such as TV, phone, or Internet access. Adding another service

might require deployment and integration of yet another service delivery platform,

leading to long wait times from inception to implementation and complicating

provisioning and de-provisioningespecially when mixing and matching platforms with

different architectures, from different vendors.

Even relatively simple, highly available services from the Cloud, such as shared Web

hosting or business-class e-mail, have to be much more exible to provide the complete

experience users now expect. When users order Web hosting for example, they expect

that a myriad of additional services such as DNS service, Web access statistics, backup,

and so forth, will be included. A business-class e-mail service requires anti-spam,

From a business

model perspective,

the Cloud service

providers with the

highest margins,

highest ARPU,

lowest operating

costs, and lowest

churn will have

a signifcantcompetitive

advantage in the

long run.


4/22


2


anti-virus, archiving, and Web-access functionalityand the exibility and

completeness of such service offerings often determine their protability, as well as

helping service providers to differentiate themselves from the competition.

A good example of this complexity is shared Web hosting, one of the rst and mostcommon Cloud services. Literally thousands of components may be required to deliver

this one service. For example, a service provider has to integrate and accommodate

such diverse elements as:

Domain management

Web host management

Public IP management

Disk space (total usage for all sites)

Trafc (total usage for all sites)

CMS and site tuning

FTP access

Backups management(For a full list, see Appendix A.)

For another example of the complexity of offering Cloud services, look at one of the

fastest-growing categories: messaging and collaboration. Services such as e-mail,

messaging, Web conferencing, and VoIP, much like shared Web hosting, can require

hundredsor even thousandsof components to be managed. For example, typical

Cloud-based messaging and collaboration services require components such as:

Hosted Exchange

o Mailboxes

o Public folders

o Resource mailboxes (rooms, equipment)

o Distribution listso Contacts

SharePoint Sites

o SharePoint users

o SharePoint storage quota

o Sites in shared Web applications

o Exclusive Web applications

Hosted OCS

o OCS user proles

Hosted PBX

o Maximum number of simultaneous calls

o Conference bridges

o Conference bridge ports

o Schedules

o Caller groups

Additional Syndicated Services:

o MessageLabs e-mail security

o MXLogic

o Postini e-mail security

o Global Relay e-mail archiving

(For a full list, see Appendix B.)

Services such as

e-mail, messaging,

Web conerencing,

and VoIP, much like

shared Web hosting,

can require hundreds

or even thousands

o components to

be managed.


5/22


3


As we have seen, even relatively common Cloud services involve provisioning of

dozens of components, which might be dependent both on each other and on

external systems.

A complete Cloud service delivery system that satises users requirements and helpsservice providers make money must be able to provision, manage, and support

thousandsor even tens of thousandsof these components.

Relationships Between ComponentsA Cloud service delivery platform must be able to design relationships between the

tens of thousands of components involved in delivering Cloud services in order to

create multiple options within service plans, as well as critical dependencies,

commercial terms, and billing optionsincluding over-usage policies. The complexity

of the relationships possible between components is signicantly greater than what is

presently found among traditional telecommunication services.

Heterogeneous Technologies InvolvedOne of the promises of the Cloud is universal access. End users expect to be able touse a desktop, laptop, tablet, or mobile device to access the services they need. The

ability to provide service, regardless of the underlying platform, is critical for end-user

satisfaction. Therefore, a complete Cloud service delivery platform must be able to

work with a multitude of operating systems, databases, and application servers that

power provisioned services and their individual components; be able to mix and

match them efciently to provide bestof-breed service offerings; and be able to easily

replace one component with another if the need arises. (For example, service

providers must be able to easily switch between third-party independent software

vendors who supply one of their enabled services.) This complexity requires Cloud

service delivery platforms to be able to handle the widest range of diverse

components.

Local or Remote/SyndicatedTraditional vertical service delivery solutions are typically designed to solely provision

services located on a providers premises. However, many services today are hosted

on third-party vendors sites or in the Cloud. Consequently, a complete Cloud service

delivery platform must be able to provision, congure, and manage such remote or

syndicated services in conjunction with their on-premise services. For example, a

service provider may want to combine an onsite Hosted Exchange deployment with

offsite e-mail archiving from a third party.

Traditional Delivery Platforms

Because of increased complexity and the need to rapidly develop and roll out newservices, traditional vertical service delivery platforms will have a hard time adopting to

Cloud requirements. But even if they can deploy enough side-by-side vertical

platforms to be able to provision the full spectrum of services, a seamless user

experience requires good integration between services, which is extremely hard to

achieve with multiple vertical stacks not meant to work together.

Self ServiceCloud services require a higher degree of end-user self-service capabilities than

traditional telecommunication or IT services, and Cloud service delivery platforms

A Cloud service

delivery platorm

must be able to

design relationships

between the tens

o thousands o

components involve

in delivering Cloud

services, in order to

create multiple optiowithin service plans,

as well as critical

dependencies,

commercial terms,

and billing options

including over-usage

policies.

Cloud services requ

a higher degree o

end-user sel-servic

capabilities than

traditional

telecommunication

or IT services, andCloud service delive

platorms need to ta

this need into accou


6/22


4


need to take this need into account. Self service is an integral part of the overall

delivery systemespecially in view of the high volume of new Cloud services that are

rapidly being made available to end users.

StorefrontsThe online storefront and underlying shopping cart and product catalog for Cloud

services need to be able to handle the tens of thousands of components dened

above. This makes such a storefront and shopping cart much more complicated than

traditional ones used by companies selling widgets, as they need to be able to handle

the relationships and dependencies between all the components. Much like self

service, this requirement is another integral part of the overall Cloud service delivery

platform.

Traditional service delivery platforms have one product catalog in the ordering system,

another in the provisioning system, and another in the billing systemplus a

stand-alone shopping cart application. Because of the large number of components

involved in delivering Cloud services, service providers either need a mechanism for

tight integration across catalogs or, preferably, a single catalog across all systems.

Having multiple product catalogs has always been difcult for telecommunication

service providers, who must maintain up to a dozen catalogs in different systems.

Without a well-designed Cloud service delivery platform, Cloud services will simply

take this mess to the next level.

Business ModelsBecause of the scale of any reasonably sized Cloud service provider, the back end

of its underlying service delivery platform has to be highly automated, eliminating the

need for manual intervention in processing, provisioning, and managing the Cloud

services. Automation is needed not only to support the need for an extremely high

degree of self service, as described above, but also to maintain margins and

protability. For example, a $10 per month service simply cannot afford any manual

operationsor even a single support ticket.

An Integrated, Protable Cloud Service Delivery PlatformTo more easily explain the characteristics of a complete service delivery platform,

Parallelsbased on its experience working with hundreds of the worlds leading

Cloud service providershas developed a blueprint of an ideal Cloud service delivery

platform. This blueprint can serve as a guide to the capabilities required to deliver

Cloud services efciently, protably, and with a seamless user experience.

The Big PictureWe can start by making the obvious assumption that Cloud services require

fundamental connectivity infrastructure services. These include data center space,

power, servers, networking gear, and an Internet connectionor, as some call it,

power, pipe, and ping. Service providers dont necessarily need to own these

resources, but they do need to have access to themfor example, by leasing them

from wholesale infrastructure providers.

On top of these fundamental connectivity infrastructure services sits a range of

capabilities and functions needed to operate a public Cloud, as shown in Figure 1.

Because o the

large number o

components involved

in delivering Cloud

services, service

providers either need

a mechanism or tigh

integration across

catalogs or, preerably

a single catalog acrosall systems.

Because o the scale

o any reasonablysized Cloud service

provider, the back end

o its underlying

service delivery

platorm has to be

highly automated,

eliminating the need

or manual interventio

in processing,

provisioning, and

managing the Cloud

services.


7/22


5


Figure 1. An overview of the management capabilities and functions needed to operate a public Cloud.

This paper will expand on the composition of each of these blocks individually. First, however, to grasp the big picture,

its helpful to see how they all t together, in order. What the gure illustrates is that the infrastructure, both physical and

virtual, needs to be managed. On top of that, services need to be dened, managed, provisioned, and billed. On top of

these services, its essential to include a layer that gives customers visibility into their subscription services and lets them

self-administer basic functions, so theyll have less need to call the support center. As pointed out above, this

self-service capability is critical to protability, especially for large-scale public Cloud offerings.

The gure also illustrates that these core elements do not live in a vacuum. They need points of integration with all

critical front- and back-ofce systems. Additional points of integration are needed to provide customers with a storefront

and shopping cartor, as it is more recently called, a services marketplace. When all of these elements are put in place

with a high degree of automation, they enable providers to offer public Cloud services protably.

Now lets look at each layer in the stack, starting at the bottom.


8/22


6


Infrastructure ManagementThe last few years have created extensive awareness among enterprises about the benets of virtualization and efcient

infrastructure management. This same awareness has generated a great deal of interest in transforming enterprise IT

resources into private Clouds. However, there is a big difference between managing enterprise infrastructure as a private

Cloud and leveraging IT assets to offer commercially available, public Cloud services. Both Clouds need to manage the

infrastructure required to deliver the service, including servers, virtual machines, the IP network, routers, switches, and

storage arrays, among other things, so the core set of capabilities are similar. However, the key capabilities service

providers should bear in mind as they look at the details of public Cloud infrastructure management are shown in

Figure 2.

Figure 2. Key infrastructure management requirements for public Cloud services.

These requirements can be further explained as follows:

Server provisioning: Automatically booting up, rebooting, or shutting down physical servers.

Server management: Pushing updates, patches, and other conguration settings to a single server or a eet

of servers.

Network management: Setting or resetting IP information for a single server or range of

machines, and managing overages in bandwidth utilization.

Storage management: Tools, processes, and policies needed to manage storage networks, including

virtualization, replication, mirroring, and compression.

Virtual environment management: Creating or deleting virtual machines, and moving workloads and data

between virtual machines and physical servers.

Monitoring, alerting, and notications: This function goes hand in hand with security (below), but it refers to the

ongoing series of tests being performed on all aspects of the infrastructure, combined with a notication system

that comes into play when critical thresholds occur.

Security: This subject could occupy one or more books, but for our purposes, sufce it to say that ample

security measures must be present both in the hardware and across the network to secure a public Cloud.

Auditing, reporting, and SLA management: At the end of the day, someone will want to see a report, or a series

of reports, on how the infrastructure is being managed. This is where an auditing and reporting feature set is

vital. Assuming providers offer their customers some sort of performance guarantee in the form of a service level

agreement (SLA), this same system will determine if and when SLA violations have occurred.


9/22


7


Summary: How is infrastructure management different in the Cloud?

Cloud infrastructure management needs to be highly automated to be able to scale up and down rapidly. For

example, a service provider offering virtual private servers and Cloud hosting may have hundreds or thousands of

servers in production. Each time a security patch or a network update needs to be installed, it could take dozens

of man hours without automated systems.

In addition, to ensure maximum scalability, elasticity, and availability of services, the key infrastructure building

blocks (servers, virtual environments, etc.) need to be standardized for usage efciency when deployed in large

numbers, and for ease of replacement in the case of failure.

Provisioning and Orchestration and Billing AutomationTwo intertwined functional elements that stack on top of infrastructure management

are (1) provisioning and orchestration and (2) billing automation. These functionsenable providers to manage and commercialize raw infrastructure resources. While

they could be addressed individually, it makes more sense to address them jointly,

since they operate in harmony. As new services are dened, created, and ultimately

purchased or subscribed to, they need to be priced, bundled, and billed. Figure 3

illustrates the components of these two functions.

Key components of provisioning, orchestration, and billing automation consist of:

Resource provisioning: When a service is ordered, the relevant resources

including those at the physical, virtual, and application levelsneed to be

appropriately provisioned.

Resource management: Before, during, and after service delivery, the

resources being used to deliver that service must be managed appropriately.

Service monitoring, alerting, and notications: Similar to the monitoring and

alerting capability in the infrastructure management layer, an additional level of

monitoring and alerting needs to be in place for the services themselves.

Service component denition and management: Each particular service will

have dozens, if not hundreds, of unique components that need to be dened

to make up that service.

Application and service management: The application or service itself needs

to be managed and maintained. This function can include things like

auto-rebooting or dynamically assigning more resources to enable theapplication to function as intended.

Reporting: Reporting straddles the fence between the two feature sets, since

reports are generated from both an operational and billing standpoint. They

can include usage reports, availability reports, and accounting reports, to

name but a few.

Two intertwined

unctional element

that stack on top o

inrastructuremanagement are

(1) provisioning and

orchestration and

(2) billing automatio


10/22


8


Figure 3. How provisioning, orchestration and billing automation work in Cloud services

Multi-tiered reseller support: This function also straddles the fence, as the provisioning side of the house needs

to be able to support a multi-tiered reseller channel, and bills need to be hierarchically categorized by reseller,

master reseller, and so on.

Payment processing and taxation: A credit card must be processed through a payment gateway and merchant

account, and the correct country-level taxes must be applied.

Fraud prevention: Standard identity-theft prevention mechanisms must be in place to prevent fraud.

Renewals and notications: This requirement applies both to the customers service subscription and to the

method of payment. When subscriptions or credit cards are about to expire, the system should automatically

notify customers and prompt them to update their billing information or renew their service plan. Order processing and workow: When an order is placed, it needs to trigger a series of workow events

including provisioning the appropriate resources and servicesthat ultimately result in fulllment of the order.

Rating: The services being used need to be measured against the payment plans and commercial terms


11/22


9


Summary: How is provisioning/orchestration and billing automation different in the Cloud?

In addition to needing to account for scalability and elasticity, as mentioned in the previous section, there is a

growing need to be able to aggregate syndicated services services that are not managed directly by the

service provider, but are bundled into a subscription plan and billed. Another difference unique to Cloud services

is the focus on usage-based billing.

For example, a provider with IaaS offerings needs to be able to monitor, meter, and bill for computing resources

used by the hour or by the CPU. The same provider might need to provision and bill SaaS offerings on a

per-seat or monthly recurring basis, while also allowing up-sell and cross-sell of additional services, such as more

storage space. All these possibilities require a highly exible billing structure.

Billing: The services need to be billed based on the relevant usage metrics. In

the Cloud environment, its important to be able to bill not just by period, but

by CPU, hour, or other usage metrics.

Product catalog management: A product catalog is always changing, withnew services, offerings, and bundlesplus, in the Cloud environment, it may

have to encompass third-party applications and syndicated services.

Marketing and promotions: The billing system needs to be able to

accommodate special offers, discount codes, promotional codes, and

coupons.

Customer Self-ServiceTo manage and operate protable public Cloud services, providers not only need to

tightly integrate the Cloud service with their customer relationship management (CRM)

system, but must also provide customers with visibility into and control over their

services. This is typically done through a control panel.

As shown in Figure 4, customer self-service control panels typically include:

Addition, modication, or removal of services: Customers should be able to

modify their services at any time through the control panel, whether the change

involves adding new services, suspending or terminating services, or updating

existing services.

Application conguration management:

Administrators at the customers site need to be able to congure their

companys applications and servicesfor example, to integrate domain names,

specify e-mail box sizes, congure SSL certicates, and manage other security

elements.

A product catalog is

always changing,

with new services,

oerings, and

bundlesplus, in the

Cloud environment,

it may have to

encompass third-

party applications an

syndicated services.

To manage and oper

proftable public Clo

services, providers n

only need to tightly

integrate the Cloud

service with their

customer relationshi

management (CRM)

system, but must als

provide customers

with visibility into an

control over their

services.


12/22


10


Figure 4. Key capabilities in customer self-service control panels.

Support: Control panels typically enable customers to get supportthrough

an FAQ section, an e-mail ticket system, and/or live chat with a representative.

N-tiered customer and channel management: Some customers may in fact

be resellers, with customers of their own potentially including other resellers.

The control panel needs to give such master resellers a view into the health of

their business, as well as the ability to assess the relative success of the

resellers underneath them.

Addition or deletion of users and passwords: Administrators at the

customers site will use the control panel to create new user accounts, delete

old accounts, and change passwords.

Management of account and preferences: The most important feature here

is enabling customers to manage their billing information and address, as a

credit card may update or an address may change. Depending on the nature

of the services and applications being managed, the customer may want to

congure personal preferences as well, such as changing a password.

Reports: The control panel should enable customers to extract a range of

reports from the systemfrom usage data to nancial data.

Some customers

may in act be

resellers, with

customers o their

ownpotentiallyincluding other

resellers.

Summary: How is customer self-service different in the Cloud?

Customer self-service is critical for public Cloud services in order to keep support and operational costs downplus, if approached correctly, it can be a way to cross-sell and up-sell additional services. In addition, Cloud services

customers generally expect to have Web-based management tools: they would typically rather do it themselves

than call a support number.

For example, a service provider offering messaging and collaboration applications needs to allow customers the

ability to add new users automatically, without requiring them to call a contact center and request additional

licenses.


13/22


11


Integration into Front- and Back-Ofce SystemsService providers already have numerous front- and back-ofce

systems and platforms that are vital to their day-to-day operations.

The specics will depend on the type of service provider, but no

matter what, the layers of Cloud management described above need

to be integrated into providers existing front- and back-ofce

systems, as shown in Figure 5. This can be done in two primary ways:

Through custom integration: This is the traditional

approach. It is costly to perform and costly to maintain, but

sometimes it is the only optionespecially if some of the

front-and back-ofce systems are proprietary.

Through application programming interfaces (APIs): More

and more applications are being written with open API

architectures that allow other systems to hook into them,

making machine-to-machine communication possible. APIintegration is almost always faster and less expensive than

custom integration.

Although specic front- and back-ofce systems will vary from one

service provider to the next, key systems that will almost always need

to be integrated into Cloud services management include:

Help desk: Also known as a trouble-ticketing program, help

desk software is the core system used by technical support

staff and should be tightly integrated into the customer self-

service layer.

CRM:A customer relationship management system, used to

manage customer relationships and sales opportunities, is

typically integrated into the providers accounting systems

and it should be integrated into the provisioning and billing

layers of Cloud management, as well.

Identity management: Different systems or platforms often

require their own means of user identication for security

purposes. To avoid administrative headaches, a service

provider may implement an identity management system that

federates an individuals secure ID credentials across multiple

systems.

Business intelligence:Also known as business analytics, thissystem crunches nancial and operational data and looks for

critical trends that can help shape the business.

Finance/ERP: A nance or enterprise resource planning

system handles accounting and supply-chain issues. While all

companies have nancial systems that will need to be

integrated into the Cloud services billing layer, ERP systems

are usually found in very large enterprises, like telecoms or

global distributors.

Figure 5. Systems integration into front

and back ofce.


14/22


12


Summary: How is systems integration different in the Cloud?

The pervasive use of APIs within Cloud systems simplies integration and helps keep costs under control, even

though custom integration may still be needed at times.

For example, a telco that wants to start offering a syndicated Cloud service will need to make sure the service is

integrated into its into its CRM system for customer support and into its nance system for accounting purposes.

Custom integration into all these systems would likely cost tens of thousands of dollars and take months.

Leveraging published APIs makes such an integrationproject cost signicantly less and enables the project to be

nished in weeks, not months.

Services IntegrationOn the other side of our Cloud management blueprint sit the actual services being

offeredbut before we address the services themselves, lets look at the integration

required to deliver the services. Just as front-and back-ofce systems need a layer of

integration to make them work with Cloud-based services, the services themselves

need a layer that integrates them with the various management layers.

As shown in Figure 6, key integration elements include:

Application and service resources: Providers need to identify the specic

resources required for each application and/or service (i.e. hard disk space,

available bandwidth) and make sure they are provisioned and deployed

appropriately relative to what the customer is purchasing.

Patch deployment: Each time an application or service gets updated through

patching, the updates need to be distributed and integrated across all

aspects of managing the application or service.

Application integration: The applications and services need specic integra-

tion mechanisms that hook into other Cloud-based systems, such as billing,

provisioning, and customer self service.

User interface integration: Applications are written in lines of code, but users

need an interface to perform the self-service functionsso each application

and service must have a user interface.

Application licensing: This is a critical factor for commercial success. How

is the application or service licensed? What system or systems issue the

license? Are there multiple licensing types or models? How are licenses

governed or managed? All of these questions need to be addressed for each

application and service.

Application syndication: Syndication refers to the ability to provision and bill

for an application or service whose underlying infrastructure resides with a

third party. Some Cloud services are delivered via a syndication model, so the

integration framework needs to support syndication.

Figure 6. Services integration

into a Cloud services

automation system


15/22


13


Summary: How is services integration different in the Cloud?

The primary difference stems from the added complexity, due to the sheer

number of integration steps required. Service providers are integrating not

one, but many services, with new services introduced frequentlyand rapidly.Further complexity comes from the fact that the services can reside either

within a providers data center or (for syndicated services) in a data center

operated by a third party.

For example, a provider of hosting services currently offers many add-ons to

its core product, including a shopping cart, a blog, and e-newsletter

functionality. Each of these add-ons is actually developed by a third party

and occasionally needs a version update or patch. Without proper services

integration, each third-party application update has the potential to break

the service providers provisioning and billing systems. With proper services

integration, however, third-party application updates have no effect on the

hosted environmentplus the integration enables the provider to deploy new

services very rapidly.

Storefront and MarketplaceFinally, we come to the customer-facing Cloud services. Figure 7 shows the

storefront and marketplace issues that need to be considered for each type of

Cloud service (software, platform, and infrastructure).

Possibilities include:

SaaS

o Web presence: This service consists of basic Web hosting,along with the typical add-ons, such as e-commerce,

e-marketing, and domain registration.

o Messaging and collaboration: This service includes business-

class e-mail and calendaring systems, Web conferencing, VoIP,

and other applications that facilitate communication between

employees, customers, and partners.

o SaaSother: This catch-all bucket includes all SaaS applications

not covered above. These are typically vertical solutionsfor

example, for insurance or health care.

Platform as a Service (PaaS)

o Hosting development environment: This is a turnkey environmentfor application development, typically specic to a single

programming language. Its a complete development environment,

from the underlying infrastructure for hosting the application through

the billing options that developers can use to make money.

Syndication reers to

the ability to provision

and bill or an

application or servicewhose underlying

inrastructure resides

with a third party.

Some Cloud services

are delivered via a

syndication model,

so the integration

ramework needs to

support syndication.

Each time an

application or service

gets updated through

patching, the updates

need to be distributed

and integrated across

all aspects o managing

the application or

service.


16/22


14


o Customized applications: This feature gives businesses the option

to customize hosted applications for their particular needs.

o Developers sandbox: This is a hosted test environment, enabling

developers to work on new features or x bugs without affecting theproduction environment.

IaaS

o VPS hosting: A virtual private server (VPS) is a standalone virtual

environment sold on a subscription basis. It looks and feels like a

server and has the isolation and security benets of a dedicated

server, but is in fact a virtualized instance. VPS hosting has a pre-

dened amount of resources, such as disk space, memory, and

processor speed.

o Cloud hosting: Cloud hosting can be thought of as elastic VPS

hosting, meaning that one can dynamically add or remove resources

and virtual environments as needed.

o Dedicated hosting: Dedicated hosting gives users complete control

over the server. They can administer it either through a command-line

interface or, in many cases, through the control panel interface itself.

Syndicated services: As shown in Figure 7, the syndicated services

component vertically spans all three types of core Cloud services

because providers can offer a syndicated version of each of these

layers. This emerging service delivery model is becoming more

common and will likely become a major force in the Cloud services

ecosystem. There is ultimately no difference to the end customer; the

only difference is that, with syndicated services, a third-party syndicator

manages the underlying infrastructure, which service providersintegrate into their storefront and bundled offerings.

Figure 7. Storefront and

marketplace issues for SaaS,

PaaS, and IaaS Cloud services.

Summary: How are storefronts and marketplaces different in the Cloud?Storefronts and marketplaces in the Cloud must include both services and applicationsand, increasingly, must be

able to manage syndicated third-party services as well as their own.

For example, a hosted e-mail provider wants to start offering anti-spam, anti-virus ,and VoIP services as add-ons

to its core e-mail offering. Each of these services is actually hosted by a third party in a separate facility. Through

services integration, the provider can connect its provisioning and billing systems into each of the third-party data

centers, enabling it to provision new accounts and resources while maintaining control of the bundled offering and

customer billing.


17/22


15


Conclusion The Detailed PictureHaving closely examined all elements that make up the big picture shown in Figure 1, we can now look at a full

blueprint, with all the details, as shown in Figure 8. What we get is an admittedly complex system of management

capabilities and requirements.

Figure 8. A detailed view of the management capabilities and functions needed to protably operate a public Cloud.


18/22


16


To succeed at delivering protable public Cloud services, service providers need to

have a complete Cloud service delivery platform, managing a large number of

interdependent cross-platform components in perfect order. Traditional vertical service

delivery platforms cannot manage such complexity, nor do they typically have enough

internal integration points to provide a seamless experience to both user and service

provider.

Attempts to integrate multiple vertical platforms typically end up as partially connected

stacks of parallel functionality. For example, even if integrated systems can provision

multiple service components at once, de-provisioning usually must be performed

manually in each system. While such an approach might be acceptable for traditional

services (e.g., voice and data services that people keep for extended periods of time),

Cloud services are often consumed on-demand, and with the addition of each new

service component typically requiring reintegration of existing systems, the resulting

service levels would be unacceptable in todays competitive marketplace.

In short, a complete Cloud service delivery platform must be purpose-built for the

Cloud, with the goal of providing the full set of services and a seamless user

experience for the entire service lifecycle, from ordering to consuming to

de-provisioning. Given the innate complexity of Cloud services, this is the only way

to ensure protability.

* * * * *

Parallels enables service providers to rapidly launch and efciently deliver the most

protable Cloud services by automating the delivery of the broadest set of solutions

demanded by small businesses. Founded in 1999, Parallels is a fast-growing company

with 700 employees in North America, Europe, and Asia. For more information,

please visit www.parallels.com/spp/feedback/.

To succeed at

delivering proftable

public Cloud

services, service

providers need to

have a complete

Cloud service

delivery platorm,

managing a large

number o

interdependentcross-platorm

components in

perect order.

A complete Cloud

service deliveryplatorm must be

purpose-built or the

Cloud, with the goal

providing the ull set

o services and a

seamless user

experience or the

entire service liecyc

rom ordering to

consuming to

de-provisioning.


19/22


17


Appendix A: Components Required for Shared Web Hosting

Domain management

o DNS hosting (number of hosted domains)Records management (if customer can change them, or only system does it automatically)

Web hosting

o Parking (number of parked domains)

Frame URL forwarding (number)

Single page hosting (number)

Standard (HTTP 301) forwarding (number)

o Standard Linux Web hosting OR Linux Web hosting NG service (number of hostings

Web spaces)

Web sites (number each hosted domain, or subdomain, or wildcard domain is counted)

IP-based virtual host (number of sites on exclusive IPs allowed)

Name-based virtual host (number of sites on shared IPs allowed)CGI support (if its available or not)

Custom error docs (if its available or not)

Denied IPS conguration (if its available or not)

Handlers conguration (if its available or not)

HotLink protection (if its available or not)

MIME types conguration (if its available or not)

MS FrontPage for Linux (if its available or not [not supported for NG])

PHP4 support (if its available or not)

PHP5 support (if its available or not)

SSH access (if its available or not)

SSI support (if its available or not)SSL support (if its available or not)

WAP support (if its available or not)

Webalizer (if its available or not)

Public IPs (number)

Disk space (KB, total usage for all hostings accounted)

Trafc (KB, total usage for all sites accounted)

Statistics

o Urchin Web statistics (number of sites)

o Awstats Web statistics (number of sites)

CMS and site tuning

o Web site building tool for Linux/UNIX (number of sites)o Logles access (number of sites)

o File manager (number of sites)

Databases

o Postgres SQL (number of databases), PHPPgAdmin is included

o MySQL 4 (number of databases), PHPmyAdmin is included

o MySQL 5 (number of databases)

n

n

n

n

n

n

n

n

n

n

n

n

n

n

n

n

n

n

n

n


20/22


18


FTP Access

o FTP users (number)

o FTP on exclusive IP (number of hostings, not supported for NG)

o Anonymous access (number of hostings, not supported for NG)o FTP on shared IP (number of hostings)

Cron jobs (if its available or not)

o Crontab Manager (number of hostings) scripts to be executed

o Scheduled applications manager (number of hostings) URLs to be accessed

Backups (number of backups)

o Backup disk space (if not pointed backups accounted to common disk space usage)

APS applications

o Number of installations for each application


21/22


19


Appendix B: Components Required for Messaging and Collaboration

Hosted Exchange

o MailboxesActiveSync access

IMAP4 access

POP3 access

Outlook access

Outlook Web access

Voice access

Maximum allowed mailbox size

o Public folders

Maximum allowed public folder size

o Resource mailboxes

o Distribution listso Contacts

o Company disclaimers

o E-mail domains

o BlackBerry messaging

o Good Mobile messaging

SharePoint sites

o SharePoint users

o SharePoint storage quota

o Sites in shared Web applications

o Exclusive Web applications

SSL support for SharePoint sitesExclusive application pools for SharePoint sites

Hosted OCS

o OCS user proles

Instant messaging

IP audio/video

Web conferencing

Hosted PBX

o Maximum number of simultaneous calls

o Conference bridges

o Conference bridge ports

o Scheduleso Caller groups

o Response groups

o Voice mailboxes

o Number of days to retain call records

o Auto-attendant templates

o Phone numbers

n

n

n

n

n

n

n

n

n

n

n

n

n


22/22

2010 Parallels Inc All Rights Reserved Unauthorized Reproduction Prohibited


Additional Services:

o MessageLabs e-mail security

Allow MessageLabs CP login

o MXLogicBasic ML protection for a mailbox

Advanced ML protection for a mailbox

Allow MXLogic CP login

o Postini e-mail security

o Global Relay e-mail archiving

n

n

n

n

cloud service provider blueprint en

Documents