|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.
- MapR Technologies Announces Upcoming June Conferences
- The Odd Couple: Marrying Agile and Waterfall
- Fanning the Flames of Agile
- WSO2 Guest Speakers at WSO2Con Europe 2014 Will Examine Technology Developments and Best Practices Enabling the Connected Business
- Internet of @ThingsExpo Silicon Valley Call for Papers Now Open
- April and May 2014 Server and StorageIO Update newsletter
- MangoApps to Exhibit at Cloud Expo New York
- WSO2 Introduces Industry’s First Enterprise Identity Bus With the Launch of WSO2 Identity Server 5.0
- Practical WebRTC: From API to Solution
- The Butterfly Effect Within IT
- Last Chance to Register for LTE World Summit
- Concurrent, Inc. to Present at Upcoming Leading Big Data and Hadoop Industry Events
- How to Get the Best From Virtual Employees
- Global Financial Firms Can Effectively Address Technology Risk Guidelines
- .CLUB Domain Name Extension Now Available for General Registration
- FOSE Expo to Feature Cutting-Edge Solutions from Top Government Technology Vendors
- MapR Technologies Announces Upcoming June Conferences
- More Mainstream Businesses Depend on Open Source
- AMAG, HP, ImageWare Systems, March Networks and StrikeForce Discuss Security Solutions in SecuritySolutionsWatch.com Interviews
- F5 to Present at Upcoming Technology and Investor Conferences
- The Odd Couple: Marrying Agile and Waterfall
- Flexera Software’s InstallShield 2014 Release Introduces New Support of Cloud and Virtualised Installations, High-DPI Displays and Touch Devices, and Agile Development
- Fanning the Flames of Agile
- FlexNet Manager Suite Wins CODiE Award for Best Asset Management Solution - 4th CODiE Award for Flexera Software
- The Top 150 Players in Cloud Computing
- Who Are The All-Time Heroes of i-Technology?
- Where Are RIA Technologies Headed in 2008?
- Success, Arrogance, Rise and Fall
- AJAX World RIA Conference & Expo Kicks Off in New York City
- The Top 250 Players in the Cloud Computing Ecosystem
- Personal Branding Checklist
- i-Technology Viewpoint: Attack of the Blogs
- Exclusive Q&A with Jeff Haynie, Co-Founder & CEO, Appcelerator
- Cloud People: A Who's Who of Cloud Computing
- Ulitzer Names the World's 30 Most Influential Cloud Computing Bloggers
- Web 2.0 News and Wrapping Up "Real-World AJAX" Seminar