I had a discussion with George Reese on Cloud and API’s, starting with me saying I’d support a maximum of 3 different API versions, and off went the discussion.
His “Max 3 versions? Do you hate your ecosystem?”, “What do you mean there’s no such thing as a public cloud API?” and “When you cease to support a version of your API, you kill your ecosystem.” were puzzling, and he ended with “The bottom line is this: If you decide to change your API, who should bear the costs of that change? You or your ecosystem?”
Let me try to explain here what Cloud is, what API’s are, and what cost is
Cloud is a blanket term covering Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). An Application Programming Interface (API) is a term that has come to be somewhat abused over the last years as something Holy-Grail-ish, yet merely implies a method, defined by the application (designers / developers) itself, to interact with the application
In a Service Oriented Architecture (SOA), such an API would be called service. In Integration, it’d simply be called interface. In Cloud, it wouldn’t exist: a Cloud API would be just as sensible and meaningful as a Personal Computer API: there is none
An API describes a specific functionality in a specific semantical and syntactical way so it can be used outside its own environment: for instance, you can converse with me about application integration via Twitter. An API connects to the application layer via the infrastructure layer: the application is the first point of contact here
An API is a program, that has been designed and built, and needs to be supported. API’s evolve along with the application or system itself, and whenever a specific functionality changes, so (in general) will the API: it will be released as a new version that discloses the added functionality, and will almost always do so via a new syntactical form as well.
“The more the merrier” is not a true statement here: yes the business is pleased to introduce new functionality to its customers and suppliers, but if this happens 10 times a year, the IT-department will be moaning and groaning. And moaning and groaning IT departments mean money, cost.
Design, build and run for a new API release involve cost. Sustaining the old releases also costs, and at some point there will be a break-even point: the profit made from new functionalities will almost equal or even be less than the cost involved with sustaining old functionalities. Then what?
Then, the business-case for adding new functionalities has to be re-evaluated, simple as that. And if you’re following your business closely, you’ll want to do this before you hit the swamp knee-deep beyond the point-of-no-return
So, you will want to support a few versions of one and the same API, but not too many. After more than a decade of Integration, I’ve learned that posing no restrictions leads to dozens, if not hundreds, of API-versions over a few years time if you’re talking about an enterprise. SaaS will typically outsize an enterprise by a 2-digit factor or more, so guess what? You’ll want to restrict the number of versions
Three is a good number in my experience. With a bit of smart design you can even squeeze three functional versions into one and the same technical version so it’s fully backwards-compatible, and cost-efficient of course
Cost doesn’t exist on a standalone basis. Whenever you talk cost, you must also talk profit: they’re Yin and Yang.
Releasing a new API version costs money for the application provider, but it also turns into profit for the business: maybe they can increase their market share this way, retain market share while they were losing a lot, etc: that will be in the business case.
Using a new API release over an existing one by an application subscriber (someone who wants to use the functionality from outside) also costs money, but then again, that design / build / run will not be undertaken if there isn’t a solid business case on that side either.
If you’re a popular application provider, people might even want to pay more for using the new API release: money travels in mysterious ways
So, where is most of the cost located? In the very back at the application provider, where the old API releases support an ever-shrinking number of application subscribers. You can charge more for their use, but that won’t help in or even near the end. At that point, it’s becoming an expensive ball-and-chain that you want to get rid off.
For old-fashioned distributed systems (like e.g. Microsoft’s operating system), the solution is easy: you just end support and your problem is out of sight, out of heart.
For new and shiny centralised systems (like e.g. SaaS) that is a bit of a problem, as they have to go through you whenever they use their old near-deprecated functionalities. You can increase cost, squeeze bandwidth, limit upload and / or download size, and torment them in dozens of ways – and hope they just go away
Or, you can simply support only a number of versions – let’s just say 3 – and prevent the entire problem from becoming one. What would you do?
(Cross-posted @ Business or Pleasure? - why not both)
I, too, think quite a bit about the *cost* of releasing APIs for distributed network apps (“Web apps” in the pas, “Cloud apps” today, etc.). I work w/ a handful of SaaS providers that are also very focused on the cost/benefits of APIs.
Over the last several years I have adopted an approach to providing APIs for dist-net apps using the following general guidelines:
- “No Versions” – there is only one version of the API, do not release v1, v2, etc.
- “Perpetual Release” – the API MUST have the ability and stability to grow and change over time.
- “No Sunset” – the public API details released five years ago MUST still work today
To pull this off, there is a fundamental difference in the way the APIs are designed. They do not rely on RPC (SOAP), Object Graphs, or URIs rules to expose functionality. Instead they rely on Hypermedia (links and forms); even in XML and JSON formats. This means new procedures, objects, and new URI rules can be safely added w/o having to re-write the client code, w/o declaring a new “version” of the API.
In my experience, this has reduced the cost of maintaining the API (both short and long-term) and reduced the cost of maintaining the clients (long term as initial construction takes a bit more work). More importantly, it has been a big benefit to third-party client creators as they are not required to repeatedly re-write their app as the API grows over time.
I do not (yet) have real numbers on this work (it takes months/years to accumulate the actual data) and am very interested in efforts to quantity the actual costs in these various appraoches.
Thank you Mike, very interesting.
API’s should be seen like letters in an old-fashioned snail-mail envelope: there is no relation between them at all. You just put a different recipient on the envelope and off you go, or you put a different letter in the current one. It is up to agreements explicitly made whether you can use the interface of course…
SOAP, XML, URI’s and REST have nothing to do with exchanging information and are overly complicated: an interface is just a function – it takes a few values (some optional, some mandatory) as input, and spits out another few as output. Then again most API’s don’t even have a functional description of the inputs and outputs, let alone which ones are optional or mandatory. Twitter would be a perfectly bad example here
If you want to not force changes, make sure that new functionality is optional at the highest level, and you’ll have technical backwards compatible API’s for centuries to come. However, there must be a sunset; hence my three versions