I got some credits for using GCP. It asked me for a credit card before accessing. Since it is quite tricky to monitor the cost in real time, I hope to set up a circuit breaker such that once my credit runs out, all my VM instance jobs will cease running. I understand there will still be some small charges for space and static IP, but they are OK.
Is such a circuit breaker feasible? I checked some FAQs on budget alerts, e.g., https://cloud.google.com/billing/docs/how-to/budgets, but there appears no mentioning of it.
Thanks.
It's possible to be notified progammatically by creating a budget then using pub/sub which that'll push a Cloud Function to stop your resources. Here is an example based on the previous suggestion.
Related
I'm planning a project and working through all the potential issues I might face. One that I keep running into which might be specific to my project is concurrency issues. From my understanding, Azure Functions scale when under demand which is exactly what I'm looking for but causes a problem when it comes to concurrency. Let me explain the scenario:
Http triggered Azure Function which does the below
Gets clients available credit, if zero, auto-charge clients card.
Deduct credit from the client for the request.
Processes the request and returns to the client.
Where I see an issue is getting the available credit and auto-charging card. Due to the possibility of having multiple instances of the function I might auto-charge the card multiple times and on top of that getting and deducting the credit will be affected.
I'm wanting the scaling of Azure Functions but can't figure a way around these concurrency issues. Any insight or pointers in the right direction would be very much appreciated.
EDIT: STILL NOT ANSWERED. I appreciate the advice I have received so far, but I still have not found a proper way to test the amount of resources my server is using. I decided to use GCE instead of GAE but I still want to measure the resource usage.
I have searched all over google as well as SA and can't seem to figure this one out.
I would like to deploy my (very small) node.js server to either Google App Engine or Google Compute Engine (not sure which to use yet).
I see that they charge based on how many resources you use, but how can I check this before I make my decision? Basically what I would like to do is find a way to analyse my server and see what CPU/DISK/NETWORK/RAM/Etc it uses, and then possibly make some refinements to my code to get the usage down as low as possible.
I am a hobbyist programmer and this server is just for personal stuff so I don't need anything fancy. I just want to get it hosted on google and not my home server. My real fear is that, since I am not a professional, my code might be doing some crazy background stuff repeatedly that would rack my usage up for nothing.
Quick rundown on what my server does:
Basic node.js express template that IntelliJ made me, then I added my code to sit and listen to a Firebase. When the firebase gets a message (once or twice a day maybe, text message equivalent size) the server sends a quick GCM/FCM message to a few devices. Extremely simple server, very little code. Nothing crazy.
As a little bonus for me, if you have a suggestion as to which platform I should use, I am all-ears.
If you do not need this server to run 24x7, use App Engine. It stops an instance if it is not being used for 15 minutes. The startup time for new instances depends on your code, but for Node.js instances it should not be long.
Generally speaking it is easier to run an app on App Engine than Compute Engine, but if you use a single instance and don't change code often the difference is negligible.
App Engine has a generous free quota. You may end up paying nothing until the usage gets over a certain threshold.
You can run some diagnostic tools on your existing server, but even then you will get an approximation - a server with a different combination of resources sitting on a different network may use resources differently. You may be able to get a rather accurate estimate of memory usage, though.
If this is a small app with not too many users, even a small instance should be able to handle it. There is no harm in trying - start with the smallest instance, test, go to the next instance up if tests fail. Your key concern should be to have enough memory to handle a small number of requests.
As for the number of requests your server can handle, you can configure automatic scaling. It is a default option in App Engine and can be enabled for flexible runtime. Then you can have the smallest instance (i.e. your server does not crash due to the lack of memory) running, and another instance will be added if and when that small instance is not enough.
Well, after over a month I figure I might as well answer this myself.
What I ended up doing was creating a basic instance on Computer Engine (the micro. Smallest one available) and letting it just sit there for a few weeks. I looked back at the data to see what some good baselines were and took note.
Then I took my server code and ran it on the server. I left if there for a few days, changed it, updated it, etc. Just tried to simulate the things I would be doing. Sent messages on my client app (that's what this server is doing after all is said and done) and I let this go on for a few more weeks.
The rest is history. I looked at the baseline then looked at my new memory, CPU, network and disk usage and there we go. Good to go. My free trial still isn't even over so it was a free experiment.
The good news is that my server is more 'lightweight' than I thought.
Is there a way in Orleans to make sure X reminder grains of same type are hosted on different silos?
Motivation:
I want to use Orleans in an Azure cloud service that runs background processing and should be highly resilient to failures and to silos downtime due to in-place upgrade. In my scenario there is a need for a grain that is always active doing it's job using timers, and if it’s hosting silo goes down then it should be activated again on another silo in few seconds. During an Azure cloud service upgrade, the instances are divided into 5 groups, one group is upgraded at a time, which means during an upgrade I always have 20% of my instances shut down, which makes it challenging to have an always active grain. I consulted with Sergey Bykov and we came up with several ideas, one of them was introducing “keep alive” grains that their purpose is to ping the “always active” grain to make sure it’s active. In order to make that work during upgrades, I need to make sure there is always at least one “keep alive” grain that its hosting silo isn’t in the same upgrade group as the silo that hosts the “always active” grain, so that “keep alive” grain will be able to make the “always active” grain be re-activated on another silo that isn’t shutdown at that moment.
I recently was reading the Orleans Timers and Reminders documentation which contained the following nugget which may be relevant. Highlighting is my own.
Reminders
Description
Reminders are similar to timers with a few important differences:
Reminders are persistent and will continue to trigger in all situations (including partial or full cluster restarts) unless explicitly cancelled.
Reminders are associated with a grain, not any specific activation.
If a grain has no activation associated with it and a reminder ticks, one will be created. e.g.: If an activation becomes idle and is deactivated, a reminder associated with the same grain will reactivate the grain when it ticks next.
Reminders are delivered by message and are subject to the same interleaving semantics as all other grain methods.
Reminders should not be used for high-frequency timers– their period should be measured in minutes, hours, or days.
Further Comments
It is possible that this isn't a solution in your case because of the final note about high-frequency. If you have a single point of failure that can't go down, it might be relevant to consider alternative solutions. :-/
The particular case that I am looking at using this for is precisely for a 5 minute polling interval. I need to call a web service, gather some data and then process it.
My only other thought is to make my polling-based implementation super lightweight so that it can be quickly brought up to speed as the underlying infrastructure is changed.
It appears that there is a decent bit of documentation here regarding activation placement strategies.
We're transitioning to a managed service provider for our IT service desk and deskside and we're working out the details of their SLAs. Many of the SLAs are based on ticket status. An example of this is the following:
"Measures the amount of time it takes to assess, schedule, test, and package application packages before they are available for User Acceptance Testing."
My first thought was to try using SLAs to measure this, as they neatly tie together calendars and priorities, but I'm having a really hard time finding any information about how I could do this.
Now I'm looking into using the TKSTATUS.STATUSTRACKING attribute on tickets, but I believe this just tracks straight 24/7 time instead of taking into consideration any calendars.
Has anyone tried this before? Any suggestions?
We are in a similar process, but we are measuring time on site of vendors for our work orders. Opposed to using any SLAs we have diffrent statuses which mark different events. Then when we want to know how long it took for an event to finish, we look to see the time required to change status in the wostatus table.
I've developed a simple system using ASP.NET MVC and WCF for customers to register software and get a license key. I was thinking about using Windows Azure instead of a traditional web hosting because it seems easy to use. I'd only need one SQL database and one small VM, but I'm confused about the billing.
Does the billing only charge as people actually use it, or would I pay the fee for each CPU every hour of everyday for the whole month because that was what was available to users? So for one single cpu VM at $0.12 an hour in a 30 day month I'd pay $86.4? Or would I pay less if no one used it? Then another $9.99 for an up to 1GB database, so for my needs I'd basically pay $96.39 a month?
That seems expensive for basic web hosting, but if it's easier for someone with little hosting experience to set up and maintain as well as making it easy to expand if I suddenly got a lot of traffic then it would certainly be worth it to me.
EDIT: I think I found the answer here: Getting started with Windows Azure
You're correct regarding the $0.12 / hour: you're billed based on resources consumed (meaning virtual machine instances), whether you're running at 0% cpu or 100% cpu.
While it might seem expensive compared to your average shared-hosting provider, consider that you're getting health monitoring, failover, SLA (if you have 2 or more instances) upgrade domains, etc.
I have two blog posts that go deeper into Compute Instance billing that you might find beneficial:
Part 1: The True Cost of Web and Worker Roles
Part 2: Staging and Compute-Hour Metering
I hope this helps...
The rule for billing is quite simple: if you look at the protal, there are the "gray" or "blue" boxes showing for a deployment.
If the box is gray, you are OK. If the box is blue, a bill is due.
This means that charges for every hour will be made whenever the box is blue, that is: once a deployment has been done, whether it's stopped or running.
Now you have a new feature in windows azure called WebSites. Deploying a website which have only a small amount of visits. It is simply 'free'. This is light weight website running in a shared environment.
http://www.windowsazure.com/en-us/pricing/calculator/ -> Check for websites.