Taming the API Sprawl | @DevOpsSummit #API #DevOps

Ten years ago, there may have been only a single application that talked directly to the database and spit out HTML; customer service, sales – most of the organizations I work with have been moving toward a design philosophy more like unix, where each application consists of a series of small tools stitched together. In web example above, that likely means a login service combines with webpages that call other services – like enter and update record. That allows the customer service team to write their own tools using the web, the command line, scheduled, or any other interface.

Sound too good to be true, doesn’t it? It is true, but it comes at a cost. For example, I never defined a mechanism to manage the explosion of APIs that will result under this approach. Consider this: uncontrolled growth is one definition of cancer.
Since the rapid creation of APIs is not quite so deadly, I will call this the API Sprawl; I’ve seen it across every client that moved to web-services approach, typically two to four years into conversion.

read more