Google Cloud Platform wants to hear from you

[Katie Ball (Google Cloud Support)]

Hi,

My name is Katie, and I am on the Google Cloud Platform technical support team.

This message is to Google Cloud Platform community members, especially if you are newer to GCP. I would like to know what our team can do to help you have a better and more enjoyable experience during the first days on GCP.

Did you need technical support?  If so, I’d like to hear all about it.

I’d also like to know:

• What did you find most difficult about the first-time user experience?

• Where did you get stuck?

Please reply to the group with your answers or any ideas you have on how the technical support team can help new customers get familiar with GCP.

And as a thank you for the great ideas, we will be giving away support coupons worth $450 (equivalent to 3 months of silver support) to 5 lucky community members who post a response. Please make sure to reply before April 22nd.

Thanks for your insights, and cloud on!

Katie

[Karl MacMillan]

Katie,

Thanks for asking the question.

I’ve been using GCP for about 6 months now. I found the tutorial material and reference documentation to range from pretty good to good enough - there are a few rough points, but nothing that really bothered me. So I didn’t get stuck much in the early days.

Some things that could be smoother (this is all python):

1. Default way to handle 3rd party dependencies in an app - there are options and they work ok, but this is so common it would be nice to have an officially supported method. Especially since the common ones break on managed VMs because you don’t support appengine_config.py there.

2. Webapp2 - it’s OK, but definitely not great. From the outside there doesn’t seem to be a strong reason to be using something that has not gained broader traction when supporting something like Flask shouldn’t be hard. That would gain a much broader ecosystem rather than the very narrow, App Engine focused ecosystem around webapp2.

3. Cloud Storage - I could not find a quick and nice way to securely expose native links from cloud storage to clients via a REST API without having to have the clients reauth to cloud storage. So I’m just pulling from cloud storage on the backend, doing my own authorization, and serving them via my own REST API. A hack that I’ll get rid of eventually, but I didn’t want to fiddle anymore. This seems like a common use case to me, but who knows.

4. Cloud Endpoints - the biggest problem I had in early days was cloud endpoints. I have what I feel is a really common use case - I just need to do some CRUD operations on datastore entities using a REST API. I looked at enpoints and it looked like exactly what I needed. But then I saw I needed to largely duplicate my data model in NDB and Cloud Endpoints. Except there is this open source library that claims to connect them together (http://endpoints-proto-datastore.appspot.com), but it’s quirky, has quirky docs, and is kinda, sorta supported by Google. And then what’s with the assumption that these APIs will accept and return the same data types (seriously - who does that by default)? And then there was the tooling to generate client libraries that’s - honestly - just not great. Eventually the CORBA flashbacks got bad enough that I just completely abandoned cloud endpoints in favor of rolling it myself. For me, cloud endpoints definitely created _way_ more problems than it solved.

5. User service - when evaluating options things like the User services popped out to me. I thought, great, I’ll use a PaaS and things like user auth will be sanely handled. Except that it is so limited as to not be viable at all for a public product.

Beyond the beginner issues, I think there is a real problem once you move towards creating real apps. There is a need for more in-depth documentation of designing apps effectively to use the platform. Things like best practices around data modeling in the datastore (e.g., when to de-normalize and how to handle data updates once you do). There is some of this (e.g., https://cloud.google.com/appengine/articles/modeling), but it is typically out-of-date and there is not really enough of it. For better or worse, there is not a big network of bloggers handling these topics like there are for open source tools like rails, postgresq, etc.

The biggest beginner problem I see right now is the architectural options around App Engine, Managed VMs, and GCE. On paper you guys have a nice blend of offerings that can allow developers to choose the right amount of control that they want / need. The reality, though, is that there are some hard choices to be made because of inconsistencies around what services are available on the different options and how to effectively wire together the components. A concrete example for me: I need to use numpy and some other non-pure python code in some background processing, so I needed to move off of App Engine for that work. I wasted quite a bit of time figuring out how / whether I could use the Datastore (via ndb) and task queues on the different options (including auth, network architecture, and scaling). None of it is rocket science, but I felt like I was inventing things when I knew that others had already come up with effective strategies. For me - the ideal situation would be if you just supported the same services through the same APIs everywhere, so I hope that is where you were headed.

Other random thoughts / complaints:

1. GCP Roadmap - it would be nice to have some nice, clear roadmap on where things are headed. Right now, I restrict myself to only what is available and supported right now because I have no idea where you guys are headed.

2. Community - there is not a supportive / coherent community around GCP. Coming from a largely open source background this gives me a lot of culture shock. It would be great if there was at least a set of your engineers out engaging effectively in the various forums. Not just support - talking about best practices, explaining how things work, etc.

3. Stack Overflow - the whole notion of pushing all of the questions from this mailing list to stack overflow is really off putting to me. I understand what you are trying to do but a) stack overflow seems to be where GCP questions go to be completely ignored and b) the way it’s done is pretty heavy handed. Why not at least post a link to the answer back to the list? I’ve always found mailing lists as an effective way to passively be aware of common questions and gain knowledge. Stack overflow is not effective in that role for me.

4. This mailing list - honestly, I keep thinking that I should unsubscribe from this list because so many of the questions are very basic and they are generally just ignored. It’s kind of painful to watch - especially given that one volunteer is handling so much of this single handedly. I think it gives a terrible impression of GCP and makes me feel like very few experienced developers are using GCP.

I hope this feedback is helpful.

Karl

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/4f59c819-731f-422c-b33d-a68ea4d525fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Katie Ball (Google Cloud Support)]

Hi Karl,

You've taken some extra time and extra care to put this feedback together -- thank you! It's incredibly helpful; this is exactly what we need in order to better serve our users and the cloud computing community. 

I've already taken your feedback to the appropriate team members to start improving things as suggested in your post.

