21 Comments

Summary:

The launch of Google’s Application Engine is a watershed moment in the software development industry. The days of building and hosting your own servers, save for specialized applications, are officially over. Meanwhile, companies that offer similar services will be forced to take a hard look at what they offer and what they need to do to improve it.

Brian McConnell is the founder of the Worldwide Lexicon project and Der Mundo.

The launch of Google’s Application Engine, which allows developers to build a web application and then host it on Google’s existing infrastructure, is a watershed moment in the software development industry. The days of building and hosting your own servers, except for specialized applications, are officially over.

This is good news. And App Engine will give everyone, including Amazon, a nice scare, which means that these companies will be forced to take a hard look at what they offer today, and what they need to do to improve it.

Here’s what I want on behalf of our firm, a web application company, from an elastic computing provider. (I think the majority of developers and managers will agree with most of these points.):

  • I want scalable computing and bandwidth on autopilot. I don’t want people spending their time configuring server arrays.
  • I want the service to look like a single instance of a generic Linux CPU with services pre-installed
  • I want to be able to use the scripting language of my choice (mine are PHP, Python or Ruby)
  • I want a distributed file system that looks like an ordinary file path
  • I want MySQL in the local cloud for database services
  • I want everything to be standards-based, to the fullest extent possible, so that I can spread resources across more than one vendor and if I need to change vendors, I don’t have to redesign my entire application
  • I want the option of not hosting applications with a potential competitor.

Google’s big weakness — which Amazon, Rackspace and others will soon exploit — is that it’s not a neutral player in this market. So for companies that are building highly automated services and web apps, Google’s inherent conflict of interest is an issue. I think App Engine will be a great deal for independent developers who want to build and host their apps somewhere but don’t care so much about building a business, much the way Geocities and other services were great for people who wanted a home for their web pages.

I don’t think it’s such a good fit for companies with legitimate concerns about vendor neutrality, access to sensitive data, etc. I know my board would be squeamish about hosting everything at Google. The search giant’s motto may be “Don’t Be Evil,” but given the choice between hosting at a company that also offers its own web services and a neutral vendor, I’d go with the neutral vendor.

In terms of vendors, Amazon seems most likely to benefit, as App Engine has further legitimized the concept of cloud computing. And in terms of needed improvements, AWS has the fewest. S3, last time I checked, required a lot of work to implement. It should have looked like a local file path, with caching and whatnot being handled transparently so apps don’t need to know about S3. Same thing with database services. I’d just like to be able to talk to a MySQL or Postgres server in the cloud, way easier than building something around a new system.

Amazon’s simple database server may be better, but it doesn’t matter. SQL is like ASCII. That’s what people are accustomed to using, and that’s what all the tools are built around. All Amazon really needs to do is make their elastic computing service look like a Linux CPU with a giant local file system, and a pre-provisioned SQL database server ready to talk to. Add some basic tools for launching and killing new systems in response to CPU or network load, and this sounds like it’d be pretty useful. (We’ve been looking at AWS pretty closely for a while now).

As with hosting and colocation, I don’t see this being a winner-takes-all market. There have always been a variety of vendors catering to different markets. Sometimes you need a cage where you can install specialty appliances (spam filters or VoIP servers, for example). So it seems to me that the winners in this category will be the same companies that have done well renting remote servers. They can offer users a range of services, from elastic computing to remote servers to rackspace and connectivity. That’s a complete solution, which if you’re building a company around your services, is often what you need.

I’ve been looking at several elastic computing services. Every one I’ve looked at so far was close to what we needed, but not quite there. Hopefully App Engine will scare the bejesus out of other companies to the point that they’ll work out the few remaining issues with these products, allowing us throw out our dedicated servers and smoothly switch over to an elastic computing platform.

