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

[Emanuele Ziglioli]

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.

http://www.drdobbs.com/cloud/whose-cloud-will-you-use/240169229

[Qian Qiao]

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]

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.  

[Kaan Soral]

+1 to Darien Caldwell

[husayt]

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]

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]

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

PK
http://www.gae123.com

[Tapir]

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]

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]

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]

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]

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

PK
http://www.gae123.com

[Doug Anderson]

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]

+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]

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]

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]

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]

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]

Hey but we did get something new, it's probably from an acquisition, but who cares (only for managed VMs): 

https://cloud.google.com/tools/cloud-debugger

[Kaan Soral]

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)]

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]

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]

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]

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]

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]

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]

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]

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]

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,

PK
http://www.gae123.com

[pdknsk]

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]

+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,

PK
http://www.gae123.com

On November 10, 2014 at 8:09:09 PM, Daniel Sturman (stu...@google.com) 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

On Sunday, November 9, 2014 9:30:16 PM UTC-8, Vinny P wrote:

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

[Stuart Langley]

What have you got against PHP bro? ;)

[Adam Sah]

+1 thx for the inspiring post.  I'm excited about Managed VMs, in our case for hosting a SOLR/Lucene instance.

adam

(Google TLM, Gadgets 2004-2009)

[Marcel Manz]

Hey Daniel

I'm very happy to hear back from Google on this forum and wish to point out that it has to be very important for Google to follow this group in order to share updates etc. Stackoverflow is an external site which is great for code fragment sharing, but it's not a great place to discuss about specific technology in general which should be discussed on a Google hosted Group/Forum.

If you would follow what the other large cloud provider is doing with its forum you would immediately recognize the importance of having a provider <> client/developer relationship. We ourselves are supported by Google Premier Support, hence we direct many questions directly to Google's support staff, which so far has been able to solve most of the issues we discovered. However there for sure are many developers out there who select a platform, based on their own judgment on how active the provider <> client/developer relationship is maintained in forums. If there is zero support/feedback by the provider, those clients might opt for another cloud provider without investigating further your solution.

From a feature perspective, Google should really complete the integration of PHP. Since its integration there's *the* key-service missing which is DataStore. Yes, it is accessible via API's, but that's not the same as the native direct datastore access we requested in:

https://code.google.com/p/googleappengine/issues/detail?id=9931

I'm really looking forward for Google to finally complete this integration, so we can migrate additional workloads using DataStore over to GAE/PHP. Many of our projects are using Datastore through Java at the moment, but Java isn't the preferred language on our recent projects, which more and more are done in PHP.

Kind regards,
Marcel

[Daniel Sturman]

Thanks for your candid responses. I hear your concerns loud and clear. I think the issues you raised all boil down to one thing: you’d like to see greater engagement between the App Engine team and our developer community.

With regards to your specific concerns:

I agree that an issue tracker is of little use if we aren’t actively triaging and updating it.  Although I could address the individual examples you pointed out one by one (e.g. we partnered with SendGrid to give you a good alternative for sending email), I think the proper action here is to triage the open issues in the tracker.  We have been ramping up support for doing this and you can expect to start seeing traction in the coming weeks.  

As we ramp back up on feature work, we’ll also resume using the group for outbound communications regarding releases as well as any other developer-facing changes.  In parallel we’re having our support engineers monitor the group for issues and topics that need to be addressed by Google.  These will either be answered directly by that team or will be routed to the proper product management and / or engineering team.

-Dan

VP, Engineering

[Brandon Thomson]

This thread could use a bump; lots of good stuff in here!

On Sunday, November 9, 2014 1:48:33 PM UTC-5, Jeff Schnitzer wrote:

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

Today I have a link to a new datastore viewer in my admin console. The UI is cleaner and looks very promising. GQL is gone (good riddance) and replaced with dropdown menus for filters and clickable headers to replace "ORDER BY". Very nice!

There are many new features in the entity viewer: indexing can be adjusted, new properties can be added, and the types of existing properties (except text, blob, and list) can be adjusted to other types (not just null). Text, list, and blob properties still cannot be edited at all (I was really hoping that would be possible).

There is also something of a regression: it does not seem to be possible to bookmark a query or a sort order. Bookmarking and linking to queries is something I really rely on in the old datastore viewer.

I am pleased to see that Google is listening to feedback and will submit these comments to google-developers...@google.com as well.

[pdknsk]

I noticed that Google closed the Perl bug yesterday. It was obvious really, but a good move nevertheless. C# was also closed.

[PK]

I am more surprised that they did not close all the open issues asking for support for another language...

Read this for context: https://www.linkedin.com/pulse/article/20141118192324-332875-program-the-cloud-in-any-language

PK
http://www.gae123.com

On November 14, 2014 at 10:05:32 AM, pdknsk (pdk...@gmail.com) wrote:

I noticed that Google closed the Perl bug yesterday. It was obvious really, but a good move nevertheless. C# was also closed.

[dele...@gmail.com]

Hello
I wrote to google-developers-console-feed...@google.com and it permanently fails.
Does somebody know a more suitable email address?  Or should I just post my feedback in StackOverflow?
Valentin

On Tuesday, November 11, 2014 4:49:12 AM UTC+1, Daniel Sturman wrote:

[I] suggest that any other feedback be sent to google-developers-console-feed...@google.com (this is a more narrowly focused list).

[Luke Stone]

The best way is to do it from within the console itself.   Look for "Need help?" in the left nav (near the bottom), then "Send feedback".   This way you can capture a screenshot which is a big help to the team. 

