I have ASP.NET web application which stores information on the session while user goes through pages. Will I have any problems if I deploy such application to Windows Azure?
As Nariman stated, you can't have server affinity - the load balancing is beyond your control. You can use either table storage or SQL Azure for session state. I don't really see much value in storing session state in blobs.
See this post on the SQL Azure blog, from August 2010, to see how to implement session storage in SQL Azure. This will allow you to manage session state across instances as you scale up.
EDIT 6/16/2014 - The Redis cache supports this. See Azure Redis Cache (Preview) ASP.NET Session State Provider
EDIT 5/23/2012 - Wow, lots has changed since I posted this. SQL Azure is fully supported as a session state provider (via Universal Providers, shipping since v1.4), as well as Windows Azure Cache. More details are provided in this StackOverflow answer.
You won't notice a difference on a single-instance deployment that uses InProc but you do need to rely on out of process Blob & Table storage if you plan on running multiple web roles. (There's no way to keep a user pegged to the same instance in Azure load-balancing, AFAIK.)
With the October 2012 release of the Azure SDK they provided a special session provider that can use the "Co-Located Role Caching" as a special back end for session. It allows you to use the role-level caches rather than having to choose from table storage or SQL Azure only. There are instructions on how to configure that here:
http://dotnetthread.com/articles/27-Setting-up-Windows-Azure-Caching-for-Session-State-Management.aspx
Related
I have a single instance of a website hosted in Azure, which uses the in-role session cache. This uses some very basic calls to pass data between pages, such as Session("MustChangePassword") = "True"
Microsoft have emailed Azure customers saying that the in-role and managed caches are going to be retired, and that Azure Redis cache should be used instead:
Azure Managed Cache Service and Azure In-Role Cache to be retired November 30, 2016
As a reminder, Azure Managed Cache Service and Azure In-Role Cache service will remain available for existing customers until November 30, 2016. After this date, Managed Cache Service will be shut down, and In-Role Cache service will no longer be supported. We recommend that you migrate to Azure Redis Cache. For more information on migrating, please visit the Migrate from Managed Cache Service to Azure Redis Cache documentation webpage. For more information about the retirement, please visit the Azure Blog.
Is this going to still affect cloud services that use just one instance, or will Session data just completely break after this change is made if I don't do anything?
If I do have to change to Redis cache, I see from the supplied links that I can download it as a NuGet package and make changes to the web.config file. However, I am then unsure as to whether I'd need to make changes to the code, or whether the calls to Session("Whatever") would still work without any further changes needed.
So in summary:
1) Do I need to change to the new cache?
2) If so, what code changes do I need to make over and above configuring the new cache?
This announcement is at least one year old, if not older.
So in summary:
Do I need to change to the new cache?
If so, what code changes do I need to make over and above configuring the new cache?
To Anser your questions:
YES
Check out the documentation links you quoted.
And by the way, you cannot downlaod Azure Redis Cache as a NuGet package. What you download is Client SDK/API to work with Azure Redis Cache. Azure Redis Cache is a separate service in Azure. Which is also billed separately.
So it turns out that using a session call such as Session("MustChangePassword") = "True" is absolutely fine to still use in the case of running a single instance machine.
It may not be supported, but it still works, and I have not had to add any other kind of session management to this project.
Everything is working exactly as it was before the announcement, and continues to work after the deadline had passed.
So in summary:
1) Do I need to change to the new cache?
2) If so, what code changes do I need to make over and above configuring the new cache?
The answers to the above questions were 1) No, and 2) No changes needed.
Our company is thinking about moving to the cloud. Would we still be able to meet all our current requirements (below). We want to be able to easily scale in the future without high costs.
5 ASP.net 4.0 websites running (using sql databases, see below)
SQL Server 2008 Express (8 databases on this)
2 Scheduler services running (send nightly reports via email e.g. new orders in db)
MongoDB and Memcached are also installed on server
Currently the websites are on a separate server from the database server for security reasons.
We were thinking about Windows Azure and Amazon Web Services (AWS) as providers, which would best fit our requirements?
Are there any other factors we need to consider?
Re: SQL Databases: on Windows Azure this would map to SQL Azure. Costs start at $5/month for up to a 100 MB instance - and goes all the way up to 150 GB - and goes beyond that with Federations.
Re: 5 ASP.net 4.0 websites running: these map naturally into Windows Azure Web Roles. The "small" instance is $0.12/hour/instance, and you'll usually want two instances (to avoid single point of failure for a few scenarios). Depending on your load, you may be able to put all 5 sites on the same instances. If you have very low usage sites, consider the $0.05/hour/instance "extra small" instance.
Re: Currently the websites are on a seperate server from the database server for security reasons: of course this is also doable.
Re: 2 Scheduler services running: Running Windows Services is no problem.
Re: send nightly reports via email e.g. new orders in db: No problem doing, though is not baked into Windows Azure directly, but there are many simple ways to do this (even for free, such as via SendGrid).
Re: We want to be able to easily scale in the future without high costs: you will need to do the math regarding your actual costs, but Windows Azure can surely scale.
Re: MongoDB and Memcache are also installed on server: These can both be run on Azure. Check out https://github.com/mongodb/mongo for MongoDB. Also, the Azure Caching service is also avail (managed for you).
Re: We were thinking about Azure and Amazon as providers, which would best fit our requirements: These are functionally very similar (in capability and cost), with a few noteworthy differences.
Windows Azure is Platform as a Service meaning that you don't need to worry about Virtual Machines, but rather Applications. In other words, you upload your (basically) Zipped app package to the cloud for execution. With Amazon, you will be dealing with the Virtual Machine yourself. In Azure, you get a copy of Windows Server 2008 which is managed for you, but you can also do admin things to it if you need to. This is far less of an advantage if your app is an old messy install that isn't really clean (though may not be a good high-value cloud candidate anyway).
Windows Azure has an emulator that works great - F5 right from visual studio to work with storage system and VMs and more popular features.
Re: Are there any other factors we need to consider: Yes. With any cloud application, you need to be prepared to deal with scaling out (not up), dealing with transient retries (you may need to retry an operation to a cloud service - any cloud service). The benefits of this are much better (and more cost-effective) scalability and higher reliability (when you run across nodes, you don't have a single point of failure). Be sure to understand when/where storage on a VM is persistent vs. ephemeral. There are more considerations, but these are primary ones.
You may want to check out the Windows Azure Pricing calculator.
Good luck! And welcome to the cloud.
with the exception of the scaling question, and the 2 physical servers, you can move this functionality into a hosted environment and you will technically be in "the cloud". This could be a dedicated or VPS (Virtual Private Server), or even a shared server if you are small.
Those can allow for growth over time...you just need to upgrade what you have with the provider.
You also could use a colo-server with a hosting provider, which basically means you put your hardware in an hosting provider rack, and use their electricity and bandwidth. They charge based on bandwidth usage.
Since you are using SQL Express, remember that each database is limited to 8gb. So that will limit your growth at some point. That would entail an upgrade from Express to regular SQL if you don't want to re-engineer anything.
Have you considered AppHarbour? It has Memcached, MongoDB, SQL Server and so on, and is quicker to deploy to than Azure. I like Azure, but there is quite a learning curve and I have found the connection to SQL Azure to be pretty bad - which means re-engineering your DAL to use something like the SQL Transient Failure Library = a bit of a faff for existing projects.
AppHarbour does not have blob storage - so if you are uploading files you will need to use Azure Blob Storage or Amazon S3 or some equivalent as well.
Hope this helps.
Not an expert but being that Asp.net is a Microsoft product it should be easier to migrate to azure, although from what I have heard AWS shouldn't be difficult. Another thing you may want to consider is cost. Last time I checked AWS is significantly less costly unless you already pay for MSDN subscriptions.
All the requirements you sum up are not any issue to deploy in Windows Azure. You can find a lot of information on the internet on how to do this.
Keep in mind, if you want to deploy your services to windows azure, you'll need to do some code review of your applications to fix session state, output cache and so forth on your web applications.
Since you want to scale them out and they are sitting behind a non-sticky round-robin load balancer, you will run into issues with your session state if it is saved on the machine itself. You'll need to part session state to SQL Azure or to the Windows Azure table storage for example.
Installing MongoB and Memcache in Azure is not an issue, you'll find a lot of information on how to do it, but it'll require some to set up your role and the scripting
codingoutloud has given a very detailed answer. I would add two very key considerations to think about when moving any application to Azure (or, indeed, many other cloud providers).
Local state
With normal Azure, they reserve the right to shut down any one instance of a role at any time in order to move or upgrade it. This means you always need at least two instances of any one role and they will be transparently load balanced. If your current websites are currently running on individual servers then they may rely on session state or files in local directories etc. Now, there are ways around this (like putting session state in SQL, using the cookie provider for temp data, using a shared drive for files etc) or, indeed, bypassing a lot of the benefits of Azure and using their "virtual server" concepts which means you don't get the scale benefits etc.
But, sites that rely heavily on local state may be challenging to move to the cloud.
Time Zones
All Azure servers run on UTC time. If you are used to running on dedicated servers serving users from a single time zone then chances are that you use things like DateTime.Now() which won't really correspond to what the user wants.
I don't see any of the above as limitations of Azure, I find them very useful in forcing you to build global and scalable solutions from the start. However, when porting an existing application, the above may be quite a challenge to adapt to, even though there are workarounds.
As also mentioned elsewhere, there is a learning curve to Azure and somehow the documentation - plentiful as it is - just doesn't quite seem to help for some reason. Once you "get it", though, I find Azure really nice and there are a bunch of subtle features that will help you build scalable solutions, like the whole queuing infrastructure, the blob storage and the table storage. In some ways the learning is hampered by having too much choice.
Good luck!
I have a c# window form application (which is basically a game).
And an ASP.NET Website. the window form application has a database with a table that contains the username and his cash. The asp.net database has a table that contains the username and his cash.
Now I want to sync between to the two servers. Once I get point in my game, It'll also update the database of the asp.net site.
You could expose a web service endpoint in the web app which the Windows app can call to post updated user stats.
Likewise a web service could return updated stats to the Windows client for synchronization into the Windows app database.
As Uwe Keim mentions, the web app can only expose a service or data feed that the Windows client must poll regularly. There is no feasible way that the web app can call the Windows app directly.
Why not host the database on one location and let the game/website connect to your DB through a web service? This way you only need one database with all the relevant data compared to two. You'll have to recode some parts of your website and game but in the long run this is more optimal than two databases with the same data.
More information regarding web services can be found here.
You can develop some kind of an API (Service) in the web application and do the sync between the two apps. You are talking about two servers at the end of your post. What kind of servers are you talking about? Is the game available in standalone also? If not, can't you think of having a single DB for both of them?
I am new to cloud computing, so please bear with me here. I have an existing ASP.NET application with SQL Server 2008 hosted on a Virtual Private Server. Here's what it briefly does:
The front end accepts user's requests and adds them to a DB table
A Windows Service running in the background picks up the request, processes it and sets a flag.
The Windows Services also creates a file for the user to download.
User downloads file
I'd like to move this web application with the service to the cloud. The architecture I envision is that I'll have 1 Web server in which I will install the front end and the windows service. I'll also have a cloud files server for file storage. The windows service should somehow create a file and transfer it to the cloud file server (I assume this is possible?)
My questions:
Does the architecture look like I am going in the right direction?
I know Amazon has been providing cloud services for a long time. If I want to do minimal changes to my application, should I go with Amazon, Rackspace, Azure or some other provider?
I understand that I would not only pay for file storage and web server but also for the bandwidth of users downloading the file and the windows servic uploading the file to the cloud server. Can I assume these costs are negligible? Should I go with VPS + Cloud Files combination to begin with?
Any other thoughts/suggestions?
#user102533,
The scenario you describe is very close to the one we cover in this guide. You can also download the documents here.
The web site should be fairly staright forwrad to move. The key things to consider:
- Authentication
- Session management
- Bandwidth use and latency considerations (e.g. big ViewState, etc)
The Windows Service will have to be refactored into a "Worker". This is covered in the guide above with more detail for very similar purposes.
The guide comes with full samples showing how to do it.
Hope it helps
Eugenio
I'm looking for a good caching strategy for an CRM App written in ASP.NET. Almost all sites depend heavily on the database, which means caching parts/the whole page for some time does not work in my situation. Is there any other way you use caching in these situations?
UPDATE 1:
The setup is the following:
- ASP.NET App hosted on IIS
- App uses either Entity Framework or nHibernate as OR Mapper as Data Access technology - which ever technology has more advantages for my specific requirements
- SQL Server 2008
We use caching for reference data that populates combo boxes and other fields(e.g. help fields) and any values that are unlikely to change frequently.
There are different levels of caching that are stored for different periods of time, including:
Session (lifetime of the session)
Application (lifetime of the web service)
What database engine?
For SQL Server, have you looked at SqlCacheDependency? Allows you to retain data sets and provides a cache invalidation mechanism based on notifications from the server. See The Mysterious Notification for an explanation how it works.