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.
Interesting analysis, JP. I won’t quibble with the individual line items, because, as you note, they are simply estimates. There is no doubt that getting started with one application on a hosted PaaS is the most cost effective way to go. I also agree that using public cloud resources, instead of on-prem, will be the predominant way for enterprises to consume cloud in the future.
Having said that, three quibbles:
1. On-premise open source PaaS will certainly have a higher long-term cost than a licensed PaaS over time. At ActiveState, we’ve seen that again and again, where organizations start with pure open-source Cloud Foundry, but find over time they are spending much more time and money maintaining it than they would with a licensed (supported and maintained) distribution.
2. “On premise PaaS” doesn’t necessarily need to be run on-premise. Our Stackato PaaS is probably considered to be in the “on premise” bucket, but it can just as easily be run on AWS (or other public providers) as it can be run in-house. The reason organizations do this rather than use a purely hosted PaaS is that they want control over the underlying platform. Sometimes this is for “compliance and regulatory” reasons, as you note; more often, it’s that they want to ensure specific languages, stacks, and services are available (often, this even means specific versions of those things). We definitely see increased interest in running our licensed PaaS on public cloud (which would be a blend of your third and fifth columns).
3. The license costs in columns one and three would be amortized as additional applications are added. Again, if you have a single application, then column five makes complete sense; once you have multiple applications, then my second point here comes into play and the cost difference becomes much smaller.
Regarding Brent’s 3rd point, it depends on the architecture and frameworks used for the applications as well as number of clusters, nodes in the clusters that affect overall cost difference. I believe, these factors will cause the difference in column 3 and 5 by considerable factor.
Yes, however, this was my point about declaring the number of concurrent users that must be supported. I wanted to make sure the scalability requirements were bounded so that this was not an arbitrary number.
[…] my blog, “Making Financial Sense of PaaS,” I provided an analysis of delivering a newly-developed mobile application using a variety […]