Three Years on Google App Engine | Hacker News Reader

Three Years on Google App Engine

blog.stephanbehnke.com

331 pointsindigodaddy115 comments

Bear in mind this article was written back in March 2017; quite a few things have changed/improved in GAE-land since. To name a few, off the top of my head:

- Java 8 is already generally available on GAE standard and, on top of that, previous limitations wr/t class whitelisting, threading capabilities and others have been lifted

- appcfg is pretty much outdated these days; all GAE management operations have been progressively integrated into gcloud app subcommand, which also fully supports newer GAE features like Flex, firewall rules, etc.

- GAE standard instances are indeed limited in computing power, but it should be enough for most web-based applications. Again, GAE Flex fills in the gap here in case more muscle is needed, since it leverages GCE-class instances

- Besides the already mentioned background work options (background threads, task queues, cron jobs), there's also Pub/Sub which can be used to inter-communicate GAE services or even other GCP services like GCE or GKE

Java 8 became available on GAE about 3 years after it was released. If Google continues that trend, Java 9 won't be available until 2020.

Slow adoption of new Java versions is a pretty big downside. Even if you are satisfied using Java 8 on GAE today, you may want to use Java 9 in the near future, and you won't be able to. By choosing GAE you are committing yourself to being stuck with Java 8 for a long time.

If you sign an NDA with Google, you'll get more up to date info about future features/roadmap etc. I think you'll be happy to know those plans.

Disclaimer I work on GAE.

You have to sign an NDA just to get the roadmap‽

Is it that volatile that they don't want to go public with their intentions? That's not really a good sign, IMO.

If I signed the NDA, would I also be happy to know the roadmap for Python 3 on GAE-Std?

That's a good question but I'm an engineer and not authorized to talk about any future plans :-)

