Google App Engine's "Achilles heel"

 

Although Google App Engine has won the leading position in the cloud computing PAAs field in the last one or two years, after a long time of learning and practicing Google App Engine, it is found that there are many shortcomings in its existing implementation, and these flaws may become its "Achilles Heel". Next we will analyze in detail what problems the App Engine has.

App Engine Deficiency

It mainly focuses on the following three aspects:

Design Fatigue

Although the App Engine has its own advantages and advantages in many aspects of design, it also uses some inappropriate Google-style design in the App Engine, although Google-style design is very suitable for applications that require massive computing and storage capabilities similar to Google search, for Paas platforms that require high response speed, rather than massive capabilities, not especially suitable, as Jeff Dean, an academician of Google, said in a speech: "design for increment, but not unlimited", and in APP engine, but for some non-existent Google-style requirements, there are two examples of this:

1. In terms of data storage, bigtable, which is famous for storing massive data, is used. Although this ensures that its applications can store massive data on the app engine, it is responsive) there are some sacrifices, especially when pre-D reading data in the memory is not supported. Unfortunately, most apps on the App Engine focus more on response speed, and complaints like this are everywhere in the official Google App Engine email list, this also includes dissatisfaction with memcache speed. When talking about memcache of App Engine, a foreign blog author commented that: "This memcache is not the memcache we are familiar ".
2. Supports cross-continent and multi-data center synchronization. Although multi-data center synchronization is a good practice, due to the speed of light, data transmission between continents is very slow and costly, more importantly, the complexity of the entire data storage architecture is greatly increased at once, and it may make itself slow and worse. This is not a special concern for this user, it consumes too much energy. If it was designed by me, users should be asked to select the location of the data center where the specific application is located, which is also favored by most users, although this design is not preferred by Google.

 

Although for some applications, the absence of some designs does not show the overall performance, but due to the complexity of the PAAs platform, the design has to be careful, any improper operation will cause very serious consequences. We hope the App Engine engineers can think more about it.

Stay away from standards

For common users, the universality and migration of applications are critical. Users want applications to be migrated between the external cloud and the enterprise's data centers. Therefore, if applications can be based on standards, it will be very helpful, as if the middle-aged and elderly investors like their father are choosing stock-selling software. What they care about is not whether the functions are powerful, but whether the shortcut keys are familiar. In terms of critical standards, App Engine is not doing very well in the Java version that could have been used. There are two main problems:

1. In terms of data storage, although App Engine supports the latest JPA, App Engine focuses on providing JDO support, but JDO has limited acceptance across the industry and has been officially abandoned, and it is outdated.
2. Some private APIs are mixed. This phenomenon is very common in data storage. For example, many private APIs are used for key and transaction processing.

 

Although the standards are not well supported, programmers who focus on the App Engine Platform will not be greatly affected, however, it is critical for users who want to migrate their applications between the appengine and the enterprise data center, because this will significantly increase the migration cost.

Insufficient attention

Although the App Engine is still under development, its potential profit is much lower than other Google services, so compared with search, andorid and chrome, its development progress is as slow as the Chrome OS of another product, and it is still in a similar stage of Public Beta.

In general, the App Engine still has many shortcomings. I personally hope that the App Engine will not be as degraded as Google wave, but will continue to develop healthily, and I do not want to see senior engineers like Max Ross, it is also like Lars Rasmussen, the father of Google wave, who left. In the next part of the article, we will discuss some potential advantages of yunengine.

Yunengine advantages

Compared with App Engine, yunengine started a lot late, But yunengine also has a certain advantage in development, just as Google was not the first search engine in the past. The following three main points:

Designed for Paas

Although yunengine uses a yuntable similar to bigtable at the backend, because yuntable takes into account the response speed in design and has the autonomy in design, therefore, yuntable is constantly optimized to better support the PAAs platform.

Adhere to standards

Although yunengine does not provide support for many standards in the initial stage, it ensures that no private APIs are added, so as to ensure app migration.

Extremely focused

As yunengine is a core project for me, I will do my best to make yunengine ready and continuously optimize it.

 

Finally, although yunengine has many bugs or problems in the coming public beta period, as long as it passes through these levels, I firmly believe that yunengine will surpass Google App Engine, as the black beard in one piece said: "people's dreams will not end! ".