[martindelemotte]

I wonder if people at Google know how awful it is to report an Appengine bug. You have to battle for days to get your bug acknowledged.

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.

[jpatokal]

Please remember that Google App Engine is entirely free up to (roughly) 5 million page views/month: https://cloud.google.com/appengine/kb/#quota

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.

[inopinatus]

I think this is a terrible attitude. I will never implement it in my own support model. People shouldn't have to pay me in order to report a bug in my system. Arguably I should pay them, because one report is the tip of an iceberg of silent affected customers.

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.

[jjjjoe]

Cloud 1:many (community) Support here.

You absolutely do not have to pay us to report a bug, period. The same day this bug was filed, one of my colleagues ([e-mail]) 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.

[Bhullnatik]

You don't demand prepayment for the water, you already got it (through taxes).

[pyvpx]

no, when your house is on fire the property-tax funded fire department comes and attempts to put it out.

the "free tier" of municipal services is actually just a form of socialism!! eek!

[lazylizard]

adam smith. tragedy of the commons. so we pool our resources together and hire a contractor to handle the commons for us.

[martindelemotte]

I can't comment on the paid support. I've just noticed that the non-paid support engineers seems to be under pressure.

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.

[jjjjoe]

Hi, I manage the team. Do you have some recent examples I can show to the higher-ups? Our incentives are built around quality of work, not speed, so what you're describing is definitely not working as intended.

[martindelemotte]

Hi Joe,

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!

[stcredzero]

I wonder if people at Google know how awful it is to report...

No. (Or they don't care.)

[spicyj]

They have paid support if you want it.

[nikanj]

Paying for the service should be enough to get support.

[nxzero]

Paying for the service is paying for the service; bundling it with support costs would just make it cost more for people that don't need support.

[developer2]

Google specifically seems to target their services much more at the large enterprise, rather than small companies and individuals. Enterprise will always pay for support, so if they are your target market, it's a given you can get them to pay. It's less of a necessity for providing lower costs, and more of a business decision to not expend resources to acquire customers that aren't bringing in tens or hundreds of thousands of dollars every month.

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

[an_account]

For a comparision, AWS also makes you pay for prompt support, and all of their services cost money (unlike AppEngine which has a lot of free services).

[bobbyi_settv]

> all of their services cost money

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.

[kordless]

They should be working on a migration tool for users of AppEngine to migrate to Google Container Engine.

[foxylad]

We wouldn't use it.

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.

[jdoliner]

Confusingly enough Google Container Engine != GCE. GCE is Google Comput Engine, which doesn't abstract out much of the administration. Google Container Engine (or GKE) on the other hand does abstract out most of the administration via Kubernetes. We were recently attempting to use appengine for something but gave up due to how bad the support for Go is and migrated to GKE. It definitely isn't quite as abstracted as Appengine but it's darn close.

[deepsun]

I believe you're talking about GCE (Compute Engine), while @kordless is talking about Container Engine.

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.

[kordless]

Microservice based architectures, or SOAs, are ideal for segmenting operational and development tasks. Using Container Engine (which != GCE) will give users a BETTER way to abstract out system administration. You imply contrary.

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.