The Enterprise Cloud: Best Practices for Transforming Legacy IT (2015)

Chapter 5. Billing and Procurement

Key topics in this chapter:

§ Capital versus operational expenses

§ Concerns with the “build it and they will come” model

§ Ordering cloud services, procurement challenges in an automated service catalog

§ Fixed price XaaS versus variable scaling and pricing

§ Metering versus allocated pricing models

§ Cloud billing versus accounting and invoicing systems

§ Usage forecasting

§ Legal and contract agreements

§ Top cloud providers

§ Billing and procurement best practices

Cloud services represent not only a new style of delivering IT services, but also a change in the way they are procured, resource usage is measured, billing is carried out, and the way organizations maintain budgets. In this chapter, I focus on lessons learned and best practices relating to the resource tracking, billing, contract terms, and public cloud vendor guidance. This chapter covers topics relating to both a private enterprise cloud and also procuring public cloud services as many organizations consider or end up with a combination of both cloud models.

Because some large organizations serve as a central IT for other departments or peer agencies, this would put central IT into a cloud service brokering role — making these other departments or agencies essentially “customers,” which is a term that will sometimes be used in this chapter. You can read a full description of cloud brokering in Chapter 8.

Capital Versus Operational Expenses

We begin this chapter with a brief discussion on the potential benefits and trade-offs of using operating funds rather than capital to procure or build your cloud. Some organizations do not have a clear delineation between these two “colors” of money but it is pretty common in government and public sector organizations.

Many organizations procure information technology using capital funds on a three- to five-year depreciation schedule for information technology hardware, software, and sometimes installation and maintenance. At the end of each lifecycle, which varies depending on the asset type, more capital funds are allocated and the cycle repeats. In this example scenario, there are operational funds for ongoing IT-related services labor, datacenter facility (e.g., electricity and HVAC maintenance), but often these operations funds are far more scarce. Whatever the length of this capital model and lifecycle, the one constant is how all IT assets are depreciated, retired, and replaced with newer technologies in a never-ending circle of expense. Many industry analysts and business leaders — right or wrong — now call this the old traditional style of IT and point to the cloud and an operational cost model as the new style of IT.

One of the core benefits or promises of the cloud service model is that there is little or no up-front expenditure of capital funds to procure, deploy, and operate the cloud. Certainly in a public cloud model, the cloud service provider invests all of the necessary money and time to deploy its cloud and then market it to consuming organizations. As a consumer organization, you would pay for public cloud services similar to a monthly utility bill and use operating funds instead of capital — again, if color of money is a concern for you. Major benefits of this cloud consumption operational expense (OpEx) model are little or no expenditures of precious capital funding, little or no term commitment, and easy scalability up and down as cloud services are needed and utilized.

When a private cloud is required, the pure capital expense (CapEx) or OpEx decisions are more complicated. You could contract with a systems integrator or cloud provider to deploy a private cloud within your datacenter; however, this continues the CapEx cost mode. The exception is if you can negotiate a deal with a systems integrator or similar IT vendor to essentially lease you a utility-based or pay-as-you-go private or managed private cloud for which your costs are spread out and paid through operational funds.

Regardless of the organization, the key advantage with public cloud services is that you can increase or decrease the selected services (and thus costs) at any time, normally without penalties from the cloud provider. This pay-as-you-go approach makes public cloud more flexible and more of a monthly utility bill rather than large long-term capital IT asset or expense. The bottom line is this: there are trade-offs between OpEx and CapEx, and the use of public cloud versus managing your own private cloud.

Concerns with “Build It and They Will Come”

Public cloud providers invest funds and considerable effort to build a cloud infrastructure and then market their service to potential customers. They are making a calculated investment that customers will want their services and at some point they will surpass the break-even point and rocket to profitability. For enterprise customers, this is important to understand. Procuring and deploying too much hardware and software initially will increase the initial cost of your private cloud infrastructure. This will delay your break-even point on whatever return-on-investment (ROI) model you or your company’s financial manager has created. The reality is that it is often difficult to guess future demand for a service you and your company’s business users haven’t utilized before. As soon as your users (your customers) are aware of all the new Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) capabilities, will there be a lot of new demand. If your organization’s goals are to migrate solely the existing IT systems you already have with no additional capacity, estimating the initial size for your enterprise private cloud will, of course, be much easier. But, you will still need some amount of additional capacity to accommodate elasticity.

The key problem with any cloud, properly sized or not, is the potential that applications are not migrated or users and consumers do not sign up in the early stages as expected. Any delays in expected revenues or chargeback within your organization will quickly destroy an ROI model. So, the lesson learned from countless customers — and I caution all of the customers with whom I work personally — is that the “build it and they will come” model has failed repeatedly, more often than not.

Key Take-Away

Countless organizations and agencies have overestimated the migration, or new service adoption rate of their new cloud. A best practice is to size the initial private cloud conservatively and rely upon disciplined capacity management to keep up with demand.

So, the best practice is to size the initial private cloud conservatively unless you have a particular reason to expect explosive growth (with which you will not be able to cope). Remember, as is detailed in the first three chapters of this book, a cloud infrastructure is all about elasticity to the consumers and (reasonable) capacity management from your IT operations team. Following the operational best practices in Chapter 2, there should be sufficient spare capacity, monitoring and alerts, and vendors and contracts in place for rapid addition of new hardware and software licenses to keep up with demand.

Some large organizations such as public sector government agencies have IT departments that service as a centralized IT “everything” for multiple subagencies or peer organizations. The relationship between these organizations and these peer or subagencies might be officially mandated or more of a cooperative agreement. Regardless of which it is, the central IT essentially supports the needs of each “customers.”

USE-CASE SCENARIO: A LARGE, PUBLIC SECTOR ORGANIZATION

