Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2574 posts at DZone. You can read more from them at their website. View Full User Profile

TyphoonAE and the Proliferation of GAE Implementations

06.09.2010
| 8829 views |
  • submit to reddit
"Yet another Google App Engine implementation" is going to become a catchphrase this year and into 2011.  We began to see the early stages of GAE implementation proliferation in 2009 when open source projects like AppScale and the MongoDB GAE connector started popping up.  Now there's a backend that offers almost all of the GAE services: TyphoonAE.  It provides a full-fledged productive serving environment to run GAE Python applications (could the next alternative GAE stack run Java apps?).  TyphoonAE also offers the tools you need to build your own scalable App Engine while maintaining compatibility with Google's API.

The TyphoonAE Philosophy

The Google App Engine SDK delivers a development web server that mirrors the production environment near flawlessly. But you obviously can't use that in a real production environment. That's where TyphoonAE comes in. It is the missing link to build a full-featured and productive serving environment to run Google App Engine (Python) applications.

We started TyphoonAE to understand and apply the techniques and philosophy of GAE using high-performance and high-scalable open source software on commodity hardware. In the beginning it was a proof of concept and - to be honest - for fun.

The main principles in the design of TyphoonAE are decoupling and statelessness to provide concurrency, better caching, horizontal scalability and fault-tolerance. It integrates various open source products where each one is a superhero and scales independently. 

We took advantage of the SDK's API proxy stub architecture as a non-intrusive approach from the very first line of code. So, patching the SDK is totally unnecessary. This allows us to follow changes and updates very quickly.  --TyphoonAE Google Code Wiki

The growing popularity in GAE as a framework, and the desire of some developers to use it in a real production environment may lead them to create their own GAE implementations.  AppScale was one of the earliest projects to offer an alternative GAE backend.  It can offer GAE in a Eucalyptus environment or Amazon's EC2.  

TyphoonAE offers many features with supported datastores like BDBDatastore and MongoDB (a NoSQL DB).  TyphoonAE also supports Memcached, and it uses RabbitMQ for messaging.  It also uses Tornado for Web Sockets, ejabberd, and the Nginx HTTP Server via FastCGI.



Project developers intend to implement other datastore backends in the near future.  TyphoonAE currently implements almost all of the services in GAE, except incoming mail.

Comments

Senthil Balakrishnan replied on Wed, 2010/06/09 - 8:33pm

The Google App Engine SDK delivers a development web server that mirrors the production environment near flawlessly. But you obviously can't use that in a real production environment. That's where TyphoonAE comes in. It is the missing link to build a full-featured and productive serving environment to run Google App Engine (Python) applications

Just to clarify, Typhoon AE helps corporate to build their own private cloud using an implementation that's compatible with GAE API ?

If above is true, will this not affect GAE cloud business ?

Would be great for coporates which intent to invest on virtualization and standardization of their apps with in their own firewall :).

Sen

 

Mitch Pronschinske replied on Thu, 2010/06/10 - 6:53am in response to: Senthil Balakrishnan

I bet TyphoonAE does compete with GAE for Buisiness.  I'm sure Google isn't worried though.  :)

Igor Ganapolsky replied on Thu, 2010/08/05 - 1:13pm

Not to mention the fact that Amazon ec2 is NOT free. A smacking contrast to Google's goal with the GAE project. I mean, if you're gonna be deploying stuff on ec2, then why not use the pre-built solutions that AWS offers. Why over-complicate things and deploy something that Google intended for people to use on their own platform?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.