Is there anything that you are currently struggling with? If there is, we'd like to offer our help as a thank you.

To our GCP community members: do you have any additional feedback you'd like to send our way? Any +1's to Karl's points? We'd love to hear from you!

Thanks again,

Katie

[Joshua Smith]

I’m with Karl that stack overflow is a terrible approach to customer support.

Here’s a clue: Look around google and see how other groups provide direct support to users. Any of them using SO? Nope.

If you are going to choose one to copy, choose Chromium. By far the best user support experiences I’ve ever had with google have been with Chromium. The developers read the forums and they fix things and they help find workarounds.

-Joshua

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/9bf4066c-1634-4d35-9b20-2e1f102b79e1%40googlegroups.com.

[Brent Washburne]

Yes, +1 for Karl's feedback!  Please treat this like a professional product, and don't treat us like beta testers.  We want to rely on GCP but it still feels like a collection of services hacked together.  We want better documentation, examples and more mainstream tools, and a more polished interface.

[SS]

Dear Katie,
                   I am a regular user of GCP products for the past 3 years right  from GAS, GAE, Cloud Sql,  GCE,..etc
What we find very tough is lack of proper detailed video tutorials. For eg. in order for us to setup a GCE server, it took us less than a week to tweak it and make it up and running, rather it shoukd have taken less than a day, if all the necessary support is given. We need to post questions in Stack Overflow(Lack of Tutorials or Customer Support only fr Privileged Members). I guess the right way to attract more new Customers is to have Free Customer support  atleast for the very first month during the Initial setup and to answer all Basic Technical Questions. This ll open up even non Technical perosn to move to Google Cloud Products or else for ever Google can target only to handful of Tech Savvy groups only..

Always we need to dig all on our own and we need to report this to Google, which really makes us Beta Testers and not End Customers, of  course we pay for each Service provided by Google.

i would like to have a Customer Support for all GCP products. Fr eg, even now, I am suffering to deploy a PHP CodeIgniter app in GAE(Lack of proper support/references), i am searching everywhere in the NET to deploy it. This makes us to waste time in digging all these rather than deploying more no of APPS in GCP and this is only reducing income fr Google and thus loosing customers.

Lot of egs like this is Cloud DNS, VPN,Firewall,...etc. all these lacks proper documentation or support, which has to be fine tuned.

I hope all this will be answered in the near future, so tht Google can play a vital role in Cloud Computing. Lack of support/proper documentation really leads to a lot of waste of time.

Hope Google ll take action and reduce all these hassles.

Thnks in advance,
Ss

[Karl MacMillan]

Katie,

I feel compelled to point out that how this discussion going is a good example of some of the things that I - and it seems others - are frustrated about. You’ve asked for and received concrete feedback. Yet we’ve received no answers or discussion back from Google engineers. At least a simple acknowledgement of the _specific_ issues we’ve raised from someone with some knowledge would be helpful. Otherwise how am I to know that you bringing the “feedback to the appropriate team members” is anything more than them receiving an email that they’ll simply delete?

Look at this way - we’ve invested and in many cases bet our businesses on GCP. And especially with App Engine, this is very much an investment in an ecosystem that you’ve created that’s largely separate from the rest of the industry. It’s hard to have confidence in that bet given the almost total lack of public engagement from Google to help make this a vibrant ecosystem.

Karl

-- 

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/9bf4066c-1634-4d35-9b20-2e1f102b79e1%40googlegroups.com.

[Brad Abrams]

Karl -- thanks for your feedback!  Rest assured we are absolutely listening.  Responses to this thread have been forwarded to many different teams within cloud and have caused lots of healthy discussion.  Your feedback is greatly appreciated.  

I will compile as many of the responses as I can and get back to this group...  But please do keep the feedback coming!

..brad

Brad Abrams

Group Product Manager

Google Cloud Platform

  

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/0935A678-ED9F-497C-8B4F-843643099447%40rakkoon.com.

[Jesse Scherer (Google Cloud Support)]

Hi,

I'm another one of the Support team members working on our community efforts. A lot of Karl's random thoughts and complaints ring true for me.

Right this minute, we're trying to sharpen the blunt instrument with which we send people to Stack Overflow. I think this will address some of the noise on this group and help new users get answers on Stack Exchange. Further out we're looking at a few ways to make Stack Exchange a more reliable place to get answers. 

I will follow up here in one week with a summary of what is going on with those Stack Exchange changes. I hope you'll keep the feedback coming until then.

Regards,

Jesse

On Monday, April 20, 2015 at 11:59:14 AM UTC-4, Brad Abrams wrote:

Karl -- thanks for your feedback!  Rest assured we are absolutely listening.  Responses to this thread have been forwarded to many different teams within cloud and have caused lots of healthy discussion.  Your feedback is greatly appreciated.  

I will compile as many of the responses as I can and get back to this group...  But please do keep the feedback coming!

..brad

Brad Abrams

Group Product Manager

Google Cloud Platform

  

On Mon, Apr 20, 2015 at 8:44 AM, Karl MacMillan <ka...@rakkoon.com> wrote:

Katie,

I feel compelled to point out that how this discussion going is a good example of some of the things that I - and it seems others - are frustrated about. You’ve asked for and received concrete feedback. Yet we’ve received no answers or discussion back from Google engineers. At least a simple acknowledgement of the _specific_ issues we’ve raised from someone with some knowledge would be helpful. Otherwise how am I to know that you bringing the “feedback to the appropriate team members” is anything more than them receiving an email that they’ll simply delete?

Look at this way - we’ve invested and in many cases bet our businesses on GCP. And especially with App Engine, this is very much an investment in an ecosystem that you’ve created that’s largely separate from the rest of the industry. It’s hard to have confidence in that bet given the almost total lack of public engagement from Google to help make this a vibrant ecosystem.