A large, public sector organization plans to use the cloud transition project as the core of an overall consolidation of legacy datacenters, applications, and sometimes IT responsibilities that might have been distributed at the subagencies or departments. In this scenario, the intention of central IT is to create a central — often hybrid cloud broker — that all department and peer agencies will share. This also means that funding goes to the central IT and little or no moneys are distributed to the subagencies so that they do not continue maintaining their own IT systems and staff. The legitimate business justification is that the centralized IT and cloud automation, service brokering, cloud infrastructure, and shared operations staff will save significant money and reduce duplication across the greater community or agencies.

So, let’s assume that central IT does an absolutely phenomenal job of planning and implementing a cloud brokering system consisting of an on-premises private cloud with the hybrid ability to connect to external public cloud providers if and when needed for certain applications or workloads. They create a very intuitive and robust range of cloud services into a web-based cloud service catalog portal for all subagencies to place their orders. They also begin a consultative effort to assess all legacy applications across each subagency to begin migrating legacy workloads.

The problem is that each subagency really isn’t happy that they are not in control of their own IT. They feel they are not in control of the cloud offerings (which they aren’t) and they had little or no input into how the cloud was designed. Finally, their IT budget was cut and redirected to the central IT department who clearly wasted money (in their opinion) building this large cloud that nobody is using — in reality, nobody is using it because it is brand new. The result is that the subagencies might try everything in their power to avoid cooperating with the cloud transition and central IT. They might play the passive-aggressive role, simply ignoring central IT, or outright object to senior management. Either way, they are holding up progress on behalf of their entire subagency. Sometimes, the IT leader making these objections has more influence or friends in senior management than central IT does. Consequently, this situation could further delay the overall cloud transition, call central ITs project into question, and cause this discontent to spread to other subagencies.

By the way, I’m not making this up: this is less a case “example” than it is an actual case, and I’ve seen it happen multiple times within large organizations.

To amplify the issues, the IT security managers at one or more of the subagencies now chime in — a month or two too late in the project plan — with objections about new servers or virtual machines (VMs) launching through automation at all hours of the day and night. They claim that this is against standard policy and they will not approve moving forward. One or two business-application owners, within a subagency, also speak up and indicate that their application cannot be moved to the cloud and must be kept at the subagency’s existing legacy datacenter. The application software vendor does not have a cloud-enabled version of their software so they, too, cannot move to the cloud.

The result of all of this is a significant delay in utilization of the new private/broker cloud. The hardware and software is under utilized for many months, the ROI model is continually “pushing right” on the timeline, and project migration cost overruns begin to mount up. You need to keep in mind that in this scenario there was no technology problem. The security objections within one or more of the subagencies were largely because central IT either didn’t include them early enough in the cloud planning or the subagency security personnel chose to ignore those meetings — either way, their objections are easily resolved through best practices (as I detail in Chapter 6). As for the business-application owner’s objections, no application assessment has even been attempted yet, so maybe there is an alternative SaaS application that can be used or some other application modernization technique applied, as is detailed in Chapter 4.

The lessons learned from this case example are the following:

§ Even when a parent organization has an official mandate to provide cloud services to peer or subagencies, don’t underestimate the ability of a reluctant “customer” to stall, delay, or otherwise avoid adoption of your new enterprise cloud.

§ Forcing your authority has proven to make matters worse in the long run.

§ Using a “carrot” instead of a “stick” method to entice subagencies to join the central IT cloud and support organization is statistically shown to have little difference in results.

§ Involve your subagencies and peer organizations early in the cloud-planning process. Ensure that they are involved and even if you do not follow some of their ideas, they need to feel that they were heard and their ideas addressed. Yes, this new style of IT sometimes includes “hugging it out.”

§ Consider consolidating subagency IT hardware and software assets based on their next three- to five-year refresh cycle so that central IT is not “taking” anything but rather deploying services on the newest, best, fastest system — that happens to be the cloud during this refresh cycle.

§ Build your initial cloud small and with a reasonable amount of features and complexity. Overbuilding the size and spending a lot of time and money configuring dozens of Anything as a Service (XaaS) offerings is often wasted when you have few if any initial “customers.” Follow best practices for capacity management to keep up with demand rather than oversizing the initial cloud.

§ You will have plenty of time to configure new cloud services in the future. Any cloud services that you configure before bringing on a new subagency’s users and applications is likely not going to be exactly correct anyway (i.e., before you meet and fully discuss goals and requirements with each new subagency or “customer,” you are really guessing as to which cloud services and applications to create in your cloud).

Key Take-Away

Countless organizations and government agencies have overestimated the adoption or consumption rate of their new cloud service offerings. Even with the promised benefits of cloud, never underestimate the ability for consuming peer or suborganizations to delay or avoid consolidating their legacy IT or reducing their fiefdoms.

§ Form a consultative team to work with each subagency as early as possible in the planning process (and on an ongoing basis thereafter) to assess their existing applications based on the guidelines for application transformation described in Chapter 4. Application assessments and migration take the most time and effort and are often the highest concern for your customers. You can begin applications assessments even before an initial cloud is staged.

Online Ordering and Approval Workflow

As stated earlier, every cloud will have some form of a cloud management system that provides a customer-facing portal for ordering, billing, and service management along with significant backend workflow, automated provisioning, and systems management capabilities that control all aspects of the cloud environment. The capabilities and level of maturity of these cloud management platforms is highly proprietary and often is what differentiates one cloud provider from another — or in the case of a private cloud, what differentiates a cloud management platform from another. For full details, lessons learned, and best practices, refer to Chapter 7.

Key Take-Away

There are two basic rules when procuring and building an enterprise private cloud: (1) the hardware and software for the infrastructure are not nearly as important as the cloud management software; and (2) because you have a favored hypervisor does not mean you should use that vendor’s cloud management platform. Rarely is the best hypervisor product also the best heterogeneous multiprovider hybrid cloud management vendor.

Common functionality within these cloud management platforms is a customer-facing (normally web-based) portal on which customers are presented with a service catalog of available cloud services along with pricing and specifications from which to choose.

