Reading through Azure documentation on Cognitive Service LUIS and Text Analytics, and it only mentioned the on-prem container offers the "same capabilities", but not mentioning if it is the same model, in terms of quality and deterministic behaviors.
Any model quality difference between Azure Cognitive Service container vs Cloud that someone could offer any insights?
As Azure cognitive service official indicated :
Cognitive Services containers are an alternative to the Cognitive
Services cloud.Cognitive Services containers are an alternative to the
Cognitive Services cloud. Containers offer the same capabilities as
the corresponding cloud services. Customers can deploy the containers
on-premises or in Azure. The core AI technology, pricing tiers, API
keys, and API signature are the same between the container and the
corresponding cloud services.
So there will be no differences between between Azure Cognitive Service container and Cloud. And Azure Cognitive Service container provides customers flexibility in versioning and updating of models deployed in their solutions
If your data can not be used on Azure due to some privacy or regulatory restrictions or you are using massive data loads, which would either be too expensive or time-consuming to bring to the cloud or High throughput / low latency is required ,using Azure Cognitive Service container will be a great practice.
Related
I have multiple RESTful APIs that are hosted in azure web app / azure service plans and covered by application insights
I have setup availability tests on top of these API using application insights which when triggered call an azure function
There is an auto resolve setting for availability tests which lets your hook up alerting when the availablity issue has been resolved.
However I didn't find anything on similar lines for Failure Anomalies
Question:
How do I setup a webhook call back on azure application insight failure anomaly detection ?
Doesn't Azure support Geo-Redundancy and Multi-region Writes options for serverless CosmosDB Core(SQL) account? But, those options are listed for Provisioned throughput capacity.
Yes you are right, It's a limitation with Serverless Accounts, According to docs,
A serverless account can only run in a single Azure region. It is not
possible to add additional Azure regions to a serverless account after
you create it.
There is some work being done in this area, but there is no ETA yet.
We started our planning phase on a new project and we settled on a ASP.NET REST API which should be hosted on Azure. Since none of us has any experience on deployment on Azure (or any other cloud service), I have two questions.
Do you need separate Azure Services for the Database and the API, or might there be a combined "package" for the prototype, which later can be changed easily?
Is there any documentation or are there any examples of the entire deployment process of a simple dummy API and the DB? I have spent the last few hours reading the official documentation and searching around, but I would really love to see some sort of reference, just to ensure I don't miss something.
For now, the best I have found is this and this. This seems rather shallow, so I really hope, that there might be more.
If you're looking for in-depth design an implementation details then I would suggest that the Azure Architecture Center would be an excellent place to start, for hands on experience there are hundreds of free courses available on Microsoft Learn.
Specifically there are sections on API design and API implementation. From the Serverless web application page is:
If you don't need all of the functionality provided by API Management, another option is to use Functions Proxies. This feature of Azure Functions lets you define a single API surface for multiple function apps, by creating routes to back-end functions. Function proxies can also perform limited transformations on the HTTP request and response. However, they don't provide the same rich policy-based capabilities of API Management.
Function Proxies
I would suggest starting with using Azure Functions for your API (you only pay for the number of calls + a combination of CPU, memory, and runtime, but the first 1,000,000 calls per month are free (consumption plan), rather than paying for an Azure App Service to host your API and run all the time but only be utilized some of the time.
Some links that might help:
Build Serverless APIs with Azure Functions
Customize an HTTP endpoint in Azure Functions
There is an excellent summary in this article that states:
For the heavy workloads.
Private(enterprise) API - API Management with a Premium plan.
Public API - Functions Proxy with the Premium plan.
For light/moderate workloads.
Private API -Functions Proxy with the Premium plan.
Public API -Functions Proxy with a Consumption plan and custom warm-up solution.
Then from here you can use a connection string to an Azure SQL DB inside your functions to write to the DB or something like Azure Managed Identity (yes the link is for Azure PostgreSQL but the process will be much the same for Azure SQL).
In terms of deployment you should be looking at using Azure DevOps (or GitHub Actions):
Setting up a CI/CD pipeline for Azure functions (old way - GUI pipelines)
Deploy an Azure Functions app to Azure (new way - YAML pipelines)
Continuous Delivery for Azure SQL DB using Azure DevOps
Another helpful tool to get a gauge of costs is the Azure Pricing Calculator.
I've been having a hard time finding the SLA behind Google Firebase Authentication. According to Service Level Agreement for Hosting and Realtime Database, Firebase shall be available with a Monthly Uptime Percentage of at least 99.95%. Does it apply to the Authentication Services?
Here is what I got from Google Support when I asked about the differences between Firebase Auth and Cloud Identity Platform.
The reason for the pricing difference
between Firebase Auth and Cloud Identity Platform is Cloud Identity
Platform offers a SLA of 99.95% while Firebase Auth has no SLA.
They also mentioned other reasons (ex: SAML and Multitenancy) which is unrelated to your question.
It seems that if you upgrade to Enterpirse tier then you get the same SLA agreement as Identity Platform. See statement below (complete with typo), on this page .
Blockquote
Upgraded prpjects get uptime guarantees for Auth services according to the Identity Platform Service Level Agreement (SLA) and access to enterprise-grade support.
Here is link to Identity Playform SLA, which specifies 99.95% uptime, with credits being given if the Service Level Objective (SLO) is not met.
I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.