We have an application which is an Asp MVC application which communicates via WCF to a middle tier application. We will be rewriting this and want to target Azure
It's split into 3 tiers, web, business, database, which are all on separate machines, as some of the business processes can take a few seconds. When the web calls the middle tier it must wait for a response before returning to the user, i.e. something like a message queue isn't appropriate here
I'm thinking for the new architecture we have
Client: AngularJS
Web: Probably Asp MVC controllers in a Web App
Middle tier: ?
Database: Azure SQL Database
The middle tier is where it gets confusing, what is this in terms of Web Apps and how does it communicate with the web? I think we'd prefer a RPC approach rather than REST based if possible. We just want to send serialized classes back and forth
What about scalability? We're presently assuming that the web will need to be stateless
Since Azure Web Apps is a platform that builds on top of IIS, you can run an IIS-hosted WCF-service on Web Apps just fine.
As for scalability, Azure App Service allows you to scale horizontally manually or automatically.
If the Web and Middle tier share scaling requirements, you can place both on the same App Service Plan. Then they share the instances and scale simultaneously. If however their scaling requirements are quite different, I recommend you put them in their own App Service Plans. Then one's scaling doesn't affect the other.
Related
I have a service, (.net core 3.1), that receives messages, a lot of them, and stores them in a DB.
The original is baked into an API and deployed as an App Service.
The App Service works fine. Great for the API and the Web but I'm uncertain whether it's the best choice for the service which I now intend to separate from the App Service. It's more or less background worker that just collects data and saves it.
I would like to know if there are any other more suitable Azure products other than App Service or should I go with another App Service?
It seems your use case basically fits to serverless scenario. All your messages processing can be handled by Azure Function.
https://learn.microsoft.com/en-us/dotnet/architecture/serverless/serverless-business-scenarios
https://learn.microsoft.com/en-us/dotnet/architecture/serverless/serverless-architecture
I am trying to implement SignalR hubs on my REST service (ASP.NET Web Api) hosted on azure. I've been reading some common stuff related to SignalR and I came to this one that it is server bound. You can check here. Which means that in order to be able to scale it on multiple server instancs I have to do some additional stuff. So, then, I started to ask myself "How many instances do I currently have running of my REST service on Azure? How do I know that?"
So, what I did was - I navigated to azure portal and opened my service > Process explorer
Does that mean than my web app scales automatically and I currently have 2 instances of my web api runing? I think it clearly says that there's currently only one instaces of it running 2 processes but how do I know if it will scale some time in the future?
No, your photo shows your app process and Kudu, which is a management interface you can access at https://yourappname.scm.azurewebsites.net.
You can see the instance count in your app's App Service Plan. If it is on Free or Shared, there can only be one. If it is Basic/Standard/Premium, it is one by default. If you haven't setup auto-scale, it won't scale to more than 1 instance unless you tell it to.
I'm currently developing a SOA based architecture in Azure, using disparate Web API services (they'd probably qualify as Microservices, but I'm hesitant to use the term).
I have a service which is triggered by the Azure Scheduler. It does some "stuff" and then needs to call another Web API (via HttpClient) service to trigger something else. To do this, I need to know the URI of the 2nd service. When running locally, this is fine, as it is something like
POST http://localhost:1234/2ndService/api/action
However, when I deploy to Azure (using Internal Only as the access level), it gets an obfuscated URI, such as http://microsoft-apiapp8cf3d453-39d8-4b3b-ad00-e9d8008a9b58, which I obviously can't guess at deploy time.
Any ideas on how to solve this problem? Or have I made a fundamental error here?
Instead of relying on public http endpoints, have you considered passing messages via queues in Azure Table Services? It's very simple to do and is going to be more robust since you can take advantage of built-in features like guaranteed message delivery.
The overall idea is that Service A does some "stuff" then puts a message on queue ONE. Service B continuously reads from queue ONE until it picks up a new message from Service A (or any other service for that matter) and then does its "STUFF". You can continue to chain calls like this to other services that need to be notified.
If you want a more elegant solution you can look at using Service Bus Topics but the concept is basically the same.
Also, since you mentioned that your architecture is much like microservices, you can check out the new Service Fabric which is designed for your scenario.
In case of Azure Web Apps, you may always see such properties going to the web app dashboard, then properties. When deploying from the Visual Studio, you can set the URL as you want - just checked it, and it works fine.
Not very clear what technology do you use - is it IaaS VM? Is it Web Apps?
From my standpoint, each service should be deployed as a separate Web App (or API App, if you want). Each Web App has defined its own name as in yourwebapp.azurewebsites.net, so once you have provisioned the Web App no 1 in Azure, you know its address so you will call it from the Web App no 2.
In all the cases, you should have fully qualified domain names, and not local/internal ones.
I have an MVC front end application (relatively small) with its own DAL implementation using repository pattern. I am thinking of moving the DAL in its own WebAPI project to maintain cleaner separation. The MVC app is hosted in Azure using a cloud service (web role). The WebAPI will only be used by the front end application and would not be exposed to any other external application for now, but even then i would still want it to be hosted as a separate app/web/worker role rather than keeping the DAL in same project.
Would it be a good idea to:
1) Host the WebAPI project within the same Cloud Service as a Web/Worker role or should I create a new website/cloud service for hosting it? Using the same cloud service is preferred keeping the cost factor and n/w latency issues in mind.
2) If I host in same cloud service, what is more advisable to use for web api project - web or worker role?
3) Somewhere i read that I should make use of Service Bus in Azure for interaction between MVC frontend and WebAPI backend. Is this the suggested way of doing it or is there any simpler way of getting it done?
I would suggest you to use the same cloud service. The reason being complexity and failure scenarios, when you split your app into multiple cloud services the problem comes when you are updating them service from your source control
You will need to do two deployments and make sure they are in sync etc.
I would keep the service runtime simple in one cloud service.
Again it is preference and comfort, if you really want to separate them at code level and know they will work fine. The two cloud services should be OK.
From experience, refactoring decision like these add a lot of work in the future. Positive or negative depends on your understand of the problem and the image of the bigger picture you have in your head that cannot be put on paper :).
Happy to Help, Yours Truly -CB
Lets say I have an application, that is separated into various layers (Presentation, Business, Data Access). How to deploy those layers to Azure independently? The question is about Azure configuration, not about the architecture of application.
An app is usually divided up into various roles, each role being Windows Server 2008 R2 with a defined size and number of instances. You'd typically break your app up into roles for scaling and management purposes. It's often simplest to deploy an app within a single deployment.
On to your scenario: If, say, you want to push up a Web Services layer that lives independently of your app (or maybe it serves multiple apps of yours), then you would put that Web Services layer (in a Web Role, let's say) in its own deployment. You'd need to manage authentication / authorization, since the Web Services would then be using a public endpoint for communication (or you could use Service Bus).
In your example: you could push your Presentation tier (e.g. website) to one deployment with a set of Web Roles, along with supporting services such as Cache. You'd have your Business Layer in another deployment, maybe running with web Services as in my example above. Then your data layer could be SQL Azure (Database-as-a-Service) or maybe a standalone database like MongoDB, running in its own deployment.
Each deployment would have its own project, and you'd deploy and manage each one separately. There's no configuration that spans all deployments.