Service Catalog

The cloud portal’s capabilities often begin with an online ordering system. Here, an authorized user or manager can browse through a catalog of service offerings. This catalog is essentially the storefront to begin cloud service orders and then manage subscriptions. It is critical that the service catalog be easy to use and have complete specifications for each offering, including an optional price field if your organization wishes to use a billing or chargeback function. For IaaS compute services, as an example, the primary service normally begins with a VM, with options underneath offering a choice of operating system (OS), processors, memory, VM size, and the amount of storage. The total price for the service with options is normally displayed on a shopping cart for customers to confirm their purchase.

Industry Trend

Public cloud providers rarely provide pricing within a service catalog, opting instead to keep pricing published on separate static web pages. This makes it difficult to understand pricing for cloud services and transaction fees when ordering new services via the cloud management portal. In an enterprise private cloud, pricing or chargeback features are optional and can be shown within the service catalog of most cloud portals.

Behind the scenes of each service catalog item is a service design, although each cloud management system might have a different name for this. These service designs define the specific applications, compute resources, automation workflows, and pricing for each item shown in the service catalog. Service designs can be a simple VM automated workflow or a complex multitiered application that launches multiple VMs and virtual networks. Finally, each service design can have optional features defined to give customers the ability to customize their order, such as selecting their preferred OS for a VM, the amount of memory, processors, disk, and so on, with each option potentially having an additional cost associated with them in the service catalog shopping cart.

Approval Workflow

Some cloud portals offer an optional and configurable approval process. This is common to private enterprise cloud portals, because they can be more customized than public deployment models. For example, the cloud management system automatically sends an email to one or more predefined approvers within the organization indicating that an order has been placed and needs approval. A link in the email launches the cloud management system web portal, where the approver can log on and see a list of pending orders. Upon her approval, services are automatically provisioned by the cloud management system. When the provisioning is completed — usually within minutes — the customer billing cycle is started with a notification sent to the person who ordered the service.

Lessons learned have demonstrated that some organizations benefit from multiple levels of approval, such as basing it on order-price thresholds, the user’s role within the organization, and depending on the specific cloud service being ordered. Some cloud portals offer passive and active approvals so that some cloud services are preapproved for ordering and do not need human vetting or layers of approval.

Subscription Management

Although the actual term “subscription” can vary from one cloud management portal to another, the basic concept is important to understand. When ordering your first IaaS VM, for example, you are placing an order for a VM at the agreed-upon pricing. This price is usually measured and invoiced on a monthly (or daily, weekly, or yearly) recurring charge that automatically renews for each billing period until canceled (or a specific end date if chosen). When your order is processed, it becomes a new subscription to which most cloud portals allow you to assign a unique name.

Using the cloud management portal, you can always view the status of your subscriptions, view configurations information (e.g., IP address and system status), or add and remove features within a subscription (such as adding an additional VM to an existing subscription).

Financial Tracking and Billing

Depending on the chosen cloud management platform vendor, you can bill cloud services to customers or internal departments or agencies in many ways (you can also disable billing if it’s not needed). With some cloud providers, users can place orders and pay using a credit card; whereas others produce invoices or chargeback reports. Billing periods are typically on a monthly basis, although the actual metered and charged cloud services accumulate based on hourly, daily, weekly, or monthly pricing plans.

Regardless of the cycle and payment methods, the actual charges accumulated are based on one or both of the following:

Fixed fee

A fixed fee is charged and shown in the service catalog for each cloud service, or optional service (e.g., additional storage or memory). The cloud management system will charge this same fixed price for each billing period.

Variable fees

Variable charges are billed based on the resources that were used during the billing cycle. These itemized resources would normally be a base price for each VM, charge per processor, per gigabyte of memory, per gigabyte of storage, and network options. The customer is only billed for what it uses, but there might be a minimum charge per billing cycle. These variable fees per usage could result in unexpected high fees — some cloud management systems allow high limit thresholds to prevent unexpectedly large bills.

Cloud portals can get extremely granular in the way subscriptions are metered. Some public providers offer VMs by the minute or hour. Regardless of the granularity, the billing cycle usually does not change (monthly is most common), with the overall charges totaled up and reported to the customer at the end of the billing cycle. Most cloud services automatically renew or move to the next billing cycle until the customer cancels the service. Again, all of this is highly configurable in an enterprise private cloud management platform that you own or operate, and is only somewhat configurable as a customer for a public cloud.

Metered versus Allocated Resources

When cloud compute resources (processors, memory, and storage) are bundled into a service catalog, it is common for IaaS applications to be offered as VMs in small, medium, large, and additional sizes. The specifications for each of these VM sizes will specify or allow you to choose the number of processors, memory, storage, networking, and OS for each VM bundle or catalog item — each at the pricing shown within the service catalog. As a consumer or user of the cloud, it is important to know whether these resources are metered or allocated; as a private cloud manager, it is important to understand the difference between these and choose which method, or both, to use when configuring resource metering.

Continuing with the VM use case, in a resource allocation model, each VM purchased has a set amount of compute resources that is charged regardless if all of the resources are utilized or not. Even if you do not use all of the allocated storage space, you are paying for it. This is pretty much standard policy and practice for all public cloud providers and the default model for private cloud management platforms unless you configure it otherwise.

Metered resource management means that the cloud provider or management system measures the actual utilization of storage, for example, and only bills for the amount used. This metered resource model is more in line with the overall pay-as-you-go and elasticity characteristics of cloud computing. Metering of resources also means using variable fees (as described earlier) whereby the cloud management system will calculate billing based on actual utilization at the end of each billing period.

Key Take-Away

Pay-as-you-go is a basic economic benefit for cloud services. To truly pay only for what is utilized, resource metering is necessary so that the consumer is billed only for actual utilization instead of traditional flat/fixed fees for service each billing period. This results in variable pricing, which is sometimes difficult for maintaining budgets and preventing unexpected overage charges.

