<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>spankalee</author><text>You&amp;#x27;re outlining all the reasons why Cloud Run is the successor to App Engine.&lt;p&gt;App Engine was the very first PaaS,  came out before Docker, and did things very uniquely in order to try to only allow scalable apps. App Engine standard has to explicitly create special environments for each of their runtimes, and that&amp;#x27;s slow and expensive. Services like Datastore and Memcache were tightly coupled.&lt;p&gt;Cloud Run fixes all that. It&amp;#x27;s just a Docker container that listens on the PORT env variable. Use whatever runtime you want. Run the same container locally, or on another cloud provider. The other services like Firestore or Memorystore (Redis) are truly optional and external.&lt;p&gt;Cloud Run is what lets you avoid single-vendor lock in, but still get from 0 scaling.</text><parent_chain><item><author>alasdair_</author><text>I wont use this for the simple reason that I bought into the Google Appengine stack in the past and it really bit me for several reasons:&lt;p&gt;They force-upgraded the java version. The problem was their their own libraries didn’t work with the new version and we had to rewrite a ton of code.&lt;p&gt;It ended up being insanely expensive at scale.&lt;p&gt;We were totally locked-in to their system and the way it did things. This would be fine but they would also deprecate certain things we relied upon fairly regularly so there was regular churn to keep the system running.&lt;p&gt;Support was extremely weak for some parts of the system. Docs for java were outdated compared with the python docs.&lt;p&gt;Support (that we paid for) literally said to us “oh... you’re still using appengine?”&lt;p&gt;Finally, they can jack up the pricing at any time and there really isn’t anything you can do - you can’t switch to an alternative appengine provider.&lt;p&gt;Certain pages in the management console were completely broken due to a js error (on any browser). In order to Use them i had to manually patch the javascript. Six months after reporting it several times and it was still broken.&lt;p&gt;Oh, and when we got featured on a bunch of news sites, our “scalable” site hit the billing threshold and stopped working. No problem, just update the threshold, right? Except it takes twenty four hours (!) for the billing stats to actually update. So were were down on the one day that “unlimited scaling” actually mattered to us.&lt;p&gt;I’m never again choosing a single-vendor lock-in solution. Especially since it’s not limited to appengine - Google once raised the fees for the maps API from thousands a year to eight figures (seriously) a year with barely any notice.</text></item></parent_chain></comment><story><title>Deploy your side-projects at scale for basically nothing – Google Cloud Run</title><url>https://alexolivier.me/posts/deploy-container-stateless-cheap-google-cloud-run-serverless</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jccooper</author><text>App Engine is indeed problematic. I have an important app on it and various forced upgrades gave me a big headache. It&amp;#x27;s been stable for several years now, so I&amp;#x27;m okay with it, but as much as I like the idea, and indeed the execution, of App Engine I&amp;#x27;m not going to do anything new on it because of the lock-in factors.&lt;p&gt;Cloud Run, however, uses standard containers, so as long as you don&amp;#x27;t use Google proprietary stuff on the backend it&amp;#x27;s relatively easy to move. As the article mentions, it&amp;#x27;s useful for low-traffic projects, and if they pick up you can move them to full-time instances.</text><parent_chain><item><author>alasdair_</author><text>I wont use this for the simple reason that I bought into the Google Appengine stack in the past and it really bit me for several reasons:&lt;p&gt;They force-upgraded the java version. The problem was their their own libraries didn’t work with the new version and we had to rewrite a ton of code.&lt;p&gt;It ended up being insanely expensive at scale.&lt;p&gt;We were totally locked-in to their system and the way it did things. This would be fine but they would also deprecate certain things we relied upon fairly regularly so there was regular churn to keep the system running.&lt;p&gt;Support was extremely weak for some parts of the system. Docs for java were outdated compared with the python docs.&lt;p&gt;Support (that we paid for) literally said to us “oh... you’re still using appengine?”&lt;p&gt;Finally, they can jack up the pricing at any time and there really isn’t anything you can do - you can’t switch to an alternative appengine provider.&lt;p&gt;Certain pages in the management console were completely broken due to a js error (on any browser). In order to Use them i had to manually patch the javascript. Six months after reporting it several times and it was still broken.&lt;p&gt;Oh, and when we got featured on a bunch of news sites, our “scalable” site hit the billing threshold and stopped working. No problem, just update the threshold, right? Except it takes twenty four hours (!) for the billing stats to actually update. So were were down on the one day that “unlimited scaling” actually mattered to us.&lt;p&gt;I’m never again choosing a single-vendor lock-in solution. Especially since it’s not limited to appengine - Google once raised the fees for the maps API from thousands a year to eight figures (seriously) a year with barely any notice.</text></item></parent_chain></comment><story><title>Deploy your side-projects at scale for basically nothing – Google Cloud Run</title><url>https://alexolivier.me/posts/deploy-container-stateless-cheap-google-cloud-run-serverless</url></story>