|By Billy Marshall||
|April 15, 2009 06:30 PM EDT||
Billy Marshall's Blog
As a technology provider that helps application companies embrace cloud computing by virtualizing the applications to run on any cloud, I was a bit disappointed with Google's AppEngine announcement. It appears that Google is embracing the “walled garden” approach of salesforce.com and Microsoft instead of the cloud approach of Amazon. I believe that walled gardens will ultimately be overshadowed by clouds because you cannot achieve webscale computing if every application has to run on a server owned by Google.
Historically, Google has been very good about providing APIs that enable applications to access its web services independent of the computer on which they run. This is an important concept because it is often the case that an application needs to run on a particular network or network segment in order to preserve some critical aspect of performance or security. It is also important because it provides developers with the broadest choice of system and programming tools when developing or maintaining their applications. If you must program the application in the Python implementation specified by Google and run it on a Google server in order to take advantage of services like BigTable and Sawzall
Why not simply expose a virtual machine API (such as Amazon Machine Image) along with the API for the web services (such as Amazon's S3, SQS, etc.)? Application instances that require minimal latency to Google services are provisioned as virtualized appliances on a Google server. For applications that need to run on a different network, you can provision the same system definition to that network while accessing the web services over the Internet. Write the program in any language you choose. With any set of system components that you choose.
The problem with walled gardens is that they ultimately restrict the growth of the market. While it is true that an attractive and well manicured walled garden will result in asymetrically large economic rent for the owner of the garden (witness Microsoft), the size of the market is nonetheless constrained. It seems to me that Google would reap the greatest benefit from maximizing the market for cloud applications quickly – independent of their ability to collect an asymetrically large portion of the rent from that market. Even their marketing of the current implementation of appengine indicates this hypothesis is correct – it is free. Success with cloud computing will no doubt lead to a decline in the value of the Microsoft system software franchise (the ultimate walled garden). Why not accelerate that decline with broad market capability instead of yet another walled garden (YAWG)?
Let me provide a concrete example. rPath was approached by a SaaS application provider to help them release their on-demand application as an on-premise application – without sacrificing management control of the system software. They want on-premise capability in order to meet the data security requirements of a certain segment of the market which they have been unable to penetrate with their SaaS offering. Their current application runs on Microsoft server technology, but it is written in Java so skipping out of the Microsoft walled garden was pretty trivial. We provided them with a virtualized implementation of their application, and we demonstrated how it could run on a local network atop a hypervisor, or as a variable cost implementation on Amazon's elastic compute cloud (EC2). Their reaction was so positive that they are now planning to gradually migrate their entire infrastructure from Microsoft to virtual infrastructure in order to seamlessly deliver the application via SaaS, variable cost cloud (Amazon), and local network (virtual appliance). Without changing their preference for programming language. Without sacrificing control of the system software layer.
To be fair to Google, appengine is a beta service. I have no doubt that they made compromises in architecture in order to get the service out the door more quickly. I hope they follow Amazon's lead and expose all of their great services as true web services while enabling any application to run close to those services via a simple virtualization spec such as Amazon's AMI. The faster we take the market to cloud computing, the sooner we can kill off the walled gardens through webscale shadows that deprive them of economic sunlight.
|Dean J. Garrett 07/21/08 12:39:41 AM EDT|
One important but less discussed trend made possible by cloud computing is the number of useful "database community websites" being published. Such a site is similiar to a wiki in how the site's data content is provided by the users themselves. The sites are free to all who want to search the database and to post new data. The sites are made possible by the use of cloud databases, Software-as-a-Service solutions designed to make web database publishing quick, simple and cheap. Here are two good examples of database community sites:
www.PhotoEnforced.com - this site publishes a database of locations where cameras are used at street intersections to photograph violators.
www.GasPricesCentral.com - this site publishes a database of gas prices in metro areas around the country.
These kinds of sites are serving a public need by distributing useful data openly through the cloud. This is just one area where cloud computing is making
|James Urquhart 06/08/08 01:03:08 AM EDT|
"I believe that walled gardens will ultimately be overshadowed by clouds because you cannot achieve webscale computing if every application has to run on a server owned by Google."
Um...but...Google is kind of the *definition* of webscale computing, isn't it? If they can't scale your application, who can?
Also, is an open source API still a walled garden? If 5 businesses are build that replicate the Google model in other datacenters (including, perhaps, EC2...already done in prototype), then haven't the walls crumbled?
I, alternatively, see the problem as one of Google building its own "solar system", with a cluster of options centered around its model. Amazon, too, has proprietary lock-in (the AMI--though this seems to be opening up some), so it is also building its own "solar system". Have you seen [http://eucalyptus.cs.ucsb.edu/]?
Over time, I think we will see standards in "layers", such as at the IaaS, PaaS and SaaS levels. RPath will certainly make big money off of the layers it abstracts, but it should be content that money can be made at other layers without their involvement.
|Neil Mansilla 05/16/08 03:33:45 PM EDT|
I've been working and deploying applications on the Web since 1994. I've gone from shared hosting on SGI boxes, to dedicated hosting, to co-location with Verio and Level3 (still have a couple racks full of equipment running there). I've decided to launch my latest Web/mobile app on AWS (Amazon Web Services), [http://ahTXT.com/ ahTXT.com (eBay auction monitoring and wireless alerts)] because of this primary reason: I no longer wish to manage hardware.
Amazon's EC2 is fantsatic.. even their smallest instance class is a high-performance server. However, all fancy-fluff and buzz-terms aside, EC2, at the end of the day, is just a virtual server. Your instance is just a Xen image. This means that at the end of the day, unless you implement some type of management solution (or outsource this to a management provider), you're dealing with a virtual server -- pretty much just like every other dime-a-dozen virtual server providers out there.
The benefit is the fact that you're running on enterprise-class equipment from top-to-bottom. That includes the servers, network switches, routers, probably even down to the quality of the cables. That also includes power redundancy/failover, environmental control (cooling/humidity), and so on. You don't quite get that with your run-of-the-mill $19.99/month "VPS" (virtual private server).
Again, my impetus behind using AWS was that I no longer wanted to manage hardware. But there are other important reasons, too. For starters, you cannot rely on cheap VPS for mission-critical applications. Secondly, you only pay for what you eat.. so if you want to launch 7 more instances and are clever enough to software load-balance between then, you can do that during a peak transaction period.. then kill the extra instances, and stop paying (you pay by the hour).
Okay, enough about AWS..
I watched the campfire presentation of Google App Engine and was initially excited. They took it a step further by taking away the need to launch additional instances and manage a cluster to load-balance, etc. I love the thought of building an app that gets slammed with billions of daily transactions and would not break, or even bend, for that matter.
But indeed, the thought of being locked into an architecture for a real business is kind of scary. I know, for instance, that if Amazon's service level started to fall, I could simply take my app back to the co-lo and load balance it across physical servers, and do it quite well. However, if Google ever decided to can my app, or demand more money than I could afford to pay to keep my app alive on their architecture, I'd have to re-write the software to be more like my traditional apps that run Apache/Tomcat on Linux, etc. and not the magical kingdom of Google and its AppEngine.
You know, there are third-party providers out there that are built on the AWS EC2/S3 architecture, and deliver the same promise -- "build your app, and we'll handle everything else." (scale, load, instances/servers, storage, etc.) If you're waiting around for Google to re-tool AppEngine for your development platform (PHP, Perl, Ruby, etc.), you may just want to check out these managed service providers on the AWS platform.
|Bert Armijo 05/15/08 05:04:24 AM EDT|
I agree in principle, but IMHO your argument is somewhat myopic. It's certainly clear why, as CEO of rPath, AppEngine is a walled garden to you. However, to be fair, I'm sure F5 or Checkpoint would see AWS as equally closed. As would many other vendors who's products don't fit easily into Amazon's unique AMI and storage model.
A more wholistic view of cloud computing is needed that allows for simple specification of requirements and interfaces so users can build applications and services that span the cloud.
|Troy Tolle 05/03/08 11:23:40 AM EDT|
I am in agreement here. I was excited to see Google jump in offering a computing infrastructure for their users, but I was disappointed that we could not use more than python. We have been using Amazon Web Services for 2 years for DigitalChalk and I was hoping to see some interesting alternatives pop up from Google. I think Google does have the right idea of handing scale transparently for the user. This is a great plus and a move that is welcomed but I would like to see other languages such as PHP and Java supported.
Jul. 30, 2015 09:00 AM EDT Reads: 2,145
Jul. 30, 2015 09:00 AM EDT Reads: 247
Jul. 29, 2015 03:00 PM EDT Reads: 1,259
Jul. 29, 2015 02:00 PM EDT Reads: 1,174
Jul. 29, 2015 01:45 PM EDT Reads: 427
Jul. 29, 2015 07:30 AM EDT Reads: 283
Jul. 28, 2015 06:30 PM EDT Reads: 1,378
Jul. 28, 2015 04:30 PM EDT Reads: 1,756
Jul. 28, 2015 11:00 AM EDT Reads: 2,036
Jul. 27, 2015 09:00 PM EDT Reads: 2,041
Jul. 27, 2015 10:00 AM EDT Reads: 2,023
Jul. 27, 2015 09:00 AM EDT Reads: 316
Jul. 27, 2015 08:00 AM EDT Reads: 1,898
Jul. 26, 2015 09:00 PM EDT Reads: 1,568
Jul. 25, 2015 02:00 PM EDT Reads: 383
Jul. 25, 2015 01:00 PM EDT Reads: 1,949
Jul. 25, 2015 12:15 PM EDT Reads: 453
Jul. 25, 2015 12:00 PM EDT Reads: 1,528
Jul. 25, 2015 09:00 AM EDT Reads: 1,482
Jul. 24, 2015 11:00 PM EDT Reads: 2,053