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.

Read More

The Pros and Cons of Cloud Computing

Several years ago, a new buzzword entered the fray of internet speak: The Cloud. In the past, I’ve written critically about cloud computing, and my reservations originally outlined remain. However, there is real value in the cloud as well.

Known for applications that are considered “Software as a Service”, or SaaS, The Cloud represents the idea that data processing and storage exists, not on physical hardware maintained by an organization or their designated controlled environment data center, but literally out on the internet. The data and processing is harnessed by the power of distributed computing across grids and data centers. The power of multiple hundreds of thousands of server farms can much more effectively manage the processing power of a service, application or company far better than a single server or node of servers. In fact, economically, cloud computing is far cheaper than traditional computing paradigms.

In an enterprise sense, cloud computing is often handled by Content Delivery Networks (CDNs) such as Limelight, Panther or Akamai. These enterprise solutions run as cheap as $0.25/Gb of bandwidth/transfer to $1.00/Gb. Other lower cost solutions include Amazon’s EC2 or Google AppEngine (which now supports Java in addition to it’s longstanding Python commitment).

Companies looking to expand their offerings with web apps, downloadable materials or provide a service relying heavily on rich media (images, video [especially HD video], or streaming audio) might consider the Cloud as a viable scaling solution. In my opinion, based on my experiences, there are benefits and drawbacks to the Cloud.

Benefits of the Cloud

Cloud computing is cheap. Dirt cheap. If you’re scaling up an application – that is active growth projections and model, not simply a prototype – Amazon EC2 will give you computing power for as little as 10 cents an hour, and time is measured only when the cloud is actually working on behalf of a user, so if it’s idling you’re in the clear. In addition, at 10 cents per gigabyte of bandwidth, it’s extremely cheap to begin a large scale growth projection.

A secondary benefit of using the cloud is your ability to fire your IT staff. Within reason, of course. The absence of physical hardware and infrastructure security requirements allows your company to devote more resources to the development of your technology product, as opposed to positioning watchmen on the wall, so to speak.

Thirdly, the cloud is infinitely scalable. It is not necessary to worry about clustering, nodes, GeoIP content serving (that is, serving content from a UK-based data center to a user in Germany as opposed to serving from Southeast Asia, as an example). Simply put, the Cloud allows you to build as much capacity and bandwidth as you’re willing to pay for.

Drawbacks of the Cloud

Of course, since there is no such thing as a free lunch, there are also detractors to leveraging the cloud. In a siloed environment of physical hardware and CAT-5 cabling across server closets, it is possible to scale by diversifying the vendors and hardware and data centers. From a business perspective, this means you can work one vendor against another and possibly incite a bidding war. You could use all or none of the vendors that might show interest. In the cloud, it is difficult, if not impossible, to choose 2 different CDN providers in addition to Amazon EC2, for instance. Tim Bray wrote a piece about this last year and raises significant, yet important, questions.

Secondarily, especially for cheaper solutions like Amazon S3 (different from EC2 in that it is simply a storage facility in the cloud), you have a high chance of latency. Simply put, the network connection is not fast enough to be able to rely on to serve rich media at scale. Many services out there, including WordPress.com opt to use Amazon S3 as a “cold cache” – that is, the last place that content is served from and then only if needed. The latency of the network makes it prohibitive, depending on the application, to do it on every page load.

Finally, Cloud reliance can cause significant problems if the control of downtime and outages is removed from your control. Over the past year, Amazon has had significant downtime incidents (8 hours in one case!). Reliance on the cloud can cause real problems when time is money.

In the past, we have advocated for a hybrid solution to cloud computing. It is perfectly okay and reasonable (even expected!) for companies to leverage the cloud. Economically, it allows them to go crazy at building the business and focusing resources. In a down economy, the economics behind the Cloud over physical hardware is a no-brainer. However, we continue to advocate for a failover plan that will help an agile company dodge the effects of downtime. A hybrid environment is also attractive as well, allowing companies to directly manage and control critical operational systems and benefit from the infinite possibilities of scale.

Read More