"One senses GAE is just not a major priority for Google"

1453 views
Skip to first unread message

Emanuele Ziglioli

unread,
Oct 28, 2014, 5:11:15 PM10/28/14
to google-a...@googlegroups.com
I would find hard to disagree:

IBM, Google, and Oracle are all equally at pains to deliver a message that makes them uniquely attractive. In this regard, Google's inability to recover from the botched roll-out of Google App Engine (GAE) will surely go down as one of the oddest business cases. It launched the product with great fanfare. But developers who flocked to it initially found a difficult platform that supported only a subset of Java and a very old version of Python. Moreover, the interfaces to the proprietary database were poorly thought out, so that almost everything in GAE required platform-specific code-arounds. While GAE has improved in a limited sense since then, Google has not done what Microsoft did — revamp the product from top to bottom to make it easy to use. Nor has it leveraged its natural connection to developers. One senses GAE is just not a major priority for Google.

Qian Qiao

unread,
Oct 28, 2014, 5:46:18 PM10/28/14
to google-a...@googlegroups.com
Yep, We should totally compare PaaS against IaaS and claim that one doesn't offer the same set of functionalities the other one offers. The comparison is totally fair and informative and not misleading in any way.

--
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.
For more options, visit https://groups.google.com/d/optout.

Darien Caldwell

unread,
Oct 29, 2014, 6:51:12 PM10/29/14
to google-a...@googlegroups.com
Disagree whole-heartedly. GAE has always been highly reliable, despite some early growing pains. Every system has platform specific quirks; name one that doesn't. And as for Python 2.5 being 'old', i could care less. The point is to get jobs done, not brag about version numbers. 2.5 was more than fine to do anything imaginable.  
Message has been deleted

Kaan Soral

unread,
Oct 30, 2014, 3:19:23 AM10/30/14
to google-a...@googlegroups.com
+1 to Darien Caldwell

husayt

unread,
Oct 30, 2014, 2:38:55 PM10/30/14
to google-a...@googlegroups.com
We all here care for Appengine. That is why we still post on this abandoned forum. Google is bloodline to Appengine, without their commitment there will not be Appengine. I have invested last years of my and teammembers lives to build a huge solution on Appengine. This radio silence from Google on Appengine is very disturbing to me.

We all here just want to hear some acknowledgement of commitment. There were number of posts like this recently. Do you remember anyone from Google ever replying to any of those concerns.

I am looking forward to an event next week, hope to hear some reaffirmation from them

pdknsk

unread,
Oct 31, 2014, 3:18:59 AM10/31/14
to google-a...@googlegroups.com
Well, it isn't a major priority, but maybe it doesn't need to be. I think the main problem is that nobody at Google seems to take ownership of App Engine. PMs are rotated in and out at high frequency. I have no insight of any kind, so I may be wrong. 

PK

unread,
Oct 31, 2014, 3:56:09 AM10/31/14
to google-a...@googlegroups.com
Here are some of my thoughts on topics raised in this thread:

1. Google has definitely abandoned this forum, no doubt about this… I am not sure if this is on purpose to force more people to buy paid support or just because of lack of leadership/ownership as @pdknsk suggests. But it is a fact.
2. However, abandoning the forum is not the same as Google abandoning Google App Engine. By many of my metrics GAE has been improving, I admit not with the pace I would have liked but it has been improving. 
3. The arguments used to reach the conclusion of the paragraph cited mostly do not resonate with me. However, the conclusion does.
4. But so what?   89% of Google's revenue still comes from advertising. Even when it comes to cloud computing, the big battle is happening in IaaS and not in PaaS, and there AWS is the major player. So it is to be expected that GAE is not a major priority. But again so what? Google has about 45,000 full time employees. What if only, let’s say, 250 employees—I made this number up---work directly on GAE? It is a minor priority but it could still be a great platform especially when it leverages the Google infrastructure.

