[google-appengine] Re: deadline errors for pages which normally load fast

[Robert King]

A few hours ago most of our python app went down & all requests were timing 
out. (Our app has never been down before).
I checked https://code.google.com/status/appengine/ and it said 
"investigating" for Memcache & Python so they must have been having some 
issues.
I'm not sure why there is a green tick there now.

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Custom domains stopped to work

[Robert King]

I'm in NZ too and none of my domains are working!

On Wednesday, 12 March 2014 09:51:30 UTC+13, GregF wrote:
>
> Yes - same issue here (NZ) on some networks. Great to hear I'm not the 
> only one. HELP!!!
>
> On Wednesday, 12 March 2014 09:40:24 UTC+13, Tomas Adamek wrote:
>>
>> Hi there
>>
>> it seems like that today all my custom domain configured in my google 
>> apps account stopped to forward the traffic to app engine applications. All 
>> custom domains directs to google.com page now (or display 404 if I use 
>> custom.domain/some-path/
>>
>> The standard appspot url's works fine, ie:
>>
>> http://cover.librarist.com/9780007489978.jpg
>> http://cover-librarist-com.appspot.com/9780007489978.jpg
>>
>> Does anyone have similar issue?
>>
>> Cheers
>>
>> Tomas
>>
>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] analysing /_ah/api performance

[Robert King]

HI, is this possible? I tried searching app engine logs: path:/_ah/api.*
nothing came up obviously.

for 
example
, /_ah/api/discovery/v1/apis/archivedash/v1/rpc?fields=methods%2F*%2Fid&pp=0  
is often at times running slowly (e.g. waiting over 10 seconds on fast 
connection). I'd like to investigate it somehow.
Is it a problem elsewhere in my app (e.g. some of my webapp2 handlers have 
high latency due to doing many urlfetches etc) or is it a problem with 
endpoints that don't have much traffic?
I'm wondering if performance of /api/discovery can be effected if other 
parts of my app are experiencing high latency or is its performance self 
contained?

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] analysing /_ah/api performance

[Robert King]

Hi Vinny,
I'm running appstats but that request doesn't come through. Is there a way 
to make it appear with app stats? (other api calls do come through on app 
stats)


--
To be clear, this is how I have appstats installed in appengine_config.py 
and app.yaml:

'''
start App Stats config
default link: /_ah/stats/
see https://developers.google.com/appengine/docs/python/tools/appstats
'''

appstats_CALC_RPC_COSTS = True

def webapp_add_wsgi_middleware(app):
from google.appengine.ext.appstats import recording
app = recording.appstats_wsgi_middleware(app)
return app

'''End App Stats config'''


and 

builtins:
- appstats: on
--

App stats works for most api calls e.g:
(1) 2014-05-20 20:08:05.073 "POST 
/_ah/spi/ArchiveDashEndpoint.getArchiveData" 200 
<http://robert-dot-td-admin.appspot.com/_ah/stats/details?time=1400645285073>real=15121ms
 
api=0ms overhead=72ms (43 RPCs, cost=133840, 
billed_ops=[DATASTORE_READ:1912])

however the request I asked about *doesn't come through in app stats *(which 
is why I asked if there is a way to investigate it): (ass you can see there 
are both robert-dot-modulename-appid and robert-dot-appid)



   1. Remote Address:
   x
   2. Request URL:
   
   
