Hey Yair,

The extent to which your specific app will scale or not scale is largely 
dependent on what code is running, what language runtime and frameworks you 
use, and how you configure 
<https://cloud.google.com/appengine/docs/python/modules/#Python_Instance_scaling_and_class>
 
your scaling settings 
<https://cloud.google.com/appengine/docs/python/scaling>. Needless to say, 
efficient scaling is something we make a top priority and to the extent 
that we can at all control for these factors beyond your own code and 
configuration, we strive to make our services (Datastore, Memcache, etc.) 
as available and efficient as possible so that you can focus on your code 
and the issue of scaling can be manageable to consider.

To see what potential bottlenecks exist in any system you build, you'll 
really need to do load testing of your app on the infrastructure *in 
addition to* any abstract reasoning based on technical specs, and all of 
this is to speak agnostically with respect to serving infrastructure (of 
course, again, we believe our infrastructure, due to our extensive and 
explicit work towards this end, is very scalable indeed, and numerous 
companies <https://cloud.google.com/customers/> have found the same to be 
true).

All this said, scaling effectively in an environment different to the 
traditional heavy monolithic server paradigm of web development in years 
past does require a mind-shift, although that's true of any modern cloud 
deployment infrastructure. Check out some of these articles we've produced 
to get a start on best-practices:

Building Scalable and Resilient Web Applications on Google Cloud Platform 
<https://cloud.google.com/solutions/scalable-and-resilient-apps>

Designing for ScaleFinally, I want to assure you that migrating away from 
the platform is definitely a possibility, especially so if you use an 
abstraction layer to our services and APIs, such as Datastore (interacting 
with Datastore via JDO or JPA in Java is one example). Secondly, Managed VMs 
<https://cloud.google.com/appengine/docs/managed-vms/> and especially Custom 
Runtimes 
<https://cloud.google.com/appengine/docs/managed-vms/custom-runtimes/> for 
Managed VMs makes this even easier, given that you can deploy your 
application as a self-contained Docker image which can really run on any 
deployment infrastructure.

I hope this has answered some of your questions and given you confidence to 
go deeper into our documentation. Feel free to ask me any further questions 
you have and I'll be happy to assist.

Regards,

Nick
Cloud Platform Community Support

On Tuesday, March 15, 2016 at 5:49:23 AM UTC-4, Yair Lempert wrote:
>
> We are at an earlier stages of new mobile app project with cloud server 
> backend.
>
> One of the cloud backend candidates is GAE. 
> I'd like to know if anyone here had experienced any sort of degradation of 
> service once reaching certain amount of users/load.
> I know this question is a bit vague and the implementation plays a major 
> part but still, it would be interesting to know if keeping all other 
> factors but an increase in concurrent users constant, did you notice a 
> lower response time or retrieving or updating objects in the datastore 
> becomes slower?
> Would appreciate any concrete figures you could share.
> The safe bet is to take mongo/node.js where we can control every factor. 
> On the other hand the GAE is obviously lucrative as it saves much dev/ops 
> work. However, porting from GAE should the scale wouldn't hold is extremely 
> difficult.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/d8ede50e-f18d-49fe-bfa7-346345828ab6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to