Karl

On Apr 16, 2015, at 5:50 PM, Katie Ball (Google Cloud Support) <kmrich...@google.com> wrote:

Hi Karl,

You've taken some extra time and extra care to put this feedback together -- thank you! It's incredibly helpful; this is exactly what we need in order to better serve our users and the cloud computing community. 

I've already taken your feedback to the appropriate team members to start improving things as suggested in your post.

Is there anything that you are currently struggling with? If there is, we'd like to offer our help as a thank you.

To our GCP community members: do you have any additional feedback you'd like to send our way? Any +1's to Karl's points? We'd love to hear from you!

Thanks again,

Katie

-- 
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+unsub...@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/9bf4066c-1634-4d35-9b20-2e1f102b79e1%40googlegroups.com.
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+unsubscribe@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.

[Alistair Burrowes]

Hi,

I would echo a lot of what Karl said.

I would like to see more examples of complex usage of GAE and or managed VMs. These are the kind of usages that more advanced developers might want. Here are a few examples of things that I have figured out or want:

- CI/CD set up, with dev/staging environments and one button deployments to production. It was a pretty long process of trial and error to achieve this.

- a single page app with separate the web front end and the backend (endpoints) modules. This was also tricky since endpoints live behind /_ah which can't be routed away from the default application. I think separating these out and their build processes is healthy separation of concerns.

- integrating gulp build processes into GAE dev servers/build processes. In my case I'm using gradle app engine plugin.

- "ismorphic" javascript app, with server side rendering via something like react (I assume this would be a managed VM running node js) that speaks to endpoints, from both client side and the node js layer.

Also I agree that more transparency on the roadmap/discussions on direction would be really useful.

For example the lack of java 8 on GAE is a concern of mine - https://code.google.com/p/googleappengine/issues/detail?id=9537 . There isn't any communication as to what the status of this is (note: AWS beanstalk supports java 8).

I love the minimal configuration/maintenance of the GAE sandbox, but I need to know if a shift to managed VMs is the longer term direction for java support. It is not clear when starting a new java project if I should bet on GAE java sandbox being supported in the long term or just go with java 8 on a managed VM. 

Other than this, I have found GAE/GCP to be fantastic and I am really happy with the different tools and quality of the libraries provided.

[Dan Ciruli]

Hi, Karl -

I'm Dan Ciruli, and I recently took over as Product Manager on Endpoints. I really appreciate your feedback. My team is currently looking at improvements that we’d like to make in the next version of Endpoints and your comments jibe with what I’ve been hearing from a lot of our users. We are working on both the developer experience as well as providing some features that help you with managing your API (controlling access, etc).

I would be interested in a follow-up conversation with you -- send me an email (my last name @google.com) and I’d like to set something up.

Thanks -

Dan

[Karl MacMillan]

On Apr 21, 2015, at 12:17 PM, Dan Ciruli <cir...@google.com> wrote:

Hi, Karl -

I'm Dan Ciruli, and I recently took over as Product Manager on Endpoints. I really appreciate your feedback. My team is currently looking at improvements that we’d like to make in the next version of Endpoints and your comments jibe with what I’ve been hearing from a lot of our users. We are working on both the developer experience as well as providing some features that help you with managing your API (controlling access, etc).

You know - one thing that I would suggest is separating the serialization features from the overall endpoints functionality. My hand-rolled solution has to dig around in the guts of the ndb.Models (using ndb.Model._properties) and I’m afraid you guys will break that since it’s not a publicly documented API.

What I would find useful is an API that gives you the ability to:

1. Introspect ndb.Models (and the equivalent for other runtimes) to find just the datastore properties.

2. Convert the property datatypes into JSON / Protobufs / whatever

3. Helpers to selectively serialize entities and entity graphs

4. Callbacks / transforms during serialization to handle API and data model changes, friendly name changes, and things like automatically fetching keys (which I do).

With that I could easily turn an entity or entity graph into a serialized format that I care about. I could then more easily build out my REST APIs using whatever I wanted. You could, of course, build the rest of Cloud Enpoints on that (and probably already have all of this functionality in the internals), but for those of us that don’t find Endpoints to be a great fit this functionality would really make life easier.

Some other notes about Endpoints:

1. Discovery is just not that interesting to me for APIs that are completely internal (i.e., only accessed by code that I control) and it comes with additional complication and a pretty significant startup delay for the default clients (from what I remember). Yeah, yeah, I know all of the REST purist arguments about discovery, but it just isn’t worth it a lot of times for me and I’m guessing others as well. Think about being able to just decorate a single URL handler so that it handles serialization / de-serialization, auth, etc. without having to muck around with discovery and the client libraries (I would in a lot of cases just use a standard HTTP API to call the APIs).

