Skip to main content

Contrasting Azure and IronFoundry Deployment Behaviour

I have been exploring Iron Foundry a PaaS player in .Net space for the last few weeks. One of the things I liked about Iron Foundry was, how fast deployments happened. One of the reasons for this is how binary\file package gets uploaded to the cloud infrastructure. The Iron Foundry \ Cloud Foundry approach (since Iron Foundry is port of CF) of only uploading change-set instead of complete binary\file package makes this step of deployment quite fast.

What happens in Azure is
  • You create a package file (cspkg) using either Visual Studio (VS) or command line tool cspack
  • The generated package file contains the complete set of binaries and other resources such as images, css, javasripts etc 
  • This package is then uploaded to Azure infrastructure and then deployed by the Fabric Controller.

In contrast the process that Cloud Foundry follows to decide what it should send to cloud follows a multi-stage process. When an application is ready to be pushed to Cloud Foundry the client and Cloud Foundry servers perform a number of steps to make sure only the required amount of binaries\files are uploaded. These steps include
  • Creating a metadata file.This metadata file contains Application Name, Url, Framework, Runtime, Instance Required, Memory reservation (this is similar to Azure configuration files cscfg)
  • Look at components (Decide what gems, libraries, npms, etc. are used in preparation for the next step.)
  • File based Fingerprinting (This is where a Manifest of files is built along with a SHA-1 hash associated with that file).
  • Send manifest to Cloud Foundry
  • The Cloud Foundry then responds with a manifest. This manifest lists only the files that Cloud Foundry needs, not all of the files that make up the application.
  • The client based on the manifest response creates a packages (compressed) which contains only the files that have changes.
  • The client then uploads the package 

If you compare the process above the optimization that Cloud Foundry does as compared to Azure reduces the deployment time considerably.

With Azure I have time and again faced issues where we miss some file\code fixed and that required us to upload the complete package again. Imagine doing it for package of 200MB+ size on a slow network.

Windows Azure has improved this process a bit by supporting Web Deploy. This allows us to do incremental\differential upgrades as supported by Web Deploy model. But this approach again has it's own set of limitations as detailed here.

This posts only talks about the packaging and upload process for Azure and Cloud Foundry. If you want to know more about how Cloud Foundry deployment works look at these posts

All in all Azure can still improve this part of their deployment process to reap good performance benefits and improve development experience.


Popular posts from this blog

Caching Images downloaded from web on Windows Phone Isolated storage

I was helping on a Windows Phone application where the requirement was to cache the images the phone downloads on the isolated storage for offline viewing.
I wanted a solution which was simple and as transparent as possible. While researching I found  someone wrote a Silverlight converter for loading images from isolated storage. Taking that as a base I created a converted which can
Load image from web (http + https), and persist it to isolated storage.In case of network connectivity issues can load the same image from isolated storage. It does that by mapping the http url to a isolated storage location.In case the network is down and the image is neither there in cache, loads a default image, passed as parameter to converter.Here is the gist for the implementation.

To use the converter
Import the name space.Declare the converter as resource.Set the Image Source Property to use this converter like this 

AngularJS Model - ViewModel

Recently Robin Ward did a comparison between AngularJS and Ember (both the post and the comments are interesting read). One of the complaint that Robin had that AngularJS does not provide any specialized model class. As described in the blog

There is no standard Model base class, nor is there a component or interface in AngularJS that defines what a model is supposed to be.
What that means is that anything defined on $scope can acts as model, as this sample on the blog describes

For some (like me) this is the flexibility where as for others who want a more structural approach this is a nuisance.AngularJS does not even provide any definite guidelines around how the model should be actually designed to be effective with AngularJS

This leads to what we call as $scope pollution. We define multitude of properties on the $scope object and managing it becomes difficult.  Looking at the code one cannot tell what is the actual model and what properties are just to support UI logic.

Model Desig…