Ongoing App Engine Commitment?

238 views
Skip to first unread message

Tim Consolazio

unread,
Mar 31, 2017, 8:39:29 AM3/31/17
to Google App Engine
I've been noticing some things:

- App Engine support shunted over to Stack Overflow (so...a non-Google community resource).
- Mail API pretty much deprecated (no more quota expansions, 100 email limit). 
- Deprecation of Channel API (sure we have Firebase, but still...what's the commitment to that?)
- No Java 8 (and 7 was a long time in coming). 
- Gradual deprecation of local SDK in favor of remote/virtual dev (which to me is unacceptable, I depend on that local SDK). 

I frequently recommend App Engine (and I've built quite a few apps on it). I've been a rogue evangelist of the platform for years (since it was released in fact), and have been contracted by Google three times to build applications using it. So I'm not a hater in any way. 

But I can't look at these events (particularly the Stack Overflow thing) and ignore the impression that App Engine is beginning to feel more like a side project rather than a commercial offering with full resource commitment by the vendor. 

Curious about a formal statement of commitment here, and a complete roadmap of what we can reasonably expect over say, the next two years. 

Jeff Schnitzer

unread,
Mar 31, 2017, 11:19:17 AM3/31/17
to Google App Engine
Not a Googler, but I’ve been around a while:

 * They moved support to stackoverflow in early 2012. It seems to be a common practice. I have mixed feelings about it myself, but it’s a thing, and definitely not a new thing.

 * The Mail API and Channel API have both been zombie products since before 2012. I agree that G should make it more explicit when features like this have dark futures, but it wasn’t hard to figure out that you should avoid these APIs even in 2012. The Channel API in particular.

 * The Java8 runtime on GAE standard is in alpha test. There have been several public announcements here. I think there’s a link somewhere in this forum for applying to the program…ah, here: https://groups.google.com/forum/#!searchin/google-appengine/java$208%7Csort:date/google-appengine/Zn7X3D7o584/DrTp64eeAwAJ

Jeff


--
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/ffc4dd64-c827-4c5f-8765-b84182e65e90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tim Consolazio

unread,
Mar 31, 2017, 11:45:49 AM3/31/17
to Google App Engine
These notices are from 2012?

P K

unread,
Mar 31, 2017, 4:50:17 PM3/31/17
to Google App Engine
This question/concern keeps popping up every few months for years now. Being a very early GAE user, I have my opinions and history based analysis that I have posted before. Recent signals, having attended Next as well, make me more optimistic than usual.

Today I want to add a new perspective: The question really is how much risk do you want to take? Recently the US stock market listed Snap. When you get listed in the US you are required to provide the investors an S-1 that contains all the risks of investing in this offering. Open the Snap S-1 here and search for Google and read these paragraphs. Bottom line, Snap says "we are alive as long as Google Cloud is alive". Then look at this Quora thread:  https://www.quora.com/How-does-Snapchat-use-Google-App-Engine Bottom line between those two, for now Snap, a US public company, is alive as long as GAE Standard is alive.

So, I conclude that Google will be committed to GAE Std. for a while. These are the kind of signals to look for; "formal statements" are good for few days, and we have seen many of those over the years, but can come and go as fast as an e-mail can be written. Does anybody else know of other such "too big to fail" successes built on GAE Std? The more of those the more confident I would be... 

Another signal of course is where Google puts its investment dollars. In the early 2010s timeframe Google puts all its (few at the time) eggs in GAE. The marketplace did not reward this approach so Google increased its Cloud investment and shifted all of it to build a better AWS because this is what the volume enterprise and startup market seemed to want. However GAE survived and remains a competitive advantage and differentiator for GCP, so I hope Google delivers and puts back more investment to GAE now.

PK

PS If the two GAEs merge downstream I am fine as long as I do not have to revisit (ie modify/test etc) code in production that has been working for years. The more of that I would have to do the more negative I would become of such a development.

pdknsk

unread,
Apr 2, 2017, 2:09:01 PM4/2/17
to Google App Engine
You mentioned Firebase. I don't use it, but isn't it fair to say that Firebase is what App Engine originally meant to be? Might be a piece of the puzzle.

dinoboff

unread,
Apr 6, 2017, 6:48:12 AM4/6/17
to Google App Engine
I don't think Firebase is like GAE. GAE managed a backend server in a scalable way; you're still programming a backend application. Firebase on the other end is suppose to get ride of the backend application.

I think Google Cloud Endpoint was trying to solve the same use case than firebase.

The various Server-less platforms (AWS lambda, cloud function) are similar to the original GAE model (before they introduced instances) with a shift away from the REST api. On GAE you map a http handler to an event (http request, pub/sub event, email received, etc...); on Server-less apps you map a function to an event directly. It's a more boilerplate if you're just writing REST API, but I guessing it's more efficient and more elegant for other type of events than HTTP request.

Tim Consolazio

unread,
Apr 6, 2017, 6:58:36 AM4/6/17
to Google App Engine
Hmm...I'm not sure that you can ever really avoid writing a back end unless you are doing only very standard, boilerplate things. How would you do a content matched (based on login) retrieval/map/transform of a collection of objects without writing back end (or at least, "virtual" backend) code?

Sivaprakash Saripalli

unread,
Apr 6, 2017, 8:35:04 AM4/6/17
to Google App Engine
One more point pointing in this direction is continous integration or lack of support for it. They have removed support for Push-to-deploy (been 2 years now I think). I couldn't even find documentation related to wiring up App Engine with Jenkins while there is ample documentation for Google Container Engine. 

If Container Engine/Kubernetes is the future, they should come out and say so. 

Jeff Schnitzer

unread,
Apr 6, 2017, 5:58:54 PM4/6/17
to Google App Engine
For multiple years now I have been using CircleCI to deploy multiple projects to GAE. My deploys are: “git checkout production; git merge master; git push”. It’s super easy and pretty well documented at Circle’s website. I’m happy to share my configs too.

“push to deploy” doesn’t seem like a CI concern not a Google concern, no? At the very least I don’t want anything going to prod that hasn’t been tested.

Jeff

--
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 https://groups.google.com/group/google-appengine.

Jesse Scherer (Google Cloud Support)

unread,
Apr 6, 2017, 7:21:49 PM4/6/17
to Google App Engine
Hi Tim, sorry for the late reply but I've been working on a novella for you :-)

I'm a technical program manager from the GCP support team. I work on community-facing support (which is just part of our support offering) for all of GCP, including App Engine.


On Friday, March 31, 2017 at 8:39:29 AM UTC-4, Tim Consolazio wrote:
I've been noticing some things:
- App Engine support shunted over to Stack Overflow (so...a non-Google community resource).

It turns out that if you search for a particular error message from one of our products, you're very likely to see a Stack Overflow question about that very message among the first results. So yes, we lose some control, but the Stack Overflow community is pretty good at maintaining a high quality Q&A site. Given that our goal is for every interaction to help as many people as possible, it makes sense to go where the users are.

I should point out that we actively monitor this Google Group and bug reports on issuetracker.google.com, not just Stack Overflow. The difference is in focus: Stack Overflow is a place for "I know what I want to do, but not quite how" type Q&A.

- Mail API pretty much deprecated (no more quota expansions, 100 email limit). 

You're right, that's not great. A while ago, Kim Lewandowski mentioned that we're investigating a solution to the issues that plague the current mail API. There's currently a thread going about this; please take Kim up on her offer to share use cases.
 
- Deprecation of Channel API (sure we have Firebase, but still...what's the commitment to that?)

Since I work for support and not product management I can only speak informally, but Firebase is a product with a lot of integrations across Google products. This isn't one I'd worry about. Also notice the byline and linked article on Firebase's homepage pointing out the integration of Firebase and Cloud Functions.
 
- No Java 8 (and 7 was a long time in coming).

I think Jeff already covered this one :-)
 
- Gradual deprecation of local SDK in favor of remote/virtual dev (which to me is unacceptable, I depend on that local SDK). 

My colleague Justin Beckwith talked about this a few months ago: we understand that local development is an important feature and are looking at how to enable it in gcloud. But since it's not ready yet, we do continue to maintain the standalone SDK.
 

I frequently recommend App Engine (and I've built quite a few apps on it). I've been a rogue evangelist of the platform for years (since it was released in fact), and have been contracted by Google three times to build applications using it. So I'm not a hater in any way. 

But I can't look at these events (particularly the Stack Overflow thing) and ignore the impression that App Engine is beginning to feel more like a side project rather than a commercial offering with full resource commitment by the vendor. 

I've spoken to your point about Stack Overflow already, but I hope you're not reading too much into things like Datastore becoming a first-class product instead of an App Engine-only feature. That sort of transition acknowledges the reality there are several models for cloud compute, and that a lot of features which launched as part of App Engine (when App Engine was our sole compute offering) make just as much sense when used with containers, or VMs, or Cloud Functions.  
 

Curious about a formal statement of commitment here, and a complete roadmap of what we can reasonably expect over say, the next two years. 


We've mentioned this before, but there are a lot of reasons for us to be tight-lipped about our exact roadmap. But I hope that seeing real progress like the Flexible Environment exiting Beta or upcoming Java 8 on Standard demonstrate our commitment to App Engine.
 
Regards,
Jesse
Reply all
Reply to author
Forward
0 new messages