2. It would have helped immensely to document how the URLs would be mapped. I had some trouble getting things running initially (can’t quite remember what the problem was) and I was trying to just use curl or something to figure out where the problem was. But I had to figure out what all of the actual URLs were. I remember having trouble even figuring out what the discovery url was, but that seems to be a little better documented now (https://cloud.google.com/appengine/docs/python/endpoints/access_from_python).

3. Authorization - it would be nice if this wasn’t endpoints specific but fit in with the rest of GAE (like the minimal authorizations that are available now in app.yaml). And having a fully functional users API would make it much better by having a standardized identity (presumably with roles) that you could use in authorization statements.

4. Like I mentioned before, having separate types for requests and responses is a basic requirement for me.

I would be interested in a follow-up conversation with you -- send me an email (my last name @google.com) and I’d like to set something up.

Great - I’ll drop you an email.

Karl

Thanks -

Dan
On Monday, April 20, 2015 at 7:38:45 PM UTC-7, Alistair Burrowes wrote:

Hi,

I would echo a lot of what Karl said.

I would like to see more examples of complex usage of GAE and or managed VMs. These are the kind of usages that more advanced developers might want. Here are a few examples of things that I have figured out or want:

- CI/CD set up, with dev/staging environments and one button deployments to production. It was a pretty long process of trial and error to achieve this.

- a single page app with separate the web front end and the backend (endpoints) modules. This was also tricky since endpoints live behind /_ah which can't be routed away from the default application. I think separating these out and their build processes is healthy separation of concerns.

- integrating gulp build processes into GAE dev servers/build processes. In my case I'm using gradle app engine plugin.

- "ismorphic" javascript app, with server side rendering via something like react (I assume this would be a managed VM running node js) that speaks to endpoints, from both client side and the node js layer.

Also I agree that more transparency on the roadmap/discussions on direction would be really useful.

For example the lack of java 8 on GAE is a concern of mine - https://code.google.com/p/googleappengine/issues/detail?id=9537. There isn't any communication as to what the status of this is (note: AWS beanstalk supports java 8).

I love the minimal configuration/maintenance of the GAE sandbox, but I need to know if a shift to managed VMs is the longer term direction for java support. It is not clear when starting a new java project if I should bet on GAE java sandbox being supported in the long term or just go with java 8 on a managed VM. 

Other than this, I have found GAE/GCP to be fantastic and I am really happy with the different tools and quality of the libraries provided.

On Thursday, April 16, 2015 at 3:37:31 AM UTC+10, Katie Ball (Google Cloud Support) wrote:

Hi,

My name is Katie, and I am on the Google Cloud Platform technical support team.

This message is to Google Cloud Platform community members, especially if you are newer to GCP. I would like to know what our team can do to help you have a better and more enjoyable experience during the first days on GCP.

Did you need technical support?  If so, I’d like to hear all about it.

I’d also like to know:

• What did you find most difficult about the first-time user experience?

• Where did you get stuck?

Please reply to the group with your answers or any ideas you have on how the technical support team can help new customers get familiar with GCP.

And as a thank you for the great ideas, we will be giving away support coupons worth $450 (equivalent to 3 months of silver support) to 5 lucky community members who post a response. Please make sure to reply before April 22nd.

Thanks for your insights, and cloud on!

Katie

-- 

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/5610bc4d-852b-4476-a10b-51574cb2e925%40googlegroups.com.

[Chris Ramsdale]

Hey Folks,

Chris Ramsdale, Lead Product Manager for App Engine here.  This is definitely some great feedback.  I’ve taken a stab at responding to some of the key points below [in bold].  Don’t hesitate to follow-up on this thread or reach out to me privately.  Thanks…

===============================================================

Default way to handle 3rd party dependencies in an app - there are options and they work ok, but this is so common it would be nice to have an officially supported method. Especially since the common ones break on managed VMs because you don’t support appengine_config.py there.

Going forward, for App Engine Managed VMs (soon to be v2),  we’ll support native ways of specifying third party dependencies, e.g requirements.txt for Python developers, pom.xml for Java developers, some love for Node.js developers, etc.  The overarching vision is to align App Engine with development practices that are common within the industry.

Webapp2 - it’s OK, but definitely not great. From the outside there doesn’t seem to be a strong reason to be using something that has not gained broader traction when supporting something like Flask shouldn’t be hard. That would gain a much broader ecosystem rather than the very narrow, App Engine focused ecosystem around webapp2.

I completely agree here, but do want to point out that App Engine supports Flask for Python developers.  More info can be found here: https://github.com/GoogleCloudPlatform/appengine-python-flask-skeleton

User service - when evaluating options things like the User services popped out to me. I thought, great, I’ll use a PaaS and things like user auth will be sanely handled. Except that it is so limited as to not be viable at all for a public product.

The Users API is primarily focused on integration with Google Accounts.  Its main use case is internal IT apps that are building on top of, or extending Google Apps.  We are actively discussing whether to update it to work with OAuth2 or simply help users understand how to more easily add OAuth2 support to their apps.

The biggest beginner problem I see right now is the architectural options around App Engine, Managed VMs, and GCE. On paper you guys have a nice blend of offerings that can allow developers to choose the right amount of control that they want / need. The reality, though, is that there are some hard choices to be made because of inconsistencies around what services are available on the different options and how to effectively wire together the components. A concrete example for me: I need to use numpy and some other non-pure python code in some background processing, so I needed to move off of App Engine for that work. I wasted quite a bit of time figuring out how / whether I could use the Datastore (via ndb) and task queues on the different options (including auth, network architecture, and scaling). None of it is rocket science, but I felt like I was inventing things when I knew that others had already come up with effective strategies. For me - the ideal situation would be if you just supported the same services through the same APIs everywhere, so I hope that is where you were headed.

For starters, and off-the-cuff,  I would recommend using App Engine Managed VMs for this use case.  It allows you to use the Python bits that you want and preserves the network path back to the other services you mentioned (Datastore and Task Queues).  Looking ahead though, the core services that are bundled into the App Engine SDK today (Datastore, Memcache, Task Queues, and Logging) will all be exposed as standalone services that one can call from any compute offering.  Cloud Datastore is the initial step in this direction, and the team is actively working on resolving a few latency issues and adding NDB and Objectify support.

GCP Roadmap - it would be nice to have some nice, clear roadmap on where things are headed. Right now, I restrict myself to only what is available and supported right now because I have no idea where you guys are headed.

I’ve seen this tried several times before and ultimately it too becomes out of date.  That’s not to say that we shouldn’t expose such information, I’m simply commenting on my hesitation to do so.  We’ll take this feedback and have a follow-up discussion (or set of discussions) internally.

Community - there is not a supportive / coherent community around GCP. Coming from a largely open source background this gives me a lot of culture shock. It would be great if there was at least a set of your engineers out engaging effectively in the various forums. Not just support - talking about best practices, explaining how things work, etc.

It’s worth noting that our engineering team has been actively engaged with Beta programs that are run within App Engine.  That said, I hear you on the broader point and will take this back to the Developer Relations within Google (in fact, Brad Abrams already has).

Stack Overflow - the whole notion of pushing all of the questions from this mailing list to stack overflow is really off putting to me. I understand what you are trying to do but a) stack overflow seems to be where GCP questions go to be completely ignored and b) the way it’s done is pretty heavy handed. Why not at least post a link to the answer back to the list? I’ve always found mailing lists as an effective way to passively be aware of common questions and gain knowledge. Stack overflow is not effective in that role for me.

