I'm evaluating Azure Stream Analytics (ASA) for a mission critical event data processing application. The SLA for ASA is 99.9, which is not sufficient for my use case. Has anyone developed a good strategy for ensuring high availability with ASA?
Related
I need to calculate pricing for azure stream analytics and i'm confused with the field 'Devices' under 'Stream Analytics on IoT Edge'. is it important for estiamating pricing ? if yes, how to fill it?
Are you planning to run Azure Stream Analytics jobs on edge devices?
Note that this is not running Azure Stream Analytics jobs on edge device data. But actually deploying jobs on a device so it can run the query locally.
For most use cases the answer to the first answer is no, and 0 should be put in that box.
I have a use case in IoT streaming, in our current architecture data from the IoT hub is consumed by our stream analytics jobs for realtime reporting on powerBi dashboards. I want to be able to expand this to additional tenants now. From what i have gathered this seems to be possible with dedicated azure stream analytics clusters and i dont seem to understand how the ingestion to the clusters would occur? Would it mean i will need to have a load balancer between my IoT hub and stream analytics jobs? Or is there a better way i could achieve this?
I would need to know that,
Is stopping Azure stream analytics service will stop the costing.
As per the answer from MSFT: For Azure Stream Analytics, there is no charge when the job is stopped.
But for Azure Stream Analytics on IoT Edge: Billing starts when an ASA job is deployed to devices, no matter what the job status is (running/failed/stopped).
Welcome to Stackoverflow!
Note: There is no charges for the stopped jobs. It will be billed on basis on steaming units in Cloud and jobs/devices in Edge.
Detailed explanation:
As a cloud service, Stream Analytics is optimized for cost. There are no upfront costs involved - you only pay for the streaming units you consume, and the amount of data processed. There is no commitment or cluster provisioning required, and you can scale the job up or down based on your business needs.
While creating stream Analytics Job, if you created a Stream Analytics job with streaming units = 1, it will be billed $0.11/hour.
Pricing:
Azure Stream Analytics on Cloud: If you created a Stream Analytics job with streaming units with N, it will be billed $0.11 * N/hour.
Azure Stream Analytics on Edge: Azure Stream Analytics on IoT Edge is priced by the number of jobs that have been deployed on a device. For instance, if you have two devices and the first device has one job whereas the second device has two jobs your monthly charge will be (1 job)(1 device)($1/job/device)+(2 jobs)(1 device)($1/job/device) = $1+$2 = $3 per month.
Hope this helps. If you have any further query do let us know.
I noticed that both Azure Functions and Azure Stream Analytics can take an input, modify or transform that input, and put it into an output.
When would I use one versus the other? Are there any general rules I can use to decide?
I tried looking at the pricing of each to guide me, but I'm having trouble discerning how my logic would affect the compute time cost of Functions versus the App service plan cost of Functions versus the streaming unit cost of Stream Analytics.
Azure Stream Analytics is a real time analytics service which can "run massively parallel real-time analytics on multiple IoT or non-IoT streams of data" whereas Azure Function is a (serverless) service to host functions (little pieces of code) that can be used for e.g. event-driven applications.
General rule is always difficult since everything depends on your requirement, but I would say if you have to analyze a data stream, you should take a look at Azure Stream Analytics and if you want to implement something like a serverless event-driven or timer-based application, you should check Azure Function or Logic Apps.
I'm struggling at understanding if and what needs to be done to provide for high availability of two different types of Azure resources:
Azure Service Bus
Function Apps
Service Bus guarantee at least 99.9% of the time for most of the service (includes Relay, Queues and Topics, Notification Hubs). Besides, replication and partitioning messaging entities (Each partitioned queue or topic consists of multiple fragments. Each fragment is stored in a different messaging store. If the corresponding messaging store is unavailable, Service Bus writes the message to a different fragment, if possible.) could be used as common solution for high availability.
The following article would be helpful, please read it.
High Availability and Disaster Recovery for Azure Service
Bus
For Function Apps running on App Service Plans Microsoft guarantee that the associated Functions compute will be available 99.95% of the time. So if possible, you could run your Function App on an App Service Plan and enable the Always On setting.