Allocated resources — storage in particular — is a common practice in most legacy datacenters. Metered resources — again in storage — are most common in a public cloud model. Within a private-enterprise cloud, many organizations do not want to deal with the extra configuration hassle necessary for metered storage, and instead use the allocation model.

Billing Reports

One key feature within the cloud management system is the ability for the organization or customer to see their billing history and current balance through the cloud portal. Most organizations do not want to rely solely on the billing cycle to see a report of their detailed charges; they prefer the ability to view resource utilization at any time, even in the middle of a billing cycle. You should look for public cloud providers that offer a detailed dashboard view of service utilization and financial forecasting or a private cloud management system with similar capabilities.

Of course, even enterprise organizations that do not bill their users or departments for IT services utilized can benefit from detailed billing and chargeback reports. Using these reports, you can see which services are being heavily utilized, which are not being utilized, and which are left running but not in use (i.e., being wasted). Many early-adopter cloud customers have used these billing reports to justify new purchases and expansion of cloud services, staffing, software, and so on, or just to plan an annual operating budget.

Draw-Down Accounts

One unique billing feature that some cloud providers and private cloud management platforms offer is the ability for a customer to submit a contract or purchase order document with a maximum funding level. This is very popular with large organizations and government customers. In this billing method, the ceiling of the contract amount is entered into the cloud management system, and the customer then places orders against this spending limit. After each billing cycle, an invoice is generated and the available contract funding is reduced by that amount. When the account nears zero, warning notices can be sent to customers reminding them that their contract ceiling is about to be reached. Customers can also submit multiple purchase orders that can be utilized by department(s) or project team(s), with the costs of each subscription invoiced against a specific purchase order.

Some public sector customers are required to track and limit their purchases so that they cannot exceed their budgeted purchase order limits. Although rare for public cloud management systems, a private cloud portal is more customizable and might be able to support this type of budgeting process. An example of this would be the cloud portal prompting for a purchase order when services are ordered, and automatically warning the customer of potential budget shortfalls if the pending order is actually processed and approved.

Implementing Grace Periods and Service Shutdowns

With successful public cloud providers hosting thousands of customers, one key feature of good cloud management software is the ability to automatically detect when a funding pool or purchase order goes to zero. A feature to consider in an enterprise private cloud management system is the ability to allow services to function while being in a grace period. The customer is told that they are overdue on their account and warned of an imminent service cut-off if payment is not received. After a configurable grace period has expired, the cloud management system can automatically pause or shut down services. One word of advice is to not destroy the account immediately after the grace period; instead, pause the services temporarily and keep the data. Payment might be on the way, the customer might want the service reinstated, or the customer intends to export their data to another provider. Whatever the situation, you don’t want to have to resort to re-creating the service and restoring it from backup if you can avoid it. You can perform a destructive deletion of old data after 30 or 60 days, for example. When you do finally clean up the data, the cloud management platform will automatically allow those resources to be assigned to the next new customer or subscription. When you consider how many cloud services are being ordered, changed, or renewed — multiplied by hundreds or thousands of customers or users — you can begin to understand how the cloud management system must include financial and resource utilization billing as a core function, even if you do not actually charge your enterprise consumers.

Cloud Billing versus Accounting and Invoicing systems

The cloud portal and billing system are a system of record (i.e., billing and utilization data) and not an invoicing or accounting system. A cloud management portal calculates cloud subscriptions, renewals, and resource utilization to generate the billing data and a printable or exportable report. Some cloud systems will call this an invoice but there is rarely a backend accounts payable or receivable system, such as a real accounting system would have. You could integrate this billing data into your organization’s accounting system, if desired, to generate official invoices or chargebacks.

Legal and Contract Agreements

When consuming services from a public cloud, the provider will have standardized service terms, service-level agreements (SLAs), and limitation agreements that you must accept before service can begin. One of the basic tenets of a public cloud service is that each customer is paying for a service to be delivered, based on a SLA. One common assumption in the industry is that cloud customers are not supposed to be concerned with all the details and technology used by the public cloud provider, only the results of the cloud service, as measured in availability of the service. Most public cloud SLAs include a financially backed, guaranteed percentage of time, per month, that the services will be available — typically this is 99.9% or 99.95%. The cloud provider will provide credits should it fail to meet the defined SLA. For your enterprise private cloud, consider what terms and conditions you want to establish and if you need to have an agreement at all if all of your “customers” are internal employees. Many organizations use some of the contractual language of the top public cloud providers to create an internal SLA.

Other terms that you should consider when evaluating or creating a cloud service agreement include the following:

Performance guarantees

Will the VMs, storage, and networking performance be guaranteed? Some cloud providers “oversubscribe” their customers, and during peak periods of usage, this could have a negative impact on your service performance. Look for guarantees from the public cloud provider that your services will not be affected by oversubscription or the peak workloads of other customers. Within a private cloud, you might not want to do this, because you might intentionally want to oversubscribe as a way to lower costs and increase overall server utilization.

Minimum service term or commitments

Ensure that you are aware of any minimum level of services or term duration required by the cloud provider. Some providers might publish attractive pricing, but there is a minimum cost or amount of services to which you are committing. Public cloud providers often do have special low-priced cloud services if you agree to a certain minimum commitment.

Migration terms and costs

Some cloud providers will charge additional fees for importing or exporting your data, applications, and VM templates out of their system. Most cloud providers do not charge for data import labor or data transfer but do charge for exporting the data if you attempt to terminate services. Make sure that you understand the process, costs, and amount of time the cloud provider will take to facilitate your service termination and subsequent export of your data so that you can move it to another provider or internal cloud.

Transaction and data input/output fees

Some public cloud providers have a significant number of transaction or data input/output transfer fees that are either hidden or not well understood. These fees can quickly add up during normal usage each month, often surprising new customers when they see their first full month’s invoice. This should not be an issue for enterprise private clouds.

Liability

