APIs Are All About The Cloud - Why Build Them on Old-School Software and Infrastructure?
This is the first in a series of three posts by Mashery co-founder and CEO Oren Michels that examines the advantages of using a genuine SaaS solution to manage your API and the hidden (or obvious) costs and challenges in deploying an API infrastructure using the model of appliances and licensed software. The series begins with a general overview of SaaS and the cloud from an API perspective.
It's hard not to feel a little nostalgic these days: Madonna performed "Like a Prayer" at the Super Bowl halftime show; Newt Gingrich is back in the headlines; and retro glasses from Warby Parker are all the rage among the cool kids set. And yet again we're treated to warmed-over SaaS FUD from incumbents who have to defend their enormous investment in the old model of using hardware appliances and licensed software to help companies solve problems that can be solved faster, more economical, and more scalable by using a SaaS delivery model without sacrificing security and with (depending on the use case) better or equal latency.
Don't get me wrong - appliances and on-premise licensed software still have their place. Sometimes they’re the best ways to solve some important problems. For instance, when you have to solve particularly tricky data integration for a couple of partners at very high volumes, it’s often easiest and most economical to have your IT team configure a gateway to handle that volume of data.
However, when it comes to API management challenges faced by enterprises today, the old appliance, or single-instance approach, simply cannot keep up with a modern architecture built from the ground up as a multitenant SaaS solution. And for those times when security or latency demand that traffic be managed on-premise, a hybrid solution - available today - provides a single control center for managing all API activity across both cloud-based and local traffic management nodes. It is the only way to meet both the business need - for short time-to-market, consolidated reporting and management, and low cost - while still meeting the IT organization's requirements for security, scalability and reliability.
You also have to wonder about the logic in managing APIs in an environment as anti-cloud as appliances (hardware or virtual) or licensed software. After all, the very essence of the cloud requires APIs; without them, the cloud would just be a bunch of computers working in silent isolation. You either have APIs and the cloud at the core of your company culture and mission, or you don't.
The Cloud Advantage
Back in 2006, a post about the advantages of SaaS by Microsoft - of all companies - tied "cloud" and "SaaS" together in the continuum of "location" for traditional vs. cloud implementations, pointing out that "today, SaaS applications are expected to take advantage of the benefits of centralization through a single-instance, multi-tenant architecture, and to provide a feature-rich experience competitive with comparable on-premise applications." This statement is as true today as it was when it was written seven years ago.
Why is that the case? Because of a number of reasons, companies delivering a wide range of platforms and applications have been moving toward the multi-tenant SaaS model for years. As Phil Wainewright points out, multitenancy is a necessary and defining characteristic of the cloud:
"Sharing a single, pooled, operational instance of the entire top-to-bottom infrastructure is more than simply a vendor convenience; it’s the only way to really achieve cloud scale. Look beyond the individual application or service and consider also the surrounding as-a-service infrastructure and any connecting framework to other cloud resources. Understand the value of having all of that infrastructure constantly tuned and refreshed to keep pace with the demands of its diverse user base across hundreds or even thousands of tenants. The most conservative among them will constantly probe for potential risks and weaknesses. The most progressive will clamor for new functionality to be brought into production as rapidly as possible. Every tenant benefits from sharing the collective results of those two extremes and all points in-between, keeping the shared infrastructure both battle-hardened and future-proofed. Every tweak and enhancement is instantly available to every tenant as soon as it’s live."
This is the way the world is moving, for us and for many other businesses. Mashery has weekly releases of bug fixes and new releases. All of our customers benefit from them as soon as they are ready for general availability.
Salesforce.com CEO Marc Benioff says, beware of the false cloud!". Speaking about virtualized appliances that do not "provide elasticity and scale on demand," Benioff warned an audience in 2011 to not be fooled. Though relieved from server closets, virtualized appliances require you to spin up additional instances and configure them to run as you scale. To avoid this, one must build, configure and manage some pretty complex infrastructure, because they do not automatically fail over to redundant networks or data centers unless you purchase, configure, and manage infrastructure to do so, and have 24/7 coverage to manage outages when they occur. And even then, you do not provide for a single, unified set of infrastructure and management of your API across locations. Virtual appliance form factors are still appliances - isolated units that need to be individually managed, and the complexity of that management increases with redundancy in physical locations and networks. It is a lot of work, but an enterprise-grade API management solution needs to have this redundancy to weather the outages of even the most sophisticated cloud infrastructure providers.
Back to the future
It seems so long ago that Siebel tried to get everyone to believe that SaaS could NEVER handle the needs of the Enterprise. It's been a decade since 2002, when Siebel's CRM market share peaked and its stock price came down to earth.The following year Siebel announced the future launch of an "on demand" (the old term for SaaS) offering, initially by rebranding Upshot, which it acquired in 2003. Two years later Siebel was subsumed by Oracle; at the time, analysts commented that the acquisition signaled a Oracle’s strategic shift toward SaaS . By 2008 most of the major enterprise software vendors had begun to embrace SaaS as a model - appropriate for many business applications, though the cultures in those companies had varying degrees of success embracing that evolution. None of this was clearer than in 2011, when SAP purchased HR software vendor SuccesFactors for $3.4 billion to effectively secure a foothold in the cloud.
Back in the day, plenty of incumbents sought whatever soapbox they could find to preach the evils of SaaS (ironically, this guy is now running his company on SaaS-based apps and recognizes all the benefits that the model gives him; although, he still has not figured out how to ascribe value to all the things he DOES NOT have to do on the IT side so he can concentrate on writing blog posts and giving well-received, inspirational talks to exterminators in Florida.) Evidently he is among those to whom Total Cost of Ownership, or TCO, isn’t part of their SaaS toolkit.
In part 2, we'll take a look at the ROI from a SaaS-based solution and talk about the TCO of an appliance/software implementation model as compared to that of a genuine multitenant SaaS implementation. Then, in part 3, we'll look at the non-financial factors that go into this decision - things like time-to-market, security, scalability, performance and reliability.