Application Infrastructure race in the clould

Today Intalio announced the takeover of webtide ( the maker of Jetty) me and my friend (an ex Intalio employee, and both of us being old middle ware hands) realize that this is the race for owning and proving the complete application infrastructure on the cloud.

Oracle with its acquisition of BEA and SUN in uniquely poised to provide a complete application infrastructure ( the whole enchilada) on the cloud.

I am also looking forward to when VMware would provide us with Virtual Middleware with VMware and Springsource technologies.

The Race is on ....

what is an API ?

I met a friend after a couple of years and we started talking about our work. We started talking about API Infrastructure and midway thru the discussion he asked me a very simple question. what is an API and how is it different from a Service , Why is a service Bus infrastructure different from a API Infrastructure. At that moment I realized that this is question that i should have answered first and here i am writing it down.

api definition:
- An api is reusable asset which can be invoked on the web. As a reusable asset the api can be combined/invoked from another website/mashup/application to add value for e.g. retrieving the List of Movies I have watched on Netflix over the last week and displaying it in my website.

what is the difference between a Service Infrastructure and API Infrastructure

I sometimes use services and apis in the same context and there is no difference between the two in my mind however architecturally there are two types of services

a) services which i create within my application/enterprise for business process reuse and loose coupling between the various technology stacks available. This is the soa story and i am not going there. there are enough products out there which can solve the problem

b) service or APIs which i create so that they can be consumed by my partners /consumers or even shared across departments and services which i consume from other guys.

From a technology perspective "a" requires "Service Infrastructure" while "b" is the "API Infrastructure"

• "Service Infrastructure" is about integration of services while "API Infrastructure" is about producing and consuming apis/services.
• "Service Infrastructure" is part of the middleware technology while "API Infrastructure" is more of a gateway functionality. In "Service Infrastructure" i am trying to integrate across disparate technologies how to integrate with ftp/email/jms etc while "API Infrastructure" is about exposing apis via http as POX/REST/SOAP
• the concerns of "API Infrastructure" are security,scale, sla& monitoring,visibility instead of transport mediation/data mediation/process orchestration. If i am 1800Flowers.com and exposing an api to buy flowers then i would be concerned of making it available on the web with regards to scalability and security (for e.g. how can i guard myself against XML xDos/MDos Attacks) on the other hand if i were an enterprise doing service integration i would looking at how can i expose my Messaging (JMS) backend with a HTTP front end and do not end up having duplicate messages , architecturally an API Infrastructure sits in front of the Service Infrastructure.
  

Adoption of Enterprise 2.0/N.0 == More API Traffic
-------------------------------------------------------------

Enterprise 2.0 as an idea was floated as an idea late as 2007 and my interest in Enterprise 2.0/N.0 stems only from the product engineering perspective and the new infrastructual requirements it poses.

What is my version of Enterprise 2.0 ( i can see you guys rolling your eyes but give me a hearing first...)

For me the definition of "Enterprise 2.0 is the successful adaption of social software platforms within companies, or between companies and their partners or customers". I have to say "successful adaption" because i do not think the enterprise will adapt the web 20 completely, Enterprises will never give up the control but they would like to adapt the practices of web 20 with regards to collaboration & self service and agility and adapt them into the enterprise.

How will they get manifested within the Enterprise:

I would like to see "Boeing" build its next generation "Partner Management/Tracking Platform" using mashups and social software paradigms , the idea of having the "part tracking" portlet implemented as a mashup and exposed as a widget of choice on someone's iphone, blackberry which is very salivating thought.

With Google announcing SDC and vendors providing support means only one thing i.e. we are going to see more api traffic coming from the enterprise and thats a very good thing.


End Result
more APIs /more enterprise data getting exposed/ more traffic.... how are you going to manage this ?

APIs Do we need a seperate Infrastructure ?

We as an industry have been talking about apis since 2007 (when web sites become web services) and with the recent success of guys like twitter (Twitter Traffic is 10x times its site) we are starting to hear more about apis.

My colleague (Greg) recently blogged about what is an api, it gives a good definition of what an api is and raises some important questions that everybody needs to ask, whoever is looking to build an api.

As a company/user who is starting to go down the API path the subsequent question that it needs ask is do i have an existing infrastructure which can handle the requirements rasied by Greg.
Some of us might say yes, we have the infrastructure to do that or there are existing products which can help me manage my apis, but do we have the "complete and comprehensive infrastructure" to cover all the requirements.

I can possibly take an existing open source stack or some Middleware product and say it provides me the capabilities but does it also do the following

• does it give analytics for e.g. Netflix launched a API and is now integrated into Facebook, Netflix would be intersted in knowing what are the top apis, who drives more traffic facebook or myspace in other words can the infrastructure provide me with information to make business decisions.
• Does the infrastructure provide me with SLA and alerts so that i know when my api is down or not behaving properly.
  
• How flexible is the deployment model of my apis so that it can change to the ever changing business needs, in other words what is the life cycle management of my apis in a ever changing world
  
• If i am Boeing who is exposing an api to my partners can i assign different rate limits to different partners , i am paranoid about security/compliance/data security can the api infrastructure help me with that.
• Does it do intelligent caching
  
• If i am an enterprise who is consuming a lot of web Apis how can i use this infrastructure to manage and control the apis i am consuming within my enterprise (this is a discussion for another day)

On top of this do i have a robust infrastructure to scale to the requirements of the web. (Each of the requirements above probably require a dedicated blog so that's a task for some other day)

Today is the day to ask whether we need a seperate infrastructure for apis and if yes then let ask for one.

Would like to hear from people producing and consuming apis what are some of the problems you have been facing and how are you planning to solve them.