Most cloud providers will have service agreement terms that attempt to limit their responsibility for data loss and consequential damages. Attempt to negotiate better terms for both the data loss and consequential damages clauses. The service agreement should include some liability on the provider’s part for maintaining, protecting, and ensuring the availability of your data, and should outline penalties in case the provider fails to meet the terms specified in the SLA. This should not be an issue for enterprise private clouds.

Maintenance windows

All clouds require maintenance of the infrastructure, including network, hardware, and software upgrades. Some providers might try to declare that they may have several hours of potential outages each month without incurring a penalty against the SLA. You should have no problem negotiating that term out of any agreement. The top cloud providers, and hopefully your enterprise private cloud, are designed with resilient applications and services so that there are no scheduled maintenance outages, because the services should automatically failover without interruption.

When building your own enterprise private cloud, you should also create a standardized service agreement to your customers, peers, or subordinate organizations that intend to use the service. In addition to the aforementioned legal and contract considerations, here are additional terms that you should consider specifically for a private cloud:

§ Consider specifying different SLA availability guarantees for optional fully managed services versus user-managed services. A common example of this is with VMs wherein a provider might not support the OS or applications in its default pricing unless the user purchases a fully managed up-lift support program.

§ Clearly define if and when services will be terminated, and data deleted, when a service subscription expires or the customer forgets to renew. As mentioned earlier, you might want to simply stop services, but not delete any data for a specified grace period. This makes restoration of services very simple if the customer determines that it wants to continue.

§ Ensure that you define what level of support is provided to your users. Customers using a Dev/Test service, for example, might unreasonably expect support on their application programming efforts that is out of scope. You should be clear that support is only for the availability of VMs and the OS or patches, depending on whether you are offering fully managed or customer-managed VMs.

§ You should specify if any departments or subagencies you support are able to bring or transfer their own software licenses to your enterprise private cloud, possibly reducing the overall cost of the services.

Licensing

In a cloud environment, application licensing has some unique challenges compared to traditional enterprise IT procurement and lifecycles. A traditional software vendor usually requires a customer to prepurchase a quantity of licenses upfront, even though those users are not yet accessing the system. In a cloud environment that is supposedly an “on-demand” style of IT delivery, this would be considered an “over purchase,” likely resulting in commitment of money up front, with potentially unpredictable revenue streams coming in the future. As a cloud service provider, even a private cloud owner or provider, you might need to negotiate (or more accurately, convince) each of your preferred software vendors to change their licensing models to support the pay-per-use and elasticity characteristics so important to cloud computing. There are many software vendors who still refuse to adapt to this new on-demand or pay-as-you-go model; however, the size of your organization and amount of potential revenue you represent can help influence the software vendor’s terms.

It is important to note that, depending on the cloud deployment model and software vendor, you might or might not be able to use legacy noncloud enterprise licensing agreements. For example, in a private cloud, it is much more likely that the software vendor will allow an existing enterprise software license to be used, assuming that you have a cost advantage in doing so. In a public or community cloud scenario, it is much more likely that the software vendor would not allow the transfer or use of the legacy enterprise licensing agreement. Although this license reuse issue often favors organizations deploying a private cloud, public cloud providers usually have the leverage of massive quantity and scale on their side to extract a good software licensing price, which ostensibly results in a competitive, if not lower, price to public cloud consumers.

The Current Cloud Industry: A Summary of the Leading Providers and Integrators

Although you might begin your cloud transition with an enterprise private cloud, it is important to understand the cloud industry, what cloud providers are offering, and in which areas each provider specializes. There are numerous successful cloud providers, so I will attempt to summarize the capabilities and target market for the most well-known and established providers in the industry. As stated earlier, for enterprise private clouds, the cloud management platform is the primary system to evaluate and deploy. Chapter 7 includes a list and description of the leading cloud management products and vendors.

Because these vendors constantly upgrade their features and capabilities, it is almost impossible to keep the information that follows completely up to date in a published book. Before you make any decisions, I recommend visiting the vendors’ websites to view the most current information.

Amazon Web Services

Amazon remains the leading public cloud provider measured by the number of customers and capacity of its infrastructure. Amazon was originally focused on IaaS applications and has the largest web content delivery network, cloud storage, and VM server capacity in the industry. Amazon now has significant PaaS applications, including multiple databases, mobile, analytics, media, transaction processing, and application development platform services. Amazon also offers a virtual private cloud (VPC) offering, whereby it still owns and manages the cloud but provides a dedicated instance of its cloud system to each customer. This VPC offering does not include all of Amazon’s cloud service options.

It is fair to say that Amazon is the current 800-pound gorilla in the cloud industry with by far the most customers. It is the largest and was the first to deploy a massive cloud service environment to the public, and it continues to add new cloud-based service offerings. Amazon was one of the first cloud providers to form a large reseller network and publish its own (proprietary) API. Amazon has a growing list of third-party SaaS and PaaS applications available through its public cloud service portal. The marketplace of third-party solutions makes it possible for customers to mix and match both Amazon and third-party vendor software offerings through the same public cloud portal and billing.

Amazon continues to lead the public cloud industry with numerous new service offerings announced each year. Amazon also leads public cloud providers in achieving security accreditations up to a year before many of its competitors. Amazon’s commercial public cloud service has achieved FedRAMP accreditation as well as its more secure and specialized GovCloud service.

Google

Google Compute is a more recent entry in the large-scale public cloud market. Its services were originally focused on IaaS but have quickly added application development tools, databases, and cloud storage options. Google’s depth of features is not yet at the level of those of Amazon or Microsoft; however, the services in place are very fast, easy to configure, and low cost. For example, Google VMs have fewer OS (e.g., minimal Windows Server OS options), platforms, and sizing options compared to Amazon and Microsoft. Given Google’s history and stated intentions, Google is expected to continuously roll out improvements and new features to catch up to the leading competitors and is likely to become a significant player in the public cloud IaaS and PaaS market, all while expanding its SaaS offering through natural growth and acquisition.

