My company have been on appengine over 4-5 years now. We use namespaces a
lot, for organising the users data.
Better namespaces support in all tools and utilities
After the backup, able to selectively restore the namespace data, to
another appid
Easy Export of namespace data to Google spreadsheet
Datastore viewer (both new and old) needs lot of improvement. It is
difficult to navigate the data and correct the data. For example, the list
property data cannot be edited in the datastore viewer
Currently, mapreduce is only the framework for processing/migrating the
data. This opensource project should have more documentation and examples.
Again, there is lack of namespaces examples and lack of documentation on
the namespaces.
Rajesh
www.AccountingGuru.net
Accounting/Inventory/Billing on Google Cloud Platform.
On Friday, April 24, 2015 at 3:39:29 AM UTC+5:30, Aleem Mawani wrote:
>
> @chris, thanks for asking,
>
> 1) Sorry I might have had some confusion here, I thought traffic
> splitting/traffic migration didn't work for managed VM's but it in fact it
> doesn't work for any non-default module. We haven't yet tried to put our
> default module on managed vms because of stability concerns (may be
> outdated) and the api's listed below)
>
> 2) Re: APIs, we can't yet do the following in Managed VM's:
>
> - channel api: we use this to send realtime notifications to web/mobile
> clients
> - logging api: we use this to export our logs to BQ
>
> 3) The other things preventing us from moving default module over to
> managed vms:
>
> - cloud console dashboard doesn't show a lot of the aggregate metrics for
> a managed vm module, most importantly instance count over time.
> - cloud monitoring can't monitor managed vm instance count
> - seemed that instances would go into unhealthy state and not recover or
> get killed (this could be outdated)
>
>
> At the current moment there seems to be no major concerns with managed
> VM's (except for the things you're working on like startup time and deploy
> time and dev experience) but there are dozens of tiny gotchas which
> individually don't seem like much but together are a big enough deal that
> we don't serve front end traffic over it.
>
> For background processing the value is so high that we've moved all of our
> backend modules to managed vms (unless they need any of the above API's).
>
> On Thursday, April 23, 2015 at 2:24:59 PM UTC-7, Chris Ramsdale wrote:
>>
>> yes, the goal is to get App Engine Managed VMs (v2) to a state where they
>> are ideal for frontend serving. couple of questions for you:
>>
>> (1) is traffic splitting and deploy-to-a-default-module not working for
>> you?
>> (2) re: APIs, which ones would you like to see enabled? you mentioned
>> logging (and the goal is to move App Engine Logging API over to Google
>> Cloud Logging all-up), but what else are you looking for?
>>
>> -- Chris
>>
>> On Thu, Apr 23, 2015 at 11:47 AM, Aleem Mawani wrote:
>>
>>> Chris - with the improvements you're suggesting to Managed VMs (20 sec
>>> deploys, <1 sec instance startup time) - will it be recommended to use
>>> Managed VMs to serve frontend traffic? Right now they seem to be more
>>> targetted to backend processing because of the slow scaling.
>>>
>>> If this is true, and you are targeting it to serve front end traffic,
>>> does that mean we'll be able to deploy Managed VMs to our default modules,
>>> perform traffic splitting, access the logging api's and realtime api's,
>>> etc? These are the things that have been traditionally missing from managed
>>> vms.
>>>
>>> On Wednesday, April 22, 2015 at 10:33:46 AM UTC-7, Chris Ramsdale wrote:
On Wed, Apr 22, 2015 at 2:21 AM, troberti wrote:
> What a flurry of activity. :) Great to see.
>
> I have been using GCP( App Engine + BigQuery) in total for over 5
> years, so not new, but I have seen plenty of new users make mistakes so
> let
> me chime in a bit:
>
> On App Engine (and GCP) there are a lot of ways to approach a problem,
> with the consequence that is very easy to choose the wrong solution.
> There
> is actually a rather steep learning curve to just know what is available.
>
> This is a problem, because the differences between various solutions
> can result in an order of magnitude difference in
> costs/latency/complexity
> etc. I stopped counting the amount of times I have seen models with every
> property indexed, resulting in huge datastore costs. Or where someone
> tries
> to put tons of data in the Datastore while BigQuery would be a much
> better
> fit for the problem. Every time this happens, the new user ends up
> disappointed. So guiding new users in the right direction when starting
> out
> on GCP seems very important.
>
> I agree with a lot in Karl's post, and especially the Roadmap. It
> doesn't need to be abou
