25 ms·

Deploy your side-projects at scale for basically nothing – Google Cloud Run

• remmargorp64 7y ago
  Of course, the downside to doing anything with a Google product is that it could be deprecated next year...
  • inscrutable 7y ago
    except it's open source...
    • akoncius 7y ago
      please give a link to source
      • foolinaround 7y ago
        its more an adherence to open standards - it is built on knative
      • wstrange 7y ago
        https://github.com/knative https://github.com/knative https://github.com/google/gvisor https://github.com/google/gvisor
  • dangoor 7y ago
    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.
  • tpetry 7y ago
    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 7y ago
      Burden of proof is on Google.
    • llampx 7y ago
      Money-earning products have been shut down at Google before.
    • gumby 7y ago
      > 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 7y ago
        Do you have examples of discontinued Google Cloud Platform products?
        • libria 7y ago
          https://cloud.google.com/prediction/ https://cloud.google.com/prediction/
        • gumby 7y ago
          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/ https://cloud.google.com/appengine/docs/deprecations/
  • lallysingh 7y ago
    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.
    • rantwasp 7y ago
      i suggest a TLA in the title so that we all know what is going to happen. why wast a good comment on it
    • GordonS 7y ago
      Yes, as much as I agree with the sentiment of the GP, these comments really are just a bore now.
  • yegle 7y ago
    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 7y ago
      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.
      • yegle 7y ago
        That 12 months is the minimum guaranteed period that your service won't be interrupted. See the full list of deprecations in App Engine: https://cloud.google.com/appengine/docs/deprecations/ https://cloud.google.com/appengine/docs/deprecations/ High profile deprecations are handled carefully and we usually handle them with extended deprecation period with clear migration path/doc and communications. Notable examples in the table: 1. Python 2.5: 4+ years 2. Java 6: 20 months with existing user automigrate to Java 7 3. Java 7: 13 months with existing user automigrate to Java 8 4. Master/slave datastore: 3+ years. Considering App Engine is the first Google Cloud offering, I'd say we have a very good track record of meet our deprecation policy and usually exceeds it.
• navd 7y ago
  Cloud run is what zeit now was before it moved to v2. https://zeit.co/ https://zeit.co/
  • ignoramous 7y ago
    What does it run on today? Or, is it multi-cloud now?
    • rgbrgb 7y ago
      yep, multi-cloud https://zeit.co/docs/v2/network/regions-and-providers/ https://zeit.co/docs/v2/network/regions-and-providers/ You can specify where to deploy to in a config file. Pretty cool stuff.
    • navd 7y ago
      Sorry for any confusion but I didn’t mean it WAS based off cloud run, but was fundamentally the same type of product with a better dev experience built around it.
• dennisy 7y ago
  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.
• inscrutable 7y ago
  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 7y ago
    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 7y ago
      Thanks, although unfortunately I'm not in the price bracket for Anthos (starts at 120k/year or so I believe).
      • yegle 7y ago
        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 7y ago
          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!
• aamederen 7y ago
  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 7y ago
    Heroku's "hobby" is $7/m while "free" is $0/m. There's no "free hobby": https://www.heroku.com/pricing https://www.heroku.com/pricing
  • elamje 7y ago
    Fixed with: https://kaffeine.herokuapp.com https://kaffeine.herokuapp.com
• datashow 7y ago
  What will the bill look like if your website suddenly hit a big traffic (e.g. someone post your site on HN)?
  • sansnomme 7y ago
    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 7y ago
      > 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 7y ago
        [deleted]
      • ignoramous 7y ago
        https://scaleway.com 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] €2.99 for 2vCPU, 2GB RAM, 200Mbits/s bandwidth.
        • tuesday20 7y ago
          75GB object storage free??? Am I reading this correctly or am I stupid?
• ealexhudson 7y ago
  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.
  • GordonS 7y ago
    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.
  • iamEAP 7y ago
    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.
    • ealexhudson 7y ago
      Yeah, I did look at that, and I think you're right on ease-of-use - it's a deploy and done deal, which is nice. I think it suffers from two things: * the cost seems net-net similar to App Service, but more granular. So I can go this route and get slightly more flexible pricing, but at the cost of some arbitrary limits on assignable CPU/memory. * it's easy to wander into Azure Container Service stuff accidentally, and that has "deprecated" plastered all over it. Shame the naming doesn't separate them more clearly.