https://robert-dot-api-server-dot-x.appspot.com/_ah/api/discovery/v1/apis/x/v1/rpc?fields=methods%2F*%2Fid&pp=0
   3. Request Method:
   GET
   4. Status Code:
   304 Not Modified
   5. Request Headers
  1. :host:
  robert-dot-api-server-dot-x.appspot.com
  2. :method:
  GET
  3. :path:
  /_ah/api/discovery/v1/apis/x/v1/rpc?fields=methods%2F*%2Fid&pp=0
  4. :scheme:
  https
  5. :version:
  HTTP/1.1
  6. accept:
  */*
  7. accept-encoding:
  gzip,deflate,sdch
  8. accept-language:
  en-US,en;q=0.8
  9. if-none-match:
  "x/x"
  10. referer:
  
  
https://robert-dot-api-server-dot-x.appspot.com/_ah/api/static/proxy.html?jsh=m%3B%2F_%2Fscs%2Fapps-static%2F_%2Fjs%2Fk%3Doz.gapi.en.6SWenkOB4-I.O%2Fm%3D__features__%2Fam%3DAQ%2Frt%3Dj%2Fd%3D1%2Fz%3Dzcms%2Frs%3DAItRSTPqnV0vyAsVqqzFCGu-iTJCnEAiGw
  11. user-agent:
  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 
  (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36
  12. x-clientdetails:
  
  
appVersion=5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010_9_2)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F34.0.1847.137%20Safari%2F537.36&platform=MacIntel&userAgent=Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010_9_2)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F34.0.1847.137%20Safari%2F537.36
  13. x-goog-encode-response-if-executable:
  base64
  14. x-javascript-user-agent:
  google-api-javascript-client/1.1.0-beta
  15. x-origin:
  https://robert-dot-x.appspot.com
  16. x-referer:
  https://robert-dot-x.appspot.com
  


btw - the appstats link i'm using 
is http://robert-dot-x.appspot.com/_ah/stats/? and appstats is only 
deployed to that version. I can't make that version the default for 
production but this api is only running on my version anyway.

On Friday, 16 May 2014 17:59:32 UTC+12, Vinny P wrote:
>
> On Thu, May 15, 2014 at 4:20 PM, Robert King 
> 
> > wrote:
>
>> for 
>> example<http://stackoverflow.com/questions/23618638/google-cloud-endpoints-ah-api-discovery-v1-apis-myapi-v1-rpc-takes-half-a-minu>
>> , 
>> /_ah/api/discovery/v1/apis/archivedash/v1/rpc?fields=methods%2F*%2Fid&pp=0  
>> is often at times running slowly (e.g. waiting over 10 seconds on fast 
>> connection). I'd like to investigate it somehow.
>> Is it a problem elsewhere in my app (e.g. some of my webapp2 handlers 
>> have high latency due to doing many urlfetches etc) or is it a problem with 
>> endpoints that don't have much traffic?
>> I'm wondering if performance of /api/discovery can be effected if other 
>> parts of my app are experiencing high latency or is its performance self 
>> contained?
>>
>
>
>
> The best way to pinpoint performance issues is to record an AppStats run 
> of the request. Can you install AppStats (see instructions 
> here<https://developers.google.com/appengine/docs/java/tools/appstats>), 
> run an API request, then post the AppStats record back here?
>  
>
> -
> -Vinny P
> Technology & Media Advisor
> Chicago, IL
>
> App Engine Code Samples: http://www.learntogoogleit.com
>  
>  

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] analysing /_ah/api performance

[Robert King]

the link is /_ah/api/discovery/v1/apis/archivedash/v1/rpc?
fields=methods%2F*%2Fid&pp=0
is for discovery - it's a google thing - i didn't write that endpoint.
I think you're thinking of *spi* rather than *api*?


On Thursday, 22 May 2014 15:00:04 UTC+12, Vinny P wrote:
>
> On Tue, May 20, 2014 at 11:38 PM, Robert King 
> 
> > wrote:
>
>> I'm running appstats but that request doesn't come through 
>>
> (other api calls do come through on app stats)
>>
>
>
> That's fine.
>
> For the other API calls, do they do largely the same work as the 
> problematic API endpoint, or do they handle vastly different workloads? For 
> instance, do they access the same search API, datastore kinds, and so 
> forth? If they don't access the same resources, what resources is the 
> problematic endpoint accessing *that are different*? For those resources 
> that are different, can you list general statistics for them (e.g. number 
> of datastore entities, size/num of search documents, etc)?
>   
>  
> -
> -Vinny P
> Technology & Media Advisor
> Chicago, IL
>
> App Engine Code Samples: http://www.learntogoogleit.com
>  
>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Why are cloud endpoints so slow ?

[Robert King]

Don't get me wrong - I absolutely love cloud endpoints - they speed up my 
development time and simplify my code significantly.
Having said that, I'd really like to see some clarification from google. 
Are endpoints intended to be high performance? I haven't once seen 
mentioned in any google documentation that endpoints are low latency?  I've 
often been waiting 5-20 seconds for calls such as /_ah/api/discovery/
v1/apis/archivedash/v1/rpc?fields=methods%2F*%2Fid&pp=0.
even on apps that have little traffic, tiny payloads and no rpc calls. One 
of the new systems i'm building is using endpoints but i'll have to switch 
away from endpoints ASAP if I can't get some reassurance. Also I don't have 
time to wait "a couple of months" to see if they get faster. I'd also be 
interested to know how efficient python / go / java / php endpoints are at 
encoding & decoding different sized payloads with json or protobuff 
protocols. (Will probably have to generate these statistics myself & 
present some graphs etc - although I'm assuming google would have already 
performance tested their own product?)
cheers

On Sunday, 25 May 2014 08:29:48 UTC+12, Diego Duclos wrote:
>
> I've done some (non extensive) tests on google appengine,
> and my response times vary from anywhere between 100ms and 5000ms when 
> directly sending http requests to a cloud endpoints.
>
> Regardless of the actual response time, the google cloud console always 
> shows a processing time of around 50ms, which, while also somewhat 
> long-ish, is much more reasonable.
>
> For the 100ms requests, I can safely know that the other 50ms are just 
> regular latency, but I have no idea where the cloud endpoint could be 
> spending 4.5 seconds at, and the logs show nothing useful at all.
>
> Does anyone have some guidance for me regarding to this ? 5 seconds is 
> unacceptable slow and makes them completely unusable.
>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Why are cloud endpoints so slow ?

[Robert King]

also might be worth noting I'm using CORS on multiple app engine modules 
etc. perhaps it's something to do with preflight requests? 
http://monsur.hossa.in/2012/09/07/thoughts-on-the-cors-preflight-cache.html

On Sunday, 25 May 2014 20:53:15 UTC+12, Robert King wrote:
>
> Don't get me wrong - I absolutely love cloud endpoints - they speed up my 
> development time and simplify my code significantly.
> Having said that, I'd really like to see some clarification from google. 
> Are endpoints intended to be high performance? I haven't once seen 
> mentioned in any google documentation that endpoints are low latency?  I've 
> often been waiting 5-20 seconds for calls such as /_ah/api/discovery/
> v1/apis/archivedash/v1/rpc?fields=methods%2F*%2Fid&pp=0.
> even on apps that have little traffic, tiny payloads and no rpc calls. One 
> of the new systems i'm building is using endpoints but i'll have to switch 
> away from endpoints ASAP if I can't get some reassurance. Also I don't have 
> time to wait "a couple of months" to see if they get faster. I'd also be 
> interested to know how efficient python / go / java / php endpoints are at 
> encoding & decoding different sized payloads with json or protobuff 
> protocols. (Will probably have to generate these statistics myself & 
> present some graphs etc - although I'm assuming google would have already 
> performance tested their own product?)
> cheers
>
> On Sunday, 25 May 2014 08:29:48 UTC+12, Diego Duclos wrote:
>>
>> I've done some (non extensive) tests on google appengine,
>> and my response times vary from anywhere between 100ms and 5000ms when 
>> directly sending http requests to a cloud endpoints.
>>
>> Regardless of the actual response time, the google cloud console always 
>> shows a processing time of around 50ms, which, while also somewhat 
>> long-ish, is much more reasonable.
>>
>> For the 100ms requests, I can safely know that the other 50ms are just 
>> regular latency, but I have no idea where the cloud endpoint could be 
>> spending 4.5 seconds at, and the logs show nothing useful at all.
>>
>> Does anyone have some guidance for me regarding to this ? 5 seconds is 
>> unacceptable slow and makes them completely unusable.
>>
>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] analysing /_ah/api performance

[Robert King]

I found this related issue 
here https://code.google.com/p/googleappengine/issues/detail?id=10017





On Thursday, 22 May 2014 17:46:16 UTC+12, Robert King wrote:
>
> the link is /_ah/api/discovery/v1/apis/archivedash/v1/rpc?
> fields=methods%2F*%2Fid&pp=0
> is for discovery - it's a google thing - i didn't write that endpoint.
> I think you're thinking of *spi* rather than *api*?
>
>
> On Thursday, 22 May 2014 15:00:04 UTC+12, Vinny P wrote:
>>
>> On Tue, May 20, 2014 at 11:38 PM, Robert King 
>>  wrote:
>>
>>> I'm running appstats but that request doesn't come through 
>>>
>> (other api calls do come through on app stats)
>>>
>>
>>
>> That's fine.
>>
>> For the other API calls, do they do largely the same work as the 
>> problematic API endpoint, or do they handle vastly different workloads? For 
>> instance, do they access the same search API, datastore kinds, and so 
>> forth? If they don't access the same resources, what resources is the 
>> problematic endpoint accessing *that are different*? For those resources 
>> that are different, can you list general statistics for them (e.g. number 
>> of datastore entities, size/num of search documents, etc)?
>>   
>>  
>> -
>> -Vinny P
>> Technology & Media Advisor
>> Chicago, IL
>>
>> App Engine Code Samples: http://www.learntogoogleit.com
>>  
>>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Why are cloud endpoints so slow ?

[Robert King]

Hi Jun, 
Thanks so much for answering these questions - it's very helpful.
What does the additional frontend API layer do? What's the performance 
impact?

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Does Google App Engine (Flexible) Support Google Endpoints?

[Robert King]

Sorry if this is harsh and correct me if i'm wrong.
I think google should take a stance on this. You can't just say "feel free 
to file a feature request". Google should decide if endpoints make sense or 
not and if not, apologies to existing developers using it & put a warning 
in the documentation for people new to app engine. I've been pretty 
disappointed with google apis, I suspect google doesn't use their own apis 
internally, and that their apis are just a quick and dirty wrapper around 
what they use internally (for example, how many full time engineers are 
there working on making google api clients nice?). For example look at the 
javascript client library that's not out of beta since 
2012 
https://groups.google.com/forum/#!topic/google-api-javascript-client/sfxFLTI8h6Y
You would think they'd have a nice typescript version too for each api. 
Perhaps they're waiting on firebase integration and there is conflict with 
firebase auth etc, who knows?



On Thursday, 30 June 2016 07:47:57 UTC+12, Nicholas (Google Cloud Support) 
wrote:
>
> You are correct that there is no documentation on Google Cloud Endpoints 
> within the App Engine flexible environment.  As posted by Zdenko, they are 
> not supported at this time.  Though it may work in some cases, there's 
> officially no support for this and it should not be relied upon.
>
> If you would like to see Endpoints implements into the flexible 
> environment, feel free to file a feature request on the App Engine public 
> issue  tracker.
>
> Hope this helps.
>
> On Tuesday, June 28, 2016 at 3:33:07 PM UTC-4, Bill Li wrote:
>>
>> Hi, I have used Google Endpoint on Google App Engine Standard environment 
>> before, and I think it is easy to use. But I did not find any documentation 
>> on how to deploy Endpoints on Google App Engine Flexible Environment. Do 
>> anyone has any idea about whether we can use endpoints on flexible 
>> environment?
>> From my research, it seems that the Google App Engine SDK is only used by 
>> Standard mode, and the endpoints need support from Google App Engine SDK. 
>> So I am wondering whether this means the Flexible Environment does not 
>> support Google Endpoint?
>> Thanks for any answer!
>>
>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
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/d337f695-4dc0-4f48-9cc1-208b72d71ab5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Does Google App Engine (Flexible) Support Google Endpoints?

[Robert King]

Thanks Jon
Good to hear there are plans for investing in endpoints. I would say being 
able to easily build APIs is fairly fundamental and is a high priority. 
There is a lot of work that could be done to the api explorer, testing, and 
api clients. Having typescript definitions would also be really nice.
I like that you can swap out backends although I'm having to use 
go-endpoints which is not an official package and comes with no guarantees 
or support
I do run seperate modules which is nice - Although It does impact instance 
hours which generally puts you over the free quota. Perhaps 15 minutes to 
startup a go module is a bit harsh since go is very quick to startup.



On Friday, 1 July 2016 07:28:26 UTC+12, Jon Parrott wrote:
>
> Robert and everyone: we hear you. Please keep in mind that App Engine 
> Flexible is still in beta, and the Python compat runtime itself is in 
> alpha. We're still doing a lot of work on both and we're still collecting 
> user feedback. Things like this mailing list and the public issue track are 
> some of the ways we collect feedback, so while it may appear dismissive for 
> us to say "file an issue" - we do take those seriously.
>
> Regarding endpoints itself: I can't speak any definite plans, but I can 
> stay that we are investing in endpoints and that you should stay tuned.
>
> In the meantime, I would recommend looking into "hybrid" applications - 
> use app engine services (neé modules) to have one service running on 
> standard that works as your API frontend, and another service running on 
> flexible that can handle the heavy lifting. 
>
> On Wednesday, June 29, 2016 at 8:57:58 PM UTC-7, Robert King wrote:
>>
>> Sorry if this is harsh and correct me if i'm wrong.
>> I think google should take a stance on this. You can't just say "feel 
>> free to file a feature request". Google should decide if endpoints make 
>> sense or not and if not, apologies to existing developers using it & put a 
>> warning in the documentation for people new to app engine. I've been pretty 
>> disappointed with google apis, I suspect google doesn't use their own apis 
>> internally, and that their apis are just a quick and dirty wrapper around 
>> what they use internally (for example, how many full time engineers are 
>> there working on making google api clients nice?). For example look at the 
>> javascript client library that's not out of beta since 2012 
>> https://groups.google.com/forum/#!topic/google-api-javascript-client/sfxFLTI8h6Y
>> You would think they'd have a nice typescript version too for each api. 
>> Perhaps they're waiting on firebase integration and there is conflict with 
>> firebase auth etc, who knows?
>>
>>
>>
>> On Thursday, 30 June 2016 07:47:57 UTC+12, Nicholas (Google Cloud 
>> Support) wrote:
>>>
>>> You are correct that there is no documentation on Google Cloud Endpoints 
>>> within the App Engine flexible environment.  As posted by Zdenko, they are 
>>> not supported at this time.  Though it may work in some cases, there's 
>>> officially no support for this and it should not be relied upon.
>>>
>>> If you would like to see Endpoints implements into the flexible 
>>> environment, feel free to file a feature request on the App Engine 
>>> public issue <https://code.google.com/p/googleappengine/issues/list> 
>>> tracker.
>>>
>>> Hope this helps.
>>>
>>> On Tuesday, June 28, 2016 at 3:33:07 PM UTC-4, Bill Li wrote:
>>>>
>>>> Hi, I have used Google Endpoint on Google App Engine Standard 
>>>> environment before, and I think it is easy to use. But I did not find any 
>>>> documentation on how to deploy Endpoints on Google App Engine Flexible 
>>>> Environment. Do anyone has any idea about whether we can use endpoints on 
>>>> flexible environment?
>>>> From my research, it seems that the Google App Engine SDK is only used 
>>>> by Standard mode, and the endpoints need support from Google App Engine 
>>>> SDK. So I am wondering whether this means the Flexible Environment does 
>>>> not 
>>>> support Google Endpoint?
>>>> Thanks for any answer!
>>>>
>>>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
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/5228a6ca-6364-40b3-acd7-6f26b1bc5714%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: "One senses GAE is just not a major priority for Google"

[Robert King]

I agree with Jeff Schnitzer. I think google is afraid of the whole open 
source & docker thing gaining huge momentum and doesn't want to miss out so 
they want to make that part of their foundation e.g. things like 
kubernettes. They also want to make it easy for people to migrate from 
other clouds to google cloud. I personally like app engine instances - they 
are very lightweight containers - docker is great if you need third party 
libraries that aren't on app engine  & lots of developers don't want to shy 
away from that. I personally like the simplicity of app engine containers & 
most of my app can run on them. 95% of my code can run on app engine doing 
orchestration - I can always have processes running on compute engine with 
docker etc if I need - but even as it stands app engine can do a huge 
amount of what you need. Even if google didn't make many improvements to 
app engine for a while - I can still do a huge amount with app engine. I 
think a lot of grads coming out of university will go with PAAS & things 
such as firebase to keep things simple, however a lot of the senior 
developers will like to stick with what they know. It also seems like 
appengine needs a faster deployment cycle & better testing / simulation. So 
perhaps there is technical debt there.

On Saturday, 1 November 2014 06:55:34 UTC+13, Jeff Schnitzer wrote:
>
> I agree. I thought that article was basically a fluff piece written by 
> someone who has never actually used GAE.
>
> Nobody ever cared about the "subset of Java" issue except Sun who, as 
> non-users, count only as whiners ("no, Java's mine, you have to use it the 
> way I want!"). And the very old version of python was fixed (2.7, well, 
> yes, it's still old but let's face it half the Python community hasn't made 
> it to 3.0 yet).
>
> IMHO, the biggest issue is that human beings are slow to adopt new things. 
> Most web developers never move beyond the first stack they learn (usually 
> LAMP or Rails). Ask them to go outside of their MySQL comfort zone and they 
> get all nervous and sweaty. GAE is something different, and the truth is 
> that even programmers are a conservative lot.
>
> There are real problems with GAE (those two items chief among them) but I 
> think the main reason Google is focusing so much on Compute Engine instead 
> of GAE is that the vast bulk of developers haven't bought into the concept 
> of PaaS yet. They've just barely made the mental transition off of 
> colocated boxes. IaaS is an easier sell, even if it's a dumb choice.
>
> Jeff
>
> On Fri, Oct 31, 2014 at 5:28 AM, Tapir > 
> wrote:
>
>>
>>
>> On Wednesday, October 29, 2014 5:11:15 AM UTC+8, Emanuele Ziglioli wrote:
>>
>>> I would find hard to disagree:
>>>
>>> *IBM, Google, and Oracle are all equally at pains to deliver a message 
 that makes them uniquely attractive. In this regard, Google's inability to 
 recover from the botched roll-out of Google App Engine (GAE) will surely 
 go 
 down as one of the oddest business cases. It launched the product with 
 great fanfare. But developers who flocked to it initially found a 
 difficult 
 platform that supported only a subset of Java and a very old version of 
 Python. Moreover, the interfaces to the proprietary database were poorly 
 thought out, so that almost everything in GAE required platform-specific 
 code-arounds. While GAE has improved in a limited sense since then, Google 
 has not done what Microsoft did — revamp the product from top to bottom to 
 make it easy to use. Nor has it leveraged its natural connection to 
 developers. One senses GAE is just not a major priority for Google.*
>>>
>>>
>>> http://www.drdobbs.com/cloud/whose-cloud-will-you-use/240169229
>>>
>>
>> GAE really has two problems, neither of them are belong to what mentioned 
>> in this article. On the contrary, what mentioned the article are really 
>> good point, IMO.
>>
>> The two problems are:
>> 1. high price, for both instance hours and bigtable operations.
>> 2. long Java instance startup time.
>>
>> In my GAE experience, it is very reliable. BigTable is very powerful and 
>> easy to use.
>>  
>>
>> -- 
>> 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 google-appengi...@googlegroups.com .
>> To post to this group, send email to google-a...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/google-appengine.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com