We do monitor the public issue tracker (https://issuetracker.google.com/savedsearches/559750) and will prioritize appropriately according to vote number.

OMG! Python 3 support was brought up 10 years ago (it is 2018 now depending on your timezone) in 2008 and comments were closed in 2012 for unknown reasons...

Tack this on as one of the reasons people don't trust google cloud...

Not really unknown reasons IMO - the comments were clearly unuseful that just served to spam the people who starred the issue.

No more information from users is needed to implement it, so the only useful comments can come from Google employees who can still comment.

This is standard procedure on Google bugtrackers.

If you work on GAE can you give a timeline for: https://issuetracker.google.com/issues/65104189

for me that is a big blocker.

I've bought this to the attention of some of our engineers, and I hope to get you an update soon.

thank you really much

In the very same post where Google announced Java 8 being generally available on GAE standard [1], they also stated Java 9 support was already in the works. Of course, actual timelines are not publicly known yet, but I wouldn't bet my money they'll take another 3 years to get this ready.

[1] https://cloudplatform.googleblog.com/2017/09/Java-8-on-App-E...

The entire sandboxing model was swapped out between Java 7 and Java 8 on GAE. That's why it took so long. No such major change is needed for Java 9, which won't lag nearly so far behind.

Also, not having access to Java 8 was painful. Not being able to use lambdas or streams for that long really sucked. There's no similar pain from not having access to Java 9 yet; it's not nearly as big of a change in the language.

The thing is Java 9 will be end of live and receive no further updates after March 2018 (yes, that's three months away).

> it's not nearly as big of a change in the language

True, but there were quite dramatic changes to the JDK.

I use Clojure* on the GAE Java SDK instead and don't think about the version of Java that's running underneath. It Just Works. https://github.com/nickbauman/cljgae-template

*(Just one of many reasons not to use Java on the JVM in general)

I recently restarted fiddling with GAE after stopping in 2012 and moving everything to heroku/aws. To say I'm blown away by how far it has come is an understatement.

Within less than a day I had a prototype up and running that handled inbound requests, did some processing, offloaded the rest to background workers and returned the request. The workers asynchronously stream data to BigQuery for real-time reporting.

The only thing I found baffling is that I could not load Googles' own cloud sdk from within the GAE environment and had to "vendor" it in, doing a bunch of workarounds/patching to get it to run. That probably consumed 3 of 4 hours it took to get this running.

Load testing this thing, GAE automatically managed everything and I never saw any error responses throughout the load test with. It's amazing how little ops work is needed.

AWS lambda and kinesis firehose/s3/Athena could provide part of this, but it's far from turnkey/conclusive. GAE/GC are just so much more complete.

> [...] doing a bunch of workarounds/patching to get it to run. That probably consumed 3 of 4 hours it took to get this running.

This always happens when I try to use one of Google's APIs/SDKs. I dread using them, I feel like they're overengineered most of the time.

Unfortunately, that's not one of those over-engineering times. GAE standard environment simply does not include the needed SDK. I'm guessing they just haven't gotten to it.

The SDK works as expected once imported as the outside library and various outbound requests things are configured and patched.

I think I overstated the complexity. All I needed to do was enable SSL for outbound connections (one-liner in the yaml file) and add the requests library patch to use URLFetch service (python/GAE specific step). Searching SO and Google documentation is what took up 95% of the 3 hours I spent on this.

Yeah, poor choice of word on my part, but I feel you. This happens to me a lot with their stuff: the solution is trivial yet not obvious and it's not documented properly so you end losing a lot of time.

The main problem with the SDKs have been that they've been changing extremely fast, and breaking backwards compatibility in every single release. The Go SDK has been particularly extreme in this regard. Not simple things like new arguments being added to functions; but actually changing everything around to the point of being unrecognizable. (The Go SDK also suffers from some unfortunate googleisms such as WithFoo() functions to chain options, which don't fit well into Go's somewhat impoverished type system.)

I agree with the author that GAE is fascinating, for hosting large scale web apps. But I strongly recommend to avoid using the Java runtime on GAE. Each GAE instance has very limited memory, 128M (the prices of high memory instances are much higher). 128M is not enough for most Java web apps! Another big problem of Java apps on GAE is a general Java app needs 20 seconds to fully warm-up (considering that the 128M instance has a 600MHz CPU). GAE instances stop and start frequently. If a user visits your website and the visit is served by an instance which has not warmed-up yet, the unlucky user will wait 10s+ to get responded. Then the user experience is very bad. (GAE really provides a way to avoid cold instances serving requests, but the way is tedious to setup and often needs more instances to run. More instances mean higher cost.)

So if you would like to use GAE to host your web app, Go is most preferred. Go instances consume much less memory than Java instances (less than 1/5) and need much less time to fully warm-up (less than one second, so you don't need to handle the cold instance problems at all).

Just my personal experiences.

As someone that's been building GAE apps on Java since the runtime first launched... well, it's a mixed bag, mostly good. It works fine for basic web apps. If you have any significant traffic it's a good idea to upgrade to F2 or F4 instances; you get more throughput per-instance so it's break-even costwise.

The instance warmup time tends not to be an issue at scale, but it does mean you end up paying for more idle instances than "optimum". It's still cheaper than hiring a devops team. The cool thing about GAE is that you can build a multi-million-dollar business with a couple engineers and they can both go camping for a weekend at the same time.

Go is nice on GAE because you have near-zero instance start time. But then you must work in Go, which is a poor language for general business processing (despite its other merits). The Go runtime also lags behind the Java and Python runtimes on GAE Standard. The GAE community does not think "Go is most preferred"; actually the GAE/Go community tends to whine a bit about support. It's not perfect, but then again nothing is.

Yes, if the traffic of your web app is large and need tons of GAE instances, then the memory and warm-up problems will become much less severe. But if the traffic is not large, then the two problems are the big obstacles to save spending and happy roll deployments. One the other hand, Go is good for both low traffic and high traffic websites.

I disagree on "Go is a poor language for general business processing". The current Go runtime on GAE is very mature to build all kinds of websites.

I love Go and use it daily, but it really is inferior to other languages for general business processing.

The lack of generics, and a nice map, filter, reduce, flatten workflow cause this for me.

Sometimes I'll just use goderive then, but it still looks clunky. (No pipe or fluent API)

Haven't been working too much with Java lately, but I think the main cause for the slow startup times are the frameworks. Many frameworks such as Spring had different use case in mind and therefore different things were optimized (for example easy of packaging/deployment vs app startup times). Scanning the classpath, generating proxies etc done at the application startup.

Yes, framework libraries loading contributes much of the 20s warm-up time. However loading the libraries in the official GAE Java SDK will also occupy about 7 seconds if the request needs handle datastore even if frameworks are not used.

It's also expensive as fuck. Good for prototyping, for when you're starting out and maybe for when you are creating an app that serves very specific uses cases that are easier to address with a fully managed architecture.

But for everything else just start adding APIs and Services and see how your costs balloon out of control.

I use AWS and find that it is "cheap as fuck." The reason is that my product is very expensive per unit of compute used, so my infrastructure costs are less than 1% of my revenue. I compete on other things and had $35K revenue last year with 120GB transferred to customers and 7GB uploaded. If you have a photo storage or video sharing site you damn well better be competing on infrastructure costs and not using Amazon's premium infrastructure-in-a-box.

That's how I feel. Cloud services are great for anything that isn't losing money on each customer and then trying to make it up in volume :).

Cloud is way more expensive than other options, but I'm serving 5,000 customers for less than $100 a month, so spending more time to get that price down is definitely not the best use of my time.

Cloud is worth if you are in the range of $10-$200. Other that, there are better alternatives.

Is it? Cloud isn't apples to apples to other options because it covers both hardware and at least some if not most of your operations costs. The less magical your infrastructure, the more (very expensive) people are required to maintain it.

It really depends on your use case and requirements.

When you have a simple stack and reduced uptime requirements, getting something like 3 servers from a provider like Hetzner (https://www.hetzner.com/dedicated-rootserver/matrix-px) can give you a lote of compute power for little money.

Of course building something on top of GAE or AWS EBS / Lambda is a lot easier on the OPS side and gives you much more confidence, but at a much higher price.

I never get this, why would you use it for prototype if you will not run on it? Why are we prototyping in the cloud? What happened to localhost?

One use case would be for getting the product/market fit. Launch fast, then either fail fast or succeed and port to a cheaper service.

I think the GP comment means prototyping a product idea to a real market. Obviously individual developers will run a local version of the production systems.

Because your local computer is not where you will run your production. You absolutely are not required to develop on the cloud, but you should at least consider (and in fact this should be “must”) test you code in thr cloud before you enable the knot to ship it in production mode.

I’d argue if cloud is convenient for you and cheap as hell, no reason not to try. However, it is not cheap because you would need to setup your own cloudfoundry or kubernetes in AWS and whatnot (or the cloud provider’s native container solution), which often means renting a machine.

So that’s why most people don’t do development in the cloud. They test their “just committed to my feature git branch” latest version in the cloud by means of automatic (Jenkins etc) or by pushing to the cloud manually.

It depends on what kind of prototype it is. If you need to run a POC with a customer or two, localhost won't do.

Might be an interesting comment except we don't know what you're comparing it to. FWIW this is the opposite of my experience. To try to duplicate what GAE does in other environments, such as EC2, has been prohibitively expensive and difficult to size correctly. You can actually tune your GAE install to reduce costs by literally twisting dials. Very hard to do with "traditional" cloud and not as dynamic with container-based offerings.

Compared to like plain Digital Ocean, yeah. But you get a lot for free with App Engine.

When you run a business each man hour of work costs money. While appengine charges a premium, it saves a lot of the overhead work of running a service.

Think about it this way. When you use appengine Google has an sre making sure your application is up and running. It makes sure it auto scales up and down. Deals with zero day security updates. And gives you a release rollout procedure. Logging is hooked in as well.

Sure you can do all of that, but at most companies it's not unheard of to cost about 50-100$/hour of SWE work.

I use it for micro services running as backends for my successful niche mobile app. I run the entire thing for free and never have to monitor the services for the most part.

You have to sacrifice a lot though, like with python there are tons of libraries that are unusable because the have native code which is only allowed with the flex runtime which can never be free.

This is simply false. GAE is not expensive. Quite the contrary. Instead of putting hundreds or thousands of man-hours into managing scalable instances and scalable databases a developer instead can invest the time into the actual money-making code. The platform abstracts away most of the pain of running a scalable app.

I've been using GAE for a while now starting from when they only supported Java and Python (I think). It's my go to source when I want to create an MVP or proof of concept. I've also used it to run some sites with medium traffic.

Over the years they've introduced a whole bunch of stuff/services, simplified a bunch of things (e.g. datastore pricing is now simpler).

They've also made things more complicated (in my opinion). Years ago, downloading and using GAE was straight forward. Now they have all sorts of versions (standard, flexible, etc) and running a program is no longer as simple as before.

Their documentation is also extremely poor and they sometimes change/remove services without enough notification (switching from modules to services, changing support for openID/Federated login even though it still showed up in GAE).

At the end of the day, I would still recommend it. It just takes more effort for me to explain to new folks how to use it.

For those who are interested to know how much App Engine Standard Environment roughly will cost in real world applications here is my simple formula for it:

Average RPS * $15

So for 100 RPS for one month it costs around $1,500.

Also, you can optimize for cost by adding the following to your app.yaml:

threadsafe: true

Also Golang and Node costs less than other environments.

My two cents.

Update: Formatting.

100 average => the service has to do 1000 req/s during active business hours.

It's not much for anyone who is used to high scale system but it is a lot more than the average application can take without effort. It's gonna require quite a few cores, disks and bandwidth to achieve. Definitely not gonna run on a single cheap instance.

I'm sorry, I'm lost. What is RPS?

Requests per second

Still in beta, but also consider Firebase + Cloud Functions on GCP. Very fast to build with. And easy to upgrade to GAE or K8 containers if need be.

Cloud Functions for Firebase

https://firebase.google.com/docs/functions/

It is a fully-managed application platform. So far, I do not know a platform which comes close to GAE's full package: log management, mail delivery, scaling, memcache, image manipulation, distributed Cron jobs, load balancing, version management, task queue, search, performance analysis, cloud debugging, content delivery network - and that is not even mentioning auxiliary services that have popped up on Google's cloud in the meantime like SQL, BigQuery, file storage... the list goes on.

I think the promise was never actually realized. When first released, you didn't have to worry about load balancing instances or scaling, it was "internet scale", out of the box, dependent only on your traffic. Then they went to the per instance pricing and raised prices.

I was really disappointed no service ever arose to fill this gap; internet scale as service you could say.

They still have the autoscaling. "Internet scale" doesn't mean we can ask for more resources without paying more.

I remember reading at least one case study of someone standing up an online poll related to a sporting event that got 100k's users over a few days on GAE, really impressive at the time. You can still do that of course, but now you're dealing with load balancers and instances, a lot more admin overhead. It is/was a total walled garden, but for scale and ease of use like that, it was really worth the sacrifice. I really don't understand why everyone wants to be wrangling containers/instances nowadays.

Moving to the charge by time instead of by CPU doesn’t change the scale or the functioning of the system. They just realised that inactive apps also consumed resources.

And AWS Lambda has sort of picked up on this. Not exactly the same but very close.

I've been hosting a service on GAE since the beginning. Pretty much 100% uptime, just had to update a .yaml file twice in... a decade? Amazing service.

I've been on GAE continuously since 2008. Can confirm virtually all comments (pro/con) in this HN thread.

- Doesn’t support Python 3

Standard environment does not and it's a damn shame.

Flexible environment does not have that restriction.

But there is no free tier in flexible as far as I know.

Don't think there is, but for initial trial there is $300 credit for a year.

Free tiers are probably the least economically interesting aspect of cloud services. If you're using gae to do valuable work, you shouldn't mind paying a little bit for the service.

It's currently sitting at #1 feature request by vote count on GAE issue tracker: https://issuetracker.google.com/savedsearches/559750

This is embarrassingly a Google-wide problem, not just a GAE problem.

Stick with Java or Go, I'd say.

Good, balanced article. I'd love to see something similar for the competitors like AWS Elastic Beanstalk or the upcoming "App Engine Flexible Environment" that the author mentions (of course it'd be hard to get a "3 years in" perspective for such a new product).

App Engine Flex is newer but I wouldn't describe it as "upcoming". My company's been using it in production for a while now.

Agree. In fact, I strongly prefer the Flex environment as it doesn't require you to use any proprietary libs or services: your applications get deployed as containers, can auto-scale, and are health checked.

This has always been one of the benefits of Heroku to me: I don't have to architect my application for a single vendor's environment. If I use a hosted Postgres backend, then even more so.

What Google should consider doing is making App Engine "classic" services like Memcached, etc. available to any service running across GCP. Flex is fairly different from classic, but I think there's some confusion generated from the "App Engine" name and the baggage (good & bad) it has gathered over the years.

> What Google should consider doing is making App Engine "classic" services like Memcached, etc. available to any service running across GCP.

Already being done. First was Datastore, now Cloud Tasks is in Alpha. Expect to see others (Cron, Cache, etc) come as well.

But there is still no way to use ndb from outside App Engine standard, right?

> But there is still no way to use ndb from outside App Engine standard, right?

Shameless plug, but for Go, there is an unofficial third-party (Chromium team) datastore package that feature near-seamless AppEngine standard/flex datastore support: https://chromium.googlesource.com/infra/luci/gae/+/master

It currently couples to any hosted memcached service, but should be forward-compatible with AppEngine if/when they release a Flex-accessible cloud version of their hosted memcache.

"luci/gae" also features a fully-compliant in-memory datastore mock for 1000x+ faster datastore testing and uses a memcache implementation based on "qedus/nds" which fixes several consistency issues present in "ndb".

> What Google should consider doing is making App Engine "classic" services like Memcached, etc. available to any service running across GCP.

Many AppEngine standard services are accessible using the "cloud" versions of APIs/endpoints. You may have to do some more heavy lifting, although on Flex you get GCE self-authentication for free, and most "cloud" API packages know how to recognize and utilize this.

Memcache is apparently on the list to receive a cloud API, although it's been in the "pre-alpha" state for over a year now. See: https://cloud.google.com/appengine/docs/flexible/java/upgrad...

At the end of the article (and in the linked article), the author says that Flex is too immature for production use, but also says that GAE Standard is practically on autopilot and not recommended for new projects. So it seems that the author doesn't recommend starting new production projects on GAE at all. Has this been others' experience?

Given Google's record with other products, I'm particularly worried Google might discontinue or stop improving GAE. Does Google provide any offical reassurance that GAE is a high-priority product that will be quickly improved and not put on autopilot? If so, do their promises seem to match the reality observed by the author for GAE standard?

quote from the end of the article: " It feels like they only invest the bare minimum anymore. Actually, I have had this feeling for the last two years...It is infuriating if there are known issues but they are not fixed. It is depressing to receive so little information on where the platform is heading. You feel trapped. ... the 'old' App Engine is on its way out. I do not think it is a good idea to start new projects on it anymore. If App Engine Flexible Environment on the other hand can actually fix its predecessor's major issues, it might become a very intriguing platform to develop apps on. "

I built my first startup (Socialwok) in 2008 on GAE Java it had just launch then. Since then I've totally been sold on the Google Cloud and building products with serverless tech like GAE.

Even today surprisingly few people know about it. So I finally authored and published a book on building products using the Google Cloud this year. (Free to read on the site)

http://www.howtobuildthefuture.com/

I tried to use App Engine flex for my application, but it seems to only support the simplest of apps. `gcloud app deploy` would always time out after about 10 mins with DEADLINE_EXCEEDED due to the Docker build taking too long. It was not well documented, but I figured out I could work around that by defining a custom cloudbuild.yaml with my own "timeout" parameter and submit remote builds using that (`gcloud container builds submit --config cloudbuild.yaml .`), then deploy that specific image (`gcloud app deploy --image`).

Then I found out that I couldn't run my own sidecar container (nginx reverse proxy), and also that Cloud CDN doesn't support App Engine Flex yet. Those were dealbreakers, so I switched to GKE. So far things are working well except a Kubernetes issue not terminating Job/CronJob sidecars correctly which gets tangled up with Google forcing you to run a "magic" proxy sidecar container to access your Cloud SQL instance(s).

what are you doing that takes over 10 minutes that can't be broken up into a series of retryable (and likely parallelizable) steps that a worksflow or queue system wouldn't work, be more resilient, scalable?

`docker build` is not parallelizable by its very nature of each layer depending on the previous layer

so you're running a build server?

No. App Engine Flex uses containers internally (the "flex" meaning supporting any type of app rather than the traditional built-in App Engine environments of Ruby, Python, etc.).

The appeal of App Engine is simply being able to type `gcloud app deploy`, which tars up your local source code, builds a Docker image from it, then does a rolling deploy of the new image to replace your old app containers - all from that one command, no complicated build system needed on your part (i.e. Google Cloud does it all for you).

My point was the moment you stray from the App Engine happy path (`gcloud app deploy` fails for obtuse reasons), you're out in the weeds. That plus the fact that App Engine has some weird missing integrations (e.g. Cloud CDN) often makes it easier to just jump to GKE in my opinion.

Okay, I think I totally missed the point you were complaining about. In my day to day I see a lot of people doing large tasks in things like AWS lambda (5 minute timeout) that really should be decomposed into workflows, decoupled with SQS, done with a batch processor or the like to make them more resilient, debuggable, and parallelizable.

Sounds like you're doing something totally different and the heroku-ness is failing you.

No worries. If we were talking about Lambda I could air grievances there too - unpredictable cold start latency, quarterly major outages, random periods of increased latency w/ no visibility as to why, etc. ;) (unless things've changed a lot in the last 6 months)

I've generally had a lot of trouble with GAE. Debugging is really hard and things seem to fail for weird reasons. The use case I have, with a front end and a static backend, has been surprisingly complicated. I recently shut my app down because it wasn't worth the time to figure out how to change my app for the Dec 15th upgrade.

Believe this article was posted about 3-5 times previously on HN in 2017, and never gained traction. I think perhaps that "cloud" and "serverless" have become even more of a thing throughout 2017. Even since March (was in the job market in right after March), I noticed how positions in tech really seemed to be coalescing around "cloud engineers," and "SRE's/Devops" and the like... people on LinkedIn getting 5 AWS certs in a week (lots of this), stuff like that; I really don't even think we are at peak cloud/serverless usage/hype right now. Believe it will continue to grow in 2018, as that other article on HN right now (about serverless in 2018) also proposes.

I've seen that most companies are still coming around to containerization as the future of their infrastructure. Serverless isn't even on the roadmap, so we're definitely far from peak hype.

I think there is much to show how to leverage container in development. I personally still struggling to get my mindset fix on using containers than running locally. It gets me every time and this makes me feel sad as if I am not in touch with the trend. If people were so stereotype about age and workers, which is not really true as my older coworkers are just as competent and as curious and as willing to adopt new technologies, now I find myself in that stereotype fallacy. But I feel helpless. Anyone?

This largely matches my own experience in using GAE. I might just add that since I was using GAE for personal projects, it is very easy to accidentally use a lot of money with the ease to scale up and handle more traffic. There is a way to tell GAE to have a budget limit though.

And yes, although this is essentially vendor lock-in, the access to the many services provided is really really a timesaver that boosts productivity tremendously. I just wonder whether Google is spending much time on it, given how slow they support newer versions of languages.

For me AWS is still a king of serverless. In particular, recent AWS step functions really help with connecting microservices (and other tasks) for more complex flows, and does so in a nice visual manner: https://aws.amazon.com/step-functions/

p.s. it is pricey, but probably this will improve soon.

The topic of this article is Google App Engine (GAE), which is a PaaS. Comparing GAE to AWS step functions (which is some wrapping around AWS Lambda) is moot since they are different categories of products solving different problems.

For PaaS products, GAE is comparable to AWS Beanstalk (or Heroku, or CloudFoundry, etc).

For "serverless" products * , AWS Lambda/Step Functions are comparable to Google Cloud Functions.

  * Serverless in the product sense rather than the literal sense.

> The topic of this article is Google App Engine (GAE), which is a PaaS.

PaaS & FaaS are quite related; so it is not unreasonable to discuss in this threat. e.g. see informative comments by @indigodaddy on the same threat.

p.s. article also talks about other non-PaaS topics e.g. Data Store, Memchase, BigQuery, etc.

> Comparing GAE to AWS step functions (which is some wrapping around AWS Lambda) is moot since they are different categories of products solving different problems.

Many of the problems that they solve are the same; but they do so in a different manner.

AWS Step Functions is a lot more than "wrapping around Lambda"

> For "serverless" products * , AWS Lambda/Step Functions are comparable to Google Cloud Functions.

AWS Step Functions has no comparable service on Google Cloud

I understand the the benefits of using a fully managed platform like GAE, but wonder if it would be the right choice for most scenarios. Personally, I would prototype with GAE, but go into production with GKE, under the impression that the application would be a little more decoupled from the platform.

When is GAE & Cloud SQL coming to Southeast region?

What are does he mean by using mnemonic as key?

Does GAE support websockets?

No. You would need to use a third-party service or build one on a VM in GCE. You can deploy a queue with websocket support to save some effort.

GAE -> easy to get in...very hard to get out! and expensive...and risky...it's not worth it!

how about other PaaS?

It's actually not that hard to get out of, unless you rely on their scaling - in which case any system is hard to get out of.

We did some contingency planning a while back, which included moving a low volume service to a LAPP (Linux/Apache/Python/PostgreSQL) stack to see how difficult is was. The biggest job was re-writing the NDB API calls, but it was not difficult.

For me, knowing the world's best sysadmins are looking after our services is worth a lot. I've heard a couple of talks by Google's system relability engineers, and they are fanatical. Visible evidence of this is the brutally honest post mortem they produce every time there is a significant outage, including the vitally important "what we're going to do to stop this ever happening again" section. This focus works - GAE is way more reliable than AWS or Azure.

So YMMV, but GAE is well worth it for us.

I have a Java Application on it but I have never found a straight forward way of exporting the data from the Datastore. Any ideas?

You are being down-voted because the whole point of almost all GAE apps is to return data from the datastore, albeit usually in nicely formatted HTML for browsers. You simply need to provide a handler that returns your data in whatever chunks or format you want.

It's not the scalling that locks you on GAE. It's about the proprietary services. I have 32 micro services, all depending by datastore, task queues etc. The only contigency plan that someone could implement is to do not use GAE in the first place. Almost 70% of the app code is really just about different ways to index/store and return data. Rewriting all the datastore ops is just like rewriting the whole application. With GAE you get stuck and there is little you can do! I had to choose between moving to their "flex" version or just dumping all the code and start over. Starting over is not an option so I'm still on GAE paying the flex prices. Now I pay regardless if the microservices are running or not. If it would be that simple to just move it all to an open source stack you can be sure I would do that.

For a platform to provide scaling, it pretty much has to provide proprietary services if those services are to scale as well. AWS proves this point, with their proprietary elastic block store, elasticache, SQS, SMS, etc). I don't know Azure at all, but I'd be very surprised if it's scalable services weren't proprietary too.

So I hold that it is the scaling that locks you into GAE, but only to the extent that you desire scaling. Scaling gives you redundancy and reliability too, don't forget.

> GAE -> easy to get in...very hard to get out!

If your codebase is really 70% datastore API calls, I'd strongly suggest writing your own wrapper so you can change datastore by updating a few primitives. But in any case, GAE is no harder to get out of than any other scalable platform.

> and expensive...

We run three services with millions of users, for about 250 USD per month. Given a single dedicated server starts at $75 USD per month, and that we'd need at least four servers for redundancy and scaling, and that we'd need to hire a system architect/administrator for say ten hours a month to maintain them, I think GAE is excellent value.

> and risky...

You don't say why you think GAE is risky. In terms of uptime, our experience is that it is an order of magnitude more reliable than AWS or Azure. The other risk people sometimes suggest is that Google will discontinue the platform, but Google seems strongly committed to Appengine and Appengine has a three year deprecation policy for any part of the service.

> it's not worth it

We obviously disagree on this point. I would accept "it's not worth it if you will never need scaling and are happy to do your own system admin for free".

I can run my Go GAE app elsewhere without modifying anything.

That's impossible

Still weird that google doesn't offer a search service.. (there is one but doesnt look good)

GAE certainly does have a search service: https://cloud.google.com/appengine/docs/standard/python/sear...

Very limited, like no cross-index-search etc...

What do you mean by cross index search?

Search on 2 indexes and get back the merged results. Like solr/elasticsearch do search on index with 1+ shards.

The future of GAE is K8S. GAE should be an app on K8S.

Google App Engine (GAE) was cool because it was for free. Then, Google started charging (really expensive), i got enough with it and i quit.

GAE does still have a free tier. Also, being able to run as much stuff as you want in the cloud for free does not seem like a reasonable expectation.

The previous poster may be confused by the fact that App Engine Flex does not have a free tier. For the record, here are the Standard Edition free tier quotas: https://cloud.google.com/free/docs/always-free-usage-limits#...

And you can trivially ensure you never exceed them simply by setting a $0 daily budget. (Although I recommend setting a low but non-zero cap instead, so your app doesn't go down if there's a legit but unexpected traffic surge.)

Disclaimer: I work at GCP.

App Engine was free before it forced you to enter a valid card number to be able to use the service.

It did? I remember using it as a cheap solution for serving static files, without ever entering a CC number (as I have no CC anyway)

Yes, the change was made in 2017.

well actually I do not have a cc for my GAE project. Basically I'm on the free version. But I guess you need a CC/bank account to register for Google Cloud and since GAE now lives inside GCloud you need one to register, but after that you can basically "remove"/disable it. And then you never need to set a budget.

I was an existing customer. Google sent me a notification to request a card and warned that all applications would be shut down if I don't register one.

I didn't register a card and all applications have been shut down. I will not register a card.

Basically, GAE cannot be used anymore for amateur, high school and student projects.

Interesting, I also haven't registered a card with Google cloud, but mine are still working

That said, I had once linked a card from my uncle with the private Google Wallet to buy a Nexus 7.

And yes, the CC requirements are insane. Every professional service supports SEPA transfers, except Google. It basically is an extra 30-60€ a year cost just to use Google services, or to develop for Google Play. 30€ CC cost plus 25$ registration fee. (CCs are basically unused in Germany, where I live).

Google Cloud actually does support SEPA.

Reply on news.ycombinator.com