So, I remain cautiously optimistic….

Tapir

unread,
Oct 31, 2014, 8:28:27 AM10/31/14
to google-a...@googlegroups.com
GAE really has two problems, neither of them are belong to what mentioned in this article. On the contrary, what mentioned the article are really good point, IMO.

The two problems are:
1. high price, for both instance hours and bigtable operations.
2. long Java instance startup time.

In my GAE experience, it is very reliable. BigTable is very powerful and easy to use.
 

Jeff Schnitzer

unread,
Oct 31, 2014, 1:42:00 PM10/31/14
to Google App Engine
Google officially 'abandoned' this forum when they moved general support to stackoverflow, so that's nothing new. And let's be honest, there was really only one person reliably following this forum before then - Ikai. Occasionally other @google.com folks would chime in but it was pretty much a one man show, and that one man wanted a change. It happens.

The bigger reason to suspect diminishing commitment to GAE (other than fairly slow pace of new feature rollouts) is that GAE gets little mention at I/O.

On the other hand, Google is going "big" into cloud services in general, and GAE is now just one part of that offering. On the plus side, GAE benefits a lot by riding that wave - managed VMs, datastore integration with Compute Engine, a whole new admin console, etc. On the downside, I'm guessing there's a lot of institutional distraction, and all the "cool kids" want to work on Compute Engine or whatnot.

And let's not forget that GAE rolled out PHP relatively recently. That must have taken a lot of development effort (sigh).

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-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Jeff Schnitzer

unread,
Oct 31, 2014, 1:55:34 PM10/31/14
to Google App Engine
I agree. I thought that article was basically a fluff piece written by someone who has never actually used GAE.