Microsoft

Microsoft originally focused on “behind the firewall” internal enterprise installations of its Windows desktop, Windows Server, and numerous other platforms and applications. Around the time cloud computing was coined, Microsoft began selling a SaaS offering based on its Exchange and SharePoint platforms. It then embarked on a tectonic shift to the cloud, transforming its large portfolio of enterprise software into cloud-based services.

Microsoft continues to expand its IaaS and PaaS offerings through its Azure public cloud service. Azure offers a complete line of public cloud services, including infrastructure VMs, storage, Dev/Test, web hosting, and database platform hosting. Given Microsoft’s success in developing its own hypervisor, virtualization, database, OSs, and numerous enterprise applications, adapting these for the cloud and hosting in a public cloud service offering is a logical step. With regard to the number and completeness of the cloud offerings, Microsoft’s key competitors are Amazon and Google. Microsoft has such a significant portfolio of development, productivity, and enterprise platforms and applications that it is using — as expected — to differentiate itself from other IaaS-focused providers with a large suite of integrated platforms and enterprise applications hosted in the cloud.

The Azure offerings are primarily public cloud in nature, but Microsoft also offers private cloud integration to its Azure platform. This private cloud integration shows great potential given the huge customer base Microsoft already has running its products within on-premises datacenters. This hybrid integration from the public Azure service back into on-premises enterprise servers and applications is sold and configured as optional offerings, including backup, server replication and failover, federated identity, virtual desktops, and application publishing. Although Microsoft has publicly stated that it will remain competitive to Amazon prices now and in the future, it appears that Microsoft will focus more on enterprise customers — keeping a focus on transitioning enterprise IT to the cloud and hybrid integration of the Azure public cloud back to these existing enterprise applications.

Rackspace

Rackspace offers a range of public cloud IaaS and PaaS applications as well as a separate line of private and hybrid cloud solutions. Rackspace was one of the first providers to offer public and private cloud services. Its claim to fame is superior customer service, but online pricing indicates this is offered at a significant premium over its base cloud service. Rackspace is one of the few public cloud providers that also offers private and hybrid clouds. Rackspace also utilizes OpenStack as its primary management platform for public cloud. Rackspace also offers multiple SaaS offerings, such as Microsoft Exchange and SharePoint hosted services. This combination of IaaS, PaaS, SaaS, and private cloud shows the maturity of Rackspace as a public and private cloud provider.

IBM

IBM provides public cloud services as well as private/hybrid consulting and deployment as part of its long history as a systems integrator. IBM announced it would retire its SmartCloud public cloud offering in 2014, with a plan to migrate all current customers to its newly acquired SoftLayer platform. IBM’s SoftLayer, which is based on the CloudStack open source cloud platform, offers all of the expected IaaS VM and storage services, but it is not yet considered an industry leader for public cloud. IBM has more recently announced the launch of two new datacenters in the United States that will host a new SoftLayer-based public cloud designed to meet FISMA and FedRAMP security standards, but no go-live target date was provided. Expect IBM to remain a significant industry player, particularly in private cloud, and expand its market presence in both public and private/hybrid enterprise cloud in the future. IBM most closely competes with CSC (Computer Sciences Corporation) and Hewlett-Packard as an enterprise cloud systems integrator. It is not known if IBM will attempt to directly compete with Amazon or Google or just continue building upon its enterprise customer base, transforming customers to private and hybrid clouds.

Hewlett-Packard

Hewlett-Packard has a long history of hosting datacenters, building large networks, manufacturing servers, storage, and creating software for leading Internet and cloud providers. It has traditionally functioned as a systems integrator but more recently began its public, private, virtual private, and hybrid cloud solutions. The cloud offerings are now marketed under the HP Helion brand name. HP Helion offers infrastructure VMs, storage, Dev/Test, database, and platform services in public, private, and hybrid cloud models with OpenStack as the underlying technology platform. Hewlett-Packard is both cloud provider and a software developer with private and hybrid cloud management platforms. Its primary competitors are IBM and CSC, both of whom also provide transitioning service to enterprise customers moving to private and hybrid clouds.

Systems integrators

Systems integrators (SIs) such as Hewlett-Packard, IBM, CSC, Accenture, Computer Associates, and many others now offer a portfolio of customized private and hybrid cloud services to enterprise customers. Most integrators do not compete with the likes of Amazon, Microsoft, or Google in public cloud. The differentiators between competing SIs are their migration and consultative deployment expertise, experience and reputation, and willingness to build highly customized private or hybrid clouds that most public cloud providers do not offer. More recently, there is a trend whereby these SIs are partnering or acquiring open source or commercially available cloud management platforms that they use as a baseline architecture that heavily influences each SIs approach to cloud, XaaS offerings, and competitive differentiators.

Service aggregators

Companies that aggregate and host several third-party software applications include Apptix, 1and1, and Intermedia. These cloud providers, previously known as application service providers, focus on web-based storefronts, online ordering, and the hosting and administration of COTS and third-party software applications over the Internet. Now called SaaS providers, these companies usually do not create applications themselves; rather, they host, manage, and provide support to customers by integrating numerous applications into readily consumable low-cost cloud service subscriptions. Some of these traditionally SaaS providers are now expanding into PaaS and IaaS offerings but are unlikely to ever compete with large-scale public cloud providers such as Amazon, Microsoft, and Google. Overall, as an industry, these SaaS aggregators have been most successful in the small and medium-sized business market.

Billing and Procurement Best Practices

Based on lessons learned and experience from across the cloud industry, you should consider the following best practices for your organization’s planning.

Capital versus Operating Expenses

One of the benefits of consuming an existing public cloud service is the ability to use operating funds for a recurring hosted service with no capital expenditures and minimum commitments. When building and deploying your own private cloud, the capital investment and ongoing operations can be extensive. Here are some considerations:

