Infosys | Microsoft

At the time of application design decision on Azure, most of us get into this discussion at some point in time, “Table Storage OR SQL Azure”.

I thought of listing down the pros and cons for both of these storage options. Following comparison might be helpful to drive the decision.

List down the expectations from the desired storage from application point of view and compare those requirements with the help of following table. 

Table Storage		SQL Azure
Pros	Cons	Pros	Cons
Provides scalability out of the box and supports approximate ~ 100TB storage	Every transaction (CRUD operation) is charged within the platform which might accumulate higher charges for high volume transactional systems	Transactions within the platform are not charged	Doesn’t provide scalability out of the box and there is a hard limit of 50 GB per database instance. Application need to handle the partition logic
More suited for developing highly scalable, high volume applications	Doesn’t support ACID characteristics of transaction across multiple entities/tables	Supports ACID characteristics of transaction across multiple entities/tables (but not across databases)	More suited for departmental applications
	Single query can serve upto 1000 entities only, beyond that we need to use continuation logic in application	Doesn’t impose any limitation like this
Since application doesn’t have to build custom partition logic, effort to build such functionality in application is reduced	Inability to support seamless portability of an application between on-premise and Azure.	More suited to support seamless application portability  between on-premise and Azure	Since application has to build custom partition logic might incur sizable efforts to build such functionality
	Doesn’t support relational data store & stored procedures etc.	Supports relational data & stored procedures etc.
	No support for Spatial data type	Going to support spatial data type

Hope you find this information useful, any other points/suggestions/comments are most welcome.

 

 

Posted by Sachin Prakash Sancheti at 10:59 AM | Permalink | Comments (3) | TrackBacks (0)

Well, if I have compute and storage available on-demand then I would not worry about capacity planning,Right?

Continue reading "Load up your clouds just about right - need for capacity planning" »

Posted by Sidharth Ghag at 1:12 PM | Permalink | Comments (0) | TrackBacks (0)

Last week, I was at Partner Summit at Seattle. During a session with one of senior executive from Microsoft, one partner representative asked what is the ROI message for Windows 7 adoption to the clients. While there is no doubt that concrete messaging on ROI directly from Microsoft will be useful; I think there are enough data points as a businress case for adoption of Windows 7. The promise of savings of $90 to $160 per PC per annum as mentioned during the launch of Windows 7, improvement in productivity, better efficiencies with new features like BranchCache, DirectAccess, Federated Search and savings due to lower power consumption etc. could also be quantified. However, this computation will obviously depend on individual client context. I tend to believe that as a broad thumb rule for an organization having 10,000 desktops to be migrated for creating a Dynamic Core Infrastructure the deployment cost could be break-even in 12 - 15 months timeframe. 

Posted by Rajesh Gupta at 10:26 PM | Permalink | Comments (1) | TrackBacks (0)

Windows Workflow (WF) 4.0 part of .NET framework 4.0 and will be shipped as RTM (Release to manufacture) on 12^th April 2010. WF 4.0 has some exciting things on offer. Here are some interesting ones which one can consider while choosing Workflow 4.0 over Workflow 3.5 while engineering .NET applications

