The BASIC Cloud Framework API

Last night, I spent the evening with a bunch of PHP developers in DC. This informal gathering in the DC-PHP community is a regular occurrence known as the DC PHP Beverage Subgroup – Virginia Chapter. There is also a DC-chapter that meets once a month as well. These two informal gatherings are for the sole purpose of getting together, enjoying some food and cold beverages and generally just talking about anything and everything. It complements the official DC PHP meeting which is generally a technical presentation directly related to PHP.

So last night, we were yukking it up about how PHP has re-invoked the GOTOoperator, a programming mechanism that, we thought, died with the BASIC programming language of yore. Coding in BASIC was very procedural and not very rich in its abilities.

1
2
10 PRINT "Hello World!"
20 GOTO 10

One of our number suggested that PHP, since they regressed so badly with the GOTO operator inclusion, should also adopt line numbers in code as well. :) This conversation devolved into all the cliché buzzwords of our time and eventually, it was suggested that what we really need is a “BASIC Cloud Framework API”.

Putting aside BASIC, which is not really practical or desirable, the concept of a Cloud-based Framework API, whatever it actually is, is not all that undesirable. If you think about it, we already have a Cloud-based API for APIs (yes, I realize this is very meta) with the super-cool Gnip which we covered last year when they launched. Social services channel their data through Gnip and Gnip provides a single API layer for data access. And it’s built in the cloud.

Similarly, up until a few years ago, Javascript was painful to write because developers had to write code for all the browsers and all their nuances. That was before Javascript libraries — or APIs, if you will — like Prototype or jQuery came along providing the developer with a single layer of javascript programming that would work seamlessly on all browsers.
1206677_75532165
The concept of single layer APIs is not a new one. Why can’t we have an API for cloud-services as well?

Think about this. Right now, anyone wanting to build an application has three options. They can build out a server cluster or farm that physically scales and, by proxy, ends up costing a lot as physical hardware costs a lot. A second option would involve a virtual cluster made up of virtual machines. You still need hardware, but each server souped up with up to 32G of RAM can theoretically host tons of virtual machines all acting as a physical server. An entirely virtual solution is hosting applications in “the cloud”.

Cloud computing is not without it’s challenges. I’ve challenged the reliance on it in the past, and I still do. However, with cloud services like Amazon’s EC2, S3 or Google’s App Engine, it becomes entirely possible to not only store data in the cloud, but also run and maintain entire services in the cloud.

The problem is, each of them require different things. Amazon has a suite of developer tools that are needed to build against their cloud offerings. Google App Engine only supports Python, Ruby or Java.

There should be a way to abstract this development to a single layer — or API, if you will — to take advantage of this.

Laugh it up, chuckles. A cloud-based framework API is not all that ridiculous of a concept. The world once thought the earth was flat as well.

A Tale of Two Cities: How DC and San Francisco Are Handling Citywide 311

Without a doubt, I am a data whore. I love raw data. I love APIs. I love finding interesting ways to mashup data. With the new found craze in government for openness, led in no small part from the Federal level and work endorsed by the Obama Administration to work pushed forward by Sunlight Labs, Craigslist founder Craig Newmark and others, I’d expect the openness to trickle down to state and local levels. And it is.

On one level, you have Washington, DC (where I live) who has been making impressive strides through OCTO (Office of the Chief Technology Officer) with the assistance of iStrategyLabs and the Apps for Democracy competition.

Washington, DC is in production of it’s Open 311 API, a RESTful data API that they are careful to note is in development. (We will be building a PHP library around this API shortly, so keep an eye for that announcement over at Emmense.com).

In using a REST API, DC is opening up the service sector of the DC City government for developers of all sorts to tap into and build applications around. All to meet the needs of city residents.

San Francisco, on the other hand, just announced that they are utilizing Twitter to allow residents to submit issues directly from their favorite web application. Simply by following @sf311 (and being refollowed), citizens are able to DM requests.

Personally, I am partial to DC’s approach but I applaud both cities for pushing the boundaries to bring city government closer to the people. Frankly, I’m a little concerned about San Francisco utilizing Twitter for this purpose, for the same reason that I am hesitant about any business making their business model about Twitter. Twitter has not proved, at least in my mind, that they have the business savvy to keep their service from going out of business. Likewise, they have not proved their technical ability to make a fail-less system. It’s a game of Russian roulette to base a business (or government service) around this application. San Francisco probably has failover plans and this is just another approach though, so arguably it’s not a significant risk.

However, the solution to the 311 problem becomes infinitely more scalable when utilizing a pure API and allowing the pure submission and retrieval of data. And the use of an API keeps responsibility in-house. Twitter is not paid for by taxpayer money, so there is no expectation of quality control. A government owned and maintained API, on the other hand, provides safeguards that make sense.

All that aside, it is clear that both DC and San Francisco recognize that the accessibility of governments to their citizens is an utmost important goal in 2009. They are taking laudable steps to break down the barriers and solve real problems with modern technologies. For that, I can find no fault.