Why we are moving away from Google App Engine

我们为什么离开Google app engine？

备注：本人看到这个文章确实觉得很遗憾，google在互联网领域的深厚技术实力毋庸置疑，gae也值得信任，但是越来越多的限制，确实需要考虑替代环境了。

当然也有很多原因，甚至是一个重要的方面，是外部环境的限制。

gae本身就是给创业者提供一个实验想法的操场，其实自带的appspot.com如果可以使用，也很好。

但是。。。

另外的一个弊端是gae和google的商业产品google apps的绑定，对于创业者产生了限制，之前2012年底前吧，还有免费的google app可以使用，但是现在完全转移到商业试用了。

怕什么来什么，Google Apps 免费版被取消，一个用户一年最便宜 50 刀

搞什么飞机，Google Apps 要取消免费版了？

利用 App Engine Admin Console 还可以注册到免费的 Google Apps，但只有一个用户

永远免费的Paas云平台总结（2011年版）

原文出处：http://blog.conceptcodify.com/2013/12/08/why-we-are-moving-away-from-google-app-engine/

ConceptCodify is moving away from our current server provider, Google App Engine. We wanted to write to our users and the develop community to share our experience

The Good

Google App Engine is the ideal choice for getting your idea out the door quickly and seeing if there is a viable market for what you want to accomplish, and the positive aspects listed below strongly show this point.

Zero to App in a few minutes. Easy deploy, local development, email, logs, cron jobs… Google App Engine comes with a great deal out of the box. In fact, no other provider out there gets you set up and developing in as little time. There’s so little that you actually have to set up to get going. This is by far the most compelling reason to use Google App Engine, especially if you are building a minimally viable product.

Admin interface. Google App Engine has a web interface that gives access to everything you could need to your production application all in one place. It makes it so much easier to manage than most other servers, where you are constantly jumping from one interface to another.

Documentation. Google provides excellent documentation to get up and running with Google App Engine quickly. No other server provider walks you through getting things setup and running as well as Google does.

Free to start. Google App Engine’s free quota has been enough for our needs so far, and we have a few thousand accounts and studies in our system. This also helps building a minimally viable product because you don’t have to set up payments or manage funding the servers to start with.

Performance. Reading blog posts from a year or two ago, it seems Google App Engine used to have problems with performance. I can say from our experience, we’ve only seen good performance from Google App Engine.

Scaling. With Google App Engine, you don’t have to think about scaling. It automatically scales itself. Almost no other platform is offering this feature.

The Bad

Google App Engine is amazing for getting started, but has some problems once you get going.

Custom domains. Google App Engine tied custom domains with Google Apps. This was fine about a year ago, when there was a free tier for Google Apps. Then, you’d also get free email hosting for your business too! Unfortunately Google decided to move away from this structure. Currently, to have a custom domain on Google App Engine, you have to pay $50 a year for a Google Apps account. They are promising an upcoming solution to this issue.

Third party libraries. Google App Engine doesn’t use package managers that are common to the development platforms, such as pip. This means you have to download the files of any third-party libraries into your application and load them in yourself. This makes it much more difficult to manage third-party libraries. Also, Google App Engine limits what third-party libraries you can use.

Support. There is no support with Google App Engine unless you pay an exorbitant fee. This means if there is a problem, you can only rely on forums and StackOverflow to resolve your issue.

Images. Letting users upload their own logos for their studies has proven an incredible challenge on Google App Engine. With other platforms, this isn’t an issue, but with Google App Engine, it requires substantial configuration and overhead to get going.

Setting up third-party services. Google App Engine comes with its services, and that’s all you can ever get. You can’t install Redis or a task queue system of your choice. If you need a service that Google App Engine doesn’t provide, you are out of luck. This makes Google App Engine difficult to sustain in the long run.