§ When procuring a private cloud infrastructure, organizations often attempt to utilize existing server farms, storage systems, and networks; however, lessons learned have demonstrated that mixing the new cloud services with legacy systems can create significant change control, security, customization flexibility, and performance problems. It is more desirable to build a new infrastructure and then, when operational, consider migrating the legacy systems into the cloud as the legacy systems lifecycles expire or need refreshing.

§ When procuring hardware and software for your private cloud, avoid purchasing too much and thus deploying more capacity than you need. The result is an overly expensive initial cloud service — you are starting with a steep expense curve and a long path to achieving your ROI. Leasing of the initial hardware and software are certainly options, but also try to negotiate pay-as-you-grow agreements with hardware vendors, in which you only pay for a portion of your equipment immediately, yet extra capacity is prestaged in your datacenter. Your agreement will only begin charging you for the prestaged equipment as you begin to use the extra capacity. Often, you can seek a similar agreement with software license vendors so that you don’t prepurchase a large pool of licenses while waiting for new customers to actually consume them.

§ In some situations, you might be able to negotiate an agreement with a systems integrator to deploy and host a private cloud that is dedicated to your organization. This systems integrator would be taking on some or all of the risk of funding and building the cloud but will likely require minimum term commitments from the customer. Lessons learned have shown that this model of a systems integrator building a private dedicated cloud for free can result in profit losses almost immediately and the systems integrators ROI model rarely recovering in future years. Although this might appear as an advantage to the end customer of this cloud, the systems integrator will eventually have to cut corners, provide reduced quality, and ultimately the customer suffers from lack of new features, new XaaS offerings, application migration assistance, and so on.

Build It and They Will Come

Many organizations and public cloud providers have relied on the “build it and they will come” approach to attracting customers and growth of the cloud. Real-world experience is in clear conflict with this approach. Rather, this can lead to significant financial loss as lack of customer adoption can make the planned ROI model worthless. Here are some notes:

§ Organizations that plan to host a private cloud and sell or chargeback service costs to peer or suborganizations often predict only the best-case adoption and growth scenario and cost model that results in financial losses and an under utilized cloud environment.

§ Organizations tend to overestimate their ability to entice, coerce, or force subagencies and departments to utilize and migrate to the new cloud environment. Lessons learned are to never underestimate a department or subagency’s ability to resist, delay, or find other methods to not migrate to the new environment that they don’t feel they control or that would reduce their political power or trusted staff.

§ Create a plan for internal marketing of the cloud service and attempt to get confirmed/signed agreements for migration and funding from subagencies or departments. This would be the equivalent to a public cloud provider obtaining some preorders so that there is a backlog going into production, thus helping the planned ROI model.

§ Do not create a financial model with the traditional “hockey stick” pro forma financial model in years three or four when suddenly everyone is perfect with customer adoption and ROI: don’t use the best-case scenario to plan your cloud pricing, staffing levels, and customer growth rates.

§ The bottom line is that when there is no customer backlog of orders, no minimum commitments contracted, and no capital or “skin in the game,” the “build it and they will come” model has not been successful even if the product (the cloud, in this case) is a technical success.

Online Ordering

The cloud management platform of a public or private cloud, will normally be the engine behind a customer-facing portal, service catalog of available XaaS, pricing, and a checkout or order confirmation process. Here are some key points to keep in mind:

§ For public cloud consumers, you have little or no choice but to customize the ordering or portal experience. Private cloud owners can often pick from available cloud management platforms and therefore evaluate capabilities, features, usability, and customization options.

§ Evaluate and walk through sample procurement use cases, such as using purchase orders and draw-down accounts (pools of funding) with the cloud management platform to determine if it meets your needs or if you customize it.

§ You will need to determine and provide to the cloud management platform the usernames or a defined group in LDAP or Active Directory who are allowed to place orders in the cloud portal. These usernames, and sometimes several group names, are used to define each role in the cloud portal. These roles-based permissions determine what exactly users of the portal can and cannot do.

Procurement Process for Ordering Cloud Services

When an order is placed within a private cloud service catalog, the approval and/or the financial obligation of funds are processed through a customizable workflow engine. Many organizations find that their traditional procurement processes do not allow for distributing authorizations for these purchases; thus, requiring the procurement or finance department approval of every order is inefficient. A successful cloud environment depends on automated ordering, pay-as-you-go, and rapidly provisioned services, which also means that the procurement of individual cloud services needs to be preapproved or automated, as well. The procurement or finance team within an organization likely cannot or does not want to be involved in every order or micro-transaction that might occur through the online service catalog and cloud portal. Here are some consiserations:

§ It is recommended that you creat funding pools, multiple purchase orders, or other forms of preapproved allocations of money with assigned personnel allowed to order services against these funds.

§ In addition to the initial procurement of cloud services, the ongoing cost allocation or chargeback to one or more consuming organizations is also critical. Some cloud management platforms and portals provide sufficient reports with the granularity of data necessary to assign costs to each consuming organization or user.

§ Even for organizations that do not directly charge costs to the consumers and thus provide reports and usage statistics along with the invoice, it is still important to track costs and track system usage, plan for system growth, and to remove or shut down services that are no longer actively in use.

Approval Workflow

Most cloud portals, particularly private clouds, have some form of customizable approval workflow. This makes it possible for specified individuals to log onto the cloud portal and place orders that then trigger a notification to one or more persons in your organization who must approve the order. Each tenant or organization can usually have its own set of approvers by department or subagency. Here are some considerations:

§ Avoid having too many approval steps or individuals involved. Remember that the intent is to quicken the pace for obtaining cloud services.

§ You might want to use a combination of passive and active approval services listed in the portal service catalog. Passive items do not need a person to actively approve the order, so it automatically provisions and starts billing of that service when ordered. Active approval requires someone to approve each order before provisioning and billing begins.

§ It is recommended that the contracting departments not be involved in the numerous micro-transactions of every order; instead, they should issue and track pools of approved funding such as purchase orders where every cloud order draws-down against the contract funding ceiling.