• z023bs 7y ago
  this is misleading, as cost curves are usually exponential for these types of managed services
  • alex-olivier 7y ago
    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 7y ago
      Cloud Functions isn't 1:1 IIRC, once a Function is booted it keeps serving more requests once warm.
      • yegle 7y ago
        No, the concurrency of GCF is always 1. If the latency of your code handling request is 1s, to handle 100 requests per second you'll need to have 100 instances running.
        • CraftThatBlock 7y ago
          You're right, thanks for letting me know Link for reference: https://cloud.google.com/functions/docs/max-instances https://cloud.google.com/functions/docs/max-instances
  • crazygringo 7y ago
    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 7y ago
      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 7y ago
  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.
  • aamederen 7y ago
    Here's a story about why you are right to be anxious: https://hackernoon.com/how-we-spent-30k-usd-in-firebase-in-less-than-72-hours-307490bd24d https://hackernoon.com/how-we-spent-30k-usd-in-firebase-in-l...
    • floatingatoll 7y ago
      This was discussed on HN (237 comments): https://news.ycombinator.com/item?id=17661391 https://news.ycombinator.com/item?id=17661391
    • StillBored 7y ago
      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 7y ago
• tomlong 7y ago
  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 7y ago
    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 7y ago
      Thanks, that's impressive.
  • alex-olivier 7y ago
    Don't have an exact time, but the bulk of the time is app startup vs container scheduling
  • minimaxir 7y ago
    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 7y ago
  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 7y ago
    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)
  • koboll 7y ago
    Netlify's stupid-easy for small projects. You just point it at a Github repo and it does the rest. As long as you're staying under its usage caps, and you can run all the server code in lambda functions, it seems like the best choice. Once you exceed the free tier, though, no doubt it's much more expensive than GCP/AWS.
• all_factz 7y ago
  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 7y ago
    GCR runs containers like Fargate, but scales to zero like lambda, so you only pay for usage
    • skj 7y ago
      GCR is the container registry and does nothing but store your artifacts.
      • PhilippGille 7y ago
        The article and comments are about Google Cloud Run
  • anirudhgarg 7y ago
    I don't think you can scale up and scale down Fargate based on Http requests
    • staticassertion 7y ago
      I'm not sure if you can reasonably scale to 0, but I believe you can attach Autoscaling Groups to Fargate.
      • anirudhgarg 7y ago
        Most likely it would be based on CPU/Memory and not requests
• jupp0r 7y ago
  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.
  • spyspy 7y ago
    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.
  • yegle 7y ago
    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.
    • jupp0r 7y ago
      Thanks for the insights!
  • Yeroc 7y ago
    Right now you may be able to do more with AppEngine but the trade-off is you're locked in to platform-specific APIs. With Cloud Run there's no platform lock in since all it is, is a Docker container with whatever you want running that listens on $PORT.
• minimaxir 7y ago
  I've been using Cloud Run for my GPT-2 text generation apps (https://github.com/minimaxir/gpt-2-cloud-run 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/human-curated 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 7y ago
    How much do you end up paying on average for a tweet-sized generated text?
    • minimaxir 7y ago
      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 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 7y ago
    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 ?
    • minimaxir 7y ago
      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)
• f311a 7y ago
  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 7y ago
    What a complimentary business strategy :)
    • riyadparvez 7y ago
      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.
• ThinkBeat 7y ago
  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.
• EGreg 7y ago
  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-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
• Havoc 7y ago
  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.
  • LogicX 7y ago
    This is the advice I give early stage startups... don’t waste cycles learning the AWS stack, and getting locked in. Just pay for a cheap VPS, and scale it vertically as you grow. By the time you outgrow vertical scaling you should have the revenue or funding to figure out your at scale architecture. You’d be surprised how much you can handle with a single beefy VPS or dedicated.
    • Havoc 7y ago
      Yup. The other aspect that surprised me is how crazy the relative costs are. I'm paying 7USD for a 16gig/4 core ryzen I snagged on a special. That's a good 10x off from what big cloud would give me. ...down side is it needs to be engineered for "provider may disappear overnight" so backup strategy needs to be on point.
    • slovenlyrobot 7y ago
      A slight twist on this is a cheap, beefy colo box with nothing installed except something like k3s. This way you end up with all the YAML bureaucracy paid down in case that dreamy future with millions of users finally manifests
    • a_imho 7y ago
      Had a VPS for side project at Vultr. First step first, could not send sign up emails from it.
      • ibly31 7y ago
        Sounds like the problem was with the networking or application code. VPS can do anything when it's configured properly.