Nobody ever cared about the "subset of Java" issue except Sun who, as non-users, count only as whiners ("no, Java's mine, you have to use it the way I want!"). And the very old version of python was fixed (2.7, well, yes, it's still old but let's face it half the Python community hasn't made it to 3.0 yet).

IMHO, the biggest issue is that human beings are slow to adopt new things. Most web developers never move beyond the first stack they learn (usually LAMP or Rails). Ask them to go outside of their MySQL comfort zone and they get all nervous and sweaty. GAE is something different, and the truth is that even programmers are a conservative lot.

There are real problems with GAE (those two items chief among them) but I think the main reason Google is focusing so much on Compute Engine instead of GAE is that the vast bulk of developers haven't bought into the concept of PaaS yet. They've just barely made the mental transition off of colocated boxes. IaaS is an easier sell, even if it's a dumb choice.

Jeff

--

Robert King

unread,
Nov 3, 2014, 11:41:01 PM11/3/14
to google-a...@googlegroups.com, je...@infohazard.org
I agree with Jeff Schnitzer. I think google is afraid of the whole open source & docker thing gaining huge momentum and doesn't want to miss out so they want to make that part of their foundation e.g. things like kubernettes. They also want to make it easy for people to migrate from other clouds to google cloud. I personally like app engine instances - they are very lightweight containers - docker is great if you need third party libraries that aren't on app engine  & lots of developers don't want to shy away from that. I personally like the simplicity of app engine containers & most of my app can run on them. 95% of my code can run on app engine doing orchestration - I can always have processes running on compute engine with docker etc if I need - but even as it stands app engine can do a huge amount of what you need. Even if google didn't make many improvements to app engine for a while - I can still do a huge amount with app engine. I think a lot of grads coming out of university will go with PAAS & things such as firebase to keep things simple, however a lot of the senior developers will like to stick with what they know. It also seems like appengine needs a faster deployment cycle & better testing / simulation. So perhaps there is technical debt there.

PK

unread,
Nov 3, 2014, 11:56:35 PM11/3/14
to google-a...@googlegroups.com
Make sure you read this on Wall Street Journal just hot of the press: http://online.wsj.com/articles/google-renews-its-cloud-efforts-1415062792 (Search online for the title "Google Renews Its Cloud Efforts” if you hit the paywall).

I quote from the article: 

"Amazon started renting computing power in 2006, in a unit known as Amazon Web Services. Google unveiled its offering two years later. But Google initially required customers to write software similar to the way Google does. Amazon’s more flexible approach proved more popular. It used so-called virtual machines that let developers use most popular programming languages, databases and other tools. Google adopted this approach later, but by then it had ceded the early lead."

"Google’s first cloud service, App Engine, used the company’s internal approach. In contrast, Amazon used more standard technology.

Doug Anderson

unread,
Nov 5, 2014, 12:23:17 PM11/5/14
to google-a...@googlegroups.com
I've certainly felt that App Engine hasn't been a significant priority for Google for quite some time.  Legitimate bug reports can go unacknowledged for years.  The velocity of change has been largely centered around increased language support rather than significant service expansion and/or bug fixes.  It comes across as "We've invested in this GAE ecosystem.  What can we do to get more people to adopt it before we invest too much more?"  So rather than expand/enhance the services themselves they focused on additional language bindings.  Now, it feels like they've realized even the additional language bindings weren't enough.

The recent announcements around the Google Cloud Platform Live event make it pretty clear that Google realizes it can't tackle the cloud alone.  With Kubernetes/Google Container Engine, bitnami, and Managed VMs for App Engine it's clear Google is building around Google Compute Engine in much the same way Amazon built AWS around EC2.  I'm sure at some point all App Engine instances will be migrated to Compute Engine.  Other than VMs for App Engine going beta I don't think there were any GAE service expansion announcements at the Live event.  So this new, open, cooperate, run anything approach is the shiny new toy in the Google Cloud group (I don't see this as a bad thing... just more evidence that legacy GAE core services are NOT a priority).

There's A LOT to like about GAE... I REALLY like the dynamic image serving service, IP geo-location with every request, ndb w/ integrated auto memcaching, and NOT having to worry about OS and web server configuration!!!  GAE's ease of use is an area where Google actually has an advantage over AWS.  But as a developer there's an uneasy feeling about adopting a proprietary platform like GAE when you see legitimate bugs remaining stale for years at a time and the rate of service expansion/enhancement seems almost stagnate.  All the new announcements seem to be pointing somewhere beyond legacy GAE which just reinforces the uneasy feeling.

 - Doug

Vinuth Madinur

unread,
Nov 5, 2014, 12:29:23 PM11/5/14
to google-a...@googlegroups.com
+1 Doug.

I hope someone from google reads these messages.

To move away from GAE to Compute Engine based systems will require lot of rewiring in many projects. Hopefully things wont come to that.


Emanuele Ziglioli

unread,
Nov 5, 2014, 3:31:40 PM11/5/14
to google-a...@googlegroups.com
Thank you everyone for your insights, very interesting.

What do you guys think it's the way forward?
Are you going to migrate your GAE apps to to Managed VMs, with Docker and the gcs command line tools?

Also, is the Datastore still a valid option? 
I wish BigQuery just worked natively with it...

Thanks 
Emanuele

Doug Anderson

unread,
Nov 5, 2014, 6:43:44 PM11/5/14
to google-a...@googlegroups.com
I don't think there's any reason to migrate existing apps unless App Engine no longer satisfies your requirements.  I don't see App Engine going away... you just need to set your expectations of the platform accordingly (don't expect bugs to get resolved unless you have a paid support plan, don't expect earth shattering new services/features, etc).

David Hardwick

unread,
Nov 5, 2014, 11:23:34 PM11/5/14
to google-a...@googlegroups.com
And how are you?

The GCP Live event was telling the story around the continuum the Google Cloud Platform now provides from PaaS to IaaS.

You have GAE and with Managed VMs (combined with Autoscaler) you have GAE 2.0 in the PaaS category.  The GAE 1.0 docker images for Java/Php/Python can be deployed on Managed VMs if you wanted to, and when you want to customize that image ("I want Java 8"), okay, now you can.

You need to run certain software on cloud servers, go with GCE (servers, disks, load balancers, etc.) in the IaaS category.
  
You want something in the middle, go with GKE (Google Containers Engine). You can deploy the Docker items for Managed VMs to GKE, but if you want to use features like traffic splitting, etc. then you want to use Managed VM. Depends on your needs, your choice now. 

I try to start in the PaaS section until I need to get out of it due to certain technical requirements.  But excited to have all these choices along the PaaS to IaaS spectrum.

rock on,
  hardwick

Brandon Thomson

unread,
Nov 7, 2014, 11:17:35 PM11/7/14
to google-a...@googlegroups.com
Perhaps it is selfish on my part, but in some ways I am glad that GAE is not getting much attention. Fixing bugs in legacy code is not exciting work and a new generation of engineers at Google may be tempted to "improve" things that aren't broken instead of doing the hard work of maintaining the existing code.

As an example of an unwanted "improvement," I would point to the new logs viewer currently being advertised in the admin console. I don't like it at all and I hope we will be able to keep using the existing logs viewer.

Emanuele Ziglioli

unread,
Nov 7, 2014, 11:43:16 PM11/7/14
to google-a...@googlegroups.com
Hey but we did get something new, it's probably from an acquisition, but who cares (only for managed VMs): 

Kaan Soral

unread,
Nov 8, 2014, 2:09:01 PM11/8/14
to google-a...@googlegroups.com
Hehe, indeed the old logs viewer is better, yet it fails to fetch old logs, while the new one manages to do that sometimes

Going off topic, I also hate the new Cloud Console, the colours, the usage, the functionality

Josh Whelchel (Loudr)

unread,
Nov 8, 2014, 2:29:02 PM11/8/14
to google-a...@googlegroups.com
Our experience couldn't be further from the opposite of what's being described in this thread.

Google has been incredibly supportive of us as Appengine clients, and we've worked closely with their teams on feedback for the platform and the new console.

Further, they've been taking a lot of their efforts to the open source community, including the pipeline and mapreduce libraries they have internally developed. [see https://github.com/GoogleCloudPlatform]

Here's hoping your experiences improve!

Also, to those criticisms of the new log viewer, what's the basis for your complaints? I love the new viewer and after adjusting to it (admittedly the transition took a few days) - it's MUCH faster and easier to use.

Also, Cloud Debugger and Cloud Trace will blow your minds (see the GCP recordings if you can) - in particular, the watchpoints <3

pdknsk

unread,
Nov 8, 2014, 3:50:23 PM11/8/14
to google-a...@googlegroups.com
Google has been incredibly supportive of us as Appengine clients, and we've worked closely with their teams on feedback for the platform and the new console.

Which support tier do you have? 

Kaan Soral

unread,
Nov 8, 2014, 3:56:45 PM11/8/14
to google-a...@googlegroups.com
Here is an issue that I've experienced: https://groups.google.com/forum/#!topic/google-appengine/s8qO_JGE7YA

Old log console can't view old logs for me, might be a bug or not, it can't, new viewer is confusing, you can't see how far it's searching, it's constantly searching, misses some logs (it did in this example, causing me to believe that the logs didn't exist, digging in deeper revealed they weren't missing)
tl;dr;imo - logs are only useful if you are not digging in deep

pdknsk has a nice point, you must be on a high support level :)

It's also extremely incomplete after all this time, not integrated deeply, you also seem to be using Java, so the experience is probably different

I personally really like the old console/style, simple yet extremely functional UI, instead of flat/flashy and useless

Brandon Thomson

unread,
Nov 8, 2014, 9:26:29 PM11/8/14
to google-a...@googlegroups.com
On Saturday, November 8, 2014 2:29:02 PM UTC-5, Josh Whelchel (Loudr) wrote:
Also, to those criticisms of the new log viewer, what's the basis for your complaints? I love the new viewer and after adjusting to it (admittedly the transition took a few days) - it's MUCH faster and easier to use.

To be clear, I am very happy with app engine in general. I like the existing offering very much and want it to either stay the same or to be genuinely improved. I am not a fan of change for its own sake, something which this new logs viewer seems to be an example of. I am calling it out publicly here to alert people to the risks of these kinds of changes, and also perhaps to decrease the odds that the old logs viewer will be scrapped.

Based on my brief tests over the last few weeks, here are my complaints so far:

  - infinite scroll seems to reliably duplicate log entries when long-running requests are involved. Very confusing.
  - infinite scroll sometimes claims no new logs exist even when we are looking at them in the old logs viewer
  - expand all button doesn't actually expand all: I still see "show more" links at the bottom of every log entry
  - "Save As" does not work correctly after expanding a logs entry using said "show more" link (probably because the page's URL is not modified, but that's just a guess)
  - limit param in url for fetching more than 100 results at once is not supported

These are just a few things that I have noticed the new logs viewer breaks relative to the old one (And I use the latest Chrome stable on Win 7, so I doubt my browser is the issue). And, I'm sure there are more regressions that I haven't discovered yet.

The one thing I like about the new viewer is the default "fully collapsed" view. Seeing more requests at a glance is handy and that would be a nice backport to the existing appspot logs viewer. But is it worth dealing with all of the above problems for this one new useful feature? Not hardly! 

Jeff Schnitzer

unread,
Nov 9, 2014, 1:48:33 PM11/9/14
to Google App Engine
Funny. I also find myself consistently going back to the old console. The log viewer is the one part of the new system that I think might be an actual improvement since the old one seems to be very quirky about actually finding logs, although I hate the new color scheme.

The task queue management is a huge step backwards though. I frequently have to reload to see the state, and the new UI takes something like 5s to reassemble itself from the various iframes/whatever it loads. It's a serious drag. Maybe just a refresh button would help.

I just hope that someone is busy reinventing the datastore viewer. That would be compelling.

Jeff

--

Vinny P

unread,
Nov 10, 2014, 12:30:16 AM11/10/14
to google-a...@googlegroups.com
On Fri, Nov 7, 2014 at 10:17 PM, Brandon Thomson <b...@brandonthomson.com> wrote:
Fixing bugs in legacy code is not exciting work and a new generation of engineers at Google may be tempted to "improve" things that aren't broken instead of doing the hard work of maintaining the existing code.


+1. New is not necessarily better. To go on a minor tangent, I liked the older Google Groups UI better than the current version.


On Sat, Nov 8, 2014 at 2:56 PM, Kaan Soral <kaan...@gmail.com> wrote:
pdknsk has a nice point, you must be on a high support level :)


