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
Related
I'm developing a simple site consisting of an Angular frontend and a simple NodeJS backend. I currently see 3 ways to setup the project:
have 1 Web App to serve the static HTML and 1 Web App for the NodeJS backend
serve both REST API and static files using the same NodeJS instance
I read about virtual directories for Azure Web Apps, but wasn't able to find appropriate documentation. Is that even a viable solution?
What's the standard setup to use for Azure? Is there any in-depth documentation I missed?
I would say that this is a type of question for which it is difficult to get an answer, because someone could write an entire book on this topic and a lot of aspects are a matter of personal preferences, approaches and so on.
Before I try to attempt a first answer I would like to point out that I am not familiar with Node.js at all, but I am fairly familiar with Azure AppService and ASP.Net Core MVC.
There is no standard setup in Azure AppService (websites in this case) and in fact all the 3 options that you mentioned are valid. Based on my expperience with Azure AppService I would say that option one is suitable when you have a publicly available API. In that case you could also register your API with Azure Management API.
The second option is, in my opinion, best suitable when your frontend is the only consumer of your API.
The third option is not that common, but 100% possible. Here is a very good article on how to set virtual directories up and how to deploy an application to them using Visual Studio. I am not sure how this would be done exactly with the tooling at your disposal, but conceptually it should be possible. However, deploying NODE.js projects in virtual directories could cause some problems you should be prepared for. More information here.
I would however stick with what I said in the start: I would deploy both backend and frontend to the same web app if my Angular application is the only consumer of the API and I would deploy to 2 different web apps if my API was public.
I'm curious what other might think in this regard.
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.
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 existing Web API 2 project that I'm looking to move over to Azure Service Fabric. I'm planning on creating a single stateless service within Fabric as detailed here (mainly as I don't understand actors/services at the moment!) and move the API across.
My API uses Entity Framework for it's backend and the built in Individual Accounts using OWIN.
Is there anything I need to consider when moving the service over (I mainly thought the the DB and authentication might be an issue) or is it just a case of putting a Service Fabric layer on top?
Thanks
EDIT
I've had a bit more of a thought about this and have some more questions (based on #Mihail's comment)!
So I'm going to have many stateless services (so I'm splitting my Web API project up) which will be exposed via a Web API project (based on this)
So two questions really:
I need to authenticate users based on Individual Accounts. I think I should do this on the Web API frontend so only authenticated users get through to the Fabric services but that means that the API has access to the DB and it's not just a pass through anymore. Is this OK? Should the API call a microservice to authenticate and then call the service it requires or is this overkill?
Entity Framework. If I have many services (and API frontend) accessing the same DB do I have to worry about concurrent connections/locking or will Entity Framework handle this for me?
As Mihail said, the questions around Entity Framework and authentication shouldn't be a problem, or at least not a Service Fabric specific problem.
One thing to consider though is whether Service Fabric is appropriate here if the only thing you'll have is a simple API, or whether an Azure API app would be a better fit for you.
If you went with Service Fabric, you'd have to have at least 5 VMs so you'll need to consider whether your app requires 5 VMs or whether that would be an overkill. Also remember that you'll need to manage those VMs - you don't get the magic that a PaaS solution would give you. You'd also have to deal with certain things that you'd get out of the box from an API app like auto-scale, authentication, rate limiting, integration with SaaS applications, etc. Might be worth having a look at this SO question for a comparison between Service Fabric and the App Service.
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.