We are using Application Insights to track some basic telemetry of a WPF application. As we have developed the app we have just been using the Basic subscription, but we would like to make use of the continuous export feature which requires the Enterprise.
But according to the pricing page the Enterprise is charged at $15/node/month, will it treat each users pc as a node? It is not really clear as AI is really aimed at web servers.
I am happy to pay for 1 node and whatever extra data charges are incurred but unsurprisingly $15 per user machine per month is not affordable.
It is based on the role instance, so basically the machine name. You should just stick with the basic plan unless you need the OMS Connector or Continuous Export. If you have this deployed to hundreds of machines and need these features ping #DaleKoetke on twitter. I think he might even have his e-mail there.
This is a response I got from Microsoft:
What we have to understand is few things.
For assumption Node==Client
Continuous feed to Node – We count the number of distinct nodes sending telemetry data each hour. If a node does not send any telemetry during a particular hour, then it is not counted. The monthly per-node pricing for enterprise($15) assumes a node is sending telemetry every hour of the month, so if there are periods of inactivity for your application during the month, the actual charge will be lower.
So the short answer is yes we charge per node however the charge is proportional to the “activity feed”. No activity no charge and the enterprise charges will decline/node.
Calculation:-
So lets say you have 744 hours in a month and there is continuous feed for one node that is priced t $15.
So we see that every hour $0.020 is being charged for continuous feed/node.
You will need to calculate the continuous activity feed on the clients machine to get an idea of the charges.
Related
I currently embed my Power BI report to my website by create Azure AAD and upgrade power bi user to PRO license, and follow the guideline from github. It worked well in testing environment. By this way I can do the filter, each of my customer can only see their data. But I found that if I want to implement in production environment I have to register Power BI Embedded service from Azure. It's quite expensive, the lowest option allow only 300 renders/hour, if I have 100 customers and they often refesh the embedded report, It would hit the limitation.
Is there any other way to embed power bi report to website with lower cost?
It is quite expensive. Here is the full list of Power BI embedded pricing:
https://azure.microsoft.com/en-us/pricing/details/power-bi-embedded/
The PowerBI bills on an hourly rate based on the type of nodes deployed. So if you don't keep your instance active and shut it down after 5 minutes, you'll only owe about 10 cents per month. If you need to have your embedded content loaded all the time this will definitely be a problem, but if you are okay with pausing the service that can save you some money.
I'd like to make a GAE app multi-tenant to cater to different clients (companies), database namespaces seems like a GAE endorsed solution. Is there a meaningful way to split GAE fees among client/namespaces? GAE costs for app are mainly depends on user activities - backend instances up time, because new instances are created or (after 15 min delay) terminated proportionally to the server load, not total volume of data user has or created. Ideally the way the fees are split should be meaningful and could be explained to the clients.
I guess the most fair fee splitting solution is just create a new app for a new client, so all costs reported separately, yet total cost will grow up, I expect few apps running on same instances will use server resources more economically.
Every app engine request is logged with a rough estimated cost measurement. It is possible to log the namespace/client associated with every request and query the logs to add up the estimated instance costs for that namespace. Note that the estimated cost field is deprecated and may be inaccurate. It is mostly useful as a rough guide to the proportion of instance cost associated with each client.
As far as datastore pricing goes, the cloud console will tell you how much data has been stored in each namespace, and you can calculate costs from that. For reads/writes, we have set up a logging system to help us track reads and writes per namespace (i.e. every request tracks the number of datastore reads and writes it does in each namespace and logs these numbers at the end of the request).
The bottom line is that with some investments into infrastructure and logging, it is possible to roughly track costs per namespace. But no, App Engine does not make this easy, and it may be impossible to calculate very accurate cost estimates.
After reading the pricing of the new google relational database Spanner, it states that the cost is based on storage and use. They charge $0.9 by hour per node.
The question is: if I create the database for development, and only use it 6 hours a day, 100 hours a Month as maximum... Do I have to pay only for the hours with active use (receiving queries) or for the whole month? The charge is similar to App Engine instances?
In the first case, there is no problem spending US$90 for testing this new database, but if they charge for the whole month (using it or not)... the cost rise to US$670/month...
Anyone has been using this database and can share the final cost invoiced?
In the tutorial they recommend to delete de database after testing, but for development deleting the database and recreating database and data every day is not suitable.
Correct, you need to maintain at least 1 node to keep the data, and you need at least 1 node for every 2 TiB of data.
So, if you upload 50 TiB of data, you need to keep 25 nodes at a minimum to maintain the data.
More info - https://cloud.google.com/spanner/docs/limits
You are charged for any resources in your instances (while the nodes are running and storage is being used), even if you aren't actively issueing queries. It's like Compute Engine or Cloud SQL.
I'm redesigning a monolith application into a MicroServices architecture and am hoping to use Google Cloud Platform (GCP) to host the entire solution. I'm having a very hard time understanding their costing breakdown, and am concerned that my costs will be uncontrollable after I build it. This is for a personal project but I'm hoping will have many users after I launch so I want to get the underlying architecture right and at the same time have reasonable costs initially when I launch.
Here is my architecture:
MicroServices 1 - 4 (Total 4 API Services):
Runs on App Engine
Exposes a REST API and saves data to DataStore
Initially each API should get hit around 200 times a day
MicroService 5 (Events triggered API Service):
Runs on App Engine
Listens for PubSub events and saves to DataStore (basically I have a sensor that pushes data to this Service for storage)
Initially the PubSub should receive events around 200 times a day
MicroService 6-7 (Total 2 UI Services):
Runs on App Engine
These are UIs so people can login and use the systems. The UIs are lightweight frond end apps that use the REST Services above to populate user data in a nice way.
Each UI Service should be used around 3 hours a day
So in Total I have 7 MicroServices with each running as AppEngine "Services" in a single GCP "Project". A DataStore is shared between these APIs within this Project.
As I have 7 App Engine instances running, and they only need to be operational for a short period of time per day, how does the pricing work?
I want to use App Engine because it's completely Managed, which is one of my design requirements. But I'm hoping AppEngine has some kind of Sleep Mode, so that when there is no usage it does not bill?
Any help in understanding what my monthly costs would be would be appreciated.
Thanks very much.
Update 8/2/2017
I've decided to stay out of GCP for now. As I hope to have 7 App Engines Services running in Flex (as they are node.js) I don't seem to get access to a free tier or the ability to scale idle services to 0 instances.
This means I'll be paying full price for these services. (i.e. 7 X Full App Engine VM Cost per Monthly :O )
This is an expense I cant have just for a POC of a proper MicroService design. Instead I'm going to continue with my MicroService design but use a 10$ DigitalOcean box and Dokku to containerise my Services. If this works well and I have a need I will migrate this design to GCP (or AWS)
The full outline of App Engine instance handling is available at https://cloud.google.com/appengine/docs/python/how-instances-are-managed .
In short, your best bet is to enable automatic scaling and set
max_idle_instances = 0
in your app.yaml.
That means that your app will autoscale to handle traffic as needed and shut down the instances afterwards. Also
When settling back to normal levels after a load spike, the number of idle instances can temporarily exceed your specified maximum. However, you will not be charged for more instances than the maximum number you've specified.
Later - when load time becomes more important you can set min_idle_instances to a more suitable number - this allows for responsive apps.
am concerned that my costs will be uncontrollable after I build it
You should be aware that automatically scalable GAE apps always have cost components dependent on the external user request patterns which are not controllable.
For example, in the standard GAE env, the way those 200 requests/day are distributed matters significantly:
if they are evenly distributed they will come in less than 15 min apart - the minimum billed time per instance lifetime, so the respective service will be billed for minimum 24 instance hours per day (very close to the daily 28 free instance-hours/day for billed apps, only a single-service app using the smallest instance class can fit in it).
if they are all received within a 15 minutes interval the service will be billed for 0.5 instance hours daily (which can easily fit in the free daily quota even with multiple services and/or with more powerfull instance classes).
The actual scalability configuration of each service can matter as well. See, for example,
The only way to keep costs under strict control is via the daily budget configuration (but hitting that limit means your app's functionality will be temporarily crippled).
All other usage-based costs being equal due to the functionality being performed you have some (potentially significant) control over costs via:
the GAE environment type selected for each service:
the standard env is billed by instance hours and includes a free daily quota
the flex env has no free daily quota.
the number of services: you could start with fewer services by combining their functionalities (you can still keep them modularized for later split). The expected initial load you describe can easily fit within the free daily budget with just a single standard env service.
Once the app usage picks up and the free daily quotas percentage in the total costs become neglijible you can gradually split the app into multiple services as needed. In general this can be a relatively simple task if the app is properly modularized.
I have developed a mobile application which is using extensively web services. It connects to my shared hosting server to get real-time information. Therefore, making sure the server is up is extremely important. Otherwise I am going to lose customers.
Some background. I changed no less than 3 hosting providers because they were not very reliable in terms of uptime. My currrent hosting is way better than those previous three, have I used it now for over a year, they have 99.9% uptime guarantee and all, but today I had about 3 hours of downtime. Which is why I am creating this post.
Not all of us small developers can afford expensive dedicated hosting, or have our own servers at home (which is not a guarantee it never will be down). In my case, having shared hosting for a very reasonable $10-15/month is OK. Except for those few hours it might be down.
One idea I have to deal with this is the following: have a second (different) shared hosting with another provider, and make the app to default to using this second hosting when my primary host is down. It's very unlikely that both will be down at the same time. I am going to pay only a few dollars extra per month for this, not 10 times more per month as I would for a dedicated hosting.
I am sure I am not the first person in this situation. Have anyone found a good way to deal with this problem, not requiring deep pockets? We are after all talking only about short periods of downtime on the primary server.
Thanks in advance for your suggestions.
If you are relying on a third party host and don't want to pay for greater reliability then a second server is the way to go. Depending on your application and budget you will also need to consider:
Database access and synchronization
Hosts in different physical locations
Multiple domain names and/or load balancing
If you opt to use multiple hosts and switch to a different (backup) host if one (the first) fails then you should aim to always have both (all) always in use. This way you won't get caught out trying/having to switch over to a "backup" server. By always using both (all) you can be sure that they are both (all) always up to date and working.
If your service is so critical that a couple of hours down time would be unacceptable to your users, then it should be easy to get the users to pay for that kind of reliability. This could fund hosting with a provider who can provide a greater level of up time or a second site. This will also help fund the time and effort to set all this up. ;)