Cloud Service Provider Blueprint by Curtis Brenneman

CLOUD SERVICE PROVIDER BLUEPRINT A Service Provider’s Blueprint for Managing Cloud Services ®

Cloud Services Provider Blueprint

Table of Contents 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, Profitable Cloud Service Delivery Platform ........................................4 The Big Picture .......................................................................................................4 Infrastructure Management ....................................................................................6 Provisioning & Orchestration and Billing Automation ............................................7 Customer Self-Service ...........................................................................................9 Integration into Front- and Back-Office Systems .................................................11 Services Integration ..............................................................................................12 Storefront and Marketplace ................................................................................. 13 Conclusion â&#x20AC;&#x201C; The Detailed Picture ...........................................................................15 Appendix A: Components Required for Shared Web Hosting ................................17 Appendix B: Components Required for Messaging and Collaboration ..................19

Cloud Services Provider Blueprint

The Cloud Services Opportunity There can be no doubt that Cloud computing has arrived and will define 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. And according 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 firm 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 significant 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 or Software-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 profit from this industrywide 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 profitability of their Cloud services offerings? These are the topics explored in this document.

What are the key capabilities service providers need from their Cloud service delivery platform?

How can providers enhance the profitability of their Cloud services offerings?

The Unique Requirements of Delivering Cloud Services While 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 specifically 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 significant competitive advantage in the long run. To achieve this advantage, they will need a comprehensive Cloud service delivery platform—and the cost of developing such a platform is a factor they will need to take into account.

Tens of Thousands of Components Traditional 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-provisioning—especially when mixing and matching platforms with different architectures, from different vendors.

From a business model perspective, the Cloud service providers with the highest margins, highest ARPU, lowest operating costs, and lowest churn will have a significant competitive advantage in the long run.

Even relatively simple, highly available services from the Cloud, such as shared Web hosting or business-class e-mail, have to be much more flexible 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, ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 1 1 http://blogs.idc.com/ie/?p=9222 2 http://www.gartner.com/it/page.jsp?id=1438813 3 http://www.ptc.org/ptc09/images/papers/PTC’09_TeleGeography_Slides.pdf

Cloud Services Provider Blueprint anti-virus, archiving, and Web-access functionality—and the flexibility and completeness of such service offerings often determine their profitability, 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 first and most common 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) Traffic (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 hundreds—or even thousands—of components to be managed. For example, typical Cloud-based messaging and collaboration services require components such as:

Services such as e-mail, messaging, Web conferencing, and VoIP, much like shared Web hosting, can require hundreds —or even thousands —of components to be managed.

• Hosted Exchange

•

• •

•

o Mailboxes o Public folders o Resource mailboxes (rooms, equipment) o Distribution lists o 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 profiles 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.) ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 2

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 satisfies users’ requirements and helps service providers make money must be able to provision, manage, and support thousands—or even tens of thousands—of these components.

Relationships Between Components A 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 options—including over-usage policies. The complexity of the relationships possible between components is significantly greater than what is presently found among traditional telecommunication services.

Heterogeneous Technologies Involved One of the promises of the Cloud is universal access. End users expect to be able to use 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 efficiently to provide best–of-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.

A 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 options— including over-usage policies.

Local or Remote/Syndicated Traditional vertical service delivery solutions are typically designed to solely provision services located on a provider’s 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, configure, 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 new services, 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.

Cloud services require a higher degree of end-user self-service capabilities than traditional telecommunication or IT services, and Cloud service delivery platforms need to take this need into account.

Self Service Cloud services require a higher degree of end-user self-service capabilities than traditional telecommunication or IT services, and Cloud service delivery platforms ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 3

Cloud Services Provider Blueprint need to take this need into account. Self service is an integral part of the overall delivery system—especially in view of the high volume of new Cloud services that are rapidly being made available to end users.

Storefronts The online storefront and underlying shopping cart and product catalog for Cloud services need to be able to handle the tens of thousands of components defined 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 system—plus 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 difficult 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.

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.

Business Models Because 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 profitability. For example, a $10 per month service simply cannot afford any manual operations—or even a single support ticket.

An Integrated, Profitable Cloud Service Delivery Platform To more easily explain the characteristics of a complete service delivery platform, Parallels—based on its experience working with hundreds of the world’s leading Cloud service providers—has 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 efficiently, profitably, and with a seamless user experience.

