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.
> 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.
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):
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.
Those are just features of a single product (appengine) which has been around for more than a decade and through several generations. Every product under every cloud vendor has API and feature changes over the lifetime.
GCP has never had a major product line shutdown. The only thing that comes close is Google Maps API pricing changes, but technically the service is still there and has even more functionality.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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!
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.
So far what I've observed is <10s cold-start times on GCR. This is a fairly lightweight web app written using Undertow in Java so carries a JVM as overhead.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Starting to think the reason we arnt working for google/aws is we make mistakes. Whereas engineers at those companies just dont make mistakes, therefor they assume that billing caps are not necessary. Such is our lot in life.
I think the bigger difference (other than a potential skill difference) is rather that they're more willing to take these risks. The ones that are good at it and succeed will rise to the top!
Bug free is a not realistic but if you are a programmer and definitely if you are a tech founder you definitely should be willing to bet your financial future on writing reasonably low bug code.
If you are a programmer, I kind of find the comment puzzling; maybe I am reading you wrong, but you seem to be saying that you are writing code for some company while being happy to commit it and not care if the company loses money if your code is bad? As you would not bet on your work yourself, but you do not mind your employer paying you for it and as such betting some of it’s financial future on your work? Sorry if I misunderstood your comment.
When you work for somebody else (or with somebody else) then you try to do as good of a job as possible, but the ultimate responsibility still lies elsewhere - might be your boss or could even be the group. There will be other people who interact with your code and might spot errors. There will be people who are trained, in some capacity, to figure out ways to mitigate against accidentally generating very large bills. It is exceedingly unlikely that these points hold true for a solo developer working on a main project, let alone a side project.
Even if you are hyper competent and can probably get all of this correctly, you can't rest easy. You simply don't know whether you did everything correctly or not. Just one dumb mistake can saddle you with an enormous bill.
This is just like gun safety: don't point your gun at anything you're not intending to shoot. Mistakes happen and the consequences of it can be catastrophic.
You are right, but at some level you are thinking 'you can do it' right? Otherwise you would be pretty miserable I would imagine. But I agree with the rest you wrote. You meant it slightly more nuanced than I read it!
You are absolutely right; no idea (thinking hard what service I was thinking off now) why I typed that. I was thinking of something entirely else. No-one try this; bad advise; they will indeed come after you. Not
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)
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.
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.
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)
I've been using gc/firebase. It's very easy to use, with acceptable documentation. I've been able to get dangerous quickly without even trying to. If I weren't on the free tier I would've racked up unaffordable bills. Instead I exhausted my API limits and had to wait. Perfectly acceptable behavior for development. I'll also add some logic to the finished project to handle resource exhaustion. Should I start exhausting resources,and it's not a bug, I'm not going to continue with infinitely scalable/infinitely billable gc. I guess if target customers are companies with 9-12 figure budgets getting a 9 figure bill wouldn't be the end of the World. If I got a high 4 figure bill I'd have to declare bankruptcy.
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).
>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.
This is ridiculous. I'm guessing a huge revenue source is going after businesses for long-tail billing spikes.
Not only do I have to worry about bad code causing a huge bill, I also have to worry about the quality of code (or config) that emergency stops the billing.
I wonder if you can sign up with a pre-paid credit card and use a fake name.
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.
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!
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.
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.
Companies are doing this all the time and not prosecuted (or prosecuted and not found guilty); they just do not make it obvious. So the ‘will’ is not that cut and dry really; even in countries where bankruptcies are not normal and frowned upon (like NL), there are many companies only created to spend money and killed off when it runs out. On paper they look like real businesses. Also it is not unusual to put employees in a separate llc and kill that when the money runs out; again that happens a lot, even with the intent of doing that. As long as it looks good on the outside, it works. I cannot stand it personally but there are not many solutions to resolve it; you cannot read the minds of the founders to get their real intentions.
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.
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).
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.
As someone who used to work as an attorney in a past career, there's a policy called "piercing the corporate veil" to handle cases like this. Basically, if the only reason an LLC exists is to protect the owner from consequences of these sorts of shenanigans, the courts can pretend like the LLC doesn't exists for purposes of financial responsibility.
Note that this is a vague, general answer and most certainly does NOT constitute legal advice.
This VERY heavily depends on your state and I'm sure a lot of other factors. Years ago when I set up my single-member LLC my lawyer was quick to point out a thousand ways the LLC would be useless in court. Mingling bank accounts was only one of them.
The IRS, for what it's worth, treats a single-member LLC as a sole proprietorship and all losses/gains are considered personal income.
As always, check your state laws and consult a real, in-person lawyer.
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.
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 ...
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.
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
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.
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.
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.
Maybe just a simply array with the list of services to be shut down in the order provided? This should be enough for hobby and smaller projects, bigger projects will have plans/people in place anyway.
It is not that they can't do it - we are talking about a company with insane technical ability and resources. It is just that they don't want to do it.
Are there any cloud products that have hard $$$ caps? Even non-big 3. Any at all?
Seems like this is a huge dealbreaker. You cannot be expected to perfectly audit your side project for security. Suppose someone finds a remote code execution and starts mining Monero on it. Or someone just points a botnet at it. You could be on the hook for an unlimited amount of money.
Might as well just install Kubernetes on a monthly-fee VPS and pretend you're using GCP.
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?
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)
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.
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).
Most definitely, but you can auto scale on custom metrics with a bit of glue. Even a very small node app has a start time in the 10-30 sec range. Every auto scaling system, even cloud run, can struggle to keep up with extremely bursty traffic. If you want no timeouts, you have to overprovision.
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
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?
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.
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.
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.
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.
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)
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.
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 ?
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)
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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)
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.
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.
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.
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 20€ 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 150€ for the CPU, 77€ 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?
> 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 20€ a month and run my MariaDB and Redis database on the same machine as my other containers.
Interesting! How/why are they so much (~8x) cheaper than e.g. DigitalOcean or Linode? Or am I missing something and they're not comparable in some way?
Sure, but 8x cheaper? And I think most non-European hosting companies have datacentres in Europe; I assumed they'd compete on price but apparently not.
396 comments
[ 3.3 ms ] story [ 270 ms ] threadWhen 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.
https://cloud.google.com/appengine/docs/deprecations/
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support...
GCP has never had a major product line shutdown. The only thing that comes close is Google Maps API pricing changes, but technically the service is still there and has even more functionality.
They're boilerplate and don't add to the discussion.
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.
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.
See the full list of deprecations in App Engine: 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.
You can specify where to deploy to in a config file. Pretty cool stuff.
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.
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).
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
https://www.heroku.com/pricing
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.
[0] €2.99 for 2vCPU, 2GB RAM, 200Mbits/s bandwidth.
See section "Traffic" on https://www.scaleway.com/en/object-storage/
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.
I’m generally very underwhelmed by Azure offerings, but ACI is one of the few that actually lives up to what is advertised.
* 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.
Link for reference: https://cloud.google.com/functions/docs/max-instances
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.
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...
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.
Sure, to most people it will never happen. But the risk is always there. Reminds me of https://en.wikipedia.org/wiki/Survivorship_bias
If you are a programmer, I kind of find the comment puzzling; maybe I am reading you wrong, but you seem to be saying that you are writing code for some company while being happy to commit it and not care if the company loses money if your code is bad? As you would not bet on your work yourself, but you do not mind your employer paying you for it and as such betting some of it’s financial future on your work? Sorry if I misunderstood your comment.
Even if you are hyper competent and can probably get all of this correctly, you can't rest easy. You simply don't know whether you did everything correctly or not. Just one dumb mistake can saddle you with an enormous bill.
This is just like gun safety: don't point your gun at anything you're not intending to shoot. Mistakes happen and the consequences of it can be catastrophic.
If you never pay then expect some aggressive account shutdown, bans across all connected user accounts, and calls from debt collections.
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)
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).
https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
>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.
I'm luckily still on Azure's MSDN tier...which is hardcapped to 150 bucks.
Not only do I have to worry about bad code causing a huge bill, I also have to worry about the quality of code (or config) that emergency stops the billing.
I wonder if you can sign up with a pre-paid credit card and use a fake name.
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.
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.
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.
(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).
Note that this is a vague, general answer and most certainly does NOT constitute legal advice.
The IRS, for what it's worth, treats a single-member LLC as a sole proprietorship and all losses/gains are considered personal income.
As always, check your state laws and consult a real, in-person lawyer.
Or think again if you really need 'infinitely scalable bla blah' for personal project on a small budget.
(I work on GCP but not this product)
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
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.
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.
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.
Maybe just a simply array with the list of services to be shut down in the order provided? This should be enough for hobby and smaller projects, bigger projects will have plans/people in place anyway.
It is not that they can't do it - we are talking about a company with insane technical ability and resources. It is just that they don't want to do it.
Seems like this is a huge dealbreaker. You cannot be expected to perfectly audit your side project for security. Suppose someone finds a remote code execution and starts mining Monero on it. Or someone just points a botnet at it. You could be on the hook for an unlimited amount of money.
Might as well just install Kubernetes on a monthly-fee VPS and pretend you're using GCP.
It boggles the mind that AWS and GCP don't offer a payment cap - for that reason alone, I wouldn't go near them for side projects.
Unfortunately Cloud Run obfuscates when a cold boot is necessary.
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.
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)
Once you exceed the free tier, though, no doubt it's much more expensive than GCP/AWS.
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
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.
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)
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.
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.
---
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).
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.
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...
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.
You’d be surprised how much you can handle with a single beefy VPS or dedicated.
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.
And I don't have to worry about accidentally unplugging my server or downtime for OS upgrades.
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.
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.
Yes, that makes about as much sense as people who can't get over their favourite RSS reader, 13 years on.
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/
> 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.
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.
More importantly, with those hypothetical numbers, you'd stay well within the free tier for compute.
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 20€ 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 150€ for the CPU, 77€ 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?
Where are you getting all that at that price?!