And +1 as well.  A paid support contract gives the App Engine unicorns some extra pep in their step :-) 

 
 
-----------------
-Vinny P
Technology & Media Consultant
Chicago, IL

App Engine Code Samples: http://www.learntogoogleit.com

Daniel Sturman

unread,
Nov 10, 2014, 10:49:12 PM11/10/14
to google-a...@googlegroups.com

Hey fellow App Engine users,


There is some great conversation in this thread. I’ll try to address some of the key points being discussed.


Regarding the discussion group; our apologies for the delayed response. Most of our customer questions now come on Stack Overflow, so we’ve been monitoring it more actively than this forum. We’ll be watching this forum more closely too from now on.


Regarding the larger topic of Google’s investment in App Engine: App Engine is a critical part of our cloud story, and will continue to be. We’re investing heavily in it. In the most recent months this investment has had two major prongs - stability improvements and new efforts to create a more flexible model within App Engine.


First, stability improvements. App Engine has grown and so has the size and sophistication of the workloads that relied on it (thanks to developers like you). We realized it was time to take a step back and invest in driving down technical debt and improving overall stability as a foundation for the future. The team has been heads down improving stability and reliability. Some of the improvements include more comprehensive monitoring across all services, better application scheduling and load balancing, deployment of SSD to reduce latency variability for Datastore access, and many others large and small.