The Big Picture We 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 connection—or, as some call it, “power, pipe, and ping.” Service providers don’t necessarily need to own these resources, but they do need to have access to them—for example, by leasing them from wholesale infrastructure providers.

Because 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.

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. ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 4

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, it’s helpful to see how they all fit together, in order. What the figure illustrates is that the infrastructure, both physical and virtual, needs to be managed. On top of that, services need to be defined, managed, provisioned, and billed. On top of these services, it’s essential to include a layer that gives customers visibility into their subscription services and lets them self-administer basic functions, so they’ll have less need to call the support center. As pointed out above, this self-service capability is critical to profitability, especially for large-scale public Cloud offerings. The figure also illustrates that these core elements do not live in a vacuum. They need points of integration with all critical front- and back-office systems. Additional points of integration are needed to provide customers with a storefront and shopping cart—or, 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 profitably. Now let’s look at each layer in the stack, starting at the bottom.

Cloud Services Provider Blueprint

Infrastructure Management The last few years have created extensive awareness among enterprises about the benefits of virtualization and efficient 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 configuration settings to a single server or a fleet 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 notifications: 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 notification system that comes into play when critical thresholds occur.

• Security: This subject could occupy one or more books, but for our purposes, suffice 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. ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 6

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 efficiency when deployed in large numbers, and for ease of replacement in the case of failure.

Provisioning and Orchestration and Billing Automation Two intertwined functional elements that stack on top of infrastructure management are (1) provisioning and orchestration and (2) billing automation. These functions enable 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 defined, 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 levels—need 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 notifications: 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 definition and management: Each particular service will

Two intertwined functional elements that stack on top of infrastructure management are (1) provisioning and orchestration and (2) billing automation.

have dozens, if not hundreds, of unique components that need to be defined 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 the application 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.

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 notifications: This requirement applies both to the customer’s 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 workflow: When an order is placed, it needs to trigger a series of workflow events—

including provisioning the appropriate resources and services—that ultimately result in fulfillment of the order.

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

Cloud Services Provider Blueprint

• Billing: The services need to be billed based on the relevant usage metrics. In the Cloud environment, it’s 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, with

new services, offerings, and bundles—plus, 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.

A product catalog is always changing, with new services, offerings, and bundles—plus, in the Cloud environment, it may have to encompass thirdparty applications and syndicated services.

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 flexible billing structure.

Customer Self-Service To manage and operate profitable 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, modification, 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 configuration management: Administrators at the customer’s site need to be able to configure their company’s applications and services—for example, to integrate domain names, specify e-mail box sizes, configure SSL certificates, and manage other security elements.

To manage and operate profitable 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.

Cloud Services Provider Blueprint

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

• Support: Control panels typically enable customers to get support—through

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 customer’s 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 configure personal preferences as well, such as changing a password. Reports: The control panel should enable customers to extract a range of reports from the system—from usage data to financial data.

Some customers may in fact be resellers, with customers of their own—potentially including 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 down— plus, 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.

Cloud Services Provider Blueprint

Integration into Front- and Back-Office Systems Service providers already have numerous front- and back-office systems and platforms that are vital to their day-to-day operations. The specifics 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-office 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 option—especially if some of the front-and back-office 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. API integration is almost always faster and less expensive than custom integration.

Although specific front- and back-office 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 selfservice layer.

• CRM: A customer relationship management system, used to manage customer relationships and sales opportunities, is typically integrated into the provider’s 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 identification for security purposes. To avoid administrative headaches, a service provider may implement an identity management system that federates an individual’s secure ID credentials across multiple systems. Business intelligence: Also known as business analytics, this system crunches financial and operational data and looks for critical trends that can help shape the business.

Figure 5. Systems integration into front and back office.

• Finance/ERP: A finance or enterprise resource planning

system handles accounting and supply-chain issues. While all companies have financial 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. ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 11

Cloud Services Provider Blueprint

Summary: How is systems integration different in the Cloud? The pervasive use of APIs within Cloud systems simplifies 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 finance 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 significantly less and enables the project to be finished in weeks, not months.

