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.

99.96% Uptime is Bogus Marketing

Reliability Update

Twitter has been making great progress in terms of uptime and
reliability. Fail Whale sightings are far less frequent these
days thanks to our efforts but we still have a long journey
ahead. Last month we saw 99.88% uptime and so far this month we
are at 99.96%. Our engineering and operations teams have been
taking a very methodical approach to improving Twitter. We’re
using the word “craftsmanship” to characterize our work here at
the office. Reliability and dependability continue to be top on
or list of key goals.

The above passage is from an email from Biz Stone at Twitter today. After a horrid June, things could only go up at Twitter HQ. Fortunately, it looked like they got serious about the uptime issues they had their and things have been better.

In the meantime, they purchased the super reliable and speedy Summize and branded it with Twitter branding at search.twitter.com.

This could only be a good thing, right?

Well, you’d think. Except the purchase of the super speedy and efficient Summize has only driven the tool into the pond. To be fair, it’s not horrible, but it suffers from the same weaknesses that Twitter does.

That is, it can’t keep up.

As an example, I’ve been following #dnc08 and #rnc08 searches on Summize to watch what people are saying about the political conventions. During the high traffic tweet windows during the evenings of the conventions, Twitter is reliable. That is, they are reliably late. Usually 1-2 hours behind the actual tweet stream.

This is completely unacceptable, and it is complete spin, I guess in the spirit of the conventions, for Biz to tout 99.96% uptime.

Let me be clear, when things are slow and not performing up to standard, you cannot claim 99.96% uptime. Technically you can. Uptime is technically defined by if the web server serves a 404 Page not Found (or Twitter Fail Whale in their case) or a 200 Page found status code.

But from a common sense user experience, this is not uptime. And to claim so is disingenuous.

I appreciate the efforts Twitter has put into improving, but why are we fighting the ability to use the tools during high-demand times. In essence, that makes the tools completely useless.

I look forward to better results, but my skepticism remains in place about Twitter. They do not have the staying power to make it.

I have been on a 3 month hiatus on Twitter blogging. I have refused to blog about it, but there’s another post that has been in the back of my mind for some time. What happens when companies and businesses trying to use Twitter as a marketing and communications tool cannot. What happens when your brand relies on the communication lines and those communications lines dying?

Another day, another post. For today, the spin needs to be exposed.