Proprietary. Google App Engine is not based on open-source technology. This means there is a small community with less support, and you can’t move your setup to another server easily. Also, because the code is closed-source, you’ll have a more difficult time finding resources, like blog posts and tutorials, to help you get setup. When you use popular open source technologies, there’s an abundance of resources you can use to get going and resolve issues.

Database. We’ve been able to get around the other issues, as any service provider is going to have issues or things you don’t want to deal with. But the database for us has been a deal-breaker. GQL, or the Google Query Language, is a highly limited knock-off of SQL. We have been unable to build features such as filtering analysis results and sharing studies because of the limitations of Google’s database. We really want our users to be able to dive deep into their data and GQL has prevented us from providing this depth to our researchers. We’ve found GQL and the Google database to be frustrating to use, and our desire to have access to systems like MongoDB and PostgresQL have prompted us to move to an alternative.

The free plan also has a very low quota for database queries, and so you will need to cache any query result into memcached, as this is the only memory-based store available, to reduce the number of queries. This is generally a good practice, but worth noting.

The Transition

We started looking at some different options a few months ago. While we wanted to stay in the PaaS realm, unfortunately no PaaS provider is really anywhere near Google’s offer.Heroku, AppFog, and Dotcloud are expensive for our needs, OpenShift had limited features.Deis, Dokku, and Flynn are interesting projects, but they are very limited in their capabilities and for our needs, make things more complicated than not using them.

We’ve decided for now to go with a more traditional setup, using Vagrant for local development with shell provisioning and deploying to the server using Fabric.

We rewrote the entire codebase, even though the user interface is largely unchanged. We’ve spent more time on this iteration making sure we have good processes in place which has added to our time. We also have limited staff hours so it has taken a bit longer than we hoped to get to this next version of our application.

The PaaS we’d like to see

So we are leaving the world of PaaS for now. Someday, we’d like to see a PaaS system with the following features:

• Super easy setup. Run a terminal command in development to get going, even on an existing project. We want it to be flexible, but provide good defaults, such as usingUbuntu Server LTS or Nginx.
• Vagrant local development that is as similar as possible to production environment. Provide an ability to specify where production should be different, such as using precompiled JavaScript and CSS.
• Make it easy to add tools such as databases, search databases, email service providers, task queue systems, logging, automated backups, and crons. This should first update local development, and then be deployed to staging or production when the code is deployed.
• Admin interface for both local and production that keeps everything together, as much as possible. This would be great too to be able to add links to third-party services, like email providers or analytics.
• Open-source and community driven. We want to be able to set this up with basically any VPS provider. We want to be able to discuss issues and see code on Github.
• Support for common development languages and including their native tool set, such as package managers and test suites.
• Handle database migrations using the existing tooling within the development languages.
• Resolve the scaling issue. We should be able to specify a cluster of servers, and not have to worry about making the application scale out to fit it.
• Git push to deploy is amazing. We love Heroku’s deployment method.

Such a system would meet development and operations needs to start and to grow. It would make it easier for more people and teams to develop applications. Sadly, this system does not exist quite yet.

What’s coming up

We are still holding off on asking our users for money. We still have some features we need to add to make sure we meet the needs of our researchers, such as filtering analysis results, recruitment management, and sharing study access. It will likely be at least a few more months before we enter the for-pay phase of our product.

One note to our users is we are moving away from OpenID. We’ve had a few cases where researchers were locked out of their accounts, and each time it took several hours for us to be able to resolve the issue. We are migrating our system to use a traditional email and password login and so when we deploy the new system, you will need to make a password for your account using the email address from your OpenID account.

Right now we are working on testing our application and getting our production server ready to go. We are also working on the method we will use to export the data from Google App Engine and put it into our PostgresQL database. We are hoping to have this migration complete by the end of the month, but we are not providing a formal time estimate due to the level of challenge this migration entails.

Closing thoughts

Google App Engine empowered us to get our idea out the door quickly and establish the need for our application. We will be forever grateful to the team at Google working on App Engine and we hope they will expand their offering. That said, we have to fulfill our needs, and its time for us to move to the next step.

—