• superkuh 7y ago
  Deploy you side-projects at more than the scale they'll ever need at home on your hardware for actual nothing.
  • spankalee 7y ago
    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 7y ago
  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.
  • yegle 7y ago
    Firestore is a managed database with free tier.
  • Kovah 7y ago
    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 €10 per month for a (SQL) database, all the monetary benefits are gone. I currently pay 7€ for two VPS which perform great, have a lot of storage and enough power to run all my projects.
  • pcnix 7y ago
    GCP has Cloud Functions as the serverless Google Cloud equivalent of Lambda, this is more like a Google version of Heroku.
• agotterer 7y ago
  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 7y ago
    https://cloud.google.com/scheduler/ https://cloud.google.com/scheduler/ ?
• rantwasp 7y ago
  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 7y ago
    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.
    • rantwasp 7y ago
      usually it's the publisher of the book that makes the decision. Amazon can actually (and does) print book on demand. Let that sink in for a second. if it was just the RSS reader, nobody would bring this up. Reader, Inbox, Wave, Plus, NestAPI, the list goes on. Here: https://killedbygoogle.com/ https://killedbygoogle.com/
• Dolores12 7y ago
  Your liability is not capped anywhere. I better stick to 5$/mo DO for my side-projects.
  • alpb 7y ago
    You can actually specify maximum number of instances https://cloud.google.com/run/docs/configuring/max-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 https://cloud.google.com/run/docs/about-concurrency).
  • minimaxir 7y ago
    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 7y ago
      [deleted]
  • tnolet 7y ago
    Or a $7 Heroku dyno if you don’t want to manage disks, networking, patching etc. and can afford the extra $2
  • cheriot 7y ago
    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 7y ago
      [deleted]
• tra3 7y ago
  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..
• scanr 7y ago
  He mentions CloudSQL for storage. Anyone know if it’s also on-demand?
  • minimaxir 7y ago
    No, you need a persistent instance unfortunately (min $7/mo): https://cloud.google.com/sql/pricing https://cloud.google.com/sql/pricing
• jsjohnst 7y ago
  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 7y ago
    "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.
    • modzu 7y ago
      people seem to forget the usage accrued via the devs themselves..
    • chispamed 7y ago
      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 7y ago
        Fair, although if the app is architected that way Cloud Run might not be the best option.
    • jsjohnst 7y ago
      2 requests/minute = 86400 requests a month. Plug in the other numbers from my earlier post and you’ll see the calculator say exactly as I said, around $2/month give or take depending on region.
  • chispamed 7y ago
• franciscop 7y ago
  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.
  • unexaminedlife 7y ago
    I just did some math on their calculator: https://cloud.google.com/products/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 7y ago
      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.
      • unexaminedlife 7y ago
• GordonS 7y ago
  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.
• iandanforth 7y ago
  I'm not sure that "at scale" means anything if the author has never had one of their projects scale.
• fareesh 7y ago
  Might be a mindset thing but if my side project needed scale I would not think of it as a side project.
  • dkarras 7y ago
    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.
• duxup 7y ago
  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.
  • jiofih 7y ago
    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.
  • jhgaylor 7y ago
    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.
    • LogicX 7y ago
      ... or you just deploy it on any VPS or bare metal with dokku installed: http://dokku.viewdocs.io/dokku/ http://dokku.viewdocs.io/dokku/
  • heavyset_go 7y ago
    Containers are great for packaging an app, ensuring dependencies will be met and avoiding lock-in. You can use containers on Heroku, by the way.
  • imtringued 7y ago
    Heroku build packs only work on Heroku. Containers work everywhere and they support any linux application.
• alasdair_ 7y ago
  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 7y ago
    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 7y ago
      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.
  • spankalee 7y ago
