I've a conceptual question about Static web site on Storage Account & App Service.
My team have develop an Angular10 + ASP.NET Core (API) application. Our frontend (Angular10) only consumes our API , so the availability of our app depends on the availability of both, frontend + backend (our API will NOT be consumed by any other app). We don't have any latence issue or requirement as our final users are all in the same region. Our app must be consumed through HTTPS and with a specific name (CNAME).
When we deploy the app to Azure, my team decide to deploy it separately using a Store Account as static web site for Angular 10 and an AppService for the API as backend of our App.
As far I see on MS docs (here is the related article):
"App Service Static Web Apps is a great alternative to Azure Storage static website hosting and is also appropriate in cases where you don't require a web server to render content"
Because of we currently need an AppService to render content, i have some questions:
The app works but, is a correct arquitectural approach or is better only publish our app to an AppService?
There are any security/cost related/whatever topic that makes StaticWebSite + AppService approach better than only AppService deploy?
I think that this approach does not give us any facility or advantage. Instead of this, we have to configure more things on Azure to connect through SSL and to give a CNAME to our app and AppService deploy.
Please, can you give me your oppinion?
Thanks in advance
Best regards
Luis
The best approach would be to split out the SPA and API and host them separately. This creates a loose coupling between the applications giving you more flexibility around performance, scalability, and deployment.
The .NET Core API could be hosted on an Azure App Service, or could it even be refactored into running as a set of serverless Azure Functions? Converting it into functions would allow for auto scaling and a likely reduction in cost as you only pay when the function is running. It depends what the API methods are actually doing.
The SPA could be hosted as a static web site in a storage account blob container, and with a CDN endpoint mapped to it you can set it up to expose the SPA using HTTPS on a custom domain. Alternatively you could use an Azure Static Web App (although this is still in preview). This simplifies the deployment of SPAs as it will connect to your code repo and build and deploy the SPA for you when changes are committed to the repo.
That would of course mean configuring two separate CNAME subdomain records (assuming you wanted to the API to have a custom domain name), but that's not a big deal and ultimately a clearer separation on concerns.
Static Web Hosting: https://learn.microsoft.com/en-gb/azure/storage/blobs/storage-blob-static-website-how-to
Azure Static Web Apps: https://learn.microsoft.com/en-gb/azure/static-web-apps/overview
Static Hosting with Azure CDN: https://www.red-gate.com/simple-talk/cloud/azure/static-hosting-with-azure-blob-storage-and-azure-cdn/
Hosting option depends on your requirements.
Use case for using Static web site on Storage Account is a need to manipulate or process data on the server side, simply call the relevant managed Azure service like Azure Cognitive Services or leverage a web server of your own hosted on Azure Functions.
https://azure.microsoft.com/en-us/blog/static-websites-on-azure-storage-now-generally-available/
Your are Static web site makes a call to Azure WebApp API, so you should have Azure WebApp Plan.
Azure WebApp Plan can host both API and Static web site. Benefits of such scenario are:
Reduce cost as you can host multiple WebApps in same Azure WebApp Plan.
Azure WebApp gives you more hosting features versus Storage Account
Deployment can be implemented in same way for both Static web site and API
Related
I have referred this https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns to find the recommended name, but couldn't find one for Logic Apps.
Logic App with Consumption Plan doesn't have private endpoint available. Where as Standard plan of Logic App is same as a web app as it leverages App Service Plan and has networking configuration available , so the same DNS as App Service can be used i.e.
Azure Web Apps (Microsoft.Web/sites) / sites privatelink.azurewebsites.net azurewebsites.net
I have an Azure App Services instance, which by default goes to https://myappservice.azurewebsites.net (not actually mine, but it's the same format). It's not a bad domain and a lot better than the sporadic randomized domains from Static Web Apps (https://lively-tree-randomletters.azurestaticapps.net).
Is there any way to switch the serverless website running on static web apps to also use the https://myappservice.azurewebsites.net domain?
Or is the only possible solution for hosting (1) react and (2) spring boot on the same domain, to buy one? Or this isn't possible at all?
(I want them to be on the same domain so I don't need to worry about CORS)
I think you could pull this off by using an Application Gateway. With the Application Gateway you can set up path-based rules so that you've got both your app service and your static website, but say yoursite.com/sprintBoot will be routed to your App Service and everything else on yoursite.com, to your static website.
See this article as an example: Create an application gateway with path-based routing rules using the Azure portal
Though it is up for debate if this is easier than worrying about CORS.
Why should I use Azure App Service and not just implement a common .NET RESTful Web API backend?
What's the explicit benefit of this service compared to a common .NET RESTful Web API backend hosted on Azure?
An Azure App Service is a place to host your web application or API. Normally when you have a .NET web API you host it behind IIS or something on a virtual machine.
Azure helps you with these common scenarios wit Platform as a Service (PaaS). An App Service completely abstracts the operating system and the way you host your web application.
App Service can host web apps both on Windows and Linux. You can use all kinds of frameworks such as PHP, .NET or Java. You can even host containers without worrying about the host.
A good sample to start with hosting your .NET Web App on Azure App Services can be found here: Quickstart: Create an ASP.NET Core web app in Azure
Yes, there is a huge difference between Azure App Service and .Net REST WebAPI backend on Azure.
Hosting on Azure can be done using two ways
Create your own VM, then install IIS and do all the required stuff
Use AppService Plan
AppService Plan allows you to leverage the powerful functionality of Azure. Here a separate VM is not assigned to you. Azure App service can scale automatically depending upon the Scaling rule which is not present in restful API hosted on Azure VM.
My question blatantly was a stupid Newbie question, and as such, I'm afraid it is non-sense, which I now know by the answers you've given.
I'm currently reading the book "Azure and Xamarin Forms" to learn Xamarin and Azure. Apparently it's outdated. It suggests to "create a Mobile App on Azure". From the book that Mobile App is just a plain App Service running a RESTful Web API with EF, but utilizing completely different namespaces to do so.
My question targeted towards these other namespaces. I didn't see a reason for them.
Apparently, Microsoft noticed the same. There is no "Mobile App" available in the Azure Marketplace anymore.
Azure App Service is a PaaS solution from Microsoft hosted on Azure. You can think of Azure App Service as some sort of "Micrsoft Heroku", because they work on a similar fashion. For many REST Projects, it can save you hours, if not DAYS of development. It has automatic TLS like heroku, but it is hosted on Azure instead of AWS and it can integrate very well with your existing Azure resources. One common pattern is to host the REST API on App Service and use a database service from Azure such as Azure SQL or Cosmos DB (which is a NoSQL service that, from the point of view of your app, it operates as MongoDB, but can be configured to behave as other DBMS).
Please Note: This is NOT a duplicate of What is the difference between an API App and a Web App?
The answer is outdated because the documentation changed and the quoted text was removed from the documentation.
So can someone explain me what the difference between API App and a Web App is? I can't find anything in the documentation.
Both API App and Web App are types of Microsoft Azure App Services. These are a platform as a service (PaaS) offerings from Azure.
API App is specific for developing RESTful APIs with feature like Swagger out of the box. Web App on the other hand is used to host Web Applications.
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK generation
Web Apps is the compute resources that Azure provides for hosting a website or web application in App Service. The compute resources may be on shared or dedicated virtual machines (VMs), depending on the pricing tier that you choose. Your application code runs in a managed VM that is isolated from other customers.
Refer: https://www.quora.com/What-is-difference-between-Azure-API-App-and-Web-App
In a typical 3-Tier web app, you run web servers in public subnet, while app tier lives in private subnet. Is it possible to run similar architecture with Azure Web apps and Api apps?
I guess you can run Asp.NET Core Web App in Azure Web App and Deploy AspNet Core Web Api to Azure Api App, then make Api end point private so only Web app can talk to it? I see options like Google, Facebook et. as auth providers. Is that what you have to do to make API private?
D.
If you want that level of isolation, one (although expensive) option is an App Service Environment (ASE). Link to docs: https://learn.microsoft.com/en-us/azure/app-service-web/app-service-app-service-environment-intro
App Service Environments are ideal for application workloads requiring:
Very high scale
Isolation and secure network access
The public environment where you deploy by default is public. Your endpoints will be accessible to anyone anywhere, and it is up to your app to do the filtering. This can be done, e.g. through static IP address security settings in Web.config. The problem with that is that even then you can't know for sure what IP address your front-end will use for communication. There are multiple possible addresses it may use for outbound traffic, and those are subject to possible change.
You can see an example of IP restrictions here: restricting IP security
Of course you should also have authentication set up on your API. Documentation links:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://learn.microsoft.com/en-us/azure/app-service-api/app-service-api-authentication
In line with what #juunas said above and a slight variant is to introduce Azure API Management Gateway in between Azure web app and Azure Api app. In standard tier API Gateway the IP address is fixed and doesn't change and you can use the API Gateway address in Azure API App web.config to whitelist.