Monday, August 24, 2009

Fatal Flaw in Cloud Based Social Media Apps?

For the purposes of this post I'm going to define "cloud computing" as a service that allows you to easily run your application on someone elses' infrastructure, and importantly, within their IP address block range.

As "web app" web API usage continues to grow, the significance of the long forgotten IP address as a fundamental application stack component grows along with it.

Public facing web APIs are accessible via publicly facing IP addresses, by applications running on other publicly facing IP addresses. When the demand for a polled web API outstrips supply (artificially imposed or otherwise), engineers throttle access to said API based on the consumer's IP address. The consuming IP address is the only guaranteed uniquely identifiable attribute of a "web app." Therefore, it is the one thing that can guarantee the rate-limiting of a resource.

This was all well and good when standing up your web application in an environment with its own IP address was relatively difficult. However, with the advent of Google App Engine and Amazon Ec2 "clouds," "web app" deployment is trivial. The result is a lot of software utilizing a relatively constrained resource; the IP address.

The overuse and abuse of web APIs is well documented and many services have been brought to their knees as a result. Operations teams have had to fall back on age-old IP address blocking techniques in order to protect themselves. Unfortunately, for cloud computing services, this means their IP address blocks/ranges are often black-listed, which leaves legitimate web applications built on top of them out in the cold.

The historical parallel to this kind of black-holing of IP address ranges goes back to ISPs restricting email from servers which would consistently allow spam through their gateways. Any email provider of size has black-lists of known wrong-doing IP address blocks, to ensure their system's (and their user's) aren't crushed by the onslaught of spam. While a reasonable model for blocking spam, the thought of the same model being used to control web application innovation is frightening.

That said, the market will decide whether or not the IP address will remain the canonical access regulator. In many ways any other version of the future is incomprehensible, but now that the IP address has become such a fundamental part of an application developer's daily life, I have to think a new construct for cross-machine communication will evolve.

Cloud providers can either live with the fact that their IP address blocks are being limited, and have web API leveraging "web app" developers move away from their platforms, or they can work to find a solution. Unfortunately for them, their entire frameworks currently revolve around relatively contiguous IP address blocks, and changing that isn't easy given their operating scale.

As with any constrained resource, developers will work hard to obtain it, and web APIs are no exception.

Monday, August 17, 2009

Dirty Data, Python & Gnip

I've been tinkering with Python (2.5) over the past few months; both in Google App Engine, and in free-running apps/processes. My initial free-running apps ingested "structured" content from a variety of web APIs, and would crash roughly every 12 hours, and would need to be restarted. Subsequently I took a "short-lived" process approach to managing these apps; cron would monitor them to make sure they were still running, then restart them if they'd died.

More recently I built an app that digested data from a known clean API (Gnip). Digesting data from Gnip ensures consistency in data format and structure. As a result, the Python app has been running for several days without issue. Now, of course the initial app crashing was due to bugs in code I wrote, but bulletproofing against broken/dirty/poorly-encoded/inconsistently-encoded data coming from random web APIs is a pain. Covering every case in modern apps takes a lot of energy. I opted for the "bounce it" strategy rather than to debug the issue (a major time sync due to variability and inconsistency; any engineer's worst nightmare).

The new application has instilled faith in Python as a choice for long-lived app processes, and reinforced how important clean input data is.