Showing posts with label Azure. Show all posts
Showing posts with label Azure. Show all posts

Wednesday, 19 November 2008

Silverlight: and Windows Azure

In my last article I was discussing Silverlight and Amazon's new CloudFront service.

I wanted now to discuss what the options with Azure are?

Hosting your Silverlight application in Azure

You can obviously host your Silverlight Application by hosting your website (which includes your Silverlight app) in Windows Azure, but I thought I'd explore avoidin the website, similar to what i was suggesting doing with Amazons Cloud Front.

The good news is that you can actually host your html file, your silverlight .xap file (set the mime type correctly), you will even be able to interact with web / wcf services via clientaccesspolicy / crossdomain files. You can host your Silverlight application completely in Windows Azure today (subject to the terms of service).

There are some caveats however at the moment:

  • Your silverlight application won't be able to access private blob storage (can't sign the http request)
  • Your silverlight application won't be able to access table or queues
  • Haven't figured how to control cache yet (not saying it's not possible, I just haven't spent enough time to figure if it is possible)

To be honest I'm not sure I want my silverlight applications to access these services directly. Certainly not at the moment (wouldn't want my shared key in the wild). May'be with a good authentication method this would be attractive.

The big difference between CloudFront and Azure for this type of thing is:

  • Content Expiry / Caching
  • Terms of Service / Pricing
  • Low Latency due to multiple datacenters and good routing

As I said, I think when Azure is out this will be a non issue.

Tuesday, 4 November 2008

Windows Azure: Development Fabric - Vista SP1 and Windows 2008 only

So before you download the CTP make sure you have Vista SP1 on your development machine (or Windows Server 2008) otherwise you won't be able to install it.

I've spoken to quite a few folks who have been complaining that it doesn't run on XP, and have been asking me why.

Part of the answer is pretty simple (i am sure there will be other reasons also), the Development Fabric is completely dependant on IIS 7. Therefore you need Vista or Windows Server 2008 (sorry).

Sunday, 2 November 2008

Windows Azure: Cache based Session Providers????

So following on from my previous article regarding cost efficient code reviews, I am going to predict a potential new session provider model.

In a world of Windows Azure we will be making more decisions for our applications based on cost. Session is an obvious target as the current session model in ASP.NET could cost us a lot of money (depending on Microsoft's pricing model).

Windows Azure, Cache and Velocity

So at the moment the only cache provider available that can realistically be used with Azure is to use Windows Azure Storage's Table Storage Service. There is already an ASP.NET provider supplied in the Azure SDK, (technically you could use SQL Services but this would be more expensive and unnecessary).

So Microsoft have said they plan to extend the options available for Windows Azure Storage Services and provide a Cache Service (based on Velocity).

This is likely to be cheaper and faster than using the Table Storage Service. If it's not cheaper (or at least the same price), I suspect folks will continue to use the Table Storage Service. This is a really good thing and will mean that we can reduce our costs further when using caching with ASP.NET.

Cache based Session Provider

So assuming that the cache service is cheaper than the Table Storage Service, it is logical that Microsoft will provider a Session State provider that is based on the Cache Service. If Microsoft don't create such a provider, then I suspect someone else will.

The reason I suspect this is that, if it's cheaper to use the Cache Service than to use the Table Service, it makes sense to utilize the service for what is considered as volatile data. It wouldn't be hard to build such a provider for the session.

In a web application where session data is frequently read and written to, if costs can be reduced using an alternative model then it makes commercial sense to utilize this.

I guess the only case that such a model wouldn't be explored is if the pricing of the Cache Service and the Table Service were the same.

Silverlight and Session Providers

This also brings an interesting question for your application and Silverlight, i.e. is exposing the session via web services to your silverlight application, the most cost efficient model. I will try and think about how this affects Silverlight also in future articles.

Cost efficient development is definitely coming and these are the sort of areas that will be explored.

Windows Azure - Cost Efficient Code Reviews

So with the advent of Windows Azure, I see that companies will put more stress on Code Reviews.

This is a great thing for companies in general as I do believe that not enough companies invest enough time in Code Reviews.

So why do i believe that Windows Azure will invest more in Code Reviews? I believe this because without code reviews, badly written applications could cost companies a lot of money than a well written application

Reviewing for Cost Efficiency

I suspect a new set of best practices and patterns will emerge with the ultimate aim of keeping costs low for applications. I suspect we will also see the development of new tools which will allow you to simulate loads and predict the cost of applications.

In order to keep cost efficiency companies will require team leads to review code with a particular emphasis on cost.

Code Reviews will be looking for:

  • Unnecessary use of SQL Services (which has a higher cost than Windows Azure Storage)
  • Appropriate use of caching (rather than just retrieving from the storage area blindly)
  • etc, etc

Session State Example

A good example of where you can use unnecessary costs in a web application is the session state.

An ASP.NET application on each HTTP Request will retrieve the session for the current user. In a normal world this is not a big deal because we have already paid for our session state. I say we have already paid for our session state, as we either have an inprocess session, or a sql server session. There is no real cost for maintaining our session, the infrastructure is already there. We have paid for our SQL Database and we tend not to be charged by hosting companies for internal network bandwidth usage.

In a world of Azure we cannot use InSession providers, because we cannot rely that requests will always be serviced by the same server / VM. Therefore we must keep session in Windows Azure storage (you could keep it in SQL Services but that would just frankly be frivolous). This is the only way (at present) we can guarantee to keep our session data with scale.

The downside is that everytime we retrieve data from the session, it's costing us money (Microsoft has not released its pricing model, so we don't know how much yet). So we therefore we have a few considerations?

Does the page in question use the session?

If not switch it off for that page, this is a performance best practice anyways but one which is generally ignored. If you switch off the session for that page then you are potentially saving yourself bandwidth, storage, CPU costs (depending on Microsoft's pricing model).

Is it appropriate to keep the data in the session?

Lets say there is a piece of data that is potentially accessed by the user in the course of a session but it may or not be used? Is it appropriate to keep that bit of data in the session (especially if it's quite large)? To be honest that question that sort of question is still valid for todays applications but with a utilization cost model, it massively increases the importance of such questions?

Conclusion

Anyways this is just my rambling as I am sitting in an airport in Los Angeles, however i think these sort of questions will become very important in a world of Windows Azure.

Developers be prepared to optimize applications not just for performance but now for cost.

It will be interesting to see the guidelines, best practices and tools that get developed in this area.