§ An existing service ticketing or service management system might already be deployed in some organizations and datacenter operations. Most cloud management portals can easily integrate with existing service ticketing systems for approvals and other event notifications.

Fixed and Variable Pricing

Both in consuming a public cloud service or building a private cloud, you need to determine which of the cloud services will need to be billed at a fixed price for each billing period and which will be at a variable price. Here are some considerations:

§ Variable pricing also means that the resources utilized for the particular cloud service will be measured or metered with usage charges accumulated and then billed at the end of each billing cycle. Thresholds or limits can be set within the cloud management system and portal, but otherwise the end customer might be surprised with a higher-than-expected invoice when using variable pricing during a high-utilization period.

§ Fixed pricing provides a more predictable and stable price for each cloud service for each billing period. The only way the cloud service expands to use more resources (processors, memory, storage, etc.) is for the customer to manually order expanded services from within the cloud portal. Although fixed pricing means predictable and controlled bills, the cloud management platform will not automatically expand resources to accommodate the increase workload. This can result in poor performance or even system failure when an XaaS application reaches its defined resource limits.

§ A combination of fixed and variable pricing is possible, even in the same service catalog. Sometimes it is best to configure the variable-pricing options in the service catalog for active approval to ensure management is aware of potential costs of the newly ordered cloud service.

Automatic Elasticity or Scaling

The ability for a cloud service to expand in resource utilization or capacity is a core benefit of cloud. Enabling automatic expansion means that the cloud management system will attempt to add more VMs, memory, processors, or disk space to a given XaaS subscription in order to keep up with peak workloads. Here are some things to keep in mind:

§ Enabling automatic elasticity can result in a surprisingly high variable cost at the end of the billing period. The alternative is for the cloud platform to be configured to enforce the maximum resources (processors, memory, storage, network, or application licenses) that were ordered and never automatically expand the service or charge more for that elasticity.

§ Many legacy applications can benefit from more processing power and memory when the amount of workload increases. The individual VMs running these applications can be scaled up, but expanding to additional VMs might or might not be as effective. It takes a newer cloud-enabled application to be easily or automatically scaled out across multiple VMs to increase capacity. The very best and most advanced cloud applications can both expand and contract themselves across multiple VMs and multiple networks, providers, and multiple instances of the application. We will begin to see these new styles of dynamic applications in the coming years, but they are rare right now.

Cloud Billing versus Accounting Systems

The cloud management portals and integrated billing should be used as a source of data that can automatically or manually feed into a true accounting system.

Government public sector customers often require the accounting systems be certified for invoicing the government. Cloud management platforms usually do not qualify as an accounting system; therefore, the invoice or bill generated by a public or private cloud management platform might not always be suitable to actually invoice or chargeback to the end-consuming organization of the cloud. Use the data from the cloud management system to input (manually or through some customized automated import process) into the real accounting and invoicing system.

Detailed Cloud Service Cost Models

In a traditional IT department or managed service model, all of the costs of the physical datacenter facility, network infrastructure, server farms, applications, software licenses, support vendors and internal IT staff are often consolidated into the budget. In this legacy managed service model, the costs of providing an individual service to a consuming end user were rarely known to any level of accuracy; the overall budgets were usually not broken down to the service level but were maintained at a much higher level. Here are some considerations:

§ In a cloud model, it will be important to recalculate the costs of providing each application or cloud service on a per-unit basis. These units are typically a consuming end user of an application or per-VM/server hosted in the cloud. As more users and services or more VMs are activated, in this example, the costs for providing these services must be known in order to properly scale the environment, potentially charge the consuming user/organizations, and to provide support services using the IT staff.

§ Create a financial model during the planning phases of a private cloud deployment. Calculate the costs of equipment, software, deployment, licensing, and support and operations labor for the initial months and out to two to three years at a minimum.

§ Your formulas should allow insertion of customers and user adoption rates (purchases of services) against your cost model so that you know your breakeven period, your average revenue per user (ARPU), and cost of every infrastructure component as you scale up the environment to meet demand.

§ Keep adjusting this model as actual customer orders come in, reset your customer demand curves, and adjust your infrastructure and support cost models every 6 to 12 months.

Legal and Service Agreements

Whether consuming a public cloud service or deploying your own enterprise private cloud, service terms and legal agreements are essential to defining the scope of the service, defining service-level guarantees, and limiting liability. Specific legal and service terms to consider, both as a consumer of cloud and as a private cloud operator include the following:

Defined SLA and availability guarantee

Ensure that there is an active SLA, not just a service-level objective. Do not be surprised if the SLAs are different from one service to another within the same cloud provider.

Minimum service term or commitments

Some providers offer the lower pricing only if customers commit to significant minimum terms, volume discounts, and so on.

Migration terms and costs

Always review termination procedures and fees that might be associated with migrating away from the provider.

Import, export, and non obvious transaction fees

Many public cloud providers have significant transaction fees that are not obvious on their price lists and are often not included in their cost-of-service estimation tools. Most providers do not charge for data importing/uploading but do charge fees for downloading and migration away from the provider’s cloud.

Liability limitations

Cloud providers often include terms in their service agreement that attempt to limit the provider’s liability for data loss or consequential damages. Some cloud service agreements even state that they have zero responsibility or guarantee to even maintain or back up your data. Ensure that these service terms are changed and negotiate a better agreement with appropriate protections and liability limits.

Declared maintenance windows

Consider the provider’s definition of maintenance outages (planned and unplanned) and how service credits are to be requested. When it comes to maintenance windows, verify that the cloud provider will deploy updates through rolling updates and not total system outages every week or two, as a legacy datacenter operation might have done.

Support limitations and exclusions

Consider what basic level of support is included with the cloud service and what support options are available at additional cost. For more advanced services such as Dev/Test, does the cloud provider offer support to developers and application development tools or is this entirely the responsibility of the end user and developers?