Intel has recently been gaining some chops in API Management. We acquired Mashery and Aepona this year. Mashery you will (or should) know but Aepona, you may not have heard of. They’re likely behind many of the telco or utility services you use. They build and support the API platform need to run and charge for the business.
I’m between conferences at the moment. I gave several talks at Nordic APIs on API management and protection a few weeks ago and will be doing similar at Apps World next week. One concern that keeps being raised, particularly from developers with enterprises is that they have a wealth of internal services, data sources and ideas to make money from exposing data but no convenient way to expose them as a RESTful service that’s likely to be used by either partners or public developers. As marketing or IT or whichever dept kicks off this idea to externalise data they hit the barrier of what legacy infrastructure they have compared to what they need.
As I go around companies typically I will see that they have data accessible via SOA, messaging middleware or SQL, all with differing authentication and identity handling but which needs to be brought together to form a coherent API. This is where the concept of surfacing comes in.
sur·fac·ing [sur-fuh-sing] noun
1.the action or process of giving a finished surface to something.
2.the material with which something is surfaced.
3.the act or an instance of rising to the surface of a body of water.
Until recently surfacing may have meant two dodgy looking blokes on your doorstep saying they have a truck load of tarmac round they corner they could get on your driveway for a few quid. From the definition above, I’m referring to the first of course; “The process of giving a finished RESTful surface to your existing infrastrucure”. This process happens in an API gateway, usually in your DMZ, which supports data transform, protocol mediation and identity mediation. This is so that any number of systems under the surface present a uniform set of interactions above the surface. In other words, API Management.
Surfacing with a gateway then becomes a method by which you scale out both the number of APIs and the messaging throughput. Your gateway should talk to the portal which advertises and defines your API, allowing you to grow, monitor and charge for more usage. It also becomes the focus for new backend integrations required for new APIs. What you should be looking to do is eliminate having a spaghetti of code and custom adaptors built out of Apache Camel or your ESB of choice.
You can liken it to an iceberg, there’s a lot lurking underneath that’s brought together at request time but all the developer sees or the app user sees are the nice white peaks of RESTful APIs and functional, fast apps which are quick on the market. Don’t carry the metaphor too far, icebergs have some down sides so don’t watch this video…
You’ll remember my title, “Doing APIs now or doing them right”. Is there some magic architecture to marry up the services you have with the way they should be? Probably not. I was kidding though. Doing APIs now is right. There is an opportunity cost involved in delaying what you want to do because your competitors are already pressing ahead. You may encounter people in the organisation who have sunk cost into a half complete SOA architecture or whatever you have. Rolling up your collective sleeves and getting involved in changing the whole IT architecture is like the tail wagging the dog for just standing up some APIs for your first few projects. An API gateway gives you the freedom and versatility to bypass architectural difficulties and get to market quickly for once.
To learn more about API management you can visit Mashery’s resources.