Optimizing your Azure Deployments for Cost and Performance!

This month’s Tech net magazine has quite a useful article on “Cost architecting” your azure deployments.

We had written something on the same lines here.

So be sure you check out both these resources before you think you are ready to get set, design and deploy!!

Happy Architecting!


Multiple Level Master Detail Binding in WPF(XAML)

I’ve seen a couple of developers fumble with a LOT of Code when asked to implement a 2-3 level Master –detail form.

So we put together a bit of code to showcase how easily it can be done with virtually no code (alteast no code behind!!) in WPF

Consider the following problem statement:

Create a form which lists a set of families in a dropdown.(Level 1)

Depending on the family selected list the members of the family. List the sons and daughters in a dropdown(Level 2)


Depending on the son or daughter selected, list their friends in a dropdown(Level 3)

So your form should look like

To make things more interesting, all this information about the families comes from this XML Document. Family.xml

So how do we do this in WPF?.

The following 4 Step process should suffice!!

1.       Create an XML Data provider for the XML  Document and set the XPath to the Family Node

<XmlDataProvider x:Key=”dataSource” Source=”Family.xml” XPath=”/Families/Family”></XmlDataProvider> 

2.       Create the UI in 2 layers  i.e there should be 3 grids let’s call them the  FamilyGrid, Son Grid and Daughter Grid

So the structure is

<Grid x:Name=”FamilyGrid”>

<..Place the Level 1 controls here…i.e Family combobox, Father and Mother text blocks–>

                <Grid  x:Name=”SonGrid”>

<.. Place the Level 2 and Level 3 controls here..i.e the “Son” Combo box followed by the Son’s friends..>


<Grid  x:Name=”DaughterGrid”>

<.. Place the Level 2 and Level 3 controls here..i.e the “Daughter” Combo box followed by the Daughter’s friends..>



3.       Set the DataContexts of the Grids

a.       Family Grid: Set the DataContext to the Family Node

<Grid x: Name=”FamilyGrid” DataContext=”{Binding Source={StaticResource  dataSource}}”>

b.      Son Grid: Set the DataContext to the “Son” Node within the current Binding

<Grid x:Name=”SonGrid” DataContext=”{Binding XPath=Children/Sons/Son}”>

c.       Daughter’s Grid: Set the DataContext to the “Daughter” Node within the current Binding

<Grid x:Name=”DaughterGrid” DataContext=”{Binding XPath=Children/Daughters/Daughter}”>

4.       Bind the Comboboxes to the required fields and set the IsSynchronizedWithCurrentItem= true

 As Highlighted above the key points here are

·         The DataContexts of the Grids which are set to the level of information which we want to show. Whenever a control does an “ItemSource= {Binding…}, the compiler will travel up the UI Heirarchy to find the first not- null data context.So it helps to set the datacontext at the “container” level if mutiple controls need to refer to a common data source.


 Since we have a hierarchy of grids and the family grid refers to the /Families/Family Node, we just need to keep setting the DataContext={Binding , XPath= <the XPath to the Node following the family node>}. DataContext={ Binding…} will take you to the /Families/Family node and the XPath will take you to your desired node


·         The Property IsSynchronizedWithCurrentItem which is being set to true in the comboboxes is the key here.When you bind a set of data to a value select control and set IsSynchronizedWithCurrentItem = true, what you are saying is “From this point onwards consider this data item as the selected item and refer to it for data for the ensuing controls”


So when you select a family in the family combobox, and make it the “Current Selected” data item, the other comboboxes will refer to the data present in the selected family at the specified path , so Family/Son will search for the Son node within the selected Family

 So using a combination of DataContexts to refer to different levels of data and IsSynchronizedWithCurrentItem to set the currently selected data you can go upto n levels of master details binding,and you wudn’t have written a single line of code in you .cs fileJ

  You can find the solution for the above example here MasterDetailBinding.zip.

 Happy Detailing!


Save some bucks on AWS with these pointers(Part 1)

Are you sure your ISV has kept these simple pointers in mind when deploying your multi-module app on AWS??

