Monthly Archives: March 2015

Making Financial Sense of PaaS, Part Deux

In my blog, “Making Financial Sense of PaaS,” I provided an analysis of delivering a newly-developed mobile application using a variety of platforms. Subsequent to my posting I had some great conversations about the content with Brent Smithurst (@brentsmi) from ActiveState and Mark Thiele (@mthiele10) from Switch. Brent is from a PaaS software provider and Mark is a world-renowned expert on data center operations and architecture, so clearly their insight is extremely relevant and credible.

As pointed out by Mark, it’s very easy to make the cloud look financially attractive when pricing out a single application versus a portfolio of applications. Indeed, I would have to agree one of the most difficult things is to formulate an apples-to-apples comparison of cloud to data center. Even with the concept of reservations, the cloud cannot come close to the amortization of capital allocations across a portfolio of applications. The cloud is all about sizing and costing one application at a time whereas data centers should be all about economies of scale.

For the original blog I chose to use a model where capital allocation was occurring on a project-by-project basis. This is a fair estimating technique given many businesses and government agencies use this technique as a way to procure hardware and software. However, it does skew the results in a particular direction. Additionally, as noted by Brent, the original $25,000 price tag could buy the equivalent of $48,000 worth of IBM BlueMix in GB-hours. Then, finally, Mark noted that even the Hosted PaaS has some operational component to them. He is correct here and that was a clear oversight in the original estimate. IT Operations should be reviewing the logs from the Hosted PaaS instance and monitoring the health of the application and its performance.

So, while one cannot argue the original estimate given the stated assumptions, it is certainly not the whole picture for businesses that leverage virtualization and have pooled hardware resources. Since my labor estimates were based on time, I believe these are firm regardless of the approach taken. The original estimate does not imply that individuals would be hired specifically for this application. Alternatively, if we are going to leverage economies of scale and use common platform requirements across a set of applications, then we have to recognize there will be increased time required of the application infrastructure specialist and operations to handle the increased complexity. That is, as we move away from a single application running in the N-tier environment to multiple applications we need to deal with clustering, high-availability, scaling and capacity management issues that were not accounted for in the original design estimate. This increases the amount of time and, hence, costs associated with these roles.

Taking all these elements into account, the following is an estimate for a business with sunk costs in an existing data center, can add the necessary virtual machines to an existing pool without incurring significant new charges, and will leverage the software licenses across multiple applications. As you can see it changes the financials enough to consider all of them viable options. However, PaaS options could save on average $100,000 per application, which, for IT shops already spending on the order of 90% of their budget to keep the lights on could open up major opportunities for transformational activities.

Making Financial Sense of PaaS

As a consultant one of the common artifacts I’m frequently asked for is a cost estimate for a statement of work. Needless to say being the “cloud guy” these requests often revolve around estimates for delivery on a public cloud platform. I’d like say there is a high-degree of science behind these estimates, but the truth is that without a completed physical and logical architecture estimates are exactly that, an estimate. Pay for use definitely introduces an opportunity to get very fine-grained in costing, but it also requires a much more detailed understanding of the application than was required to do costing for a standalone equivalent.

Being a huge supporter of Platform-as-a-Service (PaaS), specifically, container-based PaaS, such as CloudFoundry and Heroku, I decided to apply my pricing experience to hacking up an estimate for delivering a mobile application inclusive of development through operations. The goal for me was to see if my own assertions that PaaS actually reduced both development and operating costs could be supported. My results were verified by both and independent consulting peer and a provider of PaaS.

The estimate I put together is for a new mobile application. I estimated that it would take three months to deliver into production. The application is comprised of three distinct elements: the mobile application, the mobile back end application—written in Java—and the integration with existing applications to exchange data. The approaches for implementation evaluated consisted of a spectrum of options ranging from On-Premise N-tier application to hosted PaaS. In this case, I am using the term On-Premise to represent running in a privately-hosted, privately-operated environment (e.g. corporate data center). Moreover, the options include using both licensed and open source software alternatives. This application must support 500 concurrent users initially and will grow by 25% annually. For pricing estimates the following products were used as examples:

  • Licensed N-Tier: WebSphere Application Server, Oracle, Mule
  • Open Source N-Tier: Apache/Tomcat, MySQL, Mule
  • On-Premise PaaS (licensed): Stackato, MySQL
  • On-Premise PaaS (OS): CloudFoundry Community, MySQL
  • Hosted PaaS: BlueMix or Azure Web

Before posting the numbers, I will tell you I surprised myself at the costs for building and operating a single mobile application, even for the least expensive option. I believe this should certainly be eye-opening for any CFO and should definitely spur an audit of their current application portfolio. Also, there’s probably a number of ways to argue against the numbers depending upon how your business is organized and how it delivers IT services. That said, these numbers are representative of a majority of mid- to large-scale enterprise IT practices. I am keenly aware of how numbers can be played with to justify supporting a particular outcome. I have been in the position of having to illustrate break-even for AWS versus privately-hosted converged infrastructure and I can make either option look better than the other by simply tweaking certain assumptions. That said, I’m sure I didn’t account for every minutia in this analysis.

Since the labor is a major cost factor in the analysis, it’s important to understand the assumptions that went into computing these costs. First, each labor category was factored based on the amount of time they would need to spend supporting delivery of this application. Since IT Operations continuously operates the application, there is a cost for initial deployment and then maintenance and support of the environment, where required, such as patching and updates. It was assumed development would be involved in the initial development and some bug fixes as required throughout the year. The Application Infrastructure Specialist role is responsible for configuring and deploying supporting services, such as database, messaging, identity management, etc.

And the answer is ….

Hosted PaaS is definitely the least expensive option for deploying this application architecture. The next least expensive option is double the cost for deploying on Hosted PaaS, which would be acceptable if the business received double the benefit, which it does not. Other than businesses just not being ready to build and operate on Hosted PaaS—or being in an industry that is still struggling with compliance and regulatory issues that might ensue for using public cloud—there is no financial justification that makes sense for continuing to build applications and hosting them in an on-premise environment.

What do you think? Am I in the ballpark? Missed by a mile? Please share your opinions.