I’ve heard other feedback on this point -- that the mailing list was too dense with conversation and hard to use as an effective tool in which to resolve technical questions.  To which users found stack overflow to be more useful.

This mailing list - honestly, I keep thinking that I should unsubscribe from this list because so many of the questions are very basic and they are generally just ignored. It’s kind of painful to watch - especially given that one volunteer is handling so much of this single handedly. I think it gives a terrible impression of GCP and makes me feel like very few experienced developers are using GCP.

I feel compelled to point out that how this discussion going is a good example of some of the things that I - and it seems others - are frustrated about. You’ve asked for and received concrete feedback. Yet we’ve received no answers or discussion back from Google engineers.

Based on these two points, and the one that precedes, it sounds like the requirement is: please provide a forum that is free, focused on technical questions, and has Google engineers actively engaged answering user’s questions.  Does that sound correct?  I just want to make sure that I’m interpreting the feedback correctly.

I would like to have a Customer Support for all GCP products.

I’m not sure that I follow here -- Google Cloud Support covers all Google Cloud Platform services.  Does this actually dovetail with the request above, to provide free support across all GCP services?

A lot of Karl's random thoughts and complaints ring true for me

Just to clarify, Karl, your feedback is not random at all.  It was well thought out, to the point, and clear.  In fact, all the feedback is and we appreciate it.

CI/CD set up, with dev/staging environments and one button deployments to production. It was a pretty long process of trial and error to achieve this.

I would like to hear more about how you are achieving this and what your pain points are.  Mind following-up off thread (cram...@google.com).  

A single page app with separate the web front end and the backend (endpoints) modules. This was also tricky since endpoints live behind /_ah which can't be routed away from the default application. I think separating these out and their build processes is healthy separation of concerns.

Dan C (replied earlier) is most likely the Google contact that you want to reach out to.

Integrating gulp build processes into GAE dev servers/build processes. In my case I'm using gradle app engine plugin.

I’m not completely up-to-speed on gulp and would love to hear more.

"ismorphic" javascript app, with server side rendering via something like react (I assume this would be a managed VM running node js) that speaks to endpoints, from both client side and the node js layer.

That sounds correct and we’ll be enhancing support for Node.js over the coming months.

For example the lack of java 8 on GAE is a concern of mine - https://code.google.com/p/googleappengine/issues/detail?id=9537 . There isn't any communication as to what the status of this is (note: AWS beanstalk supports java 8).

I love the minimal configuration/maintenance of the GAE sandbox, but I need to know if a shift to managed VMs is the longer term direction for java support. It is not clear when starting a new java project if I should bet on GAE java sandbox being supported in the long term or just go with java 8 on a managed VM.

For Java 8 support, you should be looking into Managed VMs, this is the hosting environment where we’ll rollout new runtimes.  And...we’re actively porting over many of the features that give users the minimal configuration/maintenance.  The existing App Engine sandbox isn’t going away.

-- Chris

Product Manager, Google Cloud Platform

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/1AA8B6DC-16ED-4737-A559-A626B18E3E48%40rakkoon.com.

[Vinny P]

Hi Katie,

I think Karl's post hit a home run and I'm happy to see the positive response to his post. Let me just tack on a few items:

Managed VMs: The development toolchain for Managed VMs can be a bit finicky. To be quite honest I have no idea how I got Managed VMs working on my laptop. Streamlining this would be a huge benefit to me, and probably a lot of first-timers. If you can convince one of the online IDE services to simplify creating Managed VM GAE apps, that would be super. 

For smaller or toy apps within Managed VMs: I shouldn't need to care about the Docker container running the application; I should be able to create an application using just Eclipse + Google Plugin, then be able to deploy straight to a Managed VM runtime without the intermediate step of having gcloud create and store a dockerfile. 

Firebase: I'm glad that Google bought up Firebase - they have a lot of great ideas and a well-designed API. I'd like to see Firebase with the ability to use the Datastore and Cloud SQL directly, not just the regular Firebase DB. This would help with syncing information with server side systems.

Stack Overflow: IMO, the moderators at SO go overboard when locking questions. I often find interesting SO pages when I'm searching around, only to visit the page and find that the question is locked or that someone has deleted the page outright. At least with the mailing list I have an archive of all past questions and answers in my email account. I don't know how you plan on using SO going forward, but I would appreciate minimizing any occurrences of locked/deleted questions.

Thanks

P.S. When you're giving out the support vouchers, please skip me. There are a number of far more deserving people in this thread.

 

-----------------

-Vinny P

Technology & Media Consultant

Chicago, IL

 

 

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/4f59c819-731f-422c-b33d-a68ea4d525fd%40googlegroups.com.

[Chris Ramsdale]

On Tue, Apr 21, 2015 at 11:22 PM, Vinny P <vinn...@gmail.com> wrote:

Hi Katie,

I think Karl's post hit a home run and I'm happy to see the positive response to his post. Let me just tack on a few items:

