Date post: | 07-Apr-2018 |
Category: |
Documents |
Upload: | horacio-goldenberg |
View: | 233 times |
Download: | 0 times |
of 22
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
8/6/2019 Cloud Service Provider Blueprint En
2/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
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
8/6/2019 Cloud Service Provider Blueprint En
3/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
1
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
4/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
2
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
5/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
3
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
6/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
4
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
7/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
5
Cloud Services Provider Blueprint
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/6/2019 Cloud Service Provider Blueprint En
8/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
6
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
9/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
7
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
10/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
8
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
11/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
9
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
12/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
10
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
13/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
11
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
14/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
12
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
15/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
13
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
16/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
14
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
17/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
15
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
18/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
16
Cloud Services Provider Blueprint
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.
8/6/2019 Cloud Service Provider Blueprint En
19/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
17
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
20/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
18
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
21/22
2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited
19
Cloud Services Provider Blueprint
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
8/6/2019 Cloud Service Provider Blueprint En
22/22
2010 Parallels Inc All Rights Reserved Unauthorized Reproduction Prohibited
Cloud Services Provider Blueprint
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