If you're running production services, you should probably sign up for a paid support package, which have guaranteed response times down to 15 minutes: https://cloud.google.com/support/
Disclaimer: I work in Google Cloud Support.
More often than not, what most people want is simply an acknowledgement. They're not seeking a bug bounty. And definitely not the brush-off you just gave the GP: when someone's house is on fire, you don't demand prepayment for the water.
You absolutely do not have to pay us to report a bug, period. The same day this bug was filed, one of my colleagues ([email protected]) jumped on the report and started asking questions to determine what was happening.
It seems to me that the GP's complaint is that this process was too slow: too much back-and-forth, too little dedicated attention to get the problem figured out immediately. That's a frustration which is easy to understand.
The point about support contracts was most likely intended to emphasize that if your livelihood depends on a service, you should have an agreement in place that guarantees you can wake up an engineer on the weekend.
the "free tier" of municipal services is actually just a form of socialism!! eek!
I feel little bit bad for them sometimes. They don't seem to have the time to look into problems. It must be quite a boring job for those assigned on the public issues.
Maybe their higher-ups aren't aware of that.
Form my perspective: sometimes when I report a bug it's more so that other users don't waste their time troubleshooting it than to have it fixed immediately.
Maybe sometimes I'm not 100% clear but it is a bit discouraging to have to send follow-up messages on clear-cut issues like these: https://code.google.com/p/googleappengine/issues/detail?id=1... https://code.google.com/p/googleappengine/issues/detail?id=1... (the comment #10 of the former issue was written a bit too quickly don't you think?)
Then there are issues that "work as intended" but that seem like bad product design: https://code.google.com/p/googleappengine/issues/detail?id=1...
Do they really reach a product manager?
Finally there are issues like these ones that are not clear cut but that I can't investigate myself because it requires time and resources (they eventually cost me a few bucks running instances for testing purposes). https://code.google.com/p/googleappengine/issues/detail?id=1...
You guys have a good product. I think that the promise of not having to manage infrastructure hit a cord with many people. However you do have many bugs to fix to make the platform more stable and (non intentionally) discouraging people from reporting issues will make things improve at a slower rate.
Good luck!
No. (Or they don't care.)
$10-20/month VPS providers often respond to, and actually take action, on tickets within 5-15 minutes at no extra cost. Of course there is no guarantee, and a ticket can certainly wind up unresolved for 24+ hours. In my experience, if the ticket you file clearly explains your issue and represents something they can realistically help you with, the level of service provided for such a low server cost can be exceptional.
I'm not sure what you mean by this. Every AWS service I can think of has "free tier" for lower use and then charges for higher use, like AppEngine. For example, AWS's email service (SES) is free up to 60,000 emails per month.
To me, the whole point of Appengine is to abstract out system administration. GCE (like AWS) abstracts out the systems, but not the administration - you suddenly become responsible for all the scaling, fault-tolerance, and all the subsystems that Appengine manages for you.
I've tried Containers with Google App Engine Flexible Environment (in beta now) and liked that it's much more customizable than standard GAE. Basically, you just need any Docker container listening on port 8080. But deploy time took 10-20 minutes, so I'm still preferring Standard. Hopefully they'll fix that before GA release.
My request is for a tool which would provide this functionality in the form of code which exposes an App Engine like interface to the developer, except it's running in Container Engine. Given Container Engine has the required code to restart processes that fail and oodles of other automated goodies, this give the fault tolerance desired.
> We wouldn't use it.
Given the "tool" doesn't appear to exist IRL, that statement is illogical. You can't not use something that doesn't exist. And, if there really did exist a migration tool that provided additional operational abstraction inside the framework you were migrating to, you'd run the risk of being in conflict if you didn't consider using it.
I've noticed that they've added more support people since the early days but it's still a pain as they seem to have an incentive to answer the tickets as fast as possible without doing any real investigation.
The linked issue is a good example of this behavior.