1) Improved Performance - WF 4.0 is re written from the scratch, the new runtime in WF 4.0 promises 10 to 100 times performance improvements. Speed improvements are due to increase in execution speed as well as the reduced size of persistence information. To understand the what went behind to cause this improvement, refer this
2) New activities – Several new OoB activities introduced. Newly introduced Parallel activity helps in writing logic in parallel without needing to write explicit thread synchronization. State Machine workflows in WF 3.5 are no more around; Flowchart is introduced as a new workflow type. To understand list of various activities supported through WF 4.0, refer this
3) Fully declarative workflows and activities
Declarative workflows have been possible earlier but to build the UI declaratively using XAML in the business layer was not easy. In WF 4.0, it is very simple to create a workflow declaratively in XAML. Writing workflows in XAML eases versioning, deployment and maintenance. The advantage is there is no code (behind) and the workflow can be changed dynamically and deployed easily.
4) Better integration with WCF 4.0 (Workflow as a service)
Workflow can be exposed as service without needing to write WCF service wrapper.
5) Workflow persistence – State Machine workflows are no more supported in WF 4.0. The workflow persistence can be achieved using Persist activity and can be applied to Sequential or Flowchart workflows.
6) Correlation support – Correlation is the ability to tie up related workflow services messages to the same instance of workflow. Workflow 4.0 supports 3 types of correlations: context, content and message based correlation. Refer this to understand various correlation mechanisms supported in WF 4.0
7) Compatibility with the previous versions
In WF 4.0, System.Activities.* assemblies hold everything related to WF. But the older System.Windows.* assemblies have been retained to ensure backward compatibility, so your WF 3.5 based workflows will work in 4.0 through newly introduced interop activity. Check this for WF 3.5 to WF 4.0 migration guidance.
8) Workflow host (App Fabric) – Appfabric is used to host workflows and services. It provides out of box monitoring, scaling (instance management), persistence which otherwise will have to be implemented and managed through custom extensions.
9) Simplified Designer - In WF 4.0, the designer comes with performance and usability improvements. The workflow designer is completely rebuilt using WPF and this gives it a great, rich user interface.  It is possible to create and open large workflows without loss in performance.
10) Re-hosting designer - In the previous versions, developers would need to write a few hundred lines of code to re-host the designer where as with WF 4.0 it is just a few lines of code. One can re-host workflow designer in WPF with a few lines of code.
11) Improved developer productivity – it takes 80% less code to write custom activities as against earlier version. WF 4.0 also removes the notion of a root activity; any activity can now comprise a workflow as compared to just Sequence and State Machine Activity previously.
 

While this is not an exhaustive list on what WF 4.0 has on offer. Am sure many would be keen to adopt and exploit what WF 4.0 has on offer.

Posted by Sudhanshu Hate at 9:43 AM | Permalink | Comments (1) | TrackBacks (0)

MIX 2010 that happened in Las Vegas last week (15 - 17 March), like all earlier MIX events, had some amazing new technologies to showcase. It is very evident that Microsoft is investing heavily into user experience and the new Windows Phone 7 was a prime technology piece that was showcased with many cool demos.

In the Keynote for day 1 Scott Guthrie and Joe Belfiore talked about and showcased Silverlight 4, Blend 4 and Windows Phone 7. Silverlight 4 developer release, Blend 4 beta and developers tools for Windows Phone 7 were released and are available for everyone to try out. There is more integrated support for working with Silverlight 4 in Visual Studio 2010 now, which is already available as RC. 

The keynote talk had some very interesting demonstrations. Along with Silverlight 4 and Blend 4 showcase, there were many demos around Windows Phone 7, all the way from how easily one can build applications for Windows Phone 7 from VS 2010 or Blend 4, to some fun apps that included Scott using the accelerometer feature to have Steve's avatar bouncing around and another one where they controlled a cannon from a Windows Phone 7 app and fired T-Shirts into the audience.

It was great to note that Silverlight 4 now has a control that can help view Pivot collections. If you want to start to build on Silverlight 4, you can download the required tools from here. In case you want to try out applications for Windows Phone 7, you can download the tools from here. The really cool part is that you can use Silverlight 4 and all its capabilities to build applications targeted to Windows Phone 7. Note that for working with Silverlight 4 or Windows Phone 7 toolset you need to have VS 2010 RC.

MIX had many more very interesting sessions and in case you want to see them, you can start from here. And yes, there is expectation that the RTM version of Silverlight 4 and Blend 4 will be available along with VS 2010 RTM that happens on 12th April.

Posted by Atul Gupta at 7:38 AM | Permalink | Comments (0) | TrackBacks (0)

I had a very tough time in one of my projects where we were using the Azure management API from a web application (deployed in Azure cloud). Before this project, we had successfully used these APIs in a windows based application but this is first time we were using in a web application. And apparently had a good amount of learning in a very new dimension.

 

Azure exposes a few REST based WCF services (Azure management API) using which one can use and do a lot of task programmatically as is provided in the Azure portal like:

 1. Managing deployment (create, delete, upgrade,  swapping, etc)
 2. Managing the hosted service (start , stop, and other configuration change, etc)
 3. Listing hosted and storage services
 4. Fetching hosted application/service details, etc

