[HN Gopher] Deploy your side-projects at scale for basically not...
___________________________________________________________________
Deploy your side-projects at scale for basically nothing - Google
Cloud Run
Author : alex-olivier
Score : 307 points
Date : 2020-01-12 17:16 UTC (5 hours ago)
(HTM) web link (alexolivier.me)
(TXT) w3m dump (alexolivier.me)
| jjeaff wrote:
| This article fails to mention the issue of needing a database. It
| doesn't matter how seamlessly your application can scale if your
| data backend won't scale with it.
|
| They mention Cloud SQL, which is of course instance based and
| would run into scaling issues if your app got suddenly hammered.
| Not to mention, the cost isn't $0 if your app gets 0 traffic, you
| are going to have to pay to keep that running around the clock.
|
| I realize some applications are very heavy on the app side and
| light on needing to hit the DB, but in my experience, that isn't
| very common.
| steelaz wrote:
| AWS has Aurora Serverless
| (https://aws.amazon.com/rds/aurora/serverless/) for that
| purpose with MySQL and Postgres compatible engines. But I
| haven't heard anyone using it for side projects yet.
| kevinsundar wrote:
| They also have RDS Proxy (https://aws.amazon.com/rds/proxy/)
| that lets you pool connections from tons of lambda instances
| in order not to overwhelm your DB when scaling up.
| ec109685 wrote:
| I wonder where the threshold is that the proxy is
| beneficial. MySQL is actually really good at handling new
| connections.
| [deleted]
| navd wrote:
| Cloud run is what zeit now was before it moved to v2.
| https://zeit.co/
| ignoramous wrote:
| What does it run on today? Or, is it multi-cloud now?
| fareesh wrote:
| Might be a mindset thing but if my side project needed scale I
| would not think of it as a side project.
| dkarras wrote:
| Probably a mindset thing. Side projects are lottery tickets in
| my mind. Implementation of an interesting idea hoping for the
| remote chance that it might get actual traction (and become
| more than a side project) - at that point it needs scale and it
| needs to scale fast while people are talking about it. If you
| take another week rearchitecting your backend while your site
| is down, you lost your chance. So you shouldn't probably expect
| huge traffic, but make it ready for the traffic or there is no
| point if it will fail the moment it starts to get traction.
|
| My 3 side projects got reddit frontpaged (also here) and I got
| better at handling it. Fortunately I always had scale in mind
| (at peak got thousands of requests per second) but the first
| time was not a pleasant experience because I would have to pay
| more than I could if that kept going on. Fortunately I found a
| solution while keeping my site online and over the time the
| project paid me very handsomely. If I didn't plan ahead, those
| would be dead in the water.
| Havoc wrote:
| Interesting. I've been looking looking at options too & opted for
| essentially the opposite: Get a big(ish) VPS and stack everything
| on top of each other with docker behind a nginx reverse proxy.
|
| So far so good. Managed to host gitlab, prometheus, grafana and
| ghost working this weekend, which I'm pretty chuffed about.
|
| Not as clean as OP's, but the intention was learning, so
| sacrifices on convenience are acceptable.
| dennisy wrote:
| I am using this and it is a much better development and
| deployment workflow when compared to cloud functions. The only
| thing it lacks is some bigger RAM for ML workloads.
| scanr wrote:
| He mentions CloudSQL for storage. Anyone know if it's also on-
| demand?
| minimaxir wrote:
| No, you need a persistent instance unfortunately (min $7/mo):
| https://cloud.google.com/sql/pricing
| Iwan-Zotow wrote:
| Did he publish any IP of his project(s)?
|
| Lets flood it and have him pay the bill
| inscrutable wrote:
| started using this... pretty awesome vs the wall of yaml it
| replaces. Not suitable for all workloads (max 1cpu/2 gigs ram, 4
| minute max pod startup time, can't do background work when not
| serving a request). But it replaces cert-manager, ingress-nginx,
| oauth2-proxy, k8s service, k8s deployment, k8s secret, k8s
| configmap, k8s hpa, k8s pdb, helm charts and cluster management.
| yegle wrote:
| Disclaimer: I work closely on Cloud Run as an SRE.
|
| IF you want, you can still have it by use "Cloud Run for
| Anthos", and deploy your container to your GKE cluster with the
| same Knative API. This allows you to have more control on
| memory/CPU etc.
| inscrutable wrote:
| Thanks, although unfortunately I'm not in the price bracket
| for Anthos (starts at 120k/year or so I believe).
| yegle wrote:
| I believe there's no requirement if you just want to use
| Anthos on GKE (I could be wrong though, Anthos is
| relatively new).
|
| Alternatively, if what you really want is the ease to
| manage and deploy containers and automatically scale
| according to traffic, my understanding is you can always
| use the open source Knative project with your Kubenetes
| cluster. This provide you the exact same API supported by
| Cloud Run and makes it very easy to migrate from managed
| Cloud Run to on-prem K8s cluster (or K8s clusters from
| other Cloud vendors).
| inscrutable wrote:
| thanks, I hope you're right, GCP doesn't appear to be
| clear on this point, seems to be offering free trial up
| to May 2020 and then who know. I'm aware of the ability
| to set it up from open source which is a great fallback!
| yegle wrote:
| Yes that's unnecessarily complicated due to the naming. I
| can't find anything on the Cloud Run add-on for GKE by
| searching "GKE Anthos".
|
| This doc suggest you just need to enable Cloud Run add-on
| on your GKE cluster to use it:
| https://cloud.google.com/run/docs/gke/setup
| GordonS wrote:
| I tried out Azure Container Instances a while back, and the
| startup times were also what killed it for me - they were all
| over the shop. It was 1-2 years ago, so I don't recall exactly
| and things may well have improved now, but I seem to recall
| they ranged from 1-5m.
| aamederen wrote:
| AFAIK, PaaS solutions like heroku have a similar way of working,
| at least for side-projects. Here, you deploy a container and
| Google runs it somewhere and Heroku containerizes your
| application every time you push it. Similar to here, Heroku's
| free hobby containers also go to sleep in ~30min inactivity.
| franciscop wrote:
| Heroku's "hobby" is $7/m while "free" is $0/m. There's no "free
| hobby":
|
| https://www.heroku.com/pricing
| jsjohnst wrote:
| As an illustrative of pricing:
|
| If your deployment can run in 256MB of RAM w/ 1 vCPU, handles an
| average request in under 250ms, transfers 200kb or less per
| request on average, and you get 2 requests/minute on average to
| your site:
|
| The cost is around $2/month USD, which I feel is a more likely
| scenario for a side project vs the "pennies a month" the OP
| claims.
| minimaxir wrote:
| "2 requests/minute on average to your site" is a bad assumption
| for a relatively unpopular side project.
|
| More importantly, with those hypothetical numbers, you'd stay
| _well_ within the free tier for compute.
| chispamed wrote:
| A request is not a visit. Each visit might have a up to a
| hundred requests (or even more when showing live data and
| caching a PWA on first visit for example). That would
| translate to one user per hour or two which even unpopular
| side projects can get. But you're right about the free tier
| of course.
| minimaxir wrote:
| Fair, although if the app is architected that way Cloud Run
| might not be the best option.
| modzu wrote:
| people seem to forget the usage accrued via the devs
| themselves..
| chispamed wrote:
| I have gone serverless for a Vue frontend app I deliver with
| Cloudflare Workers Sites and with a DigitalOcean S3 Space
| serving all images. However I'm still very reluctant to use
| Google Cloud Computing or any similar Azure/AWS solutions for
| its backend because it just seems pretty expensive to me.
|
| I can get a vServer with 48 Gb RAM, 10 vCPUs and a 800 SSD with
| a 1000 Mbit/s connection and unlimited traffic for 20EUR a
| month and run my MariaDB and Redis database on the same machine
| as my other containers.
|
| Even if the vServer only runs at 25% on average the same
| performance with GC would cost me 150EUR for the CPU, 77EUR for
| the RAM (with free tier already included) and that is still not
| accounting for the traffic. And I would have to host the
| MariaDB instance elsewhere (which adds latency). And Google
| Cloud has very few data centers in Europe so it'd not even be
| near my main market.
|
| In this case Google Cloud Run (with worse performance) would
| cost me like 15x more than running a vServer. That's not a
| price I'm willing to pay to go completely serverless or to
| avoid downtime at all costs. Or am I missing something?
| sweeneyrod wrote:
| > I can get a vServer with 48 Gb RAM, 10 vCPUs and a 800 SSD
| with a 1000 Mbit/s connection and unlimited traffic for 20EUR
| a month and run my MariaDB and Redis database on the same
| machine as my other containers.
|
| Where are you getting all that at that price?!
| breakingcups wrote:
| Where can you find a server like that for EUR20/month?
| datashow wrote:
| What will the bill look like if your website suddenly hit a big
| traffic (e.g. someone post your site on HN)?
| sansnomme wrote:
| It goes up of course. Nothing's for free. Don't expect
| DigitalOcean level of pricing, the premise of cloud is on
| efficiency and scale, not necessarily being the cheapest raw
| computing provider when compared to traditional hosting. In
| other words it increases the elasticity of computation, but the
| price per unit of computation goes up. (Of course there are
| cost-savings like ops, security, uptime etc. But if you are
| talking about one-off side projects or something ML-related
| then the raw compute/bandwidth costs far outweighs everything
| else.) For PaaS the free tier is subsidized by your enterprise
| and other paying customers.
| capableweb wrote:
| > It goes up of course. Nothing's for free.
|
| Not sure why you write "of course" and "nothing's for free".
| If you use dedicated hosting with something like Hetzner,
| "suddenly hit a big traffic" doesn't automatically mean more
| costs for you. The website might get slower, or even crash,
| but your pricing will still be the same as it was before.
| [deleted]
| ignoramous wrote:
| https://scaleway.com prices their base compute _very cheap_
| [0]. They have got DCs in AMS and CDG, but unfortunately, I
| 've not got to use them since their DCs are a bit far from
| customers.
|
| [0] EUR2.99 for 2vCPU, 2GB RAM, 200Mbits/s bandwidth.
| tuesday20 wrote:
| 75GB object storage free??? Am I reading this correctly
| or am I stupid?
| PhilippGille wrote:
| Outgoing traffic counts as well. So for example 5 GB
| storage + 70 GB outgoing traffic and then you start
| paying.
|
| See section "Traffic" on
| https://www.scaleway.com/en/object-storage/
| [deleted]
| [deleted]
| [deleted]
| alex-olivier wrote:
| My blog is hosted statically on Netlify rather than a Cloud Run
| deployment. Use the best tool for the job!
| ealexhudson wrote:
| This is exactly the service that Azure needs and doesn't seem to
| have: while there is a consumption plan for functions, that's
| about it, and App Service is incredibly expensive for what you
| get.
| iamEAP wrote:
| As @GordonS mentions, Azure Container Instances is about as
| close as you'll get with Azure, but it's only close on ease-of-
| use: rather different from a deployment/scaling characteristics
| POV.
|
| I'm generally very underwhelmed by Azure offerings, but ACI is
| one of the few that actually lives up to what is advertised.
| GordonS wrote:
| Have you seen Azure Container Instances (I just posted another
| comment about it just now, before I saw your comment).
|
| An aside, but I totally agree that App Service is way too
| expensive for the piffling amount of CPU/RAM they provide, even
| though I acknowledge the platform side of the offering is
| _excellent_.
| z023bs wrote:
| this is misleading, as cost curves are usually exponential for
| these types of managed services
| alex-olivier wrote:
| Definitely something I look out for, but the advantage over
| something like Cloud Functions, which would be an alternative,
| is that a Cloud Run service handles multiple requests per
| instance so it isn't 1:1 with request rate.
| CraftThatBlock wrote:
| Cloud Functions isn't 1:1 IIRC, once a Function is booted it
| keeps serving more requests once warm.
| crazygringo wrote:
| How so?
|
| I don't understand what would make it exponential as opposed to
| merely linear with traffic.
|
| There's nothing in their pricing documentation to suggest this.
| jjeaff wrote:
| It's not. But the cost difference between servers and
| serverless is maybe exponential. As traffic gets really high,
| serverless is going to be extremely expensive compared to a
| dedicated box.
| moksly wrote:
| The thing I really want out of these services is the ability to
| set a payment cap. It's probably never going to be an issue, but
| I have anxiety, and I can't sleep easily knowing that if I fuck
| up, if someone sinister abuses my application or whatever I may
| be stuck with a giant bill.
| jskrablin wrote:
| Set budget alerts. And check what's going on if they start
| going off.
|
| Or think again if you really need 'infinitely scalable bla
| blah' for personal project on a small budget.
| vineyardmike wrote:
| Real answer here.
| cobookman wrote:
| aws lightsale and digital ocean are great alternatives for
| personal projects
| yjftsjthsd-h wrote:
| I do not want the failure mode to be the expensive case.
| spookthesunset wrote:
| A "cap" feature isn't as easy to implement as you'd think. What
| happens when you hit the cap? Does it start shutting down
| instances? If yes, which ones and in what order? And don't say
| "I don't care" because you do care--you are allowing your
| provider to basically cause an outage in your service.
|
| If you do allow some kind of ordered shutdown of service, what
| is the UX going to look like? What is the API going to look
| like?
|
| Having a cap is not an easy feature to design or implement. And
| on a backlog, it is going to be a "multi quarter, low impact"
| item--meaning it will never get built.
| arama471 wrote:
| Why not allow people to set a cap that disables everything
| set to that billing method once it's been reached? That seems
| to be the use case that people are saying is missing from
| cloud offerings.
| spookthesunset wrote:
| Yeah after I posted I realized that once you hit your cap,
| that's it you are done.
|
| Still, I bet there is a lot of companies that might be more
| upset with the provider shutting everything down even if
| they had set up a cap.
| Red_Leaves_Flyy wrote:
| I imagine most of those companies can afford to have some
| overages built into their caps. They should also be able
| to afford the developer time to create fallback behavior,
| and graceful degradation of services.
| Thaxll wrote:
| It's pretty complicated to do that on every services, imagine
| for any service they would have to call an API to get the $$
| remaining , compute before scaling / creation if you have
| enough ect ...
| patentatt wrote:
| If you wanted to be that precise, sure. But something like an
| hourly 'calculate what I owe' and compare it to a cap is not
| a big stretch of the imagination, and would suffice for many
| use cases.
| Red_Leaves_Flyy wrote:
| A ml app could scale massively in an hour.
| blhack wrote:
| It seems absolutely within amazon's technical ability to allow
| you to prepay for usage, and then evaluate your use on a per-
| hour basis.
|
| I have a side project that uses AWS at the moment, and while
| stuff like serverless RDS instances are really cool, it scares
| me that somehow amazon is going to have a bug which empties my
| checking account. I've read as much of the documentation as I
| can find and have done everything I seem to be able to to
| prevent this from happening according to AWSs documentation,
| but it sill worries me.
|
| In fact here is a banking feature I'd love to see: per merchant
| daily spending limits. I would love to be able to tell my bank
| that amazon is allowed access to up to $20/day or something of
| money until they get rate limited and I have to intervene.
|
| Uh oh I better stop before I start advocating for the
| blockchain, haha
| thorntonedgar wrote:
| Checkout privacy.com you can set merchant daily, monthly or
| yearly spending limits.
| sdan wrote:
| Google cloud doesn't allow those cards.
| eeZah7Ux wrote:
| It's very ironical to see the word "privacy" in a thread
| about "serverless" stuff.
| danenania wrote:
| I believe you could accomplish this with Brex using virtual
| cards and per-card spending limits.
| wickoff wrote:
| In Europe revolut has virtual cards with monthly spending
| limits. Cash App must have a similar feature in the US.
| dannyw wrote:
| Then don't get infinitely scaling services and get a Vultr
| instance, where your costs are fixed.
| aamederen wrote:
| Here's a story about why you are right to be anxious:
| https://hackernoon.com/how-we-spent-30k-usd-in-firebase-in-l...
| StillBored wrote:
| These stories are everywhere. A couple months ago, it hit an
| associate of mine pretty hard, he moved a small python
| monitoring and statistics application off a laptop in the
| office to AWS. A couple weeks later he came back and
| discovered that it had burned up a few thousand $'s in
| storage and transfer fees for what normally was a couple
| hundred MBs of data a day being passed around and a some
| database updates.
|
| Since it wasn't really worth debugging what went "wrong" it
| got chalked up as a learning experience and moved back to the
| laptop where its happily running. If it dies/whatever its no
| big deal, just a git clone;./runme; and it rebuilds the whole
| database and creates another web facing interface.
|
| The IaaS guys are masters of marketing. They have convinced
| everyone that their offerings are less expensive and more
| reliable, which repeatedly is proven to be false in all but
| the most dynamic of situations. In this cases its saving
| $7.99 a month over a unlimited site shared hosting
| godaddy/whatever plan. Just in case it might need to scale a
| lot, in which case your going to be paying hundreds if not
| thousands in surge pricing.
|
| No thanks...
| tnolet wrote:
| Not sure what happened to your associate but this sounds
| way, way out there. I run a fairly resource intensive SaaS
| on AWS (lots of background jobs generating data) and we
| barely go over $600 a month.
|
| People should not be scared of by these anecdotes, however
| true they may be. It's perfectly possible to run a very
| cost effective business on AWS.
| C14L wrote:
| That's great. But you are always just one unfortunate bug
| or mis-configuration away from having it happen.
|
| Sure, to most people it will never happen. But the risk
| is always there. Reminds me of
| https://en.wikipedia.org/wiki/Survivorship_bias
| Mirioron wrote:
| It's possible to write bug-free code, but would you bet
| your financial future on your ability to write bug-free
| code?
| floatingatoll wrote:
| This was discussed on HN (237 comments):
| https://news.ycombinator.com/item?id=17661391
| WrtCdEvrydy wrote:
| That's not a bug... that's a 'feature'.
|
| Interestingly, AWS will not cut you off for non-payment (we had
| an issue with finance and were 250k in the red by the time we
| got the first 'Is there any issues over there?' email)
| yegle wrote:
| If you have a payment agreement, GCP won't cut you off
| provide your account is in good behavior in the past.
|
| If your only payment method is credit card, IMHO allowing a
| past due account to continue generating cost is a very risky
| move and an easy target of abusing (imaging stolen credit
| card etc).
|
| Disclaimer: I work for Google Cloud as SRE and have first
| hand experience dealing with past due account (it was highly
| manual and not automated).
| oneshot908 wrote:
| And even as an employee, if you tell them over and over again
| that customers keep asking for that feature, they disagree
| with you over and over again.
| akudha wrote:
| This sounds like a short term 'thinking'. If there are a few
| stories on the internet (and there are some in this very
| thread) about developers getting burned by this 'feature', it
| would turn off a lot of potential users in the future. It
| would make sense to be transparent and give tools to strictly
| control usage/billing - both in terms of trust and money.
| [deleted]
| Red_Leaves_Flyy wrote:
| It is. I'm using free there to build and host my projects.
| If/when I exceed the free tier I'm not making a billing
| account unless I can set a max bill. I'll sooner rewrite
| everything to run on bare metal that has a fixed monthly
| cost.
| WrtCdEvrydy wrote:
| I pay my $5 for linode (expanded swap to 2GB, it's SSD
| backed) and just run Caprover... I'd rather not deal with
| AWS's billing (even their billing dashboards are delayed
| by 24 hours)
| spyspy wrote:
| You can deploy with a --max-instances flag to prevent infinite
| scaling. This has been a feature since the Cloud Run beta and
| has been in GAE forever.
| alasdair_ wrote:
| One issue in GAE is that it can take 24 hours to update the
| billing cap. So if you happen to get a ton of fantastic press
| coverage one day, your site will go down and there is
| literally nothing you can do to fix it.
| skj wrote:
| Seems unrelated to capping instance counts, which I assume
| would go into effect very quickly.
|
| (I work on GCP but not this product)
| alex-olivier wrote:
| Do-able today with GCP Billing
| tmpz22 wrote:
| I wonder how friendly the UI is to accomplish that
| Havoc wrote:
| I thought GCP is alerts not capping?
| alex-olivier wrote:
| The 'official' method is programmatically DIY!
|
| https://cloud.google.com/billing/docs/how-
| to/notify#cap_disa...
| throwlaplace wrote:
| haha
|
| >Warning: This example removes billing from your project,
| shutting down all resources.
|
| this is the digital equivalent of literally pulling the
| plug. i wonder how long it takes for GCP to register that
| you've pulled billing though? in some cases i'm sure even
| milliseconds could make a large difference.
| Havoc wrote:
| Damn that's ugly.
|
| I'm luckily still on Azure's MSDN tier...which is
| hardcapped to 150 bucks.
| [deleted]
| brenden2 wrote:
| It's cheap insurance to create an LLC to protect yourself from
| extreme situations for this kind of thing. Worst case the LLC
| goes defunct, but you won't be personally liable.
|
| https://www.nolo.com/legal-encyclopedia/limited-liability-pr...
|
| EDIT: This comment is based on the assumption that the parent
| was trying to start a side business. I'm certainly not
| advocating fraud.
| throwlaplace wrote:
| wut? are you suggesting that if there's a cost overrun you
| just shutdown the LLC? that sounds like a loop that couldn't
| possibly be true? when you sign TOS you agree to be
| responsible for service fees. if being an LLC indemnifies
| against these sorts of charges it would also indemnify you
| against other legitimate fees? take out a business credit
| card and cash advance and then close the LLC? free money!
| toolz wrote:
| It basically does work like that, however the law is almost
| never that cut and dry. The situation you're describing
| would have the person benefiting from the money as being
| personally liable because that person presumably would be
| taking the cash advance for self-interest instead of taking
| the loan in the interest of the business.
| mushufasa wrote:
| more or less, yes. bankruptcy courts vary by location. the
| whole point of a 'limited liability corporation' is you not
| being personally liable.
|
| BUT if you have 'malicious intent' -- meaning you build an
| llc on purpose to overrun costs and get free stuff, you CAN
| and WILL be sued and face penalties. cause that's just cut-
| and-dry fraud.
| danpalmer wrote:
| Yes. This is exactly what the "limited liability" in LLC
| means. You are not personally liable, only the business is.
|
| There are nuances to this, obviously fraud is fraud,
| regardless of using a shell company to perpetrate it, and a
| new business is unlikely to get a credit limit large enough
| to be a worthwhile avenue for fraud.
| flir wrote:
| Banks often ask for personal guarantees from ltd owners for
| precisely this reason. I've just skimmed the T&Cs and I
| can't _see_ any indemnity clauses, but that document 's
| massive and I'm just some guy, so who knows.
|
| (Incidentally, it's fairly common to structure a pair of
| ltds with the assets in one and the liabilities in another.
| If the whole thing crashes and burns, at least the IP
| doesn't go with it).
| CamelCaseName wrote:
| Which is exactly why banks require 2+ years of business
| history, collateral, or a personal guarantee. They will
| also review your financials when you apply for additional
| credit facilities.
| [deleted]
| lonelappde wrote:
| Good luck telling the judge your single person LLC with no
| investors shouldn't be pierced to pay debts incurred by its
| only owner and only employee.
| Terretta wrote:
| Works fine if you didn't co-mingle personal usage of the
| business accounts.
| bryanrasmussen wrote:
| It would be nice to have three caps:
|
| 1. notify me so I can ok continued service 2. start throttling
| usage 3. turn off if #1 has not responded and set new limits
| etc.
| clSTophEjUdRanu wrote:
| This makes me anxious as well.
| karmakaze wrote:
| What do didn't see mentioned is the latency for the first request
| when it's effectively dealer to zero. To get initial
| traffic/customers this is very important.
| superkuh wrote:
| Deploy you side-projects at more than the scale they'll ever need
| at home on your hardware for actual nothing.
| spankalee wrote:
| This will also cost actually nothing 99% of the time. Coud Run
| has a 2 million request / month free tier.
|
| And I don't have to worry about accidentally unplugging my
| server or downtime for OS upgrades.
| fideloper wrote:
| There must be added cost for a managed databases or similar,
| right?
|
| This sounds a lot like aws lambda (except nicer thanks to just
| running any container). In AWS's case, you need to pay extra for
| RDS, redis, and any other persistence.
| Kovah wrote:
| Exactly. And this is why I do not use these services yet. It's
| great if the app itself only costs like 18 cent per month.. But
| if you have to pay almost EUR10 per month for a (SQL) database,
| all the monetary benefits are gone. I currently pay 7EUR for
| two VPS which perform great, have a lot of storage and enough
| power to run all my projects.
| yegle wrote:
| Firestore is a managed database with free tier.
| pcnix wrote:
| GCP has Cloud Functions as the serverless Google Cloud
| equivalent of Lambda, this is more like a Google version of
| Heroku.
| franciscop wrote:
| I have used it for work-related reasons and indeed the service is
| quite nice. But I don't use Google Cloud Run for personal
| projects for two reasons:
|
| - No way of limiting the expenses AFAIK. I don't want the
| possibility of having a huge bill on my name that I cannot pay.
| This unfortunately applies to other clouds.
|
| - The risk of being locked out. For many, many reasons (including
| the above), you can get locked out of the whole ecosystem. I
| depend on Google for both Gmail and Android, so being locked out
| would be a disaster. To use Google Cloud, I'd basically need to
| migrate out of Google in other places, which is a huge initial
| cost.
|
| Both of those are basically risks. I'd much rather overpay
| $20-50/month than having a small risk of having to pay $100k or
| being locked out of Gmail/my phone. I _cannot_ have a $100k bill
| to pay, it 'd destroy everything I have.
|
| Also I haven't needed it so far. I've had a Node.js project on
| the front page of HN, with 100k+ visits, and the Heroku hobby
| server used 30% of the CPU with peaks at 50%. Trying to do the
| software decently does pay off.
| fearface wrote:
| Why not just make another Google Account just for this project?
|
| It's what I do since year, basically for every customer I work,
| I create a new account and even share the credentials with the
| customer (if he wants it).
| zwily wrote:
| I've heard about Google correlating these accounts (through
| billing methods, contact methods, access patterns) and
| banning them together when one infringes on something. I'm
| not sure it's the protection you think it is.
| sdan wrote:
| Yes they do. If you want to bypass these rules, just make a
| ton of accounts and wait for a couple months and the use
| those accounts with whatever credit card you have (keep in
| mind that you should get another card from your bank
| because google can tell when your card is a generated one
| like privacy.com)
| mcintyre1994 wrote:
| Won't they just correlate the name and address on your
| different credit cards?
| sdan wrote:
| I don't recall ever giving my real name/address for any
| billing address/name, because most if not all the time,
| they don't really care (or at least I never seen a
| difference).
| tamrix wrote:
| It's against the ToS to create another account to circumvate
| a ban.
| C14L wrote:
| All those accounts are "related". Made from the same PC, used
| from the same phone, etc.
| matsz wrote:
| Cloud hosting is great for businesses, that's why I believe
| that every web developer should experiment with those services.
| It's not great for personal use for the reasons you've stated -
| the risk of your service going down due to it being viral is
| much easier to bear than the risk of having to pay outrageous
| amounts of money for those services in that event.
|
| If your hobby project goes down for a while nobody will
| remember that and having to pay $100k will make you remember
| that for an eternity.
| abootstrapper wrote:
| Years ago I ran a side project that went viral. It grew to
| 60k visitors a day and my monthly cloud expenses were around
| $1,500. I cannot fathom a scenario where you get a surprise
| $100k bill from a viral hit. Anytime my project went down due
| to scaling, it was painful. You don't get many chances at
| going viral.
| jon-wood wrote:
| I've seen surprise bills not far off that, not from a viral
| hit, but from bugs in the firmware for connected devices
| which suddenly switched them from taking 1 action/10
| minutes to 1 action/3 seconds. Needless to say firmware QA
| has become much more focused since that incident.
| benhurmarcel wrote:
| $1500/month is a massive cost for a side project, I'd
| rather have it go offline by far.
| matsz wrote:
| You're right. I've went with the $100k assumption from the
| other comment.
| franciscop wrote:
| 60k is on the low-end of visits _only_ from HN where I 've
| normally seen 100k+. I saw around 60k once of 4-5 of my
| projects hitting the front-page.
|
| Also I know I make mistakes, both at coding and at setting
| things up, which can easily trash things around and make a
| 10x-100x multiplier for the cost. The risk is small, but
| the consequences are horrible so I prefer to avoid this
| risk.
|
| Edit: also note that even a $10k would be horrifying to
| spend in most personal projects, and $1500 is more than
| what most programmers are saving monthly in most of the
| world.
| redis_mlc wrote:
| > I cannot have a $100k bill to pay, it'd destroy everything I
| have.
|
| Welcome to US healthcare. Happens daily! :)
| franciscop wrote:
| I'm not in the US, and would not dream of going there without
| health insurance.
| znpy wrote:
| That makes me happy to be an European
| [deleted]
| cheriot wrote:
| From the article:
|
| > The service will create more and more instances of your
| application up to the limit you defined
|
| The Cloud Run docs confirm an instance maximum can be set and
| the price per instance can be less than $5/month.
| franciscop wrote:
| Cost is not only based on the number of instances. From a
| quick search:
|
| https://www.jhanley.com/google-cloud-run-pricing/
|
| Understanding the cost of these services is not easy at all,
| especially for extreme cases/situations. And a
| calculator/estimator won't fix the problem. That is why I
| love the fixed $X/month where there's no room for surprises.
| cheriot wrote:
| I hope GCP/AWS add a max spend ability. Until then it's
| complexity of pricing model vs time spent on OS and
| database management. To each their own.
| misterhtmlcss wrote:
| It's why I'm on digital ocean. Cheap, but good quality
| service that's comparable to the big boys and it's
| capped. $5/month is perfect for me
| itake wrote:
| I use DO too, but they have deleted a lot of customer
| data.
|
| https://news.ycombinator.com/item?id=17225665
|
| https://blog.checklyhq.com/why-the-recent-digital-ocean-
| kill...
|
| Keep your stuff backed up.
| savrajsingh wrote:
| You can definitely set limits on GCP
| franciscop wrote:
| I use Heroku for these situations where everything is
| managed automatically. The only con here would be paying
| more, $20-50/m (Node.js+DB+Redis?) instead of $5/m for
| DO, but I'm happy to pay for that and spend no time on
| manual management.
| swiley wrote:
| > No way of limiting the expenses
|
| This pattern seems common among business people: things working
| in the common case vs things working in corner cases, it's how
| you end up with consumer windows running critical machines. I'm
| always shocked and moderately disturbed when I see it but I
| guess we all need to accept the reality that most people are
| very pragmatic. It makes sense, most people's intuition comes
| from "the real material world" where you have to pragmatic, I
| think many of them fail to realize that on a computer you don't
| have to give up certainty the way you do in "the real world."
| kevan wrote:
| Loss aversion[1] describes the phenomenon pretty well:
|
| > Humans may be hardwired to be loss averse due to asymmetric
| evolutionary pressure on losses and gains: for an organism
| operating close to the edge of survival, the loss of a day's
| food could cause death, whereas the gain of an extra day's
| food would not cause an extra day of life (unless the food
| could be easily and effectively stored).
|
| For lots of companies an accidental over-use of tens or
| hundreds of thousands of dollars is an annoyance, but for a
| single person that could bankrupt them. I generally avoid
| programmatically interacting with cloud providers on my own
| time for exactly this reason. One mistake in a loop can get
| expensive fast.
|
| [1] https://en.wikipedia.org/wiki/Loss_aversion
| unexaminedlife wrote:
| I just did some math on their calculator:
| https://cloud.google.com/products/calculator/
|
| I think some folks may be overestimating their ability to put a
| dent in Google's infrastructure. 1 CPU
| 2GB memory 80 concurrent requests per container instance
| 1000ms execution time per request 5kb outbound network
| bandwidth per request 100 million requests per month
|
| $120.19 per month
|
| What if we bump it up to 100kb per request? In my experience
| only initial requests end up being enormous, especially in
| single page apps. But to be fair some folks may not have time
| to optimize. That still only brings the monthly bill to
| $1,071.48
|
| Then again that second estimate probably isn't relevant since I
| typically host my static data on a CDN.
| starptech wrote:
| Your setup is unrealistic. 100 million requests per month
| with 80 concurrent requests?. 1000 $ is cheap if you try to
| run wikipedia.com fully managed.
| franciscop wrote:
| I'm not from the US, and the thought of "only" paying $1071/m
| for a side project which is most likely not generating
| revenue is mindblowing.
|
| If you give me $1071-$120 = $951/month forever for optimizing
| an app once I'll optimize it for you :)
| chewz wrote:
| Silly me I have last week made an infinite loop on Firestore
| - update to document triggered CloudFunction which updated
| document and Firestore is fast..
|
| In just minutes I had passed free quota and here I have been
| lucky because I have checked console.
|
| If I have left that version (and I have been sure it is just
| innocent commit) for a few hours running I would be up for a
| surprise.
| C14L wrote:
| > The risk of being locked out
|
| For me, this is the main reason I try not to use any Google
| products, except for Gmail and Android. For mail, I started to
| migrate away from Google to reduce risk of being locked out.
| [deleted]
| joshvm wrote:
| You can set up alerts if you exceed a budget, and you can
| program a response to turn off billing on a project. Google has
| a guide for doing exactly what you want. It's not a
| particularly clean fix, but it is fairly easy (copy paste) and
| can be done. It also allows for fine grain control eg you could
| kill an expensive backend process but keep the fronted running.
|
| You can also rate limit some APIs.
|
| https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
|
| > You might cap costs because you have a hard limit on how much
| money you can spend on Google Cloud. This is typical for
| students, researchers, or developers working in sandbox
| environments. In these cases you want to stop the spending and
| might be willing to shutdown all your Google Cloud services and
| usage when your budget limit is reached.
| LeifCarrotson wrote:
| Is this not typical for...literally every use case? No one
| has an unlimited budget.
| michaelt wrote:
| Depends - if your profits increase in line with your
| expenses, you might be raking in the ad
| revenue/views/sales/whatever because your product 'went
| viral' and you might prefer to keep it up.
|
| Or if the rise in costs is something you can mitigate on
| your end - such as a bad deployment - you might want time
| to respond yourself, rather than your site going offline.
|
| More generally, few site reliability engineers are looking
| to add extra ways for the site to be taken offline.
|
| Of course, if you're large enough to be in those
| situations, your round-the-clock operations staff will be
| monitoring the billing situation as carefully as they
| monitor page load times and error rates and database load
| so an unexpected bill will be very unlikely.
| jsmeaton wrote:
| Sure, but typically a business will have specific resources
| they'd be willing to shut down rather than the entire
| billing account.
| deanmoriarty wrote:
| I had the same thoughts: even if I like Google Cloud a lot (I
| use it extensively at work), I don't feel it's safe for me to
| use it at home, since I don't want to risk having my entire
| google account locked due to "suspicious activity", whatever
| that might mean.
|
| In fact, I recently shut down a personal App Engine service I
| had been using for myself for a few years just because of this
| paranoia. The service was not doing anything illegal, just
| crawling a few websites (forums, ...) I like and sending me
| emails when there are interesting updates. But you never know
| if they might determine my outbound traffic is suspicious. I
| also started the long process of moving my main email from a
| @gmail.com to a @custom.domain that currently forwards to
| gmail, just in case I get locked out.
|
| It is quite bizzarre that this is the reputation google gained
| for themselves.
| irq-1 wrote:
| I ordered a phone from Google that's been lost in delivery. I
| have Gmail/documents/photos/music... Should I do a charge-
| back? Sue them in small claims court? I should never have
| done business with them.
| smt88 wrote:
| Absolutely don't do a chargeback. Try to settle it with the
| package carrier.
|
| Google's algorithm can flag a chargeback as suspicious,
| leading you to be locked out.
| europa wrote:
| Same thing happened to me once. I called google support and
| they send me another phone.
| tomlong wrote:
| Excuse my ignorance. if a container hasn't been hit in a long
| time, how long does it take to serve the first request back? Is
| it spun up or sort of hot paused?
| WrtCdEvrydy wrote:
| AWS's firecracker can start a VM for your code in under 15ms,
| but if you need database access and other stuff, you can 'pre-
| warm' it.
| tomlong wrote:
| Thanks, that's impressive.
| alex-olivier wrote:
| Don't have an exact time, but the bulk of the time is app
| startup vs container scheduling
| minimaxir wrote:
| It depends on the size of the container, but it can be a few
| seconds for a cold boot if small, then instantly for requests
| soon after that.
|
| Unfortunately Cloud Run obfuscates when a cold boot is
| necessary.
| ronyfadel wrote:
| Can anyone shed light on how this compares with Netlify? (Pricing
| and tech wise).
|
| Netlify has basic DB/Identity/Lambda support so I'm guessing it
| could replace this entirely.
|
| I'm using it only to host static websites at the moment.
| CraftThatBlock wrote:
| Netlify (without extra features) is simply static hosting. With
| Lambda, it does add server-side code.
|
| Cloud Run is to run a fully custom server, as in an API. It can
| obviously do more than Netlify, however Netlify really excels
| at static + some server code, while Cloud Run is extremely
| flexible (server in any language, more resources, etc)
| GordonS wrote:
| Sounds quite similar to Azure Container Instances, except ACI
| seems to be cheaper (at a glance). ACI is also not HTTP-only like
| this seems to be, but you do need to combine it with a Function
| App (Azure's serverless offering) if you want to trigger
| containers using HTTP.
| duxup wrote:
| As a noob I have a question as to what advantages I have using
| docker compared to just a service like Heroku where I just push
| the application to them... and I don't bother with docker?
|
| To me with my limited understanding this seems like just another
| step.
|
| Now granted when it comes to work, I'm using docker with
| specifics that I know why I would want / can specify with docker
| ... but for personal projects this ever comes up for me.
|
| But otherwise for personal projects it just never comes up.
|
| Yet on the other hand when it comes to various examples I see
| more and more that involve docker where, I'm not sure it needs to
| / what the advantage is.
|
| Obviously there must be some strategic choices / advantages I'm
| missing.
| jhgaylor wrote:
| The first thing that comes to my mind is lock-in. if you push
| the application to Heroku and "it just works" then when you
| need to deploy it somewhere else you still have that hurdle to
| cross. Heroku's pricing adds up quickly.
| jiofih wrote:
| The first obvious advantage is you can test your app locally in
| the exact same environment it will run, including any system
| dependencies and native modules. On any OS.
| agotterer wrote:
| Is there an easy equivalent for scheduled tasks in GCP? A
| background process that executes for a short period of time and
| then exists only charging you for the time it ran?
| spyspy wrote:
| https://cloud.google.com/scheduler/ ?
| alasdair_ wrote:
| 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:
|
| 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.
|
| It ended up being insanely expensive at scale.
|
| 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.
|
| Support was extremely weak for some parts of the system. Docs for
| java were outdated compared with the python docs.
|
| Support (that we paid for) literally said to us "oh... you're
| still using appengine?"
|
| 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.
|
| 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.
|
| 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.
|
| 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.
| tmpz22 wrote:
| These products remind me of that one colleague who doesn't
| understand why people don't like them. Uh, you've
| systematically fucked them over for years without even
| realizing it, and when you get caught you never even apologize,
| thats why they don't like you.
| ec109685 wrote:
| It's a good point. A reputation is really hard to build up,
| but easily torn down in an instant.
|
| Certain early decisions are still biting GCP.
| jccooper wrote:
| App Engine is indeed problematic. I have an important app on it
| and various forced upgrades gave me a big headache. It's been
| stable for several years now, so I'm okay with it, but as much
| as I like the idea, and indeed the execution, of App Engine I'm
| not going to do anything new on it because of the lock-in
| factors.
|
| Cloud Run, however, uses standard containers, so as long as you
| don't use Google proprietary stuff on the backend it's
| relatively easy to move. As the article mentions, it's useful
| for low-traffic projects, and if they pick up you can move them
| to full-time instances.
| spankalee wrote:
| You're outlining all the reasons why Cloud Run is the successor
| to App Engine.
|
| 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's slow and
| expensive. Services like Datastore and Memcache were tightly
| coupled.
|
| Cloud Run fixes all that. It'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.
|
| Cloud Run is what lets you avoid single-vendor lock in, but
| still get from 0 scaling.
| tra3 wrote:
| What kinds of applications take no time to startup though? I'm
| curious about the spin up time, 'cause my rails applications take
| on the order of minutes. I guess you can schedule a keep alive
| elsewhere though..
| all_factz wrote:
| What's the advantage of GCR over AWS Fargate/ECS? I've been
| running an app on ECS for a couple months now and have been
| pretty happy with the ease of set-up, load-balancing, auto-
| scaling etc, though there are still kinks I'm figuring out
| (SSHing into containers to perform database management, for
| example, or deploying updated tasks without downtime). Is the
| main selling point of GCR just its price? I haven't found ECS
| pricing to be an issue (but I'm also not running anything at
| scale, and I do pay more than a few cents a month -- but still
| under 10 bucks).
| mmbleh wrote:
| GCR runs containers like Fargate, but scales to zero like
| lambda, so you only pay for usage
| skj wrote:
| GCR is the container registry and does nothing but store your
| artifacts.
| PhilippGille wrote:
| The article and comments are about Google Cloud Run
| anirudhgarg wrote:
| I don't think you can scale up and scale down Fargate based on
| Http requests
| staticassertion wrote:
| I'm not sure if you can reasonably scale to 0, but I believe
| you can attach Autoscaling Groups to Fargate.
| anirudhgarg wrote:
| Most likely it would be based on CPU/Memory and not
| requests
| asdfasdfgdy wrote:
| Disclaimer: I work on cloud run
|
| Another advantage not stated by others is that cloud run
| (mostly) adheres to the KNative API spec. This allows you lift-
| and-shift your application from cloud run to a Kubernetes
| cluster with the KNative plugin installed, a feature you can't
| find with any other serverless product
| ignoramous wrote:
| Thanks. What are the usual cold start and warm start times
| for Cloud Run? Is there potential for those start times to go
| down to a few milliseconds in the near-future?
| jupp0r wrote:
| Another option is Google Cloud AppEngine. It's a little more
| limited in terms of languages that are supported, but the free
| tier is generous enough that I have never paid anything to run
| backends for side projects.
| yegle wrote:
| For personal projects I think App Engine is superior due to the
| included services like Mail API and Memcache API.
|
| There are also features like Firewall API that's lacking in
| Cloud Run right now.
|
| One downside of App Engine (due to its 10+years of history) is
| that one GCP project can only have one App Engine app in a
| single region, and you can't change the region after it's
| created. You can have arbitrary number of Cloud Run service in
| one GCP project, each can be in different region.
|
| It's also harder to take a Infrastructure-as-code approach on
| App Engine as there's no easy way to diff between the deployed
| version and the intent (in Cloud Run, you can use the container
| image hash for that purpose).
|
| Disclaimer: SRE working on App Engine and Cloud Run.
| spyspy wrote:
| GAE and Cloud functions are gradually going to be replaced by
| Cloud Run. In fact Run and 2nd generation GAE run on exactly
| the same infra backed by gVisor and you can deploy custom
| containers to either in almost exactly the same manner.
| rantwasp wrote:
| this has already been said, but due to the fact that this is
| google you have no idea when it's going to get killed and most
| things from google get killed.
|
| so i would suggest AWS. API Gateway + Lambda. It's basically free
| for side-projects and the setup + operating it is trivial. It
| also scales (and you're going to have to shell out real money) if
| you were to receive a lot of traffic.
| IAmEveryone wrote:
| Just the other day I wanted to buy a book, but Amazon no longer
| has it in stock...
|
| Yes, that makes about as much sense as people who can't get
| over their favourite RSS reader, 13 years on.
| Dolores12 wrote:
| Your liability is not capped anywhere. I better stick to 5$/mo DO
| for my side-projects.
| alpb wrote:
| You can actually specify maximum number of instances
| https://cloud.google.com/run/docs/configuring/max-instances as
| well as max requests handled by instance at a time
| (https://cloud.google.com/run/docs/about-concurrency).
| minimaxir wrote:
| It takes a _lot_ of virality to go over $5 /mo for a smaller-
| side project in Cloud Run. (essentially if you got the point
| where it would go over, the additional surplus traffic would be
| well worth it)
| [deleted]
| tnolet wrote:
| Or a $7 Heroku dyno if you don't want to manage disks,
| networking, patching etc. and can afford the extra $2
| cheriot wrote:
| From the article:
|
| > The service will create more and more instances of your
| application up to the limit you defined
|
| The docs confirm an instance maximum can be set and the price
| per instance can be less than $5/month.
| [deleted]
| iandanforth wrote:
| I'm not sure that "at scale" means anything if the author has
| never had one of their projects scale.
| minimaxir wrote:
| I've been using Cloud Run for my GPT-2 text generation apps
| (https://github.com/minimaxir/gpt-2-cloud-run) in order to
| survive random burst, and also for small Twitter bots
| (https://github.com/minimaxir/twitter-cloud-run/tree/master/h...)
| which can be invoked via Cloud Scheduler to utilize the
| efficiency benefits. It has been successful in those tasks.
|
| The only complaint I have with Cloud Run now (after many
| usability updates since the initial release) is that there is no
| IP rate-limiting to prevent abuse, which has been the primary
| cause of unexpected costs. (due to how Cloud Run works, IP rate-
| limiting has to be on Google's end; implementing it on your end
| via a proxy eliminates the ease-of-use benefits)
| montychain wrote:
| How much do you end up paying on average for a tweet-sized
| generated text?
| minimaxir wrote:
| I haven't create a service for auto-generated tweets yet
| (just human-curated ones), but for similar service which
| output tweet-length text (w/ a 2GiB RAM side), it takes about
| 30s on a cold boot (which makes sense as it has to load the
| model to RAM), and ~12s to generate text after a cold boot.
|
| From the pricing (https://cloud.google.com/run/pricing):
|
| 12 * ($0.00002400) + 12 * (2 * $0.00000250) = $0.000348 per
| text
|
| ...and that's assuming you go over the free tier limit.
| ParanoidShroom wrote:
| I'm currently serving an api that uses a 500mb resnet v2 model.
| The bootup takes to long, so now I have a single instance that
| can't handle any peaks and costs too much. Doesn't your model
| take to long to spin up before being able to serve a request ?
| orf wrote:
| Tensorflow serving, or whatever name Google cloud has given
| their managed version.
| minimaxir wrote:
| Yes unfortunately, but that's the caveat of services-on-
| demand. I'm looking more into more efficient/cheap model
| deployment workflows. (it might be just running the
| equivalent of Cloud Run on Knative/GKE, backed by GPUs)
| ignoramous wrote:
| Does GCP have an equivalent for Aurora Serverless? If so,
| would choosing that over CloudSQL been cheaper?
|
| If you're familiar with AWS, would using AWS Batch
| exclusively with Spot pricing [0] (or Fargate with Spot
| pricing) _and_ Aurora Serverless [1] been cheaper than
| Cloud Run + CloudSQL?
|
| [0] Say, the service runs for 5 mins every hour for 30
| days. The respectable a1.large instance would cost $0.50
| per month, the cheapest t3.nano would cost around $0.19 per
| month.
|
| [1] Say, the service stores rolling 10 GiB/Month ($1.00)
| and does about 1000 calls per 5 minutes every hour ($0.20)
| using 2 ACUs ($3.60). This would cost $4.80 per month.
| chishaku wrote:
| From: https://github.com/ahmetb/cloud-run-faq#how-to-keep-a-
| cloud-...
|
| ---
|
| How to keep a Cloud Run service "warm"?
|
| _You can work around "cold starts" by periodically making
| requests to your Cloud Run service which can help prevent the
| container instances from scaling to zero._
|
| _Use Google Cloud Scheduler to make requests every few
| minutes._
|
| Does my application get multiple requests concurrently?
|
| _Contrary to most serverless products, Cloud Run is able to
| send multiple requests to be handled simultaneously to your
| container instances._
|
| _Each container instance on Cloud Run is (currently) allowed
| to handle up to 80 concurrent requests. This is also the
| default value._
|
| What if my application can't handle concurrent requests?
|
| _If your application cannot handle this number, you can
| configure this number while deploying your service in gcloud
| or Cloud Console._
|
| _Most of the popular programming languages can process
| multiple requests at the same time thanks to multi-threading.
| But some languages may need additional components to do
| concurrent requests (e.g. PHP with Apache, or Python with
| gunicorn)._
| f311a wrote:
| If very few people visit a side-project, that's probably bad for
| Google search. Its crawler will be detecting slow response times
| and Google can penalize you in search results.
| texasbigdata wrote:
| What a complimentary business strategy :)
| riyadparvez wrote:
| More like unintended consequences. Like many real world
| cases, each of the policies is a reasonable, sound and fair
| policy by their own right. But when you combine them they
| might seem designed with exploitive motives.
| remmargorp64 wrote:
| Of course, the downside to doing anything with a Google product
| is that it could be deprecated next year...
| tpetry wrote:
| It's slready like a meme: the typical comment on the google
| cloud that it could be closed tomorrow.
|
| When will everyone understand that google cloud (money earning
| product) is different to all the other free products
| xenospn wrote:
| Burden of proof is on Google.
| llampx wrote:
| Money-earning products have been shut down at Google before.
| gumby wrote:
| > When will everyone understand that google cloud (money
| earning product) is different to all the other free products
|
| When Google demonstrates it. They've already discontinued
| various parts of their cloud product.
|
| True, they are unlikely to shut down gmail, search, or
| Android.
|
| On the other hand google's cloud is a money loser that has
| slipped to a distant #4 in the cloud rankings.
|
| But like many of Google's revenue-generating products it
| exists to show Wall Street that they have an increasingly
| diversified revenue stream (I think advertising is "down" to
| around 87%). They have lots of bets to try an improve this
| but little to show for it.
|
| They did recently commit $2B to making GCP a player but I
| suspect that if that doesn't show results by the end of 2020,
| investment in this sector will fall precipitously.
| tpetry wrote:
| Do you have examples of discontinued Google Cloud Platform
| products?
| gumby wrote:
| You don't need to ask me: Google provides their own handy
| list of examples (some like messaging API show up under
| other names like XMPP; others don't appear on this list
| because they were marketed differently, e.g. Google
| Print):
|
| https://cloud.google.com/appengine/docs/deprecations/
| dodobirdlord wrote:
| Many of those seem to have been around for well more than
| the 1 year deprecation minimum, and most of them appear
| to be some combination of Alpha/Beta products or language
| runtimes. Alpha/Beta products aren't really on-topic, and
| the language runtime stuff doesn't look all that
| different from how AWS does runtime deprecations.
|
| https://docs.aws.amazon.com/lambda/latest/dg/runtime-
| support...
| libria wrote:
| https://cloud.google.com/prediction/
| yegle wrote:
| Disclaimer: I work on Cloud Run as an SRE.
|
| Google Cloud has an official deprecation policy. If a product
| is labeled GA, Google Cloud guarantees that the service will
| continue running for at least 12 months since the announcement
| of deprecation.
| OkGoDoIt wrote:
| Exactly. According to what you said, any service with that
| policy could literally shut down next year if there is a
| deprecation announcement this year.
|
| Which is better than some small no name startup service
| provider who might just go out of business tomorrow, but
| among all the big cloud providers Google is definitely the
| hardest to trust with longevity.
|
| A more realistic concern is that Google might substantially
| change the free tier making this more expensive, or might
| shut down some auxiliary product that would be painful to
| switch from without migrating clouds completely, or that a
| payment might bounce for some reason and now I'm locked out
| of all of my google services without recourse.
|
| Sure the odds of all of the above are relatively low, but
| from what I've seen they are a lot higher on Google than they
| are on Azure or AWS.
| lallysingh wrote:
| Can we standardize this standard comment? Say a URL that points
| to the problems we always see complaints about for using a
| Google service? Then someone posts that link at every Google HN
| post and we can all get on with our lives?
|
| They're boilerplate and don't add to the discussion.
| GordonS wrote:
| Yes, as much as I agree with the sentiment of the GP, these
| comments really are just a _bore_ now.
| rantwasp wrote:
| i suggest a TLA in the title so that we all know what is
| going to happen. why wast a good comment on it
| inscrutable wrote:
| except it's open source...
| akoncius wrote:
| please give a link to source
| foolinaround wrote:
| its more an adherence to open standards - it is built on
| knative
| wstrange wrote:
| https://github.com/knative https://github.com/google/gvisor
| dangoor wrote:
| Assuming you're using SQL or something else that's portable for
| your data, the app is just a standard app in a container. It
| would be easy to move elsewhere, or even to just deploy to a
| different Google Cloud service.
| ThinkBeat wrote:
| I often find myself what "at scale" means. It is used by so many
| different providers and it gets confusing.
|
| When all you give the service is a container, how dos it know how
| to scale your project?
|
| I presume it gives it more CPU and more RAM automagically but
| does that really provide "at scale"
|
| I think of "at scale" to mean really a lot of traffic.
|
| Spinning up new instances if your container is possible, but I
| think I would like an API where code can somehow interact with
| the scaling mechanism.
|
| I guess "stateless" gives us some information.
| Mockapapella wrote:
| I've been looking for a service like this for a while now. The
| only problem I'm seeing with regards to my use case is I need
| powerful GPUs for NLP inference to also scale up and down to
| demand. Can someone explain if this is possible with GCR and if
| so what do i need to do to accomplish it?
| spankalee wrote:
| There are Cloud GPUs: https://cloud.google.com/gpu/ but more
| generally, there's a whole AI platform:
| https://cloud.google.com/ai-platform/
| city41 wrote:
| I'm just starting to explore cheap hosting for a web app and my
| initial digging suggests shared php hosting (with MySQL) is
| promising. It seems much cheaper than ruby, node, etc. Can anyone
| comment if my initial hunches are correct?
| sweeneyrod wrote:
| If you can save $10/month by using PHP rather than Ruby (which
| seems optimistic) and value your time at $10/hour (which seems
| pessimistic) then writing PHP instead Ruby only has to take one
| hour per month more (or the equivalent in pain) to not be worth
| it.
| city41 wrote:
| I get what you're saying and appreciate the perspective. I'm
| not convinced rails or perhaps Sinatra are really any nicer
| than say Laravel. But I personally am not a ruby fan.
|
| In this particular case the front end is very rich and the
| majority of the effort, and for the back end I just need a
| little bit of crud.
| EGreg wrote:
| If you already have an EC2 instance reserved on AWS for a year,
| you could just throw all those small projects there.
|
| If they are truly stateless then the bottleneck will probably be
| the database, anyway.
|
| For anyone starting a new app I recommend just building apps that
| are TRULY serverless. Then you can make them client-first, work
| offline, not tied to on one particular domain name, support end-
| to-end encryption, be embarassingly parallel and scalable, and
| take an _activist position_ against continuing centralization.
|
| A fuller exposition is here, so I don't have fo write a whole
| mountain of text: https://qbix.com/blog/2020/01/02/the-case-for-
| building-clien...
___________________________________________________________________
(page generated 2020-01-12 23:00 UTC)