Managed VMs: The development toolchain for Managed VMs can be a bit finicky. To be quite honest I have no idea how I got Managed VMs working on my laptop. Streamlining this would be a huge benefit to me, and probably a lot of first-timers. If you can convince one of the online IDE services to simplify creating Managed VM GAE apps, that would be super. 

For smaller or toy apps within Managed VMs: I shouldn't need to care about the Docker container running the application; I should be able to create an application using just Eclipse + Google Plugin, then be able to deploy straight to a Managed VM runtime without the intermediate step of having gcloud create and store a dockerfile. 

We're removing the Docker toolchain from the mix and will be surfacing a hosted build service that handles this on your behalf.  Their toolchain is simply unstable.  

 

Firebase: I'm glad that Google bought up Firebase - they have a lot of great ideas and a well-designed API. I'd like to see Firebase with the ability to use the Datastore and Cloud SQL directly, not just the regular Firebase DB. This would help with syncing information with server side systems.

They have a great Dev UX and we're working to further integrate them with Google Cloud Platform.

 

Stack Overflow: IMO, the moderators at SO go overboard when locking questions. I often find interesting SO pages when I'm searching around, only to visit the page and find that the question is locked or that someone has deleted the page outright. At least with the mailing list I have an archive of all past questions and answers in my email account. I don't know how you plan on using SO going forward, but I would appreciate minimizing any occurrences of locked/deleted questions.

Excellent feedback, and we'll discuss this internally.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CALSvALCyL0SC6mdVkZjmZEuoOWTc0EaAx0aJJtbowGguqyNRXw%40mail.gmail.com.

[troberti]

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 about features, but big ticket items like Python 3, Java 8, SSL etc should be communicated. It doesn't have to be an explicit list somewhere, just a PM chiming in regularly should be good enough.

Now back to App Engine:

Like I said in my post on the other thread, the trend towards managed VMs worries me a bit. For us, zero-configuration/no-maintenance is not just another feature of App Engine, it is one of the most important ones! We want to write our programs and then keep them running for years (5+) without having to do *anything*. Some of our apps are running like this for years now, and I want to ensure that this stays possible in the future.

Glad to see the Docker fad go, but please don't replace it with something where I need to choose my "technology stack" in some way. Just provide a set of stable APIs instead so we can consider everything else an implementation detail for App Engine to worry about :)

[Chris Ramsdale]

On Wed, Apr 22, 2015 at 2:21 AM, troberti <tij...@firigames.com> 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 about features, but big ticket items like Python 3, Java 8, SSL etc should be communicated. It doesn't have to be an explicit list somewhere, just a PM chiming in regularly should be good enough.

Now back to App Engine:

Like I said in my post on the other thread, the trend towards managed VMs worries me a bit. For us, zero-configuration/no-maintenance is not just another feature of App Engine, it is one of the most important ones! We want to write our programs and then keep them running for years (5+) without having to do *anything*. Some of our apps are running like this for years now, and I want to ensure that this stays possible in the future.

Managed VMs represent a new hosting environment that brings with it a set of feature benefits -- open source compatible runtimes, more CPU / memory configurations, access to native resources such as a file system and network stack.  we'll be investing in this environment more and more over the coming months (we're ripping docker out of the getting started flow, getting deployment times to <20 secs, getting instance activation time to <1 sec, adding scale to/from zero instances, etc.)  that said, don't worry, we'll absolutely keep your existing v1 apps running just as they have for years.

 

Glad to see the Docker fad go, but please don't replace it with something where I need to choose my "technology stack" in some way. Just provide a set of stable APIs instead so we can consider everything else an implementation detail for App Engine to worry about :)

exactly. if anything, we're going to make those same APIs available from other compute environments (e.g. Compute Engine and Container Engine).

 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/2281cf70-b81b-46ce-ab78-b6cbe0c1f813%40googlegroups.com.

[Aleem Mawani]

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.

[Chris Ramsdale]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/fcb86987-5dc0-4c98-b29d-56268f041ae6%40googlegroups.com.

[Aleem Mawani]

@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).

[rajesh...@veersoftsolutions.com]

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.

[husayt]

Hi,

We have been using Appengine since it was alpha ( over 8years i think). Lately, we have built a great CRM/LBM solution on top of it serving hundreds of businesses. 

Like Rajesh we are heavily using namespaces and unfortunately it seems latest Google Cloud offerrings are not supporting them. Even latest Text Search browser in Google Cloud Desktop fails to work with namespaces.

I don't even mention BigQuery, managed Backups and etc.

I fully agree with what Rajesh wrote.

Namespace support is vital in building business solutions on Google Cloud. 

PS. Also waiting for managed VMs support on frontends.

Thanks,

Huseyn

www.landmax.pro

Next Generation Property Management solution

[Chris Ramsdale]

excellent feedback.  some comments inline below.

On Thu, Apr 23, 2015 at 3:09 PM, Aleem Mawani <al...@streak.com> 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)

a fix for this is in the works.  i'll come back with a date.

 

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

have you looked into the Firebase API set?  would that work for you or is there some deficiency? 

 

- logging api: we use this to export our logs to BQ

slightly related to my point above, our goal is to enable this via Google Cloud Logging.  have you taken a look at their integration with 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

good feedback, and i've passed this on to the Cloud monitoring folks.

 

- seemed that instances would go into unhealthy state and not recover or get killed (this could be outdated)

there have been several changes submitted to address this issue.  please do let me know if you are still seeing this issue.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/6e9c0d87-21fa-4349-85bb-9598e5e32686%40googlegroups.com.

[Aleem Mawani]

On Tue, Apr 28, 2015 at 10:03 PM 'Chris Ramsdale' via Google App Engine <google-a...@googlegroups.com> wrote:

excellent feedback.  some comments inline below.

On Thu, Apr 23, 2015 at 3:09 PM, Aleem Mawani <al...@streak.com> 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)