Second, a more flexible PaaS. App Engine’s prescriptive environment for building web and mobile applications allows teams to iterate quickly on new ideas and scale up the ones that stick. The drawback, though, comes in terms of its constraints (e.g. limited JRE access, limited C/C++ Python modules, no inbound socket support). When we were building out our IaaS offering, Compute Engine, we realized that by unifying the compute stack (layering App Engine on Compute Engine), we could continue to give our customers the developer experience and efficiencies that App Engine brings with the flexibility and power that’s normally only associated with IaaS. Further, since it is a single stack, users can drop down into the IaaS layers when needed to make lower-level customizations (although we hope that most will never have to). We’ve surfaced all of this work as App Engine Managed VMs, which are now in Beta and open to everyone that wants a test drive. You’ll see that Managed VMs do not require you to manage the OS or web server configuration, and frontend serving has all the same great features as our existing runtimes. In other words, they marry the best of App Engine with a more flexible application environment.


Finally, unified administration tools are an important part of a cohesive platform. This is the goal of the Developers Console. In some cases the cutover has been a straight “drop in” of existing functionality, in others we took the opportunity to make improvements. Not all is perfect, so thank you for the feedback! I’ve created bugs / feature requests for the items you’ve mentioned (infinite scroll issues, “save as” issues, better Task Queue admin functionality) and suggest that any other feedback be sent to google-developers...@google.com (this is a more narrowly focused list).


