“Mobile APIs - Optimizing APIs for many devices” Webinar - video & slides »

Thanks to all who participated in yesterday's webinar - " Optimizing APIs for Many Devices"  with Sam @sramji, Brian @brianpagno, and Greg @gbrail.

Here are the video and slides. We'd love to hear more of your thoughts and questions; please join the conversation on the api-craft forum.

Yin and Yang of APIs and the Cloud - Part 2 »

In a recent post I talked about how you need APIs as your business grows; how services need to integrate directly to a companies' business processes through APIs rather than indirectly through a portal or Web site. Check it out here.

This time, because APIs need to scale, I talk about how you need the Cloud to effectively manage those APIs and enable developers to be successful using your APIs to build their apps.

You need a cloud to effectively manage your APIs.

Let's start by comparing API usage in the traditional enterprise scenario with API usage in the growing API economy around social and mobile applications.

In a traditional enterprise model it takes years to build out the enterprise ecosystem of apps and the life span of an app is often measured in decades. Traditional enterprise apps connected to back-end systems are typically designed to carefully shrink and grow their IT capacity. Change is slow, IT requirements are predictable but capacity needs to be available to support maximum loads.

In the new API economy - in a world of mobile and social apps development - we're working in an environment of rapid innovation and a usage model in which we cannot predict or preconfigure capacity. IT needs are not as predictable as in the traditional model. Burstiness or spikes in requests happen as a result of a number of things: API access and usage changes from within apps, app users come and go, apps can get popular for a few weeks, create a surge in demand, then subside.  It's a rapidly changing environment in which you need to be able to scale and respond to rapid bursts of requests that create periods of peak system usage.

Hosting your APIs in the cloud offers the ability to provision and deprovision as needed. In other words, you can avoid spending at the peak rate - rather spend at an average rate and take advantage of cloud elasticity and burst as required in times of peak load. Several enterprise API customers already leverage the Cloud for variable capacity.

Should the cloud be internal or external to your business? Inside or outside your firewall?

Unless your app developers and the APIs they leverage are entirely within the walls of your enterprise, I recommend that your APIs are hosted in a cloud outside your firewall. There are a few reasons:

- The developers who will use your APIs - your audience -  are external to your enterprise and supporting these developers is priority.

- Those developers are familiar with using public APIs. Developers are busy building social and mobile apps meaning that they're comfortable in an environment in which they connect to public APIs offered by Facebook, Twitter, Twilio, SimpleGeo, and so on. 

- It is common for developers to use more than one provider's API in building their apps. If APIs are behind your firewall, you make it more difficult for developers to access those APIs as they need to navigate different firewalls and different back-end systems for the different APIs they want to use. This will adversely impact developer adoption of your APIs. 

In summary, you need a Cloud to be able to scale and respond to the dynamic nature of today's API-driven apps. The Cloud should be on the Web outside your enterprise firewall to effectively support your customers - app developers.

Yin and Yang of APIs and the Cloud »

Cloud services need APIs. APIs need clouds. They are Yin and Yang. If you are working with one, you are working with the other.

First the Yin – if you have a cloud why you need APIs?

One of the ways cloud services (IaaS, PaaS, or SaaS) achieve scale is through customer self-service.

This usually means a customer portal, through which early customers – usually small companies or a department of a larger company – set up and manage their service.

At this scale, “integration” is achieved through people using the portal to interact with the cloud service, which in turn,  ‘integrates’ into the business process.

At some point, the use of the cloud service grows to serve larger companies or a larger cross-section of a company, or both. Now, “people-level” integration through a portal is not enough -  the cloud service must plug in or integrate directly to the companies business process.

At this point, you need an API. 

Tim Madewell from Innotas, a leading provider of SaaS PPM (project portfolio management) services makes this point well.

“In the early days of our company, our average customer had 25-30 users.  But as we started to grow and the SaaS market became more mature, we started working with larger enterprise customers and the product needed to evolve.  When we landed our first 5000-user account, we found that one of many requirements was that we enable integration from their back-end CRM, HR, and billing system.  Exposing the API where the customers can ‘come and get it’ worked well for large customers.”

The transformation that Tim talks about is the change from “here is a web portal that you can use to govern your IT processes,” to “here are the set of entities that we manage, and now you can interact with them in the flow of your processes.”  This is the transformation that is leading thousands of non-cloud enterprises to move from “here is a web site where you can deal with us” to “here are the APIs and now you can work with us.”