-Luke

[Alejandro Casanovas]

I will also want to make a claim for all those early users of App Engine which are joining and trying to catch up the professional world using this tool.

It really seems abandoned to me. At least if you only (and I say here ONLY) want to rely on PaaS and not going further.

The majority of app engine questions in stackoverflow are from 2013 or early and If you follow people who where actively contributing to app engine on those days you find out they no longer answer nor they belong to the app engine community any more. You really can't feel a big community of people asking and getting involved in.

It's also hard to find documentation on how to make a complete web app in app engine. 

For example, if you try to do it with Webapp2 framework (which I like the most because of it's simplicity) you will find it really difficult to implement oauth, sessions, rest, rbac, etc... 

Webapp2 it's completely abandoned! And given that almost all app engine examples on python rely on webapp2... that's a big flaw.

I find out I need to move on managed VM's, because relying just on app engine to make a complete web app It's impossible.

It's really good to learn because you didn't need to think on server issues, etc. But once you have the know-how... better move out.

But I'm glad to see Google answering here and catching up with the long, long, long.. issues list.

[pdknsk]

There has definitely been progress on the issue tracker, as bugs are now at least read and acknowledged in a timely manner. That's where the progress stops.

[Jesse Scherer (Google Cloud Support)]

Hi Alejandro,

I wanted to speak to your point about the community on Stack Overflow. It's certainly the case that given the age of App Engine, many questions will be older. As to exactly how many questions get asked and whether there really has been a decline since 2013, your post made me very curious. So, I did a quick query of question volume using the Stack Exchange Data Explorer. You can see it alongside a graph of questions per month here: http://data.stackexchange.com/stackoverflow/query/279338/app-engine-questions-by-month#graph

Assuming my T-SQL is accurate, the past few months have been slower than the busiest months in 2014, but 500 new questions per month is still a lot.

It's also clear that all of those question don't do much good if nobody is answering them. We also noticed that there were quite a few unanswered questions about App Engine (and Google Cloud Platform in general) and so for the past few months, the support team has been reading and trying to answer literally *every* question which Stack Overflow considers "unanswered."

As one of the folks working full time to make forums like Stack Overflow and this group more useful to the community, I just wanted to assure you that these things are not in any way abandoned.

- Jesse

As somebody who is working full time to make public resources like Stack Overflow and this group more useful to our users, I just wanted to assure you that these forums are not by any stretch 

[Tapir]

On Thursday, February 26, 2015 at 8:41:07 PM UTC+8, Alejandro Casanovas wrote:

I will also want to make a claim for all those early users of App Engine which are joining and trying to catch up the professional world using this tool.

It really seems abandoned to me. At least if you only (and I say here ONLY) want to rely on PaaS and not going further.

The majority of app engine questions in stackoverflow are from 2013 or early and If you follow people who where actively contributing to app engine on those days you find out they no longer answer nor they belong to the app engine community any more. You really can't feel a big community of people asking and getting involved in.

It's also hard to find documentation on how to make a complete web app in app engine. 

For example, if you try to do it with Webapp2 framework (which I like the most because of it's simplicity) you will find it really difficult to implement oauth, sessions, rest, rbac, etc... 

Webapp2 it's completely abandoned! And given that almost all app engine examples on python rely on webapp2... that's a big flaw.

just try golang, that is all.

Java is slow to startup and very memory consuming and slow for development.

PHP and Python is slow on performance.

Golang is both fast for development and fast to startup and fast on performance, and it is maintained actively.

[Alejandro Casanovas]

That's mind-blowing to me, my assumption was totally the opposite. It's clearly now that app engine questions are increasing on stackoverflow.

But at least on app-engine python I don't change my opinion. Webapp2 is abandoned, there's no python 3 support, etc...

Thanks for putting so much effort on trying to answer all the questions in stackoverflow

[Kaan Soral]

What a community really needs is simple old forums, it's that simple

Google groups comes close

S.O. is the exact opposite, yet lately S.E. networks have been improving a lot, I don't see the "this is not a simple question, f.off" stance anymore, so that's good

[Jeff Schnitzer]

Just want to point out that it's not fair to judge a tool by activity on stackoverflow. Heavy stackoverflow activity could merely indicate a buggy tool or poor documentation. Furthermore, prior questions become a body of work that satisfy answers; if SO is working as advertised, new (duplicate) questions are not required.

Also: We have a forum; we're using it now. And it seems to have picked up lately.

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.
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/64be9755-0497-41f9-a210-241159bd68fd%40googlegroups.com.

[Chris Ramsdale]

re: Python 3, we're actively building a new hosting environment that is based on containerized virtual machines, today called Managed VMs.  with this new architecture we'll be able to update existing (and build new) application runtimes at a much faster pace.  in fact, a Google-provided Python 3 runtime is definitely in the works right now.  you can actually run Python 3.x there today using the custom runtime functionality.

re: Webapp2, are there specific feature requests or bugs that you can point me to?  i'll make sure that we follow-up in some form.

-- Chris

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

[DT Rush]

This thread is silly and bad

On Tuesday, October 28, 2014 at 5:11:15 PM UTC-4, Emanuele Ziglioli wrote:

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.

http://www.drdobbs.com/cloud/whose-cloud-will-you-use/240169229

[Brandon Thomson]

Yup, golang is the winner. Perfect fit for GAE's architecture, URL routing included in stdlib... love it.

[Alejandro Casanovas]

Check: https://code.google.com/p/webapp-improved/issues/list

The issue n.100 was issued by me a few days ago.