Looking ahead, the reliability work is wrapping up (although, much like you, we’re always investing in this area) and you can expect new feature work to start ramping up (for example, we’ll have 64 bit JVM support landing soon). The beta launch of Managed VMs will progress towards General Availability and, in parallel, we’re actively looking at which additional generalized services need to be surfaced into the PaaS layer and how we can make the App Engine experience you all know and love even better. 2015 is going to be a very exciting year!


-Dan Sturman

VP, Engineering

Emanuele Ziglioli

unread,
Nov 11, 2014, 3:28:49 AM11/11/14
to google-a...@googlegroups.com
Thank you Daniel for your update!

It's great to hear an official statement from Google about App Engine's health and future.
I've certainly been enjoying increased reliability and reduced instance warmup time over the past couple of years, and that's a reflection of the hard work that's been going on behind the scenes.
At the same time, I would have liked to see some more development on the Datastore while other projects such as BigQuery appear to be isolated from it.
I believe that GAE's power is in it simplicity so my hope is that you guys will carry on with this philosophy of a simpler to use, easier to maintain solution in App Engine (I bet that's not an easy to achieve goal by any means, considering all the other services such as Gcloud).or
The other main aspect that's attracted me to GAE, the platform, is that it comes with "batteries included", all you need to get a web app up and running is there. By spinning off services such as the Datastore or adding foreign ones such as Cloudstore and Big Query, one feels that the focus gets lost.
But hey, I'm looking forward to experimenting with managed VMs, have been lurking on the Beta mailing list quite regularly.

Regards,
Emanuele


On Tuesday, 11 November 2014 16:49:12 UTC+13, Daniel Sturman wrote:

Hey fellow App Engine users,


There is some great conversation in this thread. I’ll try to address some of the key points being discussed.


Regarding the discussion group; our apologies for the delayed response. Most of our customer questions now come on Stack Overflow, so we’ve been monitoring it more actively than this forum. We’ll be watching this forum more closely too from now on.


Regarding the larger topic of Google’s investment in App Engine: App Engine is a critical part of our cloud story, and will continue to be. We’re investing heavily in it. In the most recent months this investment has had two major prongs - stability improvements and new efforts to create a more flexible model within App Engine.