a fix for this is in the works.  i'll come back with a date.

thanks! 

 

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

have you looked into the Firebase API set?  would that work for you or is there some deficiency? 

Looked into it briefly, but two things concern me:

1) Firebase is designed to synchronize state across several clients and does a great job of this. But you kind of have to shoehorn in message passing. So if your app is already built using the channel api which is more message based, moving to firebase is a little awkward. For a new app this might be less of a problem. I've heard rumblings about firebase + datastore but I'm suspicious that could work well (if every client needs to provide a list of entities it would like to subscribe to, this is non trivial) for us at least. 

2) Its far more expensive than channel API since its based on number of "connections". We'd blow through their highest tiered plan and likely increase our monthly bills by double digit percentages.

If channel API is going away, the natural replacement seems to be GCM if it supported web clients.

 

- logging api: we use this to export our logs to BQ

slightly related to my point above, our goal is to enable this via Google Cloud Logging.  have you taken a look at their integration with BQ?

Its good, but we need to process logs before sending to bigquery. We'd like to implement a Cloud Logginng -> PubSub -> Dataflow -> Bigquery  workflow which would remove the need for us to even use GAE insances to get logs to BQ but the Cloud Logging -> PubSub is the missing piece that isn't available yet. Neither is the Logging API on Managed VMs so we're left with using vanilla GAE instances to do background log processing.

 

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

good feedback, and i've passed this on to the Cloud monitoring folks.

is the plan for cloud monitoring to replace GAE dashboard. Or for the dashboard to show instance counts of managed vms? I.e. where should we get this data? 

 

- seemed that instances would go into unhealthy state and not recover or get killed (this could be outdated)

there have been several changes submitted to address this issue.  please do let me know if you are still seeing this issue.

will do. 

 

Thanks for all the responses! 

You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/GK_5qVwBIuQ/unsubscribe.
To unsubscribe from this group and all its topics, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CAD1DWLjvRJz%2Buy80kDrSoLT87rwBzkk2bWfJ6vJpOn0ByyhdJA%40mail.gmail.com.

[Jason Collins]

we need to process logs before sending to bigquery

 

Aleem, can you tell me more about what processing you do on your logs before sending them to BigQuery?

[Aleem Mawani]

During the course of an appengine request, we record a bunch of stats in the logs, such as number/type of datastore operations, profiling info, URLfetch stats, etc. Before the logs can go into BigQuery, we want to extract that info from the logs and place them in particular columns in our BigQuery tables.

Currently our GAE instances do this transformation but ideally this transformation would be done in dataflow which would be way more efficient, less code to write, cheaper, more stable and managed!

On Wed, Apr 29, 2015 at 12:08 PM Jason Collins <jason.a...@gmail.com> wrote:

we need to process logs before sending to bigquery

 

Aleem, can you tell me more about what processing you do on your logs before sending them to BigQuery?

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/GK_5qVwBIuQ/unsubscribe.
To unsubscribe from this group and all its topics, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/91564e30-0a50-460d-8e7f-680871272c34%40googlegroups.com.

[Kaan Soral]

There are many great suggestions that are already made on this thread, but I would like to concentrate on a single and extremely important aspect: Support

There are many edge issues of App Engine, or any product in general, yet with App Engine, these issues are almost never acknowledged and solved properly, we generally have to work around them for years, examples:

https://groups.google.com/forum/#!topic/google-appengine/GIRRoBxQZMo - Issue ignored + Thread closed - No freedom of speech either

https://groups.google.com/forum/#!topic/google-appengine/2O87iU8ySCM - A similar but recent issue, All I see in my logs are these errors, yet no one helps me, no one can help me, there is no channel that I can request for support

I'm not going to pay for support for a product that I'm already paying considerable amounts, the support packages are also too complicated, unclear

What we need is a new/structured purpose-built community both for issue tracking, support and help, which is both community based, google-backed and open (or simply some dedication to issues here and bugs in general, at min)

[aswath satrasala]

Appengine new Instance spinning for user facing requests.  I think there is no recommended process or solution for this. This issue is the most important for production apps.    This is discussed many times.

-Aswath

www.AccountingGuru.net

www.VeersoftSolutions.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-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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/849a05ac-b49d-4648-9d39-9d686d3092ae%40googlegroups.com.

[Robert Dyas]

• What did you find most difficult about the first-time user experience? Where did you get stuck?

No so much the first time experience, but the follow on experience.... if you ever run into a problem (often a security glitch, like when an App Engine service account goes missing in the permissions but was not deleted by me) trying to diagnose it without help is almost impossible. Had this problem with App Engine, Cloud Storage (bucket permissions). And now in trying to migrate to Managed VMs. Also with bugs and non-helpful error messages in the Cloud SQL Admin API. Or in the very beginning, even knowing what servies to use for what.

Other issues I have with Google Cloud

1. development pace is way too slow! Problems go unresolved in many cases for more than a year. For example, Managed VMs still can't access Cloud SQL in the same way that App Engine sandboxed does. For our app, this will cause major migration headaches as tons of additional @% MySQL user accounts will have to be added and maintained to mirror the existing @localhost accounts because the access paradigm is different. The Cloud SQL Admin API has been in some form of beta forever. If you are going to put out a service, don't let the beta period extend more than 6 months. People need to lock things down and deploy.
2. Another problem is google's way of naming things and having too many similar but overlapping services. A new user to the platform will find it very difficult to choose how to store his data. Big Query? Cloud SQL? Datastore? BigTable? You create lots of different services with different names rather than a single robust service that evolves over time. For example, why not call Managed VMs just App Engine 2.0? Why not have a popup on a service option that compares it with all other possible options and lists the pluses and minuses of each and the ideal and incorrect use cases? A person starting needs to make too many choices.... best language? Data storage (Big Query? Cloud SQL? Datastore? BigTable?). Front end served by CE? App Engine? Containers? Managed VM? It is just way to much to absorbe and make intelligent decisions on in any reasonable sort of time frame.

