My OperaGoogle App Engine
Wednesday, April 9, 2008 6:56:53 AM
Google app engine is a service developed by Google, that was presented to the world this week. It is still not released for real, only a limited number of people have access to the service, but it is very promising.
Of course I missed to be one of the first 10000 developers that signed up for the service. Fortunately, there is an SDK where you can develop your applications, that you can download to your computer running your favorite OS without having access to the service.
Google app engine serves web applications (or regular sites) that you write and upload to Google's servers. When uploaded, Google takes care of a lot of boring and hard stuff, load balancing, buying new hardware when needed, give you an administration interface to monitor traffic and errors, scale your data on several machines, give you a domain that you can use for your service. All you have to do is write your web application, and monitor the web application to make sure that it works. For this, Google will charge you, ... NOTHING. As long as you do not run a very popular or very big site, the service is free of charge. Google does not force you to use adwords or any other Google tricks. Popular sites will have to pay, Google have not yet announced how expensive it will be, you can not buy that service yet. For people who like ad sponsored sites (I am not one of them), hopefully the money you get from the ads will be enough to pay the bill to Google. If not, well, then Google app engine will fail. (I do not believe that will happen, it is in Google's interest to have such a cheap service that a popular web application will continue using Google app engine, so that Google can get the revenue that they are aiming for)
Enough about Google for a while, let's talk about me instead. Yeah, me! Much more interesting.
A few months ago, I was thinking about what I would want to do if I ever started another company. My favorite idea was to solve the problem with having to scale a web application when it became popular, to scale the requests and the data, without having to rewrite the web application or use a lot of administration to add a new machine. When you add a new machine to the cluster, it should just find what it needs to do, serve the database, handle incoming requests, or whatever. One solution was offering a service for all, including hosted hardware, another was to help companies doing this in house. I looked around to see if someone had done this before, and I couldn't. That is, until now. Google app engine solves all the problems that I wanted to solve. Am I glad I didn't tried. Now I get what I wanted for my own web applications, without having to solve the problem. I don't have the competence to build scalable web services anyway, so that would have taken me a lot of time.
When thinking about the problem, I at least identified some problems:
So, what did Google do? They came up with GQL, a close cousin to SQL, but without joins. They decided to use Bigtable instead of using a relational database. They made a sandbox version of Python, just by removing access to a number of Python libraries, and adding some libraries to make it possible to use GQL, Bigtable, and other stuff that they limited by removing some of the Python libraries. Google solved the problems that the web applications noob was able to identify.
Yes, I like Google app engine very much. This is money well spent. It solves a real problem. It makes sense for Google, I think this will help them get even richer. It will help people to innovate. This is the kind of service that big corporations should offer, since small corporations can not afford to do it. (development cost + infrastructure cost)
I am not a Google fan. I use very few of their services. I use their search engine, since it just works. (ok, some things are hard to find). I believe that Google Gears is well designed, and I hope that it will make it into the final HTML 5 specification, since things that run in the browser should not be controlled by one company. (hate Flash, Silverlight, etc) And now, the crown jewel Google app engine.
Last week I took another tour in the "script" language jungle. I decided that I should try to focus on Python instead of Ruby. Yes, I still think that Ruby is a much better designed language. But Python is a very pragmatic language, it doesn't care about being the best language, just being good enough. I believe it is good enough for me, and I like it enough to use it. It is also very much used. I am happy that I spent some extra time on Python, since Google app engine currently only supports Python.
The webapp Framework is included in Google app engine. It is a web framework developed by Google. It is a simple framework that works in the way that I like, no code generation, just a lib to use. Good for me, since Helma is my favorite web framework so far, and it works in a similar way.
Now, I just wonder if Rhino on Rails will be part of Google app engine. I sure hope so, I would like Ecmascript to become a serious server-side contender. With the upcoming Ecmascript 4, it at least has a fighting chance. I do not like the Ecmascript 4 syntax, but the language will be rather powerful, and having one language everywhere would be perfect.
So, if you are going to develop a web application or a web site, why should you use Google app engine? That is the wrong question. The question you should ask yourself is why you should not use Google app engine. In my opinion, using Google app engine is the obvious default choice, you will have real reasons for not doing that. Of course, there are some unknown variables, like, when will it be ready, and how much will it cost. There is also a lock-in effect, since only Google is offering this service. But it is nothing stopping another company from doing the same thing, if Google starts to overcharge for their service, other companies can afford to develop a solution and compete.
Of course I missed to be one of the first 10000 developers that signed up for the service. Fortunately, there is an SDK where you can develop your applications, that you can download to your computer running your favorite OS without having access to the service.
Google app engine serves web applications (or regular sites) that you write and upload to Google's servers. When uploaded, Google takes care of a lot of boring and hard stuff, load balancing, buying new hardware when needed, give you an administration interface to monitor traffic and errors, scale your data on several machines, give you a domain that you can use for your service. All you have to do is write your web application, and monitor the web application to make sure that it works. For this, Google will charge you, ... NOTHING. As long as you do not run a very popular or very big site, the service is free of charge. Google does not force you to use adwords or any other Google tricks. Popular sites will have to pay, Google have not yet announced how expensive it will be, you can not buy that service yet. For people who like ad sponsored sites (I am not one of them), hopefully the money you get from the ads will be enough to pay the bill to Google. If not, well, then Google app engine will fail. (I do not believe that will happen, it is in Google's interest to have such a cheap service that a popular web application will continue using Google app engine, so that Google can get the revenue that they are aiming for)
Enough about Google for a while, let's talk about me instead. Yeah, me! Much more interesting.
A few months ago, I was thinking about what I would want to do if I ever started another company. My favorite idea was to solve the problem with having to scale a web application when it became popular, to scale the requests and the data, without having to rewrite the web application or use a lot of administration to add a new machine. When you add a new machine to the cluster, it should just find what it needs to do, serve the database, handle incoming requests, or whatever. One solution was offering a service for all, including hosted hardware, another was to help companies doing this in house. I looked around to see if someone had done this before, and I couldn't. That is, until now. Google app engine solves all the problems that I wanted to solve. Am I glad I didn't tried. Now I get what I wanted for my own web applications, without having to solve the problem. I don't have the competence to build scalable web services anyway, so that would have taken me a lot of time.
When thinking about the problem, I at least identified some problems:
- You would have to use something else than SQL, since Joins don't scale, alternatively do something clever with the SQL queries and map these to chards without forcing the developer to do it themselves.
- Have something simlar to Bigtable, to easily chard the data.
- If using a hosted solution, they would have to run in a sandbox, so it would be easy to load balance between different services.
So, what did Google do? They came up with GQL, a close cousin to SQL, but without joins. They decided to use Bigtable instead of using a relational database. They made a sandbox version of Python, just by removing access to a number of Python libraries, and adding some libraries to make it possible to use GQL, Bigtable, and other stuff that they limited by removing some of the Python libraries. Google solved the problems that the web applications noob was able to identify.
Yes, I like Google app engine very much. This is money well spent. It solves a real problem. It makes sense for Google, I think this will help them get even richer. It will help people to innovate. This is the kind of service that big corporations should offer, since small corporations can not afford to do it. (development cost + infrastructure cost)
I am not a Google fan. I use very few of their services. I use their search engine, since it just works. (ok, some things are hard to find). I believe that Google Gears is well designed, and I hope that it will make it into the final HTML 5 specification, since things that run in the browser should not be controlled by one company. (hate Flash, Silverlight, etc) And now, the crown jewel Google app engine.
Last week I took another tour in the "script" language jungle. I decided that I should try to focus on Python instead of Ruby. Yes, I still think that Ruby is a much better designed language. But Python is a very pragmatic language, it doesn't care about being the best language, just being good enough. I believe it is good enough for me, and I like it enough to use it. It is also very much used. I am happy that I spent some extra time on Python, since Google app engine currently only supports Python.
The webapp Framework is included in Google app engine. It is a web framework developed by Google. It is a simple framework that works in the way that I like, no code generation, just a lib to use. Good for me, since Helma is my favorite web framework so far, and it works in a similar way.
Now, I just wonder if Rhino on Rails will be part of Google app engine. I sure hope so, I would like Ecmascript to become a serious server-side contender. With the upcoming Ecmascript 4, it at least has a fighting chance. I do not like the Ecmascript 4 syntax, but the language will be rather powerful, and having one language everywhere would be perfect.
So, if you are going to develop a web application or a web site, why should you use Google app engine? That is the wrong question. The question you should ask yourself is why you should not use Google app engine. In my opinion, using Google app engine is the obvious default choice, you will have real reasons for not doing that. Of course, there are some unknown variables, like, when will it be ready, and how much will it cost. There is also a lock-in effect, since only Google is offering this service. But it is nothing stopping another company from doing the same thing, if Google starts to overcharge for their service, other companies can afford to develop a solution and compete.
