I recently attended the API World conference in San Jose, CA, to find out what is the latest and greatest in this domain.
“Wait,” I hear you exclaim, “aren’t APIs a techy, developer topic? What is a product manager doing at an API conference?” I’m glad you asked ?
“API” has become a very overloaded term over the years. At its simplest technical definition, an API is an Application Program (or Programming) Interface which is a set of clearly defined methods of communication between various software components. In the digital economy, however, they have become much more. They are accessible, discoverable, highly available, and managed as products.
In recent years, several business-oriented sites, including the Harvard Business Review and Forbes, have been expounding APIs as assets that can be leveraged as part of a business’s digital transformation strategy. As described by Forbes, “Digital [and API] transformation strategies are part of a shift… from: supply-side thinking (in which a finite supply of goods and services was viewed as the dominant economic factor) to: demand-side thinking (in which demand can be amassed behind infinitely scalable digital assets, then leveraged).”
Dipping my toe into the journey towards API as a product, I discovered a mysterious world with concepts like monoliths, microservices, serverless APIs and API gateways – all of which was discussed at this year’s API World conference. Here is a quick rundown:
Monolith or monolithic systems: this is what most of us are familiar with – the application system that has grown over time, is built as a single unit, has a single code base, and changes require a redeployment of the system, with the inherent effort and risks. Certainly doesn’t sound like an ideal environment to aspire to, does it ?
Microservices: microservices is an architectural style that can “break down the monolith”. Microservice architecture takes each element of functionality and makes it its own service. A microservice is a small independently deployable component that runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
Serverless APIs: calling an API “serverless” is like calling the meal you ordered in a restaurant “kitchenless” – although your own kitchen wasn’t used, there is definitely a kitchen involved. In the case of serverless APIs, the developer doesn’t need to worry about the server, and can just concentrate on the code, and leverage a “function-as-as-a -service” (FaaS) service like Amazon’s AWS Lambda.
This allows for zero administration (no configuration, and the cloud provider manages everything), pay-per-execution (only pay for the resources you use, with no need to pay for idle time), microservices deployment, and event-driven functions (serverless functions are stateless and dormant until given an event to react to).
API Gateway: with microservices, you will have many different endpoints, possibly numbering into the hundreds or even thousands, which can be difficult for users looking to consume these services. An API Gateway puts a façade in front of these services, allowing for an easier entry, and providing directory and discovery functions, making it easier for people to find your APIs.
These gateways can also provide functionality like authorization (ensuring the APIs are only accessed by those authorized to do so), rate limiting (preventing someone from flooding you with requests), and security (key management, ensuring the data is transmitted in a secure manner), along with other functionality. An organization can create and run their own API gateway, or partner with a provider (Amazon, Microsoft, IBM and many others provide this service).
