3AS - already the present & definitely the future!
Did you know? API is as old as 1940s & the world seems well aware of it today. API as a Service (AaaS / 3AS) may be new to most of you although it is the present & here’s a dive-in to it's future.
Evolution
Contrarian to common belief APIs weren’t invented in the early 2000s, it is as old as the 1940s and is more of a concept that was discovered than invented by two British scientists Maurice Wilkes and David Wheeler who were working on a software library for a von Neuman based EDSAC computer.
Although they didn’t specifically coin the term API, the structure of the guide they built and the style of documentation that they followed included detailed instructions of how to access the library or make a call to a specific part of the library fitted the description of today’s APIs.
It evolved much later in 1968 when Ira W. Cotton and Frank S. Greatorex published an article with a reference to the term API, leading to another specific reference by CJ Date in 1974 when he took to explaining the relational and network approaches of databases which ultimately led to a much wider acceptance throughout the world which then transformed into a concrete definition of the API by Carl Malamud in the 1990s.
(Jump to the references section at the end of the article for more info about API history)
APIs Explained
“APIs are a set of services that are made readily available to the programmer which he references and uses in his application to perform specific tasks”
- Carl Malamud, 1990
For those of you who are relatively new to this term (although I guess this sample space could hardly be less than 10% of the world today) it is essentially that bit of software that sits on the application layer and lets your App communicate with and access / exchange data seamlessly from another application on the web almost similar to it querying the back-end.
APIs too have come a long way from where it all started and we have one such term RESTAPI (Restful API) that’s pretty widely known at least over those who are involved directly / indirectly over any phase of building products or getting their hands dirty with the development / design of Apps. RESTAPI provides a way for your App to communicate with the backend / data store for CRUD (Create, Read, Update, Delete) operations as there’s hardly an App in the world today that doesn’t seem have an interface with storing and retrieving data.
One classic example here would be Uber’s acclaimed conceptual design based on Maps. When you open Uber’s app it makes an internal call to Google Map’s APIs to communicate, access & render your source and destination locations adding to a smooth UX while looking for your trip. But brace yourself, the API calls that Uber makes aren’t just limited to that. There could be over a half a dozen APIs that your Uber App talks to internally so as to facilitate everything you see rendered on your screen.
Here’s a view of the basic APIs your Uber app could be talking to over an outcome which is - “the completion of one trip”.
NOTE 1: This representation holds for the USA although it is a no-brainer that some APIs like for instance: [Payments] ought to be localized to the geography Uber operates in so as to stitch a seamless UX for the users and enable the usage of products within that ecosystem.
NOTE 2: The actual number of APIs / API calls your Uber App makes may be more than what’s depicted in the figure above. For instance, in some geographies your OTP reaches you on your mobile device via an SMS which could be rendered by using another API.
NOTE 3: Your Uber app could make internal API calls to its’ own resources for facilitating stuff like for instance [ride sharing over Uber Pool] or whatever else that service could be termed in the other geographies.
3AS explained
Ever since the advent of cloud, the evolution of cloud native applications & all the infrastructure demands from the world over, APIs are being employed ubiquitously & it is the core / backbone of each and every App, more like you saw in the Uber example above. And, that’s only going to see an alarming increase henceforth as there seems to be many de-facto Apps that a user would quote / a business would want to integrate with as soon as one talks of a particular niche.
For ex:
talk of CRM you have SalesForce, HubSpot &
one could quote CleverTap when one’s talking about CDP
With the number of Apps increasing by the day and the users adopting them into their workflow given it’s USP / a unique approach taken to solve the problem, the need for APIs so as to be able to connect all the Apps seamlessly & exchange (send / receive) data as required is only going to rise.
That makes more than a case for something like AaaS / 3AS (pronounced - “Three ‘A’s”) which is “API as a Service”.
Difference b/w iPaaS & 3AS
Although not altogether as common as the other cloud delivery models like SaaS, PaaS the iPaaS has its own niche in the market.
Here’s a definition borrowed from Gartner:
“Integration Platform as a Service (iPaaS) is a suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on-prem and cloud-based processes, services, applications and data within individual or across multiple organizations”
Although it is not apples and oranges there seems to be some confusion between the 3AS & iPaaS but there are very significant differences.
Here’s a compilation of a few of them over the top:
The Future of 3AS
Just hark back over the past 20 years and you’d see how coding has changed significantly, more so rampant in the past 7-8 years. Earlier programmers would get down to coding almost each and every element minor to major that’s seen on the UI apart from the other ones forming an integral part of working software but isn’t visible as it isn’t a part of the presentation layer. And that holds equally for being able to capture some hardware device and communicate with / control it’s behavior or hinging on other applications online to exchange important information as required.
So, as of today you have programmers who search - find - fork / reference & integrate code snippets to whole projects into their local workspaces and build on it thereof than looking to redo the whole thing from scratch.
APIs aren’t any different at all.
I also asked someone who is an expert in the field of APIs - Deepa Goyal who is presently Product Strategy Lead at Postman & also a data nerd and the author of “API analytics for Product Managers” about the future of this tech.
Here are a few thoughts:
1. Yin and yang
Given how this space is evolving currently a lot of the relationship could be ying and yang enabling more and more disparate apps to hinge on these APIs so as to effectively fit in to the ecosystem of products already being used and be able to enhance the product building experience furthermore for the developers, product folks and ultimately speeding up delivery times affecting TTV super-positively.
2. Plug and play
Given how writing code has evolved to what it is largely today where searching over a repository and referencing the best snippet of code is made feasible, the need for a plug and play sort of an API solution is already being felt in different pockets of the world which is only bound to increase going ahead.
3. Monitoring analytics
An API going down somewhere would almost be akin to a ton of bricks crashing down on someone’s head as the maximum insight one could have access to may be, “Internal server error / Host not found” alongside some alphanumeric error code. Also, to cope with, the lack of clarity over the downtimes may rub more salt to the would and may not at all be simple to deal with. Given how 3AS may take over, the need for APIs to get more sophisticated and transparent in terms of being able to point to exact location of the error & with a snippet of info about the TAT is a given as for the expectations of the market, detailed dashboards could become a big reality as well.
4. AI intersection
The advent of disruptive tech (AI) has brought more awareness into the market as much as it has shot the expectations through the roof as well. It’s only but given as to how 3AS could work tremendously for the developer / product building community so as to run a few basic prompts over describing the requirement and looking for the exact (or the most probable) match in terms of an API provider, what’s more - there could also be cases where the AI could generate suggestions so as to enable working on a shoestring budget rendering it all over a really smart comparison of all parameters deemed imperative.
5. Tech Inclusion
Tech in general and AI in particular is advancing as it has been for over 2 decades as we know it. But the question is “how much of that breakthrough AI has been bundled into products and made available to the masses”? The answer obviously is not cheerful as there could be many logistical complications over it as much as there is no denying the fact that the org. building that AI tech isn’t prioritizing the delivery as much as it is looking to stich a product around it looking for use cases. Imagining 3AS as a centrifugal tech controlling all else, APIs could very well be used to expose the capabilities of AI furthermore making it more accessible to the entire world. This not only opens up a ton of opportunities for such products & businesses but could also mean more and more people would have access to big & breakthrough tech as it is being built - not to overlook “building in public” either.
References
1940 - Wilkes and Wheeler, The Preparation of Programs for an Electronic Digital Computer
1968 - Data structures & techniques for remote computer graphics by Ira W. Cotton and Frank S. Greatorex
1974 - The Relational and Network Approaches: Comparison of the Application Programming Interface by CJ Date