Instance Addressing

  • All Amazon EC2 instances are assigned two IP addresses at launch: a private address (RFC 1918) and a public address that are directly mapped to each other through Network Address Translation (NAT). Private addresses are only reachable from within the Amazon EC2 network. Public addresses are reachable from the Internet.
  • Amazon EC2 also provides an internal DNS name and a public DNS name which map to the private and public IP addresses respectively. The internal DNS name can only be resolved within Amazon EC2. The public DNS name resolves to the public IP address outside the Amazon EC2 network and the private IP address within the Amazon EC2 network
  • This private address is associated exclusively with the instance for its lifetime and is only returned to Amazon EC2 when the instance terminates.
  • Always use the internal address when you are communicating between Amazon EC2 instances. This ensures that your network traffic follows the highest bandwidth, lowest cost, and lowest latency path through our network.
  • Amazon EC2 instances that access other instances through their public NAT IP address are charged for Regional or Internet data transfer, depending on whether the instances are in the same Region.
  • To ensure customers are efficiently using elastic IP addresses, Amazon imposes a small hourly charge when these IP addresses are not mapped to an instance. When these IP addresses are mapped to an instance, they are free of charge.


    Watch this space for more pointers!!!

    Until Next time!!


  • Do you want to Stop or Terminate your EC2 instance?? What happens to your backup??

    So you are done for the day and stop your EC2 Instance.

    But are you sure you want to “stop” and not “terminate” it? What’s the difference?


    • You can stop an Amazon EBS-backed instance, but not an Amazon S3-backed instance.
    • Stopping causes the instance to stop running (its status goes from running to stopping to stopped). A stopped instance persists in Amazon EBS, which allows it to be re-started.
    • Stopping is different from terminating; you can’t re-start a terminated instance. Because Amazon S3-backed AMIs can’t be stopped, they’re either running or terminated. For more information about what happens and what you can do while an instance is stopped, see Stop/Start
    • When the instance is stopped, you’re not charged for any instance hours, only the volume storage. Each time you transition an instance from stopped to started, Amazon charges a full instance hour, even if transitions happen multiple times within a single hour
    • If you were using an elastic IP address with the instance, the address is automatically unmapped when the instance stops. While the instance is stopped, you’re charged for the address being unmapped (unless you remap it to another instance).
    • The root device volume and any others that you added either at the time of launch (through block device mapping) or after launch (by attaching volumes) remain attached while the instance is stopped. Any ephemeral storage does not persist. While the instance is stopped, you can’t change which devices are mapped to the instance.
    • Each Amazon EBS-backed instance has an attribute called InstanceInitiatedShutdownBehavior that controls whether the instance stops or terminates when you initiate a shutdown from within the instance itself. The default is stop. You can modify the attribute while the instance is running or stopped


    • When an instance terminates, any ephemeral storage is deleted.
    • By default, any volumes that were created when the instance launched (the root device and any others specified in the block device mapping) are automatically deleted when the instance terminates
    • However, any volumes that you attached after the instance was running are not deleted. If you detach and then re-attach a volume that was created at instance launch, it’s treated like a new volume that you attached after the launch, it will persist after instance termination and you will continue being charged for it unless you terminate it…

    So..keep a tight eye on the Instances and Volumes tab of the AWS Console to realize what is alive and accruing cost!!!


    Gearing up for AWS EC2:- Step 1. Decide your backup!


    Ready to deploy your application on the Amazon Cloud? You told your service integrator to provision a machine and put up your app. Did you discuss with him what kind of storage and back up your application would get?

    Most types of instances include a fixed amount of storage space on which you can store data. It is referred to as the “instance store” or an “ephemeral drive” as it is not designed to be a permanent storage solution.

    If an instance reboots (intentionally or unintentionally), the data on the instance store will survive. However, if the underlying drive fails, or if you stop or terminate the instance, the data is lost. Also, the data on the instance store is not included when you bundle an AMI. For example, if you have an Amazon S3-backed Windows instance, the D: drive on that instance is by default an ephemeral drive, which is not included in an AMI that you bundle from that instance.

    There are two options for your EC2 instance i.e to be backed by Amazon S3  or to be backed by Amazon EC2 and the option you select has an impact on the boot time,  data persistence and cost effectiveness of your deployment..

    Here is a brief from the Amazon EC2 official documentation.

    An Amazon EC2 instance can be launched from an AMI(Amazon Machine Instance) backed by Amazon EBS or from an AMI backed by Amazon S3. Instances launched from AMIs backed by Amazon EBS use Amazon EBS volumes as their root devices. Instances launched from AMIs backed by Amazon S3 use an instance store as the root device (e.g., / or C:\).

    The following table describes the differences between AMIs backed by Amazon EBS and AMIs backed by Amazon S3.


    If you are indeed thinking about going on the AWS, there are a lot of important decisions you will need to take..and we at Cennest can help you with the same..so its cennesttech@hotmail.com for AWS!!

    Until next time!