This is a big shift for the enterprises, and a big shift for the cloud SaaS providers.  A similar shift is happening to the IaaS and PaaS providers. An example is GoGrid's cloud control APIs where an enterprise can manage cloud provided computing and storage resources in the same seamless fashion as managing their own, internal IT-provided resources.

At IBM, we used to say that hybrid cloud management is a critical future need and that integration will become a big challenge with the proliferation of clouds (see my post).

I did not realize then was that this requires clean (hopefully REST-based APIs) on the cloud provider side.  I also did not fully realize that this requirement extends all the way into the IaaS, PaaS, and SaaS layers.  Companies like Innotas have taught me that indeed, the cloud, like other enterprise systems and applications, needs APIs.

Next, the Yang. I will discuss how all APIs need to scale, and therefore need the cloud to be effectively managed. Check out Part 2.

Retail APIs and Garden Hoses: Making Things Grow in the Enterprise »

APIs are like a garden hose. They can make things grow.

Well that's what I was thinking as I tried to save my roses from the blistering summer heat here in Dallas, Texas. It really started to make sense when I snapped off my trigger nozzle in favor of a sprinkler. I have the quick connect system so it's a piece of cake to swap out attachments. The 104 degree heat was getting to me, and I started to imagine the hose being connected to retail information and inventory - the API being the quick connect and the nozzles being the interface to consumers.

I'm sitting on the patio at this point, the sprinklers doing the work now, and I'm thinking I should grab a beer and really see where this analogy goes. I watch the sprinkler go back and forth, spraying a pattern of precious water across the lawn - and on my FENCE!

No, the source of life cannot be wasted on a board-on-board fence. I get up and carefully plan my assault on the sprinkler, careful not to get wet (note to self: cold water pelting your body when its 104 is not something you should avoid). The sprinkler has all kinds of adjustment mechanisms. I can adjust the spray pattern left or right, long or short. I can control the amount of water going through the valve and of course there's a timer.

Ahhhhh, this like API infrastructure, the control panel for APIs. Crystal clear. Just like the mechanisms of the garden hose nozzle let your control and target different areas of your lawn, API infrastructure lets you optimize your API for various sections of the market - from mobile developers to affiliate marketers. And just like a great sprinkler system, an API infrastructure lets you scale up to cover your whole "lawn." Finally, API infrastructure provides visibility, letting you see where your services are going and how they are being used.

At its core, an API infrastructure lets you harness and control the power of an API and grow your market, just like a garden hose lets you harness the power of water to grow your lawn.

So you know what I did? The next time I went to talk to a prospect I carried a garden hose, quick connect and sprinkler with me (at least they will remember me).

Analogy complete. No!

One more beer (my answer to Job's "One more thing").

API.... A Profit Interface. Another entry on that soon.

Mobile Location-Based Services - don’t forget the Telcos »

TechCrunch recently posted on a Juniper report on “Mobile Location Based Services"  This report taps on the potential for this new wave of powerful apps – like letting your phone geotag the video you just took and posting it to Facebook with a Google Maps link;  one-button dial to a nearby restaurant discovered through your social network; or dynamically billing for high-value media content via the operator.  

Companies like Google, Foursquare, and Nokia are mentioned as on the forefront of many of these services.

But don't forget the Telcos - they have rich location based services with network data and a huge customer base.  Exposing APIs and working with third party content and service providers is critical for telcos and network operators. 

But Telco APIs can be complex.  Our view is that the Telcos that focus on making these APIs as simple and accessible as those from consumer Web players can be winners in MLBS.  We talk about these and other issues in detail in our new Telco 2.0 Whitepaper.

But can you hold the API to the SLA? »

Great article by Jonathon Feldman in Information Week recently with some steps for CIOs to take before getting into cloud computing.   One is to insist on SLAs from cloud providers, especially considering the natural tension from the provider's perspective between high-availability and low-cost operations.

Absolutely agree.  But to build on this - remember that scene from Seinfeld where Jerry is at the car rental counter -  "Anybody can *take* a reservation, the important part is to *hold* the reservation."

Often, cloud and API providers will agree to SLAs, but have limited means to enforce or verify the SLA is held. Many SLAs are just 'on paper' with minimal enforcement or monitoring.  This gets especially tricky if you need to discuss financial penalties. 

Consider how you will monitor, meter, and audit API traffic and content between you and your partners - from your side - in order to pinpoint problems, protect your organization, and especially if you need to enforce penalties based on SLA misses.