First, stability improvements. App Engine has grown and so has the size and sophistication of the workloads that relied on it (thanks to developers like you). We realized it was time to take a step back and invest in driving down technical debt and improving overall stability as a foundation for the future. The team has been heads down improving stability and reliability. Some of the improvements include more comprehensive monitoring across all services, better application scheduling and load balancing, deployment of SSD to reduce latency variability for Datastore access, and many others large and small.


Second, a more flexible PaaS. App Engine’s prescriptive environment for building web and mobile applications allows teams to iterate quickly on new ideas and scale up the ones that stick. The drawback, though, comes in terms of its constraints (e.g. limited JRE access, limited C/C++ Python modules, no inbound socket support). When we were building out our IaaS offering, Compute Engine, we realized that by unifying the compute stack (layering App Engine on Compute Engine), we could continue to give our customers the developer experience and efficiencies that App Engine brings with the flexibility and power that’s normally only associated with IaaS. Further, since it is a single stack, users can drop down into the IaaS layers when needed to make lower-level customizations (although we hope that most will never have to). We’ve surfaced all of this work as App Engine Managed VMs, which are now in Beta and open to everyone that wants a test drive. You’ll see that Managed VMs do not require you to manage the OS or web server configuration, and frontend serving has all the same great features as our existing runtimes. In other words, they marry the best of App Engine with a more flexible application environment.


Finally, unified administration tools are an important part of a cohesive platform. This is the goal of the Developers Console. In some cases the cutover has been a straight “drop in” of existing functionality, in others we took the opportunity to make improvements. Not all is perfect, so thank you for the feedback! I’ve created bugs / feature requests for the items you’ve mentioned (infinite scroll issues, “save as” issues, better Task Queue admin functionality) and suggest that any other feedback be sent to google-developers-console-feed...@google.com (this is a more narrowly focused list).


Looking ahead, the reliability work is wrapping up (although, much like you, we’re always investing in this area) and you can expect new feature work to start ramping up (for example, we’ll have 64 bit JVM support landing soon). The beta launch of Managed VMs will progress towards General Availability and, in parallel, we’re actively looking at which additional generalized services need to be surfaced into the PaaS layer and how we can make the App Engine experience you all know and love even better. 2015 is going to be a very exciting year!


-Dan Sturman

VP, Engineering

PK

unread,
Nov 11, 2014, 12:25:24 PM11/11/14
to Daniel Sturman, google-a...@googlegroups.com
Hi Dan,

thanks for taking the time. We have not heard from anybody from Google in this forum for many months so your reassuring communication is very welcome. 

 I list below some of the reasons that might explain why some of us who have been following GAE for a long time have been skeptical about Google’s commitment and jump to conclusion when articles like this appears in the press.

1. There are still 3,000 issues open in the tracker. Although many of them are irrelevant enhancements others are critical. For instance, 
---we never expected that 5 years later would be still unable to send 8-bit e-mail through the platform (issue 2383) or 
—in the critical area of security we would have to deal with a Users API stuck in the 2009 reality and crashes in certain important use cases (issues 9045 and 8916)  or
--- that it would still be so difficult to create an SSL app (issue 8528). 
2. Now what makes this more frustrating is that bugs have been aging for way too long. For instance, issue 2383 was filed in 2009, it was accepted in 2012 and at the end of 2014 it is still open.
3. Google used to communicate a roadmap here. This was great for our planning. At some point the roadmap disappeared, again without communication. Furthermore, until a few months ago new releases (and pre-releases) were announced in this forum. Then suddenly the announcements and every Googler disappeared without warning. StackOverflow is a great Q&A forum but is not a discussion or announcement forum. 
4. Finally, last but not least the enthusiasm on Google’s part does not come across. I have been following GAE and developing since almost day one. The early days the developers were out here and in the irc chatrooms all the time. Input from customers was actively sought. Now we do not see anybody from your engineering/PM team here in the trenches.

