I have implemented an asp.net web site and hosted it in Azure as a Web Role. It is a relatively simple application making use of a database.
I am interested in high availability of the web site, thus I am using scale out feature of the Web Role; instant high usage of the web site is expected (peeks), so I am interested that the scale out operation to be fast.
My question is which is better to use in order to achieve high availability - a Web Role or an Azure Website? I observed that scaling out the Web Role takes sometime (meaning about 10-15 minutes for the virtual machine to be created and started);
Is it supposed the scaling out of the Azure website to be faster?
Is there anywhere on the microsoft's azure documentation mentioned about this?
Thanks.
So, a few general observations that are "as of today". Azure Websites have the following advantages
Azure Websites definately scale much faster. New instance comes up really quickly.
Deployment into Websites is usually simpler and easier
However, from other perspective, Web Roles have more of an advantage when it comes to the following:
You can get alot more control over how scaling occurs, especially if you're using services like AzureWatch. This is because, Web Roles are full blown VM's and one can potentially use any performance counter to input into scaling decisions
Web Roles are not as managed as Websites, and are generally less prone to have "Azure issues". The more managed a service is, the obviously, more possibilities there are to occur some "host-related issues"
So, what this means, is that Websites can execute scale actions faster, but with Webroles you'll know better WHEN to execute them.
Which one is more improtant to you?
HTH
Related
I have been getting a bit lost in the creation of my program architecture and I want to take a step back to see if I'm approaching it correctly.
I am wondering if my setup makes sense. I'm starting to think it doesn't.
I am creating intranet applications (We were creating Internet applications, but now the scope has changed). We use an onsite Active Directory (Windows Server 2012 R2). We have a SQL Server Database.
I have been building Front End Angular applications and ASP.NET Web API's to push and pull data. I am now implementing Authentication with Auth0 and it's been a nightmare.
What kind of program architecture would you setup in this scenario?
Much Appreciated.
SQL Server + Asp.Net Web Api + Angular JS forms a perfect architecture for building Single Page Applications (SPAs). This architecture is useful for building desktop like web applications, i.e. apps that runs over web but works like desktop apps.
If you can be more specific about the problem you are facing, you will be able to get better recommendations from so.
This architecture is widely adopted in many scenarios such as SPAs. With it, you will be able to keep your front-end highly decoupled from your backend services being able to support multiple front-ends on the same set of services and run quite a few integration scenarios.
Some of the downsides of such an approach will be the extra layer of complexity added to the application (which might force you to write more tests and handle different failure scenarios that wouldn't happen otherwise, for an example) and authentication routines since you will need to authenticate two heterogeneous environments (the .NET/IIS one and the JS/Angular one).
As for the authentication pain, token-based auth schemes seem the current way to go (such as Auth0) since they let you keep and send an environment-agnostic token which will be used by different layers of your architecture.
In that sense, your architecture makes sense.
However, since you're feeling some pain in its implementation, you might want to ask yourself if you really needed all of these. When you choose an architecture, you do so trying to accomplish some specific goals (multiple front-ends? specific performance requirements? maintainability? auditability?) and the more goals you try to accommodate in your architecture the more complex will become up to a point where the pains start outweighing the benefits.
So, what were you trying to achieve in the first place?
I was reading this article Build Your First Cloud Application Using Visual Studio 2010 when It hit me:
Why would I switch from my normal
hosting (shared account, VPS, or
whatever) to host it on cloud
servers ?
Do I have to build my website with
ASP.NET Cloud Application to be able
to host it with any cloud providing
service company ?
How can I edit my ASP.NET Web
Application to be an ASP.NET Cloud
Application ?
Those are the questions I thought would help to gather a full picture about this new technology and it's own application template! but please feel free to add more points to consider in the answers.
Edit
so beside the difference in implementing a website between Azure and other cloud server
is there is a performance difference or any other differences between Azure and the other cloud servers ?
I didn't quite get what you meant by "bringing your app on site with your own staff may become more economical"
the Azure pricing are high and requires a whole new dedicated project to work with it restrictions. so both the hosting and the development are costy
I hope if there's any article about the good cloud hosting out there and perhaps any articles about the user experience (a legitimate review and maybe yours if you have any)
First, I believe "cloud" in the context of the blog article you read should really be more granularly defined as Azure. There are several cloud solution offerings and Azure is only one although it is gaining immense popularity in the MS community space. The Azure cloud is fairly unique compared to products like Amazon's cloud in that it requires applications that use it to comply to a specific set of APIs. To build an application for azure requires you to embrace certain architectural principles from the beginning and to build your app using its web and worker roles. To "fit in" to these roles, your app must be built within a special VS project that references the Azure SDK.
If you were to use another cloud solution like Amazon, it is more similar to firing up a VM or group of VMs that can host your app as is without the constraints of specific APIs. You simplu would fire up a windows server instance, install what you need on it like any other server you would use in a hosted or or leased data center environment.
I am not implying that the azure solution is flawed or overly restrictive. Rather, I think it supports some architectural constraints that will allow you to "fall into the pit of success." However, it may be difficult to effortlessly migrate many brown field apps to azure without making significant changes.
As far as why host a application in the cloud as opposed to a normal hosted environment. It really depends on your app, your business/budget constraints and your traffic level. For many small, hobby sites, you may be better off keeping your app on a traditional hosted environment. For larger scale apps, the cloud begins to make more sense. The cloud is really supporting a "pay per use" model. If you need to have the ability to scale out quickly without the funds or the ability to wait on a purchase of lots of additional hardware, the cloud is a good option. Cloud providers have deep pockets and plenty of server resources and bandwidth to send your way at a moments notice that you can rent instead of buy.
Also, because cloud providers are large and typically highly reputable, they can afford to hire expert staff and follow best practices that you may not be able to afford on your own. They can and will handle a lot of the day to day ops administration enabling you as a developer to not have to think of things like security and redundancy.
So as I see it, cloud solutions are ideal for apps that are beginning to see a fair amount of traffic, need guaranteed up time, and do not want to pay or bother themselves with their own admin staff, server purchasing and data center management. I think they are not practical for many small hobby sites and once you become really big, bringing your app on site with your own staff may become more economical.
That all said. it has become "cool" in the .net space for any site to run on azure. I'll admit that some of the architectural models are interesting and seem fun to work with. However, if you take a close look at the pricing model, you may find you are better off with your hosted plan.
Moving your .NET application to a cloud or hybrid infrastructure allows you to start evolving to a Microservices Architecture, with the ability to phase in Containers and a Serverless architecture.
You mentioned that Azure costs are high and maybe cumbersome in your situation.
Maybe consider other popular cloud providers like AWS. They have a ton of vendors and services all readily available to help make the adoption easy, in fact over 57% of Windows workloads currently run on AWS.
Here is an eBook we recently published about this exact topic.
We are currently finishing a web-based time-tracking software built on ASP.NET and WCF (for different desktop-clients). Our customers can register an account and add an unlimited number of users to their account. Pricing is tied to the number of active users in the companys account.
To keep things simple and easily scalable we thought it would be a good architectural decision if we design each account to run as a single IIS-website with it's own application-pool, SQL-Server database and subdomain.
Unfortunately we rapidly run into memory-shortage, due to the fact that a single worker-process will consume at least 150mb, which means that for every single trial-account we need approx. 200mb more of memory...
Beside the heavy costs of such an architecture (trial-accounts!), we are not sure if it was a good decision for scaling, to design the architecture that way.
How would you design such
SAAS-applications?
Single app-pool for many sites?
Single website for many accounts with shared database?
Scaling vertically (more power) over scaling horizontically (more servers)?
Any good books or blogs on this topic?
Thank you!
What are the reasons for creating a new site and application pool for each account?
A single site with a shared database (number 3 in your list) is a much easier solution that can scale much better. You can then scale up the number of web or database servers when needed. This architecture is used in e.g. Sharepoint and most public web sites.
I am on a project helping to analyze the load a VB.Net WinForms application can take. This app has been in production for several years and has many many products on it. We plan to add more products but see the client footprint rapidly increasing. This is contributing the degradation of performance on the system overall.
There is duscussion that moving the UI intensive portions of the app to ASP.Net it will reduce the client footprint and solve many of our issues.
My question which of the following will scale better in terms of performance and load?
- ASP.Net(VB) Web based architecture
- VB.NEt WinForms 3-tier architecture
Links to articles on the topic are also appreciated.
Additional Info
Client - Apparent issue is large memory footprint due to data caching (High cph utilization)
Middle Tier - web services that house BLC & DALC assemblies (Low utilization here)
Database - Multiple database that that serve data to the DALC via sprocs (Medium Utilization)
Deployment is not an issue, we have a very well developent methodology there.
Thanks in advance,
Freeon
Winforms will scale better than ASP.NET
B/c
a. when you use an ASP.NET client - (a Browser) you pay a price, html rendering - another price, Viewstate - a huge price.
about view state - it is a chunk of data that might grow more and more as long as you operate even on the same page.
You need to use special techniques in order to make a asp.net webform efficient (AJAX).
You don't have this on winform.
Anyway - a specific answer should be aware of your product functionality, architecture and design, so this is gust a general advice.
Not enough data...
In terms of a user interface a desktop application should out perform (by various measures) a web based one in all but the most trivial of cases - that's not to say that you can't produce a very decent and capable web application but even then Outlook Web Access is not Outlook on the desktop.
To further illustrate the point, look at the effort going into Silverlight and Adobe AIR which are attempts to provide desktop level capabilites with web level deployment.
So the question becomes one of asking what is it in the current desktop application that is causing the problem i.e. is it a deployment issue, a performance issue or something else?
If its deployment issue then that will suggest one set of solutions, if its a performance issue then things get a lot more interesting.
Either way, there is insufficient data to do anything other than generalise enthusiastically
With a web based application you can scale servers both up and out for both the web server itself and the database servers. I would think that a desktop based application would be somewhat limited in how much scaling can be done, along with the need to update each and every client installation when changes/bug fixes are done.
There are negatives about web based applications. They will live in a stateless enviroment, the UI maybe somewhat slower than a desktop installation. It is possible to create UI's that are very responsive using lots of Ajax/Javascript, but the development time for those RIA needs may be more than desktop development. Connectivity issues maybe be of a concern, along with user browsers and such.
Quick deployment though of updates is one huge benefit of a web based application. You only have to manage one installation rather than many.
Good luck with your project!
The application is planned to be built using ASP.NET, .NET Remoting & MS SQL Server.
High availability is required at presentation layer, application layer and database.
Does IIS 7.0 provide any advantages over IIS 6.0 in regard to the High availability aspect?
Among the many aspects you want to consider, make sure that you have numbers.
By numbers, I mean how many request per second do you want to deliver? How many users per day are you planning? Are they all going to come in 1 hour or through out the day? Are they simply buying stuff on a e-Commerce website or is it a social network website with lots of pictures and videos?
All those questions matters in how you will architecture your website. If you go with a simple e-Commerce website that should not crash, make sure to have 2 servers with load balancing with some health monitoring on the IIS process. For the database, 1 machine will do the trick especially if you have some RAID hard drives.
However, if you go toward a social network site... things get freaky fast. If users upload pictures, you will need lots of space and much more if they upload videos. You might want to use Cloud Service to host those pictures without too much fees. For videos, you might want to use embeded link like Youtube or Google video.
As for IIS 7.0 versus IIS 6.0, I don't think there will be any significant changes. Both are really reliable.
Take a look at the High Scalability Blog
Make sure your design scales in a horizontal manner.
That is, have your system hiding behind a load balance layer with the servers that are actually providing the service behind the load balance layer.
When you need to increase capacity, you build a new server or servers and plug it in alongside the existing servers. Then you configure the load balance layer to also consider the new server(s) when passing out the work.