Cloud Thunder: The Biggest Bang for the Buck, Part 2

Cloud Thunder: The Biggest Bang for the Buck, Part 1

Cloud deployment and delivery architecture offers many opportunities to reduce cost and improve service levels, sometimes too many for the beleaguered IT team. So how can your IT team identify what cloud components might be considered early opportunities for your infrastructure?

In Part 1 of this two-part series, I examined a few examples of services in the cloud model, including internal Infrastructure as a Service (IaaS) and external IaaS. In this installment, I will highlight two additional examples of services in the cloud model — Software as a Service (SaaS) and Platform as a Service (PaaS). Let’s look at these two cloud strategies, and consider benefits and speed-of-adoption possibilities.

Software as a Service, or SaaS

The SaaS model may offer IT the opportunity to seize a more immediate benefit, albeit by making a pool of infrastructure highly visible and possibly even eliminating or redeploying human resources. The SaaS provider has typically built sophisticated technology infrastructure including servers, storage and networking, to support classic client-server functionality such as email. The menu of supported applications under SaaS is growing day-by-day as more and more organizations seek the immediate benefit of outsourcing applications that while important, if not critical, provide no competitive differentiation.

They provide no competitive differentiation because competitors have access to the same functionality and typically at the same level of implementation. SaaS also supports applications with Web-based interfaces such as the popular Salesforce.com or Google Docs.

SaaS allows an application like email to transition from an internally managed IT task requiring a significant infrastructure in servers and storage, as well as human resources, for day-to-day administrative tasks. Because of the nature of the application outsourced and the size of the SaaS provider customer base, this usage of cloud services can seem like a quick reward at a relatively low risk.

Nonetheless, there are some critical aspects to consider when seeking the quick reward. First, the IT team will consider all the same vendor acceptance issues as they did with IaaS. These include but are not limited to security, stability, availability, performance, scalability, back-out capabilities and pricing acceptability.

The IT team will construct a request for proposal (RFP) that specifically addresses each of these issues, seeking tangible and empirical evidence that the vendor is in a position to meet, and continue to meet, these basic criteria. The most important step is to ensure that the costs are in fact less than, or equal to, current costs. This can be a tricky exercise.

The assistance of a friendly finance person is essential as you grapple with a transition of an investment that includes capital expense (Capex) and operational expense (Opex) calculated over a fixed time period for fixed capabilities to one that is purely Opex and based on a variable workload.

The basics require a fully loaded cost of the deployable unit. In the case of email, we might conclude that the deployable unit is the individual mailbox. We therefore need to understand our fully loaded cost of a mailbox in its current state and then consider the price per mailbox from the SaaS vendor. Your finance friend will help you understand what a fully loaded cost should contain.

As the cost model is built, one of the key differences between current state and the new outsourced SaaS state will be that your internal Capex/Opex model is now purely Opex, and that will be variable based on the use of the deployable resource. This means it can increase if you add mailboxes or it can decrease if you close mailboxes. You may need complementary policies from HR to ensure that old/obsolete mailboxes are closed or consolidated.

While SaaS is not as challenging as IaaS, it still has many issues that will, and should, impede a rapid switchover. Bypassing the caveats identified can result in what is referred to as a resume producing event (RPE). Immediate candidates for SaaS are email and CRM functions. For those prepared to courageously venture forth on the leading edge, perhaps even office productivity applications.

Platform as a Service, or PaaS

PaaS can often be confused with IaaS. In recent years, the word “platform” has often been misused to describe a computing platform like Unix and Mac OS X. The original use of the term “platform” describes the development environment, which may of course mandate a particular OS and middleware. The correct use of “platform” describes the actual software development framework used to create applications.

The PaaS offering therefore provides us with a specific development platform. Examples are Microsoft’s Azure platform for development and the Force development platform provided by Salesforce.com. Users of this service need not be concerned with the underlying storage and server infrastructure.

The nature of the development environment is in many ways less critical and/or more tolerant than the demands of end-consumer-driven IaaS and SaaS services. It is typically not the business unit’s end consumer placing demand; more often, it is the IT development team looking for this type of service.

In some more sophisticated organizations, these development functions may have been partially outsourced to a business unit, but the developer in that business unit will typically be an IT lookalike with similar skills and knowledge.

As is the case with other cloud services, potential users must satisfy themselves on the basics of vendor and service capabilities. Security, stability, availability, performance, scalability, back-out capabilities and pricing requirements should be empirically defined and included in the RFP. Where possible, the RFP answers should be considered part of the purchase contract.

PaaS is possibly the easiest cloud service to justify. The infrastructure used for development is often discrete and easily identified. Again, your friendly finance department can assist you to develop the fully loaded Capex and Opex costs and help you compare this against the purely Opex cost of PaaS.

It is important to understand the billable unit(s) of PaaS and ensure you are comparing apples to apples in your cost model. The PaaS pricing model can be very complex and include rates for storage, compute power, transaction count and number of instances, so it is important to understand this model. In fact, if you can’t simulate the PaaS pricing model, you not only can’t build a justification, but also may be left without the ability to assess the vendor’s billing accuracy.

Unfortunately, the complexity and granularity of the typical PaaS pricing model make it quite difficult to develop a cost model.

While pricing is the most complex and difficult of all cloud services, the migration to PaaS is probably the quickest and easiest of the cloud services. No users are impacted, and no production schedules need to be considered. However, the IT team should consider only the capabilities of their vendor in how quickly they can gain access and use the platform resources.

The PaaS consumer should carefully consider the role of development vis-a-vis test and quality-assurance functions. It may not be the most cost-effective use of PaaS to utilize it for test and quality-assurance functions. There may be justification for initial testing to take place on the same platform until the application reaches pre beta, but it is possible that IaaS may provide a more cost-justified platform for testing and certainly for quality assurance.

Both beta testing and quality assurance demand short-term usage of significant computing and storage resources. Quality assurance, in particular, may demand production-sized data and therefore be cost-effective only on the simpler IaaS facility.

In Conclusion

It would seem we could conclude that the shortest lead time to cloud benefits is by way of PaaS, while the largest financial return might be from targeted use of SaaS services. PaaS may provide the quickest implementation, but its pricing complexities make assessment of the actual benefit quite challenging. On the other hand, the SaaS pricing model is often based on seats, and it is much easier to calculate the projected benefits.

Over the long term, internal IaaS offers perhaps the most significant financial benefits because of SPM efficiencies and technology reduction through virtualization. External use of IaaS is subject to concerns about security and availability, but it may be an ideal solution for short-term requirements in application testing and low-value data storage. The pricing model is relatively simple and easy to replicate in an internal cost model form justification.

Where security concerns can be satisfied, it may also be a good choice for the deployment of quick time-to-market implementations. Where security is a prime requirement, the internal IaaS is seen as the preferred choice.

However, the ability for IT to provide sufficient resources to meet fluctuating demand may inhibit full realization of the benefits of the internal IaaS cloud. In addition, the ability of internal IaaS to drive savings through cost-conscious behaviors in service selection may founder because of finance division policies on charge-back.

In summary, each cloud service has its pros and cons, measured in time-to-implement and savings resulting from implementation. One final caveat is that classical cloud calls for billing on-demand or usage-based billing. What is equally important is when the resource is released, the billing stops.

Some providers who market their service as a cloud capability include a monthly premium to retain access to the on-demand resources, even if they are not used. While this is not the classical cloud mode, it is important to include any such premium as an additional overhead in the justification calculations.