Oren Michels | Co-Founder & GM
March 28, 2012

No Fake Clouds: Only a Genuine SaaS API Management Solution Delivers Lowest TCO

 

This is the second in a series of three posts by Mashery co-founder and CEO Oren Michels that examines at the advantages of using a genuine SaaS solution to manage your API, and the hidden (or obvious) costs and challenges in deploying API infrastructure using the model of appliances and licensed software. Part II examines the ROI from a SaaS-based solution and the potential TCO of an appliance/software implementation model as vs. a genuine multitenant SaaS implementation.

In my last post we took a nostalgic romp through some old school SaaS FUD, a retro version of which popped up in a recent blog post looking a bit like a guy showing up to work in a polyester leisure suit.

Today we're going to talk about the economics of a modern multitenant SaaS API Management Solution when compared with the old-school appliance/software model.

Return on Investment

Here I have to agree with Francois's basic premise - the advantages of lower initial investment in ANY project quickly becomes irrelevant when the ongoing cost increases. Good thing that over 25 years ago the good folks at Gartner popularized the analysis called Total Cost of Ownership (TCO) to help us figure out the overall economy of each option. The Wikipedia entry on TCO outlines a by-no-means-comprehensive list of cost factors that figure into TCO when making computer and software acquisition decisions.

Naturally, you start with the basic cost of the solution itself – with a SaaS solution, this is the annual service fee; with software, this is the license fee. It's important to look carefully at both and evaluate each option on how well the pricing structure fits your business, and how it grows (if it does at all) as your usage changes over time.

On the SaaS side, the service fee is your only cost, so it's a good idea to understand how it works. At Mashery we like to keep it simple. We have found it very important to tie our pricing to the value we're delivering to the customer, rather than to a metric that may have relevance to us - but is a lousy proxy for the value the customer perceives. Earlier this month I was visiting a prospective customer in London and was asked what we would charge him as a "per hit billing fee"; it was an easy answer since we don't charge such any such fees. Some APIs have a ton of volume but each call is relatively low-value, while others may have very low volume but have significantly higher requirements for special configurations, failover, caching and other high-value services. A billing structure based on a price per call can struggle to reflect value in API management, so we offer three packages with no per-hit pricing, including an "unlimited" package that guarantees unlimited API volume via our redundant cloud-based network for a flat annual fee. To us, unlimited means the same as EVERYTHING. No invoices for additional licenses, instances, storage, infrastructure, sysadmins, backup, upgrades, hardware or anything else. True SaaS means you can budget for a flat predictable cost to handle your API management needs.

Contrast this to the software license model. I'm not sure how Francois's company builds volume into its pricing, but they do talk about licenses, so it would appear that there is some component by which you need to purchase additional licenses as you grow. I've seen a lot of different software licensing schemes, but they all have one thing in common: by some growth metric that may or may not correlate with value delivered, one will eventually trigger a mechanism requiring the purchase of more licenses (plus hardware, and administration, and all the other costs). Such schemes may commonly induce hasty decision-making around either purchasing additional licenses or choosing to artificially reduce usage as defined by the scheme. Sometimes the scheme causes customers to create their own usage sub-schemes to "stay under the limit".

With an appliance/software model, the budget continues to get more complicated because the license fee is only the tip of the iceberg. Beneath the surface lie substantial hidden costs affecting the overall TCO of the software solution.

When Marc Benioff famously warned enterprises to beware of the fake cloud, he was calling out the software industry’s attempts to repackage software with the appearance of simpler value. Because, the fact is that many of these solutions were just better looking software packages. Instead of the dreaded “L word”, the unforeseen costs appeared in the form of new hardware and other costs hidden along your growth path. Ask yourself a few simple questions that can help uncover those costs up front.

See Our Infographic: Avoid the Hidden Costs of Software here

Where does it run?

If it’s a hardware appliance, it lives in your data center, with all your other hardware and software, and all the incumbent costs of that. I say "it", but I should say "they", since you are going to have to buy at least two units for failover, or more depending on traffic or distributed geography. Virtual appliances replace purpose-built hardware with buying, provisioning, installing and maintaining servers, which still might be in your data center, but could also be either on a private or public cloud. Either way, you are paying infrastructure costs, data transfer and bandwidth costs, and everything else that goes with that. In a multitenant SaaS implementation, of course, all of this is included in the service fee.

Who runs it?

