The commoditization of technology has reached its pinnacle with the advent of the recent paradigm of Cloud Computing. Infosys Cloud Computing blog is a platform to exchange thoughts, ideas and opinions with Infosys experts on Cloud Computing

« Is your service ready to be 'API'-fied? (Part 1) | Main | Software is the New Hardware »

Is your service ready to be 'API'-fied? (Part 2)

In my previous blog, we looked at the data and security aspects that might hinder an internal service from being API-fied. In this conclusive part, we will look at the other two important aspects that needs to be addressed before internal services can be certified for API exposure.

 

Scalability is the next key area to talk about. Exposing APIs for external consumption can quickly lead to explosive growth in traffic due to genuine or rogue usage. Will the back-end applications, databases and infrastructure be able to scale as traffic swells? APIs exposed to external consumption usually have stricter service level agreements and financial implications to adhere to.  But that should not come at the expense of the internal consumers. Imposing usage quotas and throttling limits is just one way of managing growth in API traffic. A complete discussion on API scalability however merits a dedicated blog.

Last, but not the least, is service design. Service granularity is a tricky subject and in many cases consumers of internal services have to make several calls to the back-end to complete a transaction or achieve a functionality. While this might not be a big challenge for internal consumption, when it comes to externalizing these APIs, it makes the consuming apps unnecessarily "chatty".

Internal services are also often infested by the 'pass-me-back' syndrome i.e. sending pieces of data absolutely irrelevant to the consumer but required to be passed back by the consumer for future calls. The problem creeps in during early service design for the ease of processing and lives through internal consumption without much fuss. However, when the same services are exposed for external consumption, these design issues may be barriers to API adoption.

API Management products that are available in the market provide a lot of capabilities especially in the area of security and traffic management. But as you can see from this blog series, it takes a lot more than just a product to make an API strategy successful. There's no one-size-fits-all solution.


Comments

Will the back-end applications, databases and infrastructure be ready to scale as traffic swells?

Good one...

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.