How to migrate Google App Engine Project to Compute Engine completely?

5
votes

We have been using Google App Engine for the backend services of a project which has been developed completely as a Gooogle App Engine Project.

Lately, the front end instances were consuming more than 60-70% of our project expense. Thus we decided to do away with it completely and migrate to Google Compute Engine instead.

Wanted to know if anyone has migrated their GAE project to GCE. I understand that GCE VMs could be dynamically spun up from within a GAE app, but we want to completely do away with GAE. (Source)

As a last option, I shall host a Django project and use GAE files as the controller for the web services.

However, wanted to know if there are other potentially easier options for moving GAE projects to GCE while keeping the datastore integration intact.

TIA

1
pythongoogle-app-enginegoogle-compute-engine
Are you GAE services using standard or flex environment? – Dan Cornilescu
@DanCornilescu GAE is using standard environment. – silverFoxA
I believe GAE standard is generally more cost effective than GCE. Why do you think GCE is a better solution for you? – gaefan
@JeffO'Neill GAE - Hosting a simple laravel project with minimum requests cost us 90$ per month where hosting the same on a VPS cost us 10$. The difference in pricing is the real concern as our product is still in beta stage – silverFoxA
@silverFoxA, to give you another data point, my GAE app gets about 20,000 sessions a month and costs me $10-15 per month. When I had minimal requests, I was paying 10 cents per month. Perhaps you are using SQL which I believe costs much more than datastore? – gaefan

1 Answers

3
votes

Unfortunately the uniqueness of the standard environment support for the application may make your migration quite difficult.

Take, for example, the significant differences just between the standard env and the flexible env (which, if you want, would be like an intermediary step towards total migration to GCE): Migrating Services from the Standard Environment to the Flexible Environment. To me they're practically different beasts.

To make matters worse the very thing you consider the most important in your migration - keeping the datastore integration intact - is also the most likely to stand against your migration.

That's because chances are that your app uses one of the dedicated client libraries, optimized for and only available to the standard environment GAE apps. If so - the migration effectively means re-designing the entire interaction with the datastore to make it use one of the more generic datastore libraries instead. Which means more than just translating API calls - there are conceptual and functional differences that would need to be addressed.

So the answer to the title question may very well be: redesign your app for GCE. Personally I'm unsure if GCE is overall more cost-effective - I still prefer the standard env GAE. Assuming at some point the costs go up enough to maybe re-consider, I'd:

  • take a closer look at the pricing and the current app costs breakdown, to see which components are the heavier ones: if the majority of the costs come, for example, from the datastore usage - I wouldn't expect a migration to GCE to significantly help
  • try to tune the app's config and/or code to reduce costs: for example if the instance hours represent the majority in the costs tuning the scalability configurations depending on the actual traffic patterns might lower the bill
  • estimate the costs for similar usage patterns but with the corresponding components available on GCE (and/or GAE flex)
  • if the respective components are also available on GAE flex I'd make some experiments using that instead of going full GCE (which would pretty much require the re-write first).

A gradual transition using the flexible environment as a stepping stone could reveal if the estimated costs savings aren't quite there, thus helping drop the whole transition before doing the entire re-write. And also could help with the re-write, in case the transition still remains a "go".

Update: There might be another solution to consider for reducing costs: running the existing GAE app code through AppScale (see also ) on a more cost-effective IaaS provider.