For getting a detailed list of possible operations, please follow this MSDN link.

All these call are over https and each call needs to have a certificate (.cer) attached as part of the web request. There are a few requirements which need to be met so that this certificate based call can be made successfully:

1. Upload the certificate having the public key (.cer) to the subscription to which these calls are to be made. For each Azure account, one subscription (ID) is assigned. This subscription is analogy to the space where we are intended to do the tasks like deploying an application/service, fetching the details of an already hosted service/application, etc

 2. This certificate is also required to be installed (with private key) in the machine from where these API calls are originating. This specific requirement is very to achieve when the calls are made from a local machine say using a windows based application. But a little involved when the application (web application/service) raising the calls is deployed in a virtual machine in the cloud to which we have very little access.

To achieve the above mentioned second requirement we had a tough time, so thought worthy to present it through this blog.   To achieve the same we have to follow the following listed activities. Let us assume that we have a requirement to make this API calls from a web application called CallAPI_WebRole which is to be deployed in Azure cloud:

1. Through the Azure portal go to the hosted service representing the VM for the CallAPI_WebRole application and upload the certificate (.pfx) giving the password
         a. This will not install the certificate in the certificate store of the VM. Certificate is just kept in one collection to be used for installation later.

2. In Visual studio (VS), go to the properties of the CallAPI_WebRole webrole under the ccproj and select the certificates tab. Then select the concerned certificate (as shown in the below picture) from the development machine’s certificate store (earlier by default it was currentuser/my but now fixed in VS 2010 to look into localmachine/my) and then give the Store location (LocalMachine or CurrentUser) and store name (my, root, CA or trust). This selection of the store location and store name will tell the Azure cloud where to install the certificate (those thumbprint is shown in the picture below) in the VM where this concerned application package is to be deployed.

 

          a. When the package is deployed and started giving the mentioned certificate information, Azure will look into the collection mentioned in 1a (above) and try to find the certificate with the given thumbprint and installs it in the store location/ store name mentioned.
          b. With the deployment package (cspkg) the certificate is not sent, only the information of the certificate to be installed are sent

I hope that, this piece of information will be quite helpful in similar scenario of using Azure management API.

 

 

Posted by Rahul Bandopadhyaya at 6:50 AM | Permalink | Comments (0) | TrackBacks (0)

While trying to debug a service call, where we suspected a buffer overrun situation, we wanted to find out the size of the object being returned by the service call. However finding size of a .net object is not trivial and if you thought you could do a sizeof(object), then you are wrong. This will only return the size of the object based on the size of each field in object that itself is based on the type of the field. This doesn't returns the size of the object in memory with data loaded into it.

Another option people try to use is Marshal.Sizeof(object), but this gives the size of the unmanaged representation of the object and the layout in managed and unmanaged world may be very different.

Chris Brumme (earlier was in the CLR team) had written that there is no direct API in .net to provide this size and he has explained it here.

Some forums talk about using a serialization approach. So you essentially create a memory stream and then use  binary formatter and serialize the object in the stream and then get the size of the stream. While this can be used, be aware of potential pitfall. The size thus obtained is really the serialized size and not the in-memory size. Why will the two differ? These can differ for

1. The layout of the object in memory/byte alignment etc will cause the diference and
2. If the object overrides and has custom serialiation, it might alter what all get's serialized and thus the size will differ.

Another option, that possibly is the best according to me is to use GC.GetTotalMemory() API before and after the call to create the object. See details here. However this itself has its own challenges in that this isn't thread safe, as the blog also points out. Multiple things can happen between the two calls to GC and other threads may release or allocate other objects and hence the size difference you will get may not truely reflect the size of only this object. Another aspect is that this object itself may need multiple steps to fully populate and hence enclosing these steps within calls to GC.GetTotalMemory() may be tricky.

There is one last option, which will mostly be 100% accurate, and that is to take a memory dump of the process once the object is allocated and then using WinDBG find out the total size of the object by using the objsize command. See some explaination of how to use WinDBG for this purpose here.

Posted by Atul Gupta at 6:56 AM | Permalink | Comments (0) | TrackBacks (0)