[Robert Dyas]

Also, just wanted to reiterate points 3 and 4 from Karl's earlier post:

3. Stack Overflow - the whole notion of pushing all of the questions from this mailing list to stack overflow is really off putting to me. I understand what you are trying to do but a) stack overflow seems to be where GCP questions go to be completely ignored and b) the way it’s done is pretty heavy handed. Why not at least post a link to the answer back to the list? I’ve always found mailing lists as an effective way to passively be aware of common questions and gain knowledge. Stack overflow is not effective in that role for me.
4. This mailing list - honestly, I keep thinking that I should unsubscribe from this list because so many of the questions are very basic and they are generally just ignored. It’s kind of painful to watch - especially given that one volunteer is handling so much of this single handedly. I think it gives a terrible impression of GCP and makes me feel like very few experienced developers are using GCP.

[Robert Dyas]

Can I +100 this?

On Monday, April 20, 2015 at 11:44:58 AM UTC-4, Karl MacMillan wrote:

Katie,

I feel compelled to point out that how this discussion going is a good example of some of the things that I - and it seems others - are frustrated about. You’ve asked for and received concrete feedback. Yet we’ve received no answers or discussion back from Google engineers. At least a simple acknowledgement of the _specific_ issues we’ve raised from someone with some knowledge would be helpful. Otherwise how am I to know that you bringing the “feedback to the appropriate team members” is anything more than them receiving an email that they’ll simply delete?

Look at this way - we’ve invested and in many cases bet our businesses on GCP. And especially with App Engine, this is very much an investment in an ecosystem that you’ve created that’s largely separate from the rest of the industry. It’s hard to have confidence in that bet given the almost total lack of public engagement from Google to help make this a vibrant ecosystem.

Karl

On Apr 16, 2015, at 5:50 PM, Katie Ball (Google Cloud Support) <kmrich...@google.com> wrote:

Hi Karl,

You've taken some extra time and extra care to put this feedback together -- thank you! It's incredibly helpful; this is exactly what we need in order to better serve our users and the cloud computing community. 

I've already taken your feedback to the appropriate team members to start improving things as suggested in your post.

Is there anything that you are currently struggling with? If there is, we'd like to offer our help as a thank you.

To our GCP community members: do you have any additional feedback you'd like to send our way? Any +1's to Karl's points? We'd love to hear from you!

Thanks again,

Katie

-- 
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+unsub...@googlegroups.com.

[Jeff Schnitzer]

Just wanted to comment on one thing:

On Thu, Nov 26, 2015 at 7:56 AM, Robert Dyas <rober...@parasql.com> wrote:

1. Another problem is google's way of naming things and having too many similar but overlapping services. A new user to the platform will find it very difficult to choose how to store his data. Big Query? Cloud SQL? Datastore? BigTable? You create lots of different services with different names rather than a single robust service that evolves over time. For example, why not call Managed VMs just App Engine 2.0? Why not have a popup on a service option that compares it with all other possible options and lists the pluses and minuses of each and the ideal and incorrect use cases? A person starting needs to make too many choices.... best language? Data storage (Big Query? Cloud SQL? Datastore? BigTable?). Front end served by CE? App Engine? Containers? Managed VM? It is just way to much to absorbe and make intelligent decisions on in any reasonable sort of time frame.

When you get to the point where you actually need these services, you'll find that there is very little actual overlap between BigQuery, Cloud SQL, Datastore, and BigTable. Picking an application architecture is not at all a Google issue - even on Heroku you have the options of Postgres, MongoDB, Redis, Cassandra, MySQL, all of which have their use cases. You get no guidance there either.

It would be nice if there was some great way to learn when columnar stores are more appropriate than row stores, or when relational databases are more appropriate than nosql databases. It's a broad educational problem that has not been solved. It's even reasonable to argue that the internet hasn't figured it out - you will need some trial and error specific to your use cases. Hell, I'm on my third analytics database.

If your application is at all complicated, you will likely need more than one data store. Choice is great.

Jeff 

[Juan Juarez]

Hello Katie,

I am new to the Google App engine. I have been trying to learn to use the GAE for about a week now and i've had some trouble getting off the ground. 

I am not a seasoned developer, but i was able to follow along with the google apps script docs much more easily. 

This might seem like a trivial problem for most here, but i have yet to understand how to upload an app to the GAE. 

There's a line in the hello world tutorial that says to invoke this command: "appcfg.py -A YOUR_PROJECT_ID update helloworld/". How do I invoke this command? Should I invoke it in the GAE Launcher? Should I invoke it in windows' command prompt? Somewhere else?

From a novice's standpoint this seems to be a big barrier of entry...

From all of the research that I've done on databases the Datastore sounds great for what i'm trying to accomplish, but I need to find better documentation on how to use it.

[Kaan Soral]

Juan, in the beginning, the easiest way is to setup GAE Launcher (the name might have changed, it's the Java/Python/etc. SDK) - create a project from there, and upload from the program

[Jitendra Kumar]

Hi Katie,
How can I deploy a python script with two url staging.abc.com and admin.abc.com under one project

[Pierre-Yves (Google Cloud Support)]

Hello Jitendra,

This thread was to discuss how new users could benefit from an improved experience using GCP. If you have specific inquiries on using App Engine, I suggest you open a new thread [1]. To address your question, you may create multiple App Engine services in a project, targeting different URLs. Here is more information on this.

[1] https://groups.google.com/forum/#!newtopic/google-appengine

[2] https://cloud.google.com/appengine/docs/standard/nodejs/configuration-files