• jjeaff 7y ago
  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.
  • deleted 7y ago
    [deleted]
  • steelaz 7y ago
    AWS has Aurora Serverless (https://aws.amazon.com/rds/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 7y ago
      They also have RDS Proxy (https://aws.amazon.com/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 7y ago
        I wonder where the threshold is that the proxy is beneficial. MySQL is actually really good at handling new connections.
    • chris_st 7y ago
      Note that you can either run Aurora Serverless constantly (at a cost of about $43 a month) or have ~30 second startup times if the instance has timed out (~15 minutes).
  • ramraj07 7y ago
• karmakaze 7y ago
  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.
• city41 7y ago
  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 7y ago
    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 7y ago
      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.
      • sweeneyrod 7y ago
        Sure, I'm not saying that you should use Rails over Lavarel, but rather that you shouldn't consider differences in costs of hosting much since other factors like difference in development time probably dwarf those.
• Iwan-Zotow 7y ago
  Did he publish any IP of his project(s)? Lets flood it and have him pay the bill
• Mockapapella 7y ago
  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 7y ago
    There are Cloud GPUs: https://cloud.google.com/gpu/ https://cloud.google.com/gpu/ but more generally, there's a whole AI platform: https://cloud.google.com/ai-platform/ https://cloud.google.com/ai-platform/
• acvny 7y ago
  Can't you see this article is a paid advertisement for Google Cloud? Just like those 1 hour long videos on youtube - where they show how pilots fly an airplane of a specific company and how well is al organized or a 1 hour long video of a german car factory. Just reading this line makes you suspicious: "I have built hundreds of side projects over the years " really? Hundreds? And then below: "I am yet to have a side project go ‘viral’" Out of hundreds of projects over the years, none of them went viral? And if you look at his "blog" you will see it has 3 entries in total: https://alexolivier.me/ https://alexolivier.me/
  • D2187645 7y ago
    similar to that woman who said she was on times person of the year.
  • fenomas 7y ago
    Bummer to see comments like this so high up the page after so many hours. HN guidelines: > Please don't post insinuations about .. shilling.. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data. Also: every blog starts somewhere. Plenty of stuff in the author's GH and linkedin, both linked from TFA.
  • icemelt8 7y ago
    That is a sad comment, I learnt a lot from OPs article.
• oli5679 7y ago
  Is anyone familiar with pros/cons vs. AWS ecs? I've used ECS a few times, it's pretty nice. https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/
  • tybit 7y ago
    As others have said, this is like ECS Fargate but scales like Lambda. Very nice offering and I hope it’s lit a fire under Fargate.
• realtalk_sp 7y ago
  Out of curiosity, how are people thinking about GCP platform risk after the '2023 deadline fiasco'[1]? Is it still a good idea to use GCP at all in the aftermath of them articulating that it could experience budgets cuts or even be axed entirely (though that latter seems much less likely)? [1] https://news.ycombinator.com/item?id=21815260 https://news.ycombinator.com/item?id=21815260
• cutler 7y ago
  For personal projects and client work I prefer a VPS with fixed pricing. Many have quoted Digital Ocean on this thread but you get much more for your money with a VPS from Hetzner.com. $11.75/month = 8Gb RAM, 2 CPUs, 80Gb SSD and 20Tb of traffic. That's 4 times the RAM, 2 times the CPU and 10 times the traffic compared with a $10 Digital Ocean VPS.
  • zebnyc 7y ago
    Does Hetzner.com have servers based in the US?
    • cutler 7y ago
      No, just Europe. See https://hetzner.com https://hetzner.com. No, I don't work for them or receive any commission :)
• darklajid 7y ago
  I was tinkering with it recently. My problem was .. support. After a lot of double-checking on my part, I was finally convinced that Cloud Run messed things up (in my case: A Content-Type header was changed from ThingsISend to text/html and broke every client). The issue tracker is hard to find and more or less abandoned, SO wasn't helpful (but had people that .. love Google Cloud Run and didn't believe me) and only after tweeting a bit someone looked into it. The issue is fixed now, which is nice. The way to get there was ... questionable?
• hardwaresofton 7y ago
  Do the kind of people who have tech jobs and have side projects really need it to cost nothing to run side projects? I don't understand this obsession with running projects for "nothing" and contorting software architecture to do so. $5/mo for a digital ocean droplet or $50/month for a a beefier VPS (or even dedicated hardware if you know where to look[0]) is not much compared to the normal monthly expenditure of people in tech on average. If it was all for convenience/efficiency that'd be one thing, but learning "google cloud run" teaches you nothing about system maintenance, limits your understanding of the full stack, and encourages a myopic view of development, all so at some point when Google/AWS/Azure raises the temperature of the water in the pot everyone starts wondering "how did running software get so expensive?".
  • nscalf 7y ago
    While I tend to agree, I'm the type to have ~3 projects going at a time. I'm pretty young, but I can see myself spinning up a few projects a year. Each project needs a sql database, hosted by google for a few bucks a year, a server per service, a company email per project per person on the project, etc. I can easily see this being $50/month/project. So let's call it $150/month, $1800/year. If you're not making any money, that's a lot of bare minimum over a life time just to play around with. Then if you assume your side project isn't meant to be profit optimizing, you may never make money. It really isn't a lot, but some people aren't in SF where they make massive profit. In more rural areas in the US, non-senior engineers can make ~$60k-$80k. In non-US roles, that's even lower. I can see this price range being meaningful. Also, I know you can get cheaper with this, but if your goal is to spin up MVP's ASAP, you don't care to work hard to optimize ever penny out of your infrastructure. This is a nice breakdown, and I'll probably use it for the current project I'm spinning up as a test.
    • ramraj07 7y ago
      You can do all of that with a $5/month vps assuming you don't get a ton of traffic.
  • _squared_ 7y ago
    Running side-projects at a loss prevents you from keeping a lot of them around, and might make it harder to decide to create a new one - "I want to do this cool project, but i already spend $X a month in hosting and I don't want to spend more".
• abbadadda 7y ago
  Nice post! But this is a big hurdle for some, no? Are all your side projects fully stateless? > As long as you have architected your application to be stateless
• twayback 7y ago
  Your side projects don't need scale :D :D
• cocoflunchy 7y ago
  We evaluated using it at work to replace App Engine Flex and unfortunately it was not ready for our use case: 1. There is no liveness/readiness check nor a way to move the traffic between versions, so you'll have downtime at every deployment 2. The only way to rollback to a previous version is to redeploy, no support from the web interface 3. There is no way to SSH to an instance (not so important) 4. You can't connect to Google Cloud MemoryStore (hosted redis) Scale to zero + instant deploys would make cloud run a great candidate for staging environments deployed on every pull request but it's not quite there yet.
• ishankhare07 7y ago
  Isn't this exactly the same model as Amazon ECS(Elastic container service)?
• ksahin 7y ago
  For my next side project, I'd like to test https://render.com/ https://render.com/ It seems like a cheaper alternative to Heroku. Any feedback on this?
  • indigodaddy 7y ago
    Interesting. Seems good. I guess the Render free tier is basically competing with Netlify, with the added luxury that you can add paid dynamic services at any time...?
    • anurag 7y ago
      Correct.
• ecmascript 7y ago
  Would be cool but I don't trust Google enough. I rather pay more than to host on Google's infrastructure.
• giorgioz 7y ago
  YES with serverless you can really deploy your side projects at scale paying basically nothing if they don't get visited. The Serverless Framework on AWS Lambda though are more mature to do that. One of the biggest gotchas is using just one aws lambda function with the entire web server instead of doing one aws lambda for each endpoint.
• runeks 7y ago
  > The service will create more and more instances of your application up to the limit you defined (currently the cap is 1000 instances). > As long as you have architected your application to be stateless - storing data in something like a database (eg CloudSQL) or object storage (eg Cloud Storage) - then you are good to go. Won’t this just defer the scalability issue to the SQL part of the application? It’s nice that the stateless REST part can be scaled almost infinitely, but if the SQL part doesn’t offer the same scalability, what’s the point? Last time I looked, CloudSQL didn’t offer this kind of scalability.
• josephernest 7y ago
  Is there an alternative with similar ease of use, i.e. you just pack the files, create a Dockerfile, and push it live? (For same reasons as other comments, I don't want to use another Google service for this, risk of being locked out, etc.)
• luord 7y ago
  This doesn't seem all that different from app engine or any other PaaS. Even the example he wrote is similar (probably longer) to a small guide I wrote for deploying to gae.
• elchupanebre 7y ago
  We've been using Firebase and one of the issues we had is that methods become "cold": if it's not used for a few minutes, the latency of the next call is unpredictable and could be in tens of seconds. The way Cloud Run is described ('Only pay when your code is running') suggests that it may suffer from it too. Does anyone know if it actually has the problem?