Services Integration On the other side of our Cloud management blueprint sit the actual services being offered—but before we address the services themselves, let’s look at the integration required to deliver the services. Just as front-and back-office 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 specific

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 specific integration 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 functions—so 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

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 frequently—and rapidly. Further complexity comes from the fact that the services can reside either within a provider’s 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 provider’s provisioning and billing systems. With proper services integration, however, third-party application updates have no effect on the hosted environment—plus the integration enables the provider to deploy new services very rapidly.

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.

Storefront and Marketplace Finally, 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 businessclass e-mail and calendaring systems, Web conferencing, VoIP, and other applications that facilitate communication between employees, customers, and partners. o SaaS—other: This catch-all bucket includes all SaaS applications not covered above. These are typically vertical solutions—for example, for insurance or health care.

• Platform as a Service (PaaS) o Hosting development environment: This is a turnkey environment for application development, typically specific to a single programming language. It’s a complete development environment, from the underlying infrastructure for hosting the application through the billing options that developers can use to make money.

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.

Cloud Services Provider Blueprint o Customized applications: This feature gives businesses the option to customize hosted applications for their particular needs. o Developer’s sandbox: This is a hosted test environment, enabling developers to work on new features or fix bugs without affecting the production 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 benefits of a dedicated server, but is in fact a virtualized instance. VPS hosting has a predefined 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 providers integrate 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 applications—and, 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. ©2010, Parallels Inc. All Rights Reserved. Unauthorized Reproduction Prohibited 14

Cloud Services Provider Blueprint

Conclusion â&#x20AC;&#x201C; The Detailed Picture Having 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 profitably operate a public Cloud.

Cloud Services Provider Blueprint To succeed at delivering profitable 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 todayâ&#x20AC;&#x2122;s 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 profitability.

To succeed at delivering profitable 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.

* * * * *

Parallels enables service providers to rapidly launch and efficiently deliver the most profitable 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/.

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.

Cloud Services Provider Blueprint

Appendix A: Components Required for Shared Web Hosting • Domain management •

• • • • •

•

o DNS hosting (number of hosted domains) n Records management (if customer can change them, or only system does it automatically) Web hosting o Parking (number of parked domains) n Frame URL forwarding (number) n Single page hosting (number) n Standard (HTTP 301) forwarding (number) o Standard Linux Web hosting OR Linux Web hosting NG service (number of hostings – Web spaces) n Web sites (number – each hosted domain, or subdomain, or wildcard domain is counted) IP-based virtual host (number of sites on exclusive IPs allowed) n Name-based virtual host (number of sites on shared IPs allowed) n CGI support (if it’s available or not) n Custom error docs (if it’s available or not) n Denied IPS configuration (if it’s available or not) n Handlers configuration (if it’s available or not) n HotLink protection (if it’s available or not) n MIME types configuration (if it’s available or not) n MS FrontPage for Linux (if it’s available or not [not supported for NG]) n PHP4 support (if it’s available or not) n PHP5 support (if it’s available or not) n SSH access (if it’s available or not) n SSI support (if it’s available or not) n SSL support (if it’s available or not) n WAP support (if it’s available or not) n Webalizer (if it’s available or not) Public IPs (number) Disk space (KB, total usage for all hostings accounted) Traffic (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 Logfiles 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)

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 it’s 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

Cloud Services Provider Blueprint

Appendix B: Components Required for Messaging and Collaboration • Hosted Exchange

o Mailboxes n ActiveSync access n IMAP4 access n POP3 access n Outlook access n Outlook Web access n Voice access n Maximum allowed mailbox size o Public folders n Maximum allowed public folder size o Resource mailboxes o Distribution lists o 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 n SSL support for SharePoint sites n Exclusive application pools for SharePoint sites • Hosted OCS o OCS user profiles n Instant messaging n IP audio/video n Web conferencing • Hosted PBX o Maximum number of simultaneous calls o Conference bridges o Conference bridge ports o Schedules o Caller groups o Response groups o Voice mailboxes o Number of days to retain call records o Auto-attendant templates o Phone numbers

Cloud Services Provider Blueprint

â&#x20AC;˘ Additional Services:

o MessageLabs e-mail security n Allow MessageLabs CP login o MXLogic n Basic ML protection for a mailbox n Advanced ML protection for a mailbox n Allow MXLogic CP login o Postini e-mail security o Global Relay e-mail archiving