Hi Daniel, I use automatic scaling with 1 max-instances in my dev project. This is one thing that helps to limit the costs of the dev environment.
I also debug and test the app locally first, before I deploy anything to GAE. In your case with Node.js flex: <https://cloud.google.com/appengine/docs/flexible/nodejs/testing-and-deploying-your-app> npm start You can do this in Cloud Shell, too. Another measurement was to use a different app.yaml and cron.yaml in dev project than in production project. In app.yaml I define auto-scaling with max-instances 1 and F1 (because 28 hours of F1 are free in standard environment). Although there is no free tier for flex instances, you still can define cheaper virtual machine types for dev. Cron-job tasks are scheduled far less frequently than in production, because I typically debug/test them by triggering them manually and I don't need them to actually run in dev project in contrast to production. You probably also want to make sure that in dev (!) project, with every new deploy every previous version is stopped and the new version is promoted to default version, e.g.: gcloud app deploy app.yaml --promote --stop-previous-version See the gcloud app deloy reference <https://cloud.google.com/sdk/gcloud/reference/app/deploy> for details. Alternatively, you could overwrite an existing version, by specifying the version to replace: gcloud app deploy app.yaml --version=v-ani-dev This would also work with multiple devs deploying to the same dev project, although I usually would go with one dev project per dev. Then also have a QA project where you can deploy and test release candidates before they are deployed into staging or production. (Basically, dev -> qa -> staging -> production) One last thing: I do not use production data in dev or QA (for cost reasons, but also for security reasons). Instead I would use only a small subset of fictive sample data that reflects the nature of the production data. You always can use import/export features of Cloud Datastore, Cloud SQL etc. to restore sample data if for example you debug a new feature that changes schema. And only provide production data to the staging project (using export/import again) if you need to test that a migration will run successfully through your entire production data. That can be quite expensive though. Hope that gave you some ideas. On Thu, Jul 19, 2018 at 2:56 PM Daniel Iñigo <din...@divisadero.es> wrote: > I found myself in the same situation. > > A couples months ago we were going through heavy *development / deploying > / testing* and got ourselves with a *huge* bill. Do you confirm that > using automatic scaling and setting it to 1 max-instances will fix it? > > Thanks in advance. > > El sábado, 18 de marzo de 2017, 17:39:42 (UTC+1), Adam (Cloud Platform > Support) escribió: >> >> Are you using manual scaling or automatic scaling in your app.yaml? If >> you're using manual scaling, App Engine will try to keep instances alive >> indefinitely >> <https://cloud.google.com/appengine/docs/flexible/nodejs/how-instances-are-managed#instance_uptime> >> until you manually shut them down. >> >> On Thursday, March 16, 2017 at 3:10:07 PM UTC-4, Alan deLespinasse wrote: >>> >>> I'm not sure if this is a bug or expected behavior. It's not what I >>> expected, but I'm still somewhat confused by the Cloud Console. >>> >>> I have several services for which I noticed there were still some old >>> versions running, although the old versions were serving 0% of traffic. >>> Example: >>> >>> >>> <https://lh3.googleusercontent.com/-YZWAxJMW7x4/WMrgCXinq6I/AAAAAAAAMac/iRAXXz_vhjYU9072hPy7ZXGENs4bvoCfQCLcB/s1600/oldservices.png> >>> >>> The two selected versions were made obsolete by the top version. >>> Normally when I deploy a new version, the previously running version is >>> shut down. In these cases, I think a new version never succeeded in >>> starting up, because I had a bug that would simply crash every time. So >>> here's what apparently happens: >>> >>> 1. Version A is running >>> 2. I try to deploy version B; it repeatedly fails to start up. My >>> "gcloud app deploy" command eventually returns an error, telling me that >>> deployment failed. Version A is still serving all traffic. Version B is >>> apparently still running, though I didn't know that until just now. >>> 3. I fix the bug and deploy version C. It starts up, version A is >>> correctly stopped. Apparently version B is still running, though. >>> >>> So, is this a bug or expected? Is it costing us money? I'm finding it a >>> bit hard to tell what our recent charges are for, although they are a bit >>> higher than expected (still looking into that). I'd submit a billing ticket >>> if I was sure. >>> >> -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-appengine+unsubscr...@googlegroups.com. > To post to this group, send email to google-appengine@googlegroups.com. > Visit this group at https://groups.google.com/group/google-appengine. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/6678e51f-cb09-4cac-b4cc-83890975bbbd%40googlegroups.com > <https://groups.google.com/d/msgid/google-appengine/6678e51f-cb09-4cac-b4cc-83890975bbbd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Ani Hatzis Consultant and developer for Google Cloud solutions <https://www.credential.net/ukfxy03s> <https://www.credential.net/b0y6kwie> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CALdDuQ59RCZF83C7ei%2Bof%2BK4-Y5A0Rtvga3yfuSnOKrD-ot5dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