You’re subscribed! If you like, you can update your settings

  1. Alan Wilensky Tuesday, April 8, 2008

    So true that the custom configuration market that are users of things like XML appliances and Cast Iron Services boxes, will never go this route.

    And, it seems that people, like yourself, that must have a Linux Look-Alike, may not like the Google way, either. It seems that Rightscale has that market wrapped as a layer on top of Amazon Web Services.

    Bungee and keroku, they are hosted IDE’s with push button deployment; who in the world knows what massive scaling challenges will bring to these? Hopefully some simulated loads can be run and published.

    Bungee is very strong in creating WS compliant end-points – but it has a strange new language to learn. Keroku is Ruby on Rails, and so has a community. That is one slick system for folks that must have a real MySql, but want the application server in the cloud.

  2. “….. is a watershed moment in the software development industry”

    Oh boy – someone has been drinking those free fruit smoothies during frequent visits to Googleplex.

    This is more about Google trying to find use for its over the top CapEx based on lofty ambitions – than about a watershed moment in software development – and a half baked product at best – get grip will ya.

  3. Duane Storey Tuesday, April 8, 2008

    Yah, I’m not sure I agree with your opening statement either. Even the content of your article calls to question the current offerings of cloud computing. I don’t think what Google is offering is very revolutionary yet — that’s not to say it can’t be, I just think it’s in the realm of “hey that’s interesting”. I’d be very worried as a business about putting data in the Google plex at this stage.

    With Amazon’s recent announcement of their elastic IPs, I think their service becomes even more interesting. While having a distributed data system look like a file path is a nice feature, I don’t think it’s really that necessary (at least for anything I’ve don), and it’s nothing that can’t be overcome with a few scripts (we switched our whole company to S3 a while ago and it was fairly trivial).

    But I agree that cloud computing is probably where the industry is going, and that it’s exciting. I’m just not entirely sure I’m on board with what Google is doing yet.

  4. Alan Wilensky Tuesday, April 8, 2008

    Google’s primary ‘product’ has always been its OS and infrastructure. scalability is their stock and trade. they have monetized everything on top of this incredible grid, and what we are now seeing is the first peek (beyond API’s) of a development platform for the daily programmer.

    Watershed – hmmm. Important – absolutely. It stirs the pot.

  5. The database problem is fundamentally a theoretical one. Transaction support and performance adversely impacts broad scalability and distributability. Consequently, you cannot support a conventional SQL database as a scalable cloud application while also retaining the features and behaviors that are integral to a conventional SQL database. In practice, it is a tradeoff between not losing too many features or adding to many prohibitive caveats, and maintaining performance and distributability.

    If they supported a MySQL or PostgreSQL “as is”, developers would complain because many aspects of performance would be worse than a standalone system. If they disable or abstract many features to allow general scaling and performance in a distributed environment, developers would complain about lack of certain features and the creation of non-standard behaviors. You cannot have your cake and eat it too.

    It is actually a bit embarrassing to the profession that so many developers are essentially ignorant of the relationship between transaction theory and distributed systems considering how fundamental it is to software design.

  6. Lew, Rackspace Tuesday, April 8, 2008

    Great post. Google and Amazon are serious and they are doing some very cool things. But, the broader move to the cloud is a huge trend and there will be many flavors. Our own cloud hosting offer, Mosso, is a whole stack variant just like google, but standards based (LAMP, .net and Ruby). Compute clouds, like AWS, will also emerge from hosters.

    Truth in the room, I would prefer not to compete with the richest company in the world, but, no one can advance a trend like they can. Many winners will exist when you think about millions of servers moving to the cloud in the coming decade.

  7. Alan Wilensky Tuesday, April 8, 2008

    Embarrassing? Boy have you said a mouthful. “There is nothing more perfect for your mobile application back-end than MySQL enterprise cluster”, said one LAMP developer to me. We had already simulated that there would be greater than 400 writes /sec/ and transient joins.

    The young man’s mouth hung open for a full minute, and while he waffled, I sent him to http://danga.com for a copy of Fitzpatrick’s paper on avoiding write saturation.

    Well, one thing the schema-less no join architecture buys us on top of Google’s GFS is no write saturation. So, a generation of table joiners and SQL jockeys will just have to get jiggly with a hierarchical or object based storage model.

  8. I think if it were straight forward to treat scalable storage as if it was a local file system, and scalable databases as if they were just ordinary mySQL or Postgres databases, Amazon would have done so before they ever started offering public web services it would have be much simpler for their internal application developers.

    It’s pretty clear that scalable services require deviations from the familiar programming models can can use for apps that run on a small number of machines. Pretending otherwise would likely create as many problems as it solves. Providing different interfaces helps set expectations up front: These services are similar to things you are used to, but they aren’t the same.

  9. Brian McConnell Tuesday, April 8, 2008

    The key point I wanted to get across is that I think this is what Google had in mind for a web OS, that you could run your app on a platform that automatically scales, and that hides all the operational issues from you. I do think it’s a milestone in the sense that hosting vendors have to pay attention to this now, and that a year from now, vendors who do not offer scale-on-demand hosting in some form will look like dinosaurs.

    I’ll be the first to admit that I do not have extensive experience building large scale web applications that can handle millions of users. None of the services I have designed so far have grown to that level. Not many other people have personal experience dealing with this issue, and they’re not cheap either.

    What I like about cloud computing services, if they can be made to look like a pretty standard LAMP server, is that you can focus on designing your application, and generally not worry about planning for unexpected success. Of course, if your app does take off and attract millions of people, you’ll be smart to hire someone who’s dealt with large scale services before, but if it doesn’t happen, you haven’t wasted time and money building something for people who never show up. Or if it takes off unexpectedly, at least your service does not completely fall on its face for several months while you sort through these issues.

  10. Doug Cutting Tuesday, April 8, 2008

    As others have indicated above, cloud-based MySQL is not practical, and a distributed filesystem cannot be used like a local filesystem. What’s required to build vendor-neutral cloud applications are non-proprietary APIs. One could try to develop standards for this, or, more simply, start building an open-source stack. http://hadoop.apache.org/ provides a foundation for this.

Comments have been disabled for this post