Anyone tried Beanstalk? Is it any better? I’ve recently had a run-in with Azure where I had to store some stuff for a customer in their S3-like blob store service. It was a nightmare. Insanely over-engineeered to the point that it becomes impossible to figure out how to do the simplest things. Much like GAE’s trajectory.
Ima coin a new law: All PAAS services will expand until they are indistinguishable from IAAS. > On Mar 16, 2020, at 2:46 AM, Nickolas Daskalou <n...@daskalou.com> wrote: > > Same experience for us. > > 10 years ago App Engine was a revolution. Now it's almost revolting. > > Agree with the hard to set up development environment for the newer App > Engine installments. > > Other pain points too, like no shared Memcache replacement (we're told NDB > for Python 3 is fully ready, when in reality a lot of existing apps which > rely on the built in feature of the free shared Memcache will either suffer > performance issues and/or an increase in billing cost if they switch over). > > Google are having a hard time working out how to crack the cloud computing > market. Enterprises go with Azure because Microsoft are already heavily > embedded and sell the business fluff well, and AWS have a massive head start > on startups due to a larger existing user base and service offering because > they were first in the game. > > Nick > > On Mon, 16 Mar 2020, 4:35 am Matthew Parkes, <mattgpar...@gmail.com > <mailto:mattgpar...@gmail.com>> wrote: > I have to totally agree with this. My experience has been the same coming > from AppEngine Standard python 2.7 I decided to try and migrate one of my > apps to Python3.7 but was extremely frustrated and put off with the whole > experience. I lost a lot of nice framework that made decisions easy and > straight forward to actually just get functionality working. (Endpoints API, > User management, Data management, Admin datastore). I found it very hard to > get an actual development environment setup where I could rapidly develop and > test, see data in the database etc. > > The local testing has become very difficult. It's sad that while google > appears to say "Oh AppEngine so much more flexible for you now" sounds like a > step forward, when really it's more like 1 step forward, 5 steps backwards. > > Disappointed, > > Matt > > On Sunday, 15 March 2020 08:48:56 UTC-7, Brian Ruuska wrote: > Glad to hear I'm not the only one disappointed with it all. I started using > App Engine when it was in beta, and launched a one-person business when it > went GA. It's so overwhelming attempting to port my product to the new > environments that it's much more than a one-person effort. And with all the > land mines and missing functionality I decided to just close the business > last year. They seem to be more interested in serving big enterprises, and us > little guys are just left behind. :-( > > On Saturday, March 14, 2020 at 7:22:15 AM UTC-5, Kaan Soral wrote: > I'll whine a lot, but there's a concentrated and crisp TL;DR in the end > > > > I've been using App Engine I guess for 10 years now? It's hard for me too, > but also, I'm preparing to open source my current project, at each step I > question everything, I was going to open source my game so young > developers/kids/gamers could dive into networked game development easier > (It's an MMORPG on Google Cloud, my dream was that open sourcing it could > enable fast experimentation with the genre), but as it is, at the current > state of App Engine, the bottleneck is definitely all the diversified and > separated products, separate emulators (missing ones), separate environment > variables for everything etc. - I can't imagine a happy scenario where one > could just develop an App Engine app locally without spending weeks trying to > understand what's what first - Back in the day, I think the Launcher GUI and > the simplicity of it all, got us all hooked (This is coming from a CLI user) > > > > Things used to be as simple as "python2.7 /sdk/dev_appserver.py > --storage_path=/storage/ --blobstore_path=/blobstore/ > --datastore_path=/storage/db.rdbms --host=0.0.0.0 --port=8080 /path > --require_indexes" - We could test EVERYTHING locally, now we can almost test > nothing locally > > > > It seems that the python2.7 that's currently in the process of being > deprecated was the last of it's kind > > > > Instead of refactoring everything for Python 3, I decided to move onto NodeJS > instead, the work done, the documentation, the depth of it all, on the > surface, is very exciting, until you dive in > > > > First of all, at each step, you're faced with initially arbitrary decisions > that's going to eliminate you, flexible or standard? - does it really matter, > I don't think so, firestore in datastore mode or firestore? oh my god, it's > like each option is designed to torture and drive away a potential user > > > > As a long time App Engine / Datastore user, I've simplified my data design to > a singular dimension and simple get/set by key operations wherever possible, > so for me the limitations of the new datastore really doesn't matter much, I > just wanted to use the new Firestore and all the new exciting stuff that came > with it, experiment with it, see how it can improve my approach, I've always > designed products that regularly pinged the server for new data, so the > realtime features etc. appealed to me a lot - so I'd choose the unlocked > Firestore, instead of the irreversibly locked one, at least that decision was > easy, but the not so easy part was to find out how I'm going to emulate it > locally, authenticate it locally, use it locally > > > > Honestly, it's been months since I've been entertaining idea, whenever I can > find some free time, I re-dive back into it, but still, I achieved nothing, > yesterday I finally discovered "gcloud beta emulators firestore start" - but > the new "environment variable" based approach etc. is making me want to cry, > so I gave up again (the examples/docs are from "firebase", the > authentication/flow is from "firebase", there are no simple examples to just > use and authenticate "firestore" locally) - When I'm configuring a product, I > either want to configure it in-code, or configure it in .yaml files, with the > new approach, even app id's are set through environment variable's ... > > > > Just before writing this, I wondered if I'm being unjust, and wondered > whether I should just pick an arbitrary service, experiment with it using > NodeJS, so I picked Taskqueues, or "Cloud Tasks" as they are now called, once > again, it's a seemingly well documented and seemingly a well designed > product, but no matter what I did, I just couldn't find how I'm going to test > it locally, as it turns out, it can't be tested/emulated locally? bummer. > (Related: > https://stackoverflow.com/questions/53826183/local-development-with-cloud-tasks-cloud-datastore-with-gae-with-python3 > > <https://stackoverflow.com/questions/53826183/local-development-with-cloud-tasks-cloud-datastore-with-gae-with-python3>) > > > > TL;DR/Conclusion: > > > > I believe we need a practical, all in one and turnkey local emulation > solution again - There's a vast/overflowing/overwhelming amount of new > options and no easy way to test them - I think the best way to learn about > something is to use it > > > > Suggestion/Takeaway: > > > > I think local development is no longer feasible or possible, so it seems like > a better idea to just deploy and test live, I don't know whether it's the > intended way now, but it's seemingly the only way. In the past we assumingly > all had a local development version of our products, I assume we now should > start with live development versions of our products. So when I'm ready to > try again, I'll experiment with it all live. (It's sad that likely this > option is only possible for paying customers, I don't know whether the > products have safe free tiers now, I assume not) > > > > I also wonder whether I'm the only one who feels this way, are there any > success stories out there, happy new App Engine users? > > > -- > 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+unsubscr...@googlegroups.com > <mailto:google-appengine+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/9b64def7-8ce2-4cf3-a6c7-84aba79e7aea%40googlegroups.com > > <https://groups.google.com/d/msgid/google-appengine/9b64def7-8ce2-4cf3-a6c7-84aba79e7aea%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 google-appengine+unsubscr...@googlegroups.com > <mailto:google-appengine+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/CAOj3zuA6P676X8EKyt22MB5G01Nv8uLOqfGm14A%2BRbNmgCMUmQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/google-appengine/CAOj3zuA6P676X8EKyt22MB5G01Nv8uLOqfGm14A%2BRbNmgCMUmQ%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 google-appengine+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/4E5613FB-2ACE-4460-B002-9A2C1C004F40%40gmail.com.
