I feel like Google has made some improvements and some of the deprecations are understandable. My biggest issue is the way Google has gone about doing this. GAE started out as a platform coded to a number of languages' interfaces, some standard and some proprietary. For example, it used to be possible to send emails in Java using standard javax.mail interfaces. But as time went on, Google felt like there were opportunities and pressures to make changes to the offerings and many of these changes were made in a breaking fashion or with alternatives that didn't add up to the functionality they were replacing.
>From day 1, when compared to AWS, Google's documentation felt a bit disjointed, like a patchwork of output from different teams that don't talk to each other. Now that there's this push to move everything under GCP tooling, this disjointed nature of documentation and sense of lack of direction feels even worse. I don't mean to downplay GAE's strengths or discourage people from using it, but undoubtedly it feels like you can't put too much trust in Google's willingness to support services or interfaces you build against. So as a long-term decision, GAE carries more risk than some competing approaches. Certainly, as others have said, it doesn't seem as friendly of a product to small teams or less technical teams, which is a shame. Alexey On Sunday, March 22, 2020 at 2:49:37 PM UTC-4, Jeff Schnitzer wrote: > > As another longtime user, I have mixed feelings. Some things are better, > some things are worse. I certainly wouldn't give up the current GAE to go > back to the old one, but mostly because I still have enough of the old one > available. > > I straddle the old world and the new world, using the "old" memcache and > task queue APIs. I guess if I ever want to upgrade from Java8 I'll be > forced into Cloud Memorystore and Cloud Tasks. The biggest problem would be > converting my test harness. I could use a live Redis that I flush between > tests, but lack of an emulator for Cloud Tasks is a pretty serious problem. > I'm very dependent on the LocalTaskQueueTestConfig. > > Actually this is maybe a symptom of a bigger problem. In the old > "integrated whole" GAE, the task queue is a way of deferring execution. The > fact that there were URLs and http requests underneath was plumbing that > could be ignored. 100% of my task queue usage is "execute this bit of code > later", so it's really easy to write tests with an awaitTasks() method that > chews through the list of deferred operations. The only level of > abstraction provided by Cloud Tasks is "http request" so all the deferring > and test harness logic would be up to me to implement. Ugh. > > Honestly though, the old memcache and task queue APIs are so rock solid > reliable, upgrading seems like a terrible idea. And there's nothing > particularly compelling in Java11 (except the 10m deadlines). > > On the plus side, Cloud Postgres is pretty fantastic, although balancing > the number of database connections with the number of instances is really > tricky with autoscaling on GAE. Under load, you either run out of JDBC > connections or you run out of instances to serve user requests... if you're > used to the datastore, tuning your scaling settings is now hard. PG > connections are an expensive resource. > > I like the new console quite a lot more than the old one, and it's getting > better. The error notifications are great - nicely integrated with logging, > unlike rollbar (which I no longer need to pay for). > > GCS is vastly superior to the old blobstore. > > I agree it's harder to get started with the current GAE offering, but I > still recommend it to folks. > > Jeff > > On Sat, Mar 21, 2020 at 6:45 PM Rajesh Gupta < > [email protected] <javascript:>> wrote: > >> Please Google don't deprecate anything. Dont' introduce new parallel way >> of doing things with new stuff and put the developers in confusion on the >> dev roadmap. >> Get back mapreduce. If I write a simple SAAS that is serving few >> customers and growing, why do I need new and big and scary DataFlow >> technologies. Dataflow is too enterprisish. >> >> Following issues small companies faced for having been on Google >> appengine: >> >> - GWT is not promoted as it was 7-8 years ago >> - Image API was deprecated. It was so hard for finding equivalent things >> for low cost. >> - Mapreduce is made open source and not promoted. Mapreduce itself went >> two api iterations and then finally parked away as open source. >> - A bunch of new things equivalent to what is available on appengine with >> new terms like 'cloud tasks'', 'cloud datastore' etc. >> >> Lastly, give good and easy migration UI tools for making bulk schema >> changes. >> Improve documentation. >> >> >> On Sat, Mar 21, 2020 at 1:44 AM Luca de Alfaro <[email protected] >> <javascript:>> wrote: >> >>> I will sorely miss Appengine, as it was a uniquely simple way to get >>> reliability and scalability. >>> >>> And it was unique to Google. Other things, like containers, vms, and >>> databases, AWS also has them. >>> >>> So I think the strategy is foolish. If Appengine is de-emphasized, I >>> won't be confident putting resources in Firebase, which seems to be just >>> the next Appengine. I will move to things that historically have been more >>> stable, and that means, I am afraid, AWS. >>> As much as I admire Google's technical skills, for the things I and my >>> startups do, we need to be able to focus on developing new features rather >>> than porting what we have from services that are going to be deprecated >>> periodically. >>> >>> Luca >>> >>> On Fri, Mar 20, 2020 at 1:02 PM Joshua Smith <[email protected] >>> <javascript:>> wrote: >>> >>>> It’s interesting to look at what Google is doing with Firebase. >>>> >>>> 1. They are encouraging us to move more of the processing into the >>>> client, which while often architecturally foolish, does eliminate the need >>>> for some of the PaaS stuff. >>>> >>>> 2. They have a serverless/cloud functions thing over there, which >>>> overlaps a lot with the PaaS stuff we’ve been able to do in GAE. I haven’t >>>> dug into that too much, but on the surface it looks like the spaghetti >>>> antipattern. >>>> >>>> Given that this is google, and that it’s PaaS all over again, I think >>>> the risk of putting *any* eggs in the Firebase basket seems almost >>>> unbearably high. Is Google going to turn their back on Firebase when the >>>> next shiny object distracts them? Why should we believe that *any* service >>>> google offers will last more than their committed 3 years? >>>> >>>> I’m super tired of having to go back and rewrite my critical business >>>> infrastructure every few years. >>>> >>>> (Google’s competitors in the PaaS space don’t inspire any more >>>> confidence, so this isn’t so much a google problem as a cloud problem, I >>>> think.) >>>> >>>> -Joshua >>>> >>>> On Mar 20, 2020, at 12:59 PM, Patrice B <[email protected] >>>> <javascript:>> wrote: >>>> >>>> >>>> Hi guys, >>>> >>>> A few months back, I had a similar reflexion on current trends >>>> regarding AppEngine, which I called "the end of paas", which could be >>>> called "end of serverless" in a way >>>> >>>> >>>> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!search/paas|sort:date/google-appengine/DHMMv5r8qjU/A-VO3PXPDwAJ >>>> >>>> It's not very long, so I paste it here, since it is quite similar to >>>> what is being said here. >>>> >>>> It seems most of the services that made AppEngine a proper Platorm as a >>>> Service are now scheduled to be shut down, and users are advised to >>>> migrate. Migrate search to ElasticSearch, migrate memcache to Redis, and >>>> maybe at some point we'll be asked to migrate Ndb to MongoDB and GCS to >>>> whatever. I'm not complaining about the way the process is handled >>>> actually, there is enough time to consider the options and work on a >>>> migration scenario, there is no imminent deadline, at least for the >>>> moment. But I'm wondering what went wrong with the PaaS approach, and is >>>> it officially dead. >>>> >>>> Is this the end of GAE as a PaaS ? I truly believed PaaS was the >>>> future of cloud architectures: stop thinking in terms of servers, start >>>> thinking in terms of services. When I started working with AppEngine, I >>>> dreamed of CPU as a service, with no server granularity, and I was >>>> disappointed to find I still had to worry about servers, starting up a new >>>> server instance, choosing what type of instance would be best, a scaling >>>> strategy, etc. I was expecting servers as a service, i.e. serving my >>>> requests without me ever thinking in terms of servers. But at least >>>> there >>>> was Ndb, search, memcache, GCS and a few more. >>>> >>>> Now it seems all of these are on their way out, which makes me wonder: >>>> was there something wrong with the concept of PaaS itself, or is it just >>>> that these products didn't gain traction, and are now too costly to >>>> maintain with regards to their user base ? Actually, the one thing that >>>> was wrong with Paas from the very beginning was that it would lock a >>>> project into a given cloud. That was a risk to be reckoned for users, >>>> but >>>> it could have been seen as a feature for the cloud provider. Now is it >>>> for this reason that the mentionned services didn't make it ? Because >>>> users would have been wary of being locked in, and for that reason would >>>> prefer to use leading products deployed on leased servers ? One thing >>>> is >>>> for sure: once an application has migrated to more standard services, it >>>> will not be tied to GCP anymore. >>>> >>>> There was a major benefit to the PaaS concept: it was very cheap for >>>> startups. Deploying ElasticSearch on a the smallest possible cluster >>>> will >>>> start at around $200 a month, while the search usage of a small >>>> application >>>> could cost less than $10. Same for the shared memcache service offered >>>> by >>>> AppEngine. Now you are having to pay for running servers all night with >>>> very little transactions to handle. >>>> >>>> I'd be happy to hear your thoughts on this matter ? >>>> >>>> >>>> >>>> -- >>>> 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 [email protected] <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/google-appengine/6edf3459-a4d0-4ea4-9282-86cdb6a2672f%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/google-appengine/6edf3459-a4d0-4ea4-9282-86cdb6a2672f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> >>>> -- >>>> 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 [email protected] <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/google-appengine/5644BD34-868F-48F8-8FD7-87B8C0FA6AD6%40gmail.com >>>> >>>> <https://groups.google.com/d/msgid/google-appengine/5644BD34-868F-48F8-8FD7-87B8C0FA6AD6%40gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/google-appengine/CAPgu2uKUr7mY89NYrOWG0kJa9a1V%2Bc0395-5csqq7JycE7u4nQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/google-appengine/CAPgu2uKUr7mY89NYrOWG0kJa9a1V%2Bc0395-5csqq7JycE7u4nQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Rajesh >> www.servicefolder.com >> *Field Service Software on Google Cloud Platform and Mobile* >> >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-appengine/CA%2BS7ijaK%3DutqkAT%2BPHYRg4sf6CteT6a4uT6wqUfNR3a40oPVqw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/google-appengine/CA%2BS7ijaK%3DutqkAT%2BPHYRg4sf6CteT6a4uT6wqUfNR3a40oPVqw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/7b77d863-b00c-4f45-9412-8f4dd3025a01%40googlegroups.com.
