We would like list out all the active Senders and Listners for a given realm. Is there any API available to query the Service Bus for this information?
We've been getting that question several times in recents months. We're going to add better metrics to Service Bus in the next several months and the number of active listeners is one of the counters that's high up on the list. Senders is more difficult because that number is extremely volatile. We have a spec'd out feature to provide trends across a number of meters and senders is one where a trend is probably a reasonable way to show how the traffic looks.
I can't provide a better timeline for either, unfortunately.
Clemens
Related
I am using UPS APIs to figure out ratings and create shipments and now I'd like to track shipments in real time. I know there are a lot of services that provide tracking aggregation for different couriers, including UPS, via webhooks, but I am looking for a "native" UPS API for the real time tracking that would not require me to keep poling for updates.
I went over the UPS API docs and could not find anything. Is there such an API that offers webhook type notifications or something similar in UPS? If not, how do those services like EasyPost, ParcelMonitor, TrackingMore and others can offer such functionality?
I'd like to track shipments in real time
"Real-time tracking" is a misnomer in the shipping technology industry. EasyPost does provide webhook events to notify you of updates, but those updates will never come in "real-time" and no tracking service provider should ever make such a claim. There will always be some kind of delay between when the carrier updates their system and when the updates are able to flow through providers like EasyPost. The delay may be short, but any delay at all means that "real-time" goes out the window.
Being an EasyPost employee myself, I have to disclose my bias and say that I believe EasyPost can help you get updates as promptly as possible for UPS shipments.
The nice thing about setting up webhooks with EasyPost is that you don't have establish your own logic to repeated poll for new tracking updates. This can save you network bandwidth and reduce the complexity of your code and it can help you get updates sooner than if you were trying to poll updates on your own intermittent schedule.
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.
I have 100,000+ addresses that need to be geocoded, but most geocoding services seem to cost money after the first couple thousand entries. Is there any free service that can geocode what I need either in one go or in a relatively short amount of time i.e. a couple weeks at most while being free or relatively cheap?
Also, I may have access to arcgis and I'm wondering if arcgis's geocoding service have a limit if you have the premium version.
The answer is No, there are no free services that will handle 100,000+ entries.
Although it can be argued that one can write a script that will handle geocoding actions in sequence and parallel, i.e. Google's geocoding API with 100 instances running at 2500/day. It is unrealistic and violates their Terms of Service.
To my knowledge, ArcGIS also has a limit as well.
Your best bet is that if this is company or business related, have them foot the bill.
I'm designing an architecture for leveraging Azure Search for multiple tenants. Since each tenant will have a slightly different schema my solution will require 1 index per tenant. This is easy enough to set up and I'm really liking what Microsoft has put together. However now that I am starting to think about on-boarding new tenants, monthly costs and scaling up the service I am starting to hit a few walls and wondering what my "best" option is.
Has anyone encountered this situation that can shed some light onto best practices? Here are the options as I see them now:
Option 1:
Spin up a new BASIC plan for every 5 tenants at a cost of $38/m for every 5 tenants ($7.60 per tenant per month).
Pros: Cheap to start.
Cons: Tenants are crippled by the limited performance and storage capabilities, I'll have to manage X number of services and ClientQueryKeys once I get past 5 indexes/tenants.
Option 2:
Spin up a new STANDARD S1 plan for every 50 tenants at a cost of $250/m for every 50 tenants ($5 per tenant per month).
Pros: Better performance, less services to manage as tenant counts increase
Cons: Much higher costs to start, still need to manage tenant-to-service relation once system has greater than 50 tenants, I'll have to manage X number of services and ClientQueryKeys once I get past 50 indexes/tenants.
Option 3:
Spin up a single STANDARD S2 plan that can be used for ALL tenants (assuming no cap on index count)
Pros: Better performance, no need to manage multiple services/client keys as tenant counts increase
Cons: Much higher costs to start, very little documentation on costs and limitations.
In all scenarios (aside from option 3, I'm assuming?) I would have to manage client keys across multiple services. So obviously having only one service with an infinite index count is ideal. However I am a startup (yes I am using BizSpark already) and the costs for search a very daunting when I may only have 1-5 tenants to start.
I've read that there is no way to easily migrate data between plans (without doing it manually or writing a script) so my first choice is likely to be my last. I would also prefer to only have to manage one service with one plan for all my tenant. Therefore I am leaning to option 3.
If option 3 is the best option:
Can I start on BASIC and scale up to S1 then S2 as needed, or is this not possible?
If BASIC cannot scale to S1 is it at least possible to scale from STANDARD S1 to S2 once I go past 50 tenants or will I need to manually manage this or start at S2?
What are my startup costs and/or costs per index/tenant on Standard S2?
Is my index limit infinite on S2?
If not, what is the index cap?
Are there any other options or caveats that I should consider?
S2 services work much better in multi-tenant scenarios. Not only they can fit more indexes (up to 200), but they also have more overall capacity so assuming exponential distribution of index sizes and loads, you get a better typical experience for your customers.
You're right that the cost of entry is higher.
Regarding the cons of S2, soon we're going to publish proper documentation and other supporting materials for it. In the meanwhile, feel free to contact me directly (Pablo DOT Castro AT the usual Microsoft domain) for more details.
If you think you'll have lots of indexes in the future (many 100s), we're also working on options for better multi-tenant support. We're not ready to announce the details yet but I'm happy to discuss if you get in touch with us.
Answering your specific questions:
1.Can I start on BASIC and scale up to S1 then S2 as needed, or is this not possible?
We don't currently support this. You'd have to create a new search service and migrate the indexes.
2.If BASIC cannot scale to S1 is it at least possible to scale from STANDARD S1 to S2 once I go past 50 tenants or will I need to manually manage this or start at S2?
No, it's not. We want to do this, just have not gotten to it yet.
3.What are my startup costs and/or costs per index/tenant on Standard S2?
Please get in touch with us and we can discuss pricing.
4.Is my index limit infinite on S2?
5.If not, what is the index cap?
No, S2 services are limited to 200 indexes/service.
6.Are there any other options or caveats that I should consider?
You've done a good analysis, I think you're on the right track. One thing you may want to consider is fairness. All indexes in the same service share the capacity you've provisioned for the service. If there's risk of unfair loads you might want to consider per-tenant throttling.
I am trying to understand the pricing shceme of Pusher. According to their pricing, the Boostrap allows 100 max. Connections. My question is this: if I have 10,000 daily visitors to my page, each one subscribed to a different channel to receive messages, how much I need to pay.
With realtime.co it's easier to understand because I know that I pay $1.00 per 1,000,000 messages without any other limitations. So I need to know how to calculate and estimate the total cost for my application, becaues I might designed it in a different way to reduce the costs.
I am considering choosing betwee, PubNub, Pusher and realtime.co, but knowing how to calculate estimated total cost is crucial for me because beginning to develop my application and going with a specific client/server library.
See the Pusher FAQ post: How are Connections Counted?