I have a .NET v4 application consisting of a web application (ASP.NET MVC2) and several web services (WCF). During development I have deployed the app to IIS 7.5 using /app1/ for web application and /app1/services/serviceXX.svc for web services...However, for production deployment I would like to find out if it would be better to deploy these apps into separate web sites and host each from root context.
So here are some of the scenarios, I am thinking of and was wondering if someone can share some pros and cons of each...
Scenario 1 (app per web site)
Deploy each app to a seaparate Web Site under IIS 7.5 ad use root context (/). I can then assign separate app pools for each site.
For example:
http://app1.domain.com/ <-- ASP.NET MVC2 app #1
http://app1svc.domain.com/ <-- WCF services related to app #1
http://app2.domain.com/ <-- ASP.NET MVC2 app #2
http://app2svc.domain.com/ <-- WCF services related to app #2
...
Scenario 2 (web app per web site, all services for all apps in one web site)
In this scenario, each web app is deployed just like in scenario 1 but all web services for all apps are deployed in single web site of iis 7.5.
I am guessing, advantage in this case is that only 1 web site has to have WCF bindings
For example:
http://app1.domain.com/ <-- ASP.NET MVC2 app #1
http://app2.domain.com/ <-- ASP.NET MVC2 app #2
http://services.domain.com/app1/ <-- WCF services related to app #1
http://services.domain.com/app2/ <-- WCF services related to app #2
...
Scenario 3 ( one IIS web site with sub-context for each app)
In this scenario there is only 1 IIS web site and each application is deployed in sub-context (this is what I use during development).
This approach (seems?) simple and easier to administer than other 2 but I am not sure...
For example:
http://apps.domain.com/app1/ <-- ASP.NET MVC2 app #1
http://apps.domain.com/app1/services/svc1/ <-- WCF service #1 related to app #1
http://apps.domain.com/app1/services/svc2/ <-- WCF service #2 related to app #1
http://apps.domain.com/app2/ <-- ASP.NET MVC2 app #2
http://apps.domain.com/app2/services/svc1/ <-- WCF service #1 related to app #2
http://apps.domain.com/app2/services/svc2/ <-- WCF service #2 related to app #2
...
I am thinking that Scenario #1, although a bit more involved, is the most flexible as I can controll the bindings, limits, and other properties which are only available on a web site level.
What do others think?
Option 1 is the most flexible in some ways, yes. If you have any issues where any single app and it's web service needs more resources, it would be very easy to do so since multiple apps are not tied together on any single URL. It's easiest, IMO, to keep every app in its own app pool with this option.
Option 2 may be good; you could scale the entire 'services architecture' out for the collective needs of all the apps, as opposed to one or another. But that can be bad as well; if you have a small number of the apps whose services are getting higher use (as opposed to it being somewhat more 'level' in distribution), it may make more sense to be able to scale up only those services which need it individually. But honestly, I'm not sure how valuable that is.
Option 3, IMO, is the best option if you expect that all the individual apps might need to scale up together; That is, you don't expect to have a very small number of the individual apps that need considerably more resources than the rest. But even if you do, say, have just one that is much busier than the rest, this would still enable you to scale the entire app up. But with an extreme mismatch between needs of the separate apps, it might not work out so well.
I think ultimately it may really come down to what will be easier for you to manage, though. Will creating new sites or new virtual dirs/apps fit better with your expected growth?
Related
My company has a very large site made up of lots of distinct sections, each maintained by their own team (e.g. browse pages vs checkout).
Does it make sense to build a separate Progressive Web App for each section, or do we need to unify our approach and build only a single Progressive Web App?
Think about progressive web apps in the same way you think about native applications. Then think if makes sense to have separated applications and you'll get your answer.
Being specific with your question I think you distinguish between some kind of info pages and service pages you currently keep under the same domain. If this is so, be aware that progressive web apps are unique by origin (protocol + domain name + port) and need HTTPS enabled so keeping separated progressive web apps can incur in additional infrastructure costs.
Nevertheless, this does not mean the same teams you have now can not maintain different parts of the same application.
If you are moving from a legacy website to progressive web apps (PWA), then I'd suggest you start small. Build a serious but not mission-critical PWA that performs a single function and go through the development/deploy process of building a PWA with Service Workers (fast reload and offline), home page installation and push notifications. This is no different than introducing any new technology to an organization (e.g, cloud, microservices, devops, et al).
A progressive web application is an application. And that PWA can potentially be installed on the home screen of a smartphone. I don't think you want users to have separate apps/icons on their home screens for your web "site".
Imo, your website should be a collection of microservices that are accessed via the web, not really a collection of applications. This gives you much more flexibility and agility. Combining microservices with PWA can be quite compelling for both content producers and users.
I am a web guy and I was just hired by a company that does only desktop apps (WCF/WPF) to help them start moving to web apps, using asp mvc.
Their current architecture uses 3 different servers, UI on one, service on one and DB on one, apparently to keep the UI and DB very separate.
So with moving to web apps, I am wondering how mimic that architecture. They are mostly internal apps, so I really dont see a reason to involve 3 different servers. If we do Web API apps with MVC front end, can the API and front end be on separate servers? I have never done web api stuff, so not sure of the structure.
I am used to a repoitory pattern (UI > ViewModel > Controller > Repository > ORM/EF > DB ) with a repository between the controller and and DB. How would web api be better?
I have a standard nteir setup :-
Web server -> App server -> DB server
I have an MVC 5 web application sitting on the web server with controllers calling a WCF services project sitting on the App server. WCF services project uses EF6 to marshal data on the DB server.
I am wondering if WCF is overkill? Is there is an easier way to achieve this same architecture? I am thinking I should have gone with Web API on the app server and then just call the web API from the controllers with the HTTPClient?
Or, I could even just use a plain MVC project on the App server returning JSONResults to the MVC controller on the web server?
It depends...
You have to understand what are the benefits of each set up. This is not exhaustive, just a quick brain dump. This should give you some hints to look further as in the wild world there might be many more reasons for choosing one or another solution.
Why WCF. Are you going to have different clients to your backend ? You need some entreprisy security between clients and you backend ? With WCF you could configure Http, TCP endpoints, set message or transport security and a lot more. It could be needed for example if your doing an intranet application and you would like not only to have your UI (MVC application) but other systems going to it. If this is not needed WCF seems overkill here.
Web Api is also agreat choice if you would like to built more REST oriented api, enabling content-negotiation for different clients (different media-types). Building REST is not about issuing JSON, it's much more and this would be too long to explain it here. If your client is not only your MVC app, but you could have a need for a api for other mobile devices, OAuth authentication and the so, this could be a good way to do.
Plain MVC app would also fit if you don't have any special needs, go for it. No overhead needed. Keep It Simple And Stupid.
I hope this helps
I would not change this.
WCF is a good choice for communication between Web Tier and App Tier. I would never put my App Tier exposed to outside world, so if there is any communication to my app from outside world, it would be through Web tier only and if there is a need to support multiple clients, I would create a WebAPI on web tier and expose that.
I would keep App tier only available to Organization internal and with WCF I would have flexibility to write service code and contracts which can then be exposed over various bindings (transport, security, etc.).If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF is indeed a good choice.
Can I have an ASP.MVC 3 application running in my site root (a simple CMS to provide MOST site content), and have it co-exist with additional ASP.Net apps (2 Web Forms apps and 1 MVC app) running in subfolders to provide more specialized functionality?
Example:
www.mycompany.com
/ // ASP.MVC 3 App goes here to handle 90% of our page content.
/store/ // Older web forms app to handle our online store.
/survey/ // Older web forms app to provide survey forms.
/locations/ // An ASP.MVC 3 app to render a map with site locations.
I wouldn't mind integrating the 'locations' MVC app with the CMS if necessary, but if they can be separate, it would simplify long term maintenance. Does the root application need to know about the others? (including the other projects as subprojects into the main MVC project in VS.2010?)
As for the 'store' and 'survey' Web Forms apps. They are running .Net 3.5, but we could recompile them to 4.0 if needed. Do the 'store' 'survey' and 'locations' folders need to be virtual folders mapped in with IIS?
Hopefully this example is simplified enough, to find out if it is possible (and how) to integrate applications together with ASP.MVC 3 running in the site root. I'm in a situation where the separate apps must share a domain and pretend to be 1 cohesive site. (They will all share the same HTML template)
Just mark those other applications as Applications in IIS and that will do.
Not directly -- you'll be fighting nasty IIS battles all week methinks. You might be able to get there eventually but it won't be pretty. There are two potential approaches here:
a) Put the entire thing behind a reverse proxy that passes traffic to the appropriate server (or virtual server). Downside is you might have to do a little tom-foolery to convince IIS that your store is running at http://www.example.com/store instead of http://localhost:666/store but it is doable.
b) Try and incorporate the old webforms apps into your MVC cms app. Really depends on lots of specifics but could be as easy as setting the route to be ignored and tweaking config as appropriate.
is it possible to deploy asp.net MVC site on windows AZURE platform? I understand we can deploy a WCF service, but what about full site? Will it work? Will it scale (i.e. load balance)?
We're having a project to develop - a donation site, which will be advertised a lot and will receive a lot of traffic. I do want to try AZURE, but is it possible for AZURE to run the full asp.net mvc site?
Yes - you just need to make sure that MVC dlls are copied to bin folder and MVC project is added as a web role.
Here's a tutorial.
Also take a look here:
MVCCloudService
PS. Remember about Azure prices.
As others mentioned, MVC2 sites are totally OK for Azure. Your second question: will it scale (auto-balance) needs more explanation:
If you have more then one compute instance (VM) allocated to your application, MVC2 site will auto-balance provided you haven't made any mistakes with keeping session-information inside the URLs.
However, if you want to automatically adjust the number of compute instances per load on the site, you will either have to write the scaling logic yourself (check this site to get started http://convective.wordpress.com/2010/10/12/autoscaling-in-windows-azure/ ) or use a third-party scaling engine like # http://www.paraleap.com/
HTH