Your staff, of course. Large companies are often pretty good at tracking this and estimating the cost of maintaining systems. Smaller companies, though, often mistakenly assume that since they are paying people anyway there is no marginal cost. Quite the contrary - in a small company, talented engineers are the dearest resource, and the opportunity cost of dedicating talent to learn, deploy and manage third-party hardware and software means that they can't spend the time building and implementing a feature that will allow you to launch your next version, or doing whatever it is that only they know how to do to contribute to your core mission.

Provisioning

If you buy an appliance, or a virtual appliance, it needs to go somewhere. Hardware needs to be provisioned. Network infrastructure needs to be configured to work with the new system. Monitoring needs to be set up (and paid for). Since it is something new and different, plan on enough training and experimenting time (and cost) for your talented and experienced sysadmins and network administrators that they can configure and test the whole network to be sure that nothing else broke when they set it up. Then you have to analyze the impact the new traffic will have on your network and potentially reconfigure it or even upgrade it.

Virtual appliances have no less of a time and cost impact – in fact, there are often additional complexities to provision, test and run this ersatz “cloud” solution.

Suppose time-to-market is critical, and you can’t wait on lead times to get hardware purchases approved and fulfilled? Will your infosec team have to review it before it can be installed? What if your team runs into installation snags or questions outside of tech support hours? And, of course, as you scale, you are provisioning more, and if you want failover and multiple locations, it just keeps getting more and more complicated and requires more and more time from your staff.

These same people will need to be around at upgrade time, or the new person doing the upgrade is going to have to learn all about it before they get started - and hope that they don't break it when they do (and be sure you set up a fully redundant sandbox environment to test upgrades before rolling them out).

Or you could opt for a SaaS solution. Your IT staff will be focused on running your core systems and not wasting time and money trying to figure out and manage your API management solution.

What About Maintenance and Upgrades

First off, you need to maintain that software and buy upgrades over time. Often those costs come as a shock to companies who thought they had bought a "perpetual" license, as SAP learned the hard way a few years ago. Upgrading and support are rarely optional; if you don't stay current you open your system to security risks and don't have the benefit of bug fixes and new features. With SaaS, upgrades are delivered at no additional cost to the customer, and every customer is always running on the most recent version. There is no risk that you "missed a security patch".

Security in a SaaS solution is another topic for tomorrow, but in any TCO analysis you have to factor in ongoing security and compliance costs. If PCI compliance is important, you will have to add any new hardware or software to your own PCI audit and scans; a SaaS solution which comes with PCI Level 1 certification and a Report on Compliance (ROC) allows you to rely on the vendor's certification for your compliance audit.

What If It Fails?
How important is it if your API goes down? Will critical partners be unable to access your service? Or maybe more importantly, can your technology fail gracefully in a way that doesn't result in long timeouts and a bad user experience for your partners' customers? If you need your API management to be reliable, you need multiple geographic locations, multiple networks, and multiple people on your team who know how to handle failures. Plus all of the infrastructure and configuration needed to effect failover with minimal downtime. Which probably means more hardware, more provisioning and more software licenses. Every one of Mashery's customers, no matter how small or how large, enjoys automatic failure to multiple geographies across two completely separate networks at no extra cost. It's included in the price, and managed 24/7/365 by our operations team (who are, themselves, located in multiple geographic regions).

Can I Afford To Take a Chance on Growth?
We'll talk about the ease of scaling in my final part of this series, but there is a significant hidden cost in planning for scale. In a multitenant SaaS solution, scaling is the responsibility of the service provider, and multitenancy allows a quality provider to overprovision for spikes in usage. In the appliance/software model, it is your responsibility to have sufficient infrastructure to handle the peak demand you anticipate (with additional headroom for growth) - and you are paying for that all the time, even when you don't use it. Which means more licenses, more hardware, more provisioning...

It's a bit surprising to me that there is still even a debate on things like this. Perhaps it's because I spend so much of my time talking to customers who have looked at TCO and come to the obvious conclusion that multitenant SaaS represents the most compelling value, and to investors who see the wisdom of backing companies that are delivering this value to enterprise customers. On the other hand, perhaps it is because even with a compelling TCO argument, some people still are concerned about the risks of a SaaS solution with regard to security, scalability, latency and reliability. We'll take those on tomorrow, in the third and final installment of this series.

-----
Read Part 1 | Read Part 3