Knowing the alternatives, I remain very enthusiastic about PaaS in general and GAE in particular. I acknowledge that the GAE stability is very good, Google’s innovations in the hybrid IaaS/PaaS cloud is significant and that recently I have seen more activity in the issues tracker. For instance, I was impressed how proactive you were when I filed 11396 or regression 10503. 

I remain optimistic that the GAE stability will stay where it is but also that the Google investment reflected in faster feature velocity will increase, and the open communication will return.

Best,

pdknsk

unread,
Nov 11, 2014, 2:18:06 PM11/11/14
to google-a...@googlegroups.com
Completely agree on the issue tracker. There are many relatively low hanging fruit bugs which have been neglected for years. I guess partly because Google went after the most starred bug: PHP. If that was a worthy investment I do not know. I guess it wasn't. I hope the second-most starred bug (Perl) isn't next on the TODO list :D

Doug Anderson

unread,
Nov 11, 2014, 4:09:29 PM11/11/14
to google-a...@googlegroups.com, stu...@google.com
+1 nice to hear from Dan... very encouraging indeed!!!
+1 to PKs comments as well...

Hopefully Dan's improvement list includes better Datastore admin... especially the ability to edit repeated fields!  I have to write custom admin code for every repeated field I may need to edit.  The strategic use of repeated fields is key to success with the GAE datastore so it's not like they are some obscure back seat feature.

I really like Dan's comments about SSDs... the write time on the datastore is terrible compared to AWS Dynamo (all SSD with single digit ms writes) BUT the datastore has better transaction support and is arguably a better general purpose datastore (includes zigzag merge-join queries etc).

Managed VMs via Docker containers gets a big thumbs up from me as a GAE gap filler!  Looks very promising!

 - Doug


On Tuesday, November 11, 2014 12:25:24 PM UTC-5, PK wrote:
Hi Dan,

thanks for taking the time. We have not heard from anybody from Google in this forum for many months so your reassuring communication is very welcome. 

 I list below some of the reasons that might explain why some of us who have been following GAE for a long time have been skeptical about Google’s commitment and jump to conclusion when articles like this appears in the press.

1. There are still 3,000 issues open in the tracker. Although many of them are irrelevant enhancements others are critical. For instance, 
---we never expected that 5 years later would be still unable to send 8-bit e-mail through the platform (issue 2383) or 
—in the critical area of security we would have to deal with a Users API stuck in the 2009 reality and crashes in certain important use cases (issues 9045 and 8916)  or
--- that it would still be so difficult to create an SSL app (issue 8528). 
2. Now what makes this more frustrating is that bugs have been aging for way too long. For instance, issue 2383 was filed in 2009, it was accepted in 2012 and at the end of 2014 it is still open.
3. Google used to communicate a roadmap here. This was great for our planning. At some point the roadmap disappeared, again without communication. Furthermore, until a few months ago new releases (and pre-releases) were announced in this forum. Then suddenly the announcements and every Googler disappeared without warning. StackOverflow is a great Q&A forum but is not a discussion or announcement forum. 
4. Finally, last but not least the enthusiasm on Google’s part does not come across. I have been following GAE and developing since almost day one. The early days the developers were out here and in the irc chatrooms all the time. Input from customers was actively sought. Now we do not see anybody from your engineering/PM team here in the trenches.

Knowing the alternatives, I remain very enthusiastic about PaaS in general and GAE in particular. I acknowledge that the GAE stability is very good, Google’s innovations in the hybrid IaaS/PaaS cloud is significant and that recently I have seen more activity in the issues tracker. For instance, I was impressed how proactive you were when I filed 11396 or regression 10503. 

I remain optimistic that the GAE stability will stay where it is but also that the Google investment reflected in faster feature velocity will increase, and the open communication will return.

Best,


On November 10, 2014 at 8:09:09 PM, Daniel Sturman (stu...@google.com) wrote: