protected override ICommunicationListener CreateCommunicationListener() { ... } 

See Service Communications Model for guidance on implementing your own communications stack.

WcfCommunicationListner is provided by the Service Fabric SDK for hosting WCF endpoints inside stateful and stateless services. The usage of the listener is documented at WCF Communication Listener.

Current implementation of WcfCommunicationListener is not aware of the public IP address/FQDN; so, for NetTcpBinding it generates the following communication endpoint with private IP address:

net.tcp://10.0.0.5:8080/7854ce3f-4e30-4949-b5e4-22cdcbd477c1/8f4106a5-0d38-4f30-aaf0-e435688e5ed6-130808019994632301 

This will work fine if the client also located in the same network; however, for internet based access the local IP address will have to be replaced with the load balancer's public IP/FQDN.

To fix this issue, I used the following listener implementation that extended WcfCommunicationListener:

//WcfFabricCommunicationsListener.cs 
using Microsoft.ServiceFabric.Services.Wcf;
using System;
using System.Collections.Generic;  
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 
using System.Fabric; 
using System.Threading; 
using System.ServiceModel; 
using System.ServiceModel.Description; 
public class WcfFabricCommunicationsListener: WcfCommunicationListener
{
  private string _gatewayFQDN;
  public WcfFabricCommunicationsListener(Type communicationInterfaceType, object service) : base(communicationInterfaceType, service) { }
  public WcfFabricCommunicationsListener(Type communicationInterfaceType, Type communicationImplementationType) : base(communicationInterfaceType, communicationImplementationType) { } 
  public override void Initialize(ServiceInitializationParameters serviceInitializationParameters) 
  { 
     ConfigurationPackage configPackage = serviceInitializationParameters.CodePackageActivationContext.GetConfigurationPackageObject("Config"); 
     var infrastructureSection = configPackage.Settings.Sections["Infrastructure"]; 
     _gatewayFQDN = infrastructureSection.Parameters["Gateway"].Value; 
     base.Initialize(serviceInitializationParameters); 
} 
public async override Task<string> OpenAsync(CancellationToken cancellationToken) 
{ 
  string partitionUrl = await base.OpenAsync(cancellationToken); 
  if (_gatewayFQDN == null) 
  { 
   return partitionUrl; 
  } 
  UriBuilder ub = new UriBuilder(partitionUrl); 
   ub.Host = _gatewayFQDN; 
   return ub.ToString(); 

  }
}

Initialize() expects the definition of the FQDN of the gateway through Config package as shown in the following snippet of Settings.xml: <!-- Settings.xml located in the Config directory of the service project --> 

<Settings> 
<!-- other stuff --> 
   <Section Name="Infrastructure"> 
   <Parameter Name="Gateway" Value="mycluster.cloudapp.net" /> 
  </Section> 
</Settings>

OpenAsync() merely replaces the host IP address with the FQDN of the load balancer.

• Building Resilient, Scalable Services with Microsoft Azure Service Fabric by Vipul Modi, Vaclav Turecek: https://channel9.msdn.com/Events/Ignite/2015/BRK3730
• Microsoft Azure Service Fabric Architecture by Gopal Kakivaya : https://channel9.msdn.com/Events/Ignite/2015/BRK3717
• Deploying and Managing Services with Microsoft Azure Service Fabric by Chacko Daniel, Kunal Deep Singh: https://channel9.msdn.com/Events/Ignite/2015/BRK3478
• Service Orchestration with Microsoft Azure Service Fabric by Matthew Snider : https://channel9.msdn.com/Events/Ignite/2015/BRK3485
• Microsoft Azure Service Fabric Actors: The Director's Cut by Vipul Modi https://channel9.msdn.com/Events/Ignite/2015/BRK3476

For generating a metric stream, simply execute MetricWriter.exe after changing Config.json, a sample of which is below:

{
    "TsdbHostName": "localhost", //the DNS name of the TSDB HOST
    "TsdbPortNumber": "4242",    //TSDB port number; the default is 4242;
    "MetricName": "LivingRoom.Temperature", //any meaningful name
    "StartDate": "01/01/2013", //mandatory
    "EndDate": "01/2/2013",    //if missing, current date will be used
    "SamplingIntervalMinutes": "5", //minutes
    "MetricLow": "65",              //low end of the metric
    "MetricHigh": "85",             //high end of the metric
    "Tags": { "app": "test" }  //comma separated list of name:value pairs
}

The project is located at: https://github.com/hanuk/tsdbwriter.

1. Namespace support: binding multiple implementations to the same base class/interface without collisions 
2. Configuration driven type registry: extensibility of the application after it is published
3. Load assemblies from arbitrary locations: support for  assembly loading from several arbitrary locations; needed this to make it easier for testing with build directories owned by someone else. I understand the security implications and hence the framework will insist on strong named assemblies and warns if not.  [At the moment I am testing this and will commit later in the week]
4. Generate type registry: this is a consequence of 2; since the Type specification syntax for reflection can become complex with nested generics, I needed this in a framework.

I can't say I have done thorough research across the IoC landscape but after a quick scan I didn't find one framework that supported all the above.

Also, I may have thought like a developer; within the time that is consumed by the research and testing of the frameworks, I thought I could put together one myself:)

Is this the best in its current incarnation? NO; it just serves my purpose. I will add constructor and setter injection soon.

End of the day, I did this for my own use and if any of you find it useful please use it. If not, IMO, no harm done. If you want to help me make it better, please do send me feedback.

As @Dave (THANK YOU @Dave!) suggested, I now have the experience of all the issues that one faces while writing an IoC container!

The project repo is located at https://github.com/hanuk/typec; the nuget package can be installed using the command: "Install-Package TypeC" from the NuGet Package Manager Console inside Visual Studio.

The following snippets show the sample usage:

//during the startup 
 TypeContainer typeC = TypeContainer.Instance; 
 typeC.Register<IList<string>, List<string>>(); 

 //bind the interface to an implementation
 var list = typeC.GetInstance<IList<string>>(); 

 list.Add("test"); 

With namespace support:

 //during the startup 
 string namespace = "MyNamespace"; 
 TypeContainer typeC = TypeContainer.Instance; 
 typeC.Register<IList<string>, List<string>>(namespace); //deep inside the layers of the code 
 var list = typeC.GetInstance<IList<string>>(namespace); list.Add("test"); 

Loading type mapping from a configuration file:

//during the startup 
 string fileName = "TypeConfig.xml"; 
 TypeContainer tc = TypeContainer.Instance; 
 //the Load(fileName) will fail if types can't be resolved tc.Load(fileName); 
 

 //bind the interface to an implementation
 IGenericWriter<MyClass> writer1 = tc.GetInstance<IGenericWriter<MyClass>>("gwriter3"); 
 writer1.Write(new MyClass()); 
 IGenericWriter<MyClass> writer2 = tc.GetInstance<IGenericWriter<MyClass>>("gwriter4"); 

Sample XML configuration file is located in TypeC.Tests project. The file follows the standard reflection notation: https://msdn.microsoft.com/en-us/library/w3f99sx1(v=vs.110).aspx

TypeContainer.GetRegistryAsXml() will dump the registry for easy configuration file creation and debugging. The returned XML string can be pasted into the configuration file so that complex generic types can be defined easily for dynamic binding.

The sample xml configuration snippet returned by TypeContainer.GetRegistryAsXml()is shown below:

//code snippet 

TypeContainer tc = TypeContainer.Instance;
tc.Register<IWriter, Lib1Writer1>("writer1");
tc.Register<IWriter, Lib2Writer1>("writer2");
tc.Register<IGenericWriter<string>, Lib1GenericWriter1>("gwriter1");
tc.Register<IGenericWriter<string>, Lib2GenericWriter1>("gwriter2");
tc.Register<IGenericWriter<MyClass>, Lib1GenericWriter2>("gwriter3");
tc.Register<IGenericWriter<MyClass>, Lib2GenericWriter2>("gwriter4");
 

string xml = tc.GetRegistryAsXml();

//corresponding XML

<typecmap>
 <mapping namespace="writer1" from="TypeC.Tests.Shared.IWriter,TypeC.Tests.Shared" to="TypeC.Tests.Lib1.Lib1Writer1, TypeC.Tests.Lib1"/>
 <mapping namespace="writer2" from="TypeC.Tests.Shared.IWriter,TypeC.Tests.Shared" to="TypeC.Tests.Lib1.Lib1Writer2, TypeC.Tests.Lib1"/> 
 <mapping namespace="gwriter1" from="TypeC.Tests.Shared.IGenericWriter`1[[System.String, mscorlib]], TypeC.Tests.Shared" to ="TypeC.Tests.Lib1.Lib1GenericWriter1, TypeC.Tests.Lib1"/> 
 <mapping namespace="gwriter2" from="TypeC.Tests.Shared.IGenericWriter`1[[System.String, mscorlib]], TypeC.Tests.Shared" to ="TypeC.Tests.Lib2.Lib2GenericWriter1, TypeC.Tests.Lib2"/> 
 <mapping namespace="gwriter3" from="TypeC.Tests.Shared.IGenericWriter`1[[TypeC.Tests.Model.MyClass, TypeC.Tests.Model]], TypeC.Tests.Shared" to ="TypeC.Tests.Lib1.Lib1GenericWriter2, TypeC.Tests.Lib1"/> 
 <mapping namespace="gwriter4" from="TypeC.Tests.Shared.IGenericWriter`1[[TypeC.Tests.Model.MyClass, TypeC.Tests.Model]], TypeC.Tests.Shared" to ="TypeC.Tests.Lib2.Lib2GenericWriter2, TypeC.Tests.Lib2"/> 
</typecmap> 

If you have complex nested generic types, hand coding XML can be error prone; build your registry using code and dump xml into the configuration file.

Hope this helps.

Mission critical systems will often have higher SLA requirements than those offered by the constituent cloud platform services. It is possible to build systems whose reliability and availability are higher than the underlying platform services by incorporating necessary measures into the system architecture. Airplanes, satellites, nuclear reactors, oil refineries and other mission critical real world systems have been operating at higher reliabilities in spite of the constant failures of the components. These systems employ varying degrees of redundancy based on the tolerance for failure. For instance, Space Shuttle used 4 active redundant flight control computers with the fifth one on standby in a reduced functionality mode. Through proper parallel architecture for redundancy, software systems can attain the necessary reliability on general purpose cloud platforms like Microsoft Azure. The SLA numbers used in this document are theoretical possibilities and the real SLA numbers depend on the quality of the application architecture and the operational excellence of the deployment.

Reliability of Software Systems

Any system that is composed of other sub systems and components exhibits a reliability trait that is the aggregate of all of its constituent elements. This is true for airplane rudder control, deployment of solar panels in a satellite, or the control system that maintains the position of control rods in a nuclear reactor. Many of these systems include both electronic and mechanical components that are prone to fail, yet these systems apparently function at a high degree of reliability. These real world systems attain high reliability through parallel architecture for the components in the critical path of execution. The parallel architecture is characterized by varying degrees of redundancy based on the reliability goals of the system.

The redundancy can be seen as heterogeneous or homogeneous; in heterogeneous redundancy the hardware and software of the primary and standby components will be made by entirely independent teams. The hardware may be manufactured by two independent vendors and in the case of software two different teams may write and test the code for the respective components. Previously mentioned Space Shuttle flight control system is an example of heterogeneous redundancy where the 5th standby flight control computer runs software written by an entirely different team.

Not every system can afford heterogeneous redundancy because the implementation can get very complex and expensive. Most commercial software systems use homogeneous redundancy where same software is deployed for both primary and redundant components. With homogeneous redundancy it is difficult to attain the same level of reliability as its heterogeneous counterpart due to the possibility of the correlated failures resulting from the software bugs and hardware faults replicated through homogeneity. For the sake of simplifying the discussion we will ignore the complexity of correlated failures in commercial systems caused by homogeneous deployments.

Impact of Redundancy on Reliability

Borrowing from the control system reliability concepts, if there are n components and if each of the components have a probability of success of Ri, the overall system reliability is the Cartesian product of all the success probabilities as shown by the following equation:

If a system has three independent components in the execution path the reliability of the system can be expressed by the following equation:

This equation assumes that the reliability of the individual component doesn’t depend on the reliability of the other participating components in the system. Meaning that there are no correlated failures between the components due to the sharing of the same hardware or software failure zones.

System with no Redundancy

The following is a system with three components with no redundancy built into the critical path of execution. The effective reliability of this system is the product of R1, R2 and R3 as shown by the above equation:

Since no component can be 100% reliable, the overall reliability of the system will be less than the reliability of the most reliable component in the system. We will use this in the context of a cloud hosted web application that connects to cloud storage through a web API layer. The server side architecture schematic with hypothetical SLAs for the respective components is shown below:

SLA of the Web Farm and Web API is 99.95 and the Cloud Storage is 99.9; hence the overall system reliability is shown by the following equation:

The system’s reliability went down to 0.998 in spite of each component operating at a higher level of individual reliability. Complex systems tend to have more interconnected components than shown in this example and you can imagine what it does to the overall reliability of the system.

Let us see how redundancy can help us reaching our reliability objective of, say 99.999, through the progressive refinement of the above application architecture.

Double Modular Redundancy (DMR)

In a Double Modular Redundancy (DMR) implementation, two active physical components combined with a voting system will form the logical component. If one of the components were to fail, the other will pick up the workload, and the system will never experience any downtime. Proper capacity planning is required to accommodate the surge in workload due to the failover in an active-active system. Active-passive systems tend to have identical capacity for both the execution paths and hence may not be an issue. The application outage can only occur if both the physical components fail.

Component #2 in the above system is duplicated so that if one instance fails the other will take over. The requests from component #1 will go through both the paths and the voting system will decide which output of the components is the correct one to be accepted by component #3. This typically happens in a control system circuitry, but similar concepts can be applied to software systems. To attain higher reliability in this configuration, it is absolutely critical for both the instances of component #2 to be active. In control system circuitry, DMR is not sufficient; if two outputs of component #2 disagree there is no way to verify which component is correct. DMR can effectively be employed in scenarios where component #1 can decide if the connection to component #2 is successful through the execution status codes known a priori.

An example of DMR in the computer networking space is the creation of redundancy (active-standby mode) with network load balancers to prevent single point of failure. In this case, the voting system typically is the heartbeat from master to the standby (e.g. Cisco CSS) system. When the master fails the standby takes over as the master and starts processing the traffic. Similarly DMR can be applied to web farms where HTTP status codes form the implicit voting system.

The reliability of a DMR applied component can be computed by subtracting the Cartesian product of the probabilities (since both of them have to fail at the same time) of failure from “1”:

If the individual load balancer’s SLA is 99.9, the redundant deployment raises its reliability to 99.9999.

Now we will work on improving the availability of the deployment shown in Figure 1 through DMR. After applying redundancy to the Web API layer the systems looks like Figure 2 shown below:

Reliability of this system can be computed using the following equation:

Redundancy of component #2 only marginally improved the system’s reliability due to the availability risk posed by the other two components in the system. Now let us implement redundancy for the storage layer which gives us the system reliability of 99.95 as shown by the following equation:

Redundancy with stateful components like storage is more complex than the stateless components such as web servers in a web farm. Let us see if we can take the easy route to get acceptable reliability by adding redundancy at the web frontend level and removing it at the storage level. The schematic looks like the one below:

This still did not give us the target rate of, say, 0.99999. The only option we have now is to bring back the redundancy to storage as shown below:

The following table shows the theoretical reliabilities that can be attained by applying redundancy at various layers of the schematic in Figure 1:

After applying redundancy across all system components, we finally reached our goal of 99.999. Now we will look at the implementation strategies of this scheme on Azure. As mentioned previously the homogeneity of the hardware and software for commercial systems may impact the reliability numbers shown in the above table. See the Wikipedia article “High Availability” for the downtime numbers of various nines of availability.

DMR within an Azure Region

When redundancy is being designed into the system, careful consideration has to be given to make sure that both the primary and the redundant components are not deployed to the same unit of fault isolation. Windows Azure infrastructure is divided into regions where each region is composed of one or more data centers. In our discussion we will use “region” and “data center” interchangeably based on the physical or logical aspects of the context.

Failures in any given data center can happen due to the faults in the infrastructure (e.g. Power and cooling), hardware (e.g. networking, servers, storage), or management software (e.g. Fabric Controller). Given that the first two are invariant for a DC, software faults can be avoided if applications are given a chance to deploy to multiple fault isolation zones. In the context of Azure, compute cluster and storage stamp are such fault isolation zones.

Each Windows Azure data center is composed of clusters of compute nodes and each cluster contains approximately a 1000 servers. The first instinct is to deploy multiple cloud services for compute redundancy; however, at the time when this article was written, the ability to override Azure decisions on compute cluster selection for provisioning PaaS or IaaS VMs is not enabled through the portal or through the REST APIs. So, there is no guarantee that any two cloud services either within the same Azure subscription or across multiple subscriptions will be provisioned on two distinct compute clusters.

Similarly Azure Storage uses clusters of servers called storage stamps, each of which is composed of approximately a 1000 servers. The developers can’t achieve redundancy at the storage layer by placing two storage accounts on two different storage stamps in a deterministic manner.

Since developers have no control over increasing the redundancy for single region deployments, the model in Figure 3 can’t be realized unless multiple regions are considered. The system shown in Figure 1 is what can be attained realistically with Windows Azure through a single region deployment which caps the maximum achievable system reliability at 0.998.

DMR through Multi-Region Deployments

The implementation shown in Figure 3 can only be realized through multiple Azure regions because of the lack of control on the compute cluster and storage stamp selection in a single Azure region. The only reliable way of getting desired redundancy is to deploy the complete stack on each region as shown in Figure 4.

Affinity-less interaction between application layers in an active-active deployment shown above is too complex to implement due to the near real time multi-master replication requirements of the persistent application state (e.g. Azure Table) resulting from the arbitrary cross DC access of the application layers. No matter which storage technology is used, changes to the business entities have to be written to storage tables in both the data centers. Preventing arbitrary layer interaction between data centers reduces the state complexity issues and hence the architecture can be simplified as shown below:

Let us describe the changes that we made from the hypothetical system in Figure 5 to an implementable model.

• The inter-layer communications between the data centers is removed due to the complexities involved with the multi-master write activities. Instead of an active-active model we selected an active-passive model where the secondary is in a warm standby mode.

• Azure Traffic Manager is replaced with a custom traffic manager (e.g. an on-premise distributed traffic manager or a client rotating through a list of URLs) that can have higher availability than Azure Traffic Manager’s SLA of 99.99. With Azure Traffic Manager usage, the max reliability of even the multi-region deployment will mathematically be <= 99.99.

• Since Azure Table doesn’t support multi-master replication and doesn’t give storage account level control to failover (entire stamp has to fail6) to the geo replicated secondary for writes, application level writes are required. In order for this to work, a separate storage account is required on the secondary data center.

• Web API level Azure Table replication requires local writes to be asynchronously queued (e.g. storage or service bus queue) to the remote storage table because otherwise it will reduce the SLA due to the tight coupling of the remote queuing infrastructure.

The above implementation can turn into an active-active set up if the storage state can be cleanly partitioned across multiple deployments. The transactional data from such partitions can be asynchronously brought into a single data warehouse for analytics⁴.

Content driven applications like media streaming, e-Books, and other services can easily build systems with 99.999 on Azure by distributing content through multiple storage accounts located in multiple Azure regions. So, with shared nothing architecture the set up in Figure 3 can easily be translated into an active-active deployment.

Triple Modular Redundancy (TMR)

Triple modular redundancy, as the name indicates, involves the creation of 3 parallel execution paths for each component that is prone to fail. TMR can dramatically raise the reliability of the logical component even if the underlying physical component is highly unreliable. For most software systems, DMR is good enough unless the systems (such as industrial safety systems and airplane systems) can potentially endanger human life. In fact, Space Shuttle2 employed quadruple redundancy for its flight-control systems.

The Azure architecture shown in Figure 3 is morphed into the Figure 7 shown below for TMR:

The theoretical availability for such a system is as shown below:

99.999999 is unthinkable for most cloud-hosted systems because it is an extremely complex and expensive undertaking. The same architecture patterns that are applied to DMR can easily be applied to TMR, so we will not rehash the strategies here.

CAP Theorem and High Availability of Azure Deployments

Distributed multi-region deployment is a key success factor for building highly available systems on cloud platforms including Microsoft Azure. Per CAP theorem8, you can only guarantee two of the three (C – Consistency, A- Availability, P – network Partition tolerance) systemic qualities in applications that use state machines. Given that multi-region deployments on Azure are already network partitioned, the CAP theorem can be reduced to the inverse relationship of C and A. Consequently it is extremely hard to build a highly consistent system that is also highly available in a distributed setting. Availability in CAP theorem refers to the availability of the node of a state machine, and in our case Azure Table is such a logical node. In this case, the overall deployment’s Availability and Consistency are correlated to A and C of Azure Table . Azure Table can be replaced with any state machine (e.g. Mongo DB, Azure SQL Database, and Cassandra) and the above arguments are still true.

High availability at the order of 99.99 and above requires the relaxation of system’s dependency on state consistency. Let us use a simple e-commerce scenario where shoppers can be mapped to their respective zip codes. We needed TMR due to the availability requirement of 99.999 or above for this hypothetical system. We can safely assume that the reference data like product catalog is consistently deployed to all the Azure regions.

This multi-region deployment requires the identification of embarrassingly parallel data sets within the application state and map each deployment as the primary for mutability of the respective data sets. In this case, the deployment in each region is mapped to a set of zip codes and all the transactional data from the users belonging to these zip codes will be written to the respective regional database partition (e.g. Azure Table). All the three regions are serving the same application in an active-active setting. Let us assume that the replication latency is 15 min for an entity write. We could set up the following mapping for primary and fail-over operations:

If Region #1 is down, users can be sent to other regions with appropriate annotation that their shopping carts and order status are not current. Users can continue browsing the catalog, modify the shopping cart (albeit an older one) and view the delayed order status. Given that this only happens at the failure of a region, which is expected to be a rare event, users may be more forgiving than the dreaded “System is down and comeback later” message.

Tying this back to CAP theorem, we attained higher availability through an active-active TMR deployment at the expense of the overall consistency of the state data. If system functionality can’t tolerate data inconsistency resulting from the replication latency, one can’t use eventual consistency model. Strong consistency implementation between Azure regions can result in reduced availability due to the cascading effect of a region’s failure because of the tight coupling with other regions.

Summary

Given the current SLA model of Azure managed services such as compute, storage, networking and other supporting services, architecting systems with high availability like 99.99 and beyond requires a multi-region deployment strategy. In most cases the ceiling for a single region Azure deployment is 99.95 or below due to the compounding effect of the SLAs of multiple services used in a typical cloud service. Redundancy with shared nothing architecture is the key success factor of achieving high system reliability. Building highly reliable systems of 99.99 or above is an expensive undertaking that requires deliberate designs and architecture practices regardless of whether it is for the cloud or on-premise. Factoring in the trade-offs between consistency and availability into the application architecture will produce the desired solution outcome whose complexity can be manageable.

Thanks to Mark Russinovich, Patrick Chanezon, and Brent Stineman for helping me in improving this article.

References

1. "Redundant System Basic Concepts." - National Instruments. N.p., 11 Jan. 2008. Web. 30 Mar. 2014. https://www.ni.com/white-paper/6874/en/.
2. "Computers in the Space Shuttle Avionics System." Computer Synchronization and Redundancy Management. NASA, n.d. Web. 30 Mar. 2014. https://www.hq.nasa.gov/office/pao/History/computers/Ch4-4.html.
3. Russinovich, Mark. "Windows Azure Internals." Microsoft MSDN Channel 9. Microsoft, 1 Nov. 2012. Web. 30 Mar. 2014. https://channel9.msdn.com/Events/Build/2012/3-058.
4. McKeown, Michael, Hanu Kommalapati, and Jason Roth. "Disaster Recovery and High Availability for Windows Azure Applications." Msdn.microsoft.com. N.p., n.d. Web. 30 Mar. 2014. https://msdn.microsoft.com/en-us/library/windowsazure/dn251004.aspx.
5. Mercuri, Marc, Ulrich Homann, and Andrew Townsend. "Failsafe: Guidance for Resilient Cloud Architectures." Msdn.microsoft.com. Microsoft, Nov. 2012. Web. 30 Mar. 2014. https://msdn.microsoft.com/en-us/library/jj853352.aspx.
6. Haridas, Jai, and Brad Calder. "Windows Azure Storage Redundancy Options and Read Access Geo Redundant Storage." Microsoft MSDN. Microsoft, 11 Dec. 2013. Web. 30 Mar. 2014. https://blogs.msdn.com/b/windowsazurestorage/archive/2013/12/04/introducing-read-access-geo-replicated-storage-ra-grs-for-windows-azure-storage.aspx.

1. Create VNET1 with address space 10.1.0.0/16
2. Create VNET2 with address space 10.2.0.0/16
3. Create LOCAL-VNET1 with address space 10.1.0.0/16
4. Create LOCAL-VNET2 with address space 10.2.0.0/16
5. Edit VNET1 to connect to LOCAL-VNET2
6. Edit VNET2 to connect to LOCAL-VNET1
7. Provision gateway on VNET1
8. Provision gateway on VNET2
9. Update LOCAL-VNET1 gateway address with the provisioned gateway address  of VNET1
10. Update LOCAL-VNET2 gateway address with the provisioned gateway address of VNET2
11. Set the IPsec/IKE key of the gateways of both VNET1 and VNET2 to the same value

Once the above process is complete, the network connectivity is established between VNET1 and VNET2. if you are doing this first time the documentation tells you (steps 3 and 4) to use a place holder IP address for the yet to be created gateway.

This placeholder can’t be any IP address from the private IP address spaces. Since this placeholder will be replaced with the gateway address created during steps 7 and 8, use anything (e.g. 25.345.131.1) that resembles a public IP address.

Note that the address spaces of VNET1 and VNET2 are mutually exclusive as these two VNETs will be combined into one logical address space after the connectivity is established.

Hope this helps to save a few minutes if you are doing this first time.

-Hanu

These systems employ a varying degree of redundancy based on the tolerance for failure. For instance, Space Shuttle used 4 active redundant flight control computers with the fifth one on standby reduced functionality mode. Through proper parallel architecture for redundancy, software systems can attain the necessary reliability on general purpose cloud platforms like Windows Azure.

Building systems with reliability of 99.99 or above is a lot of hard work and can get expensive pretty fast. Cloud platforms like Microsoft Azure gives you the necessary tools but you have to do the hard work of designing the necessary redundancy into the system layers.

Just published a paper on this subject at: https://download.microsoft.com/download/1/C/2/1C23BE8E-D0D8-448C-BF38-A0708C9EF9F5/Building_Mission_Critical_Systems_on_Cloud_Platforms.pdf.

In any case, since I needed the log in challenge screen to show up every time click sign in during testing, I wrote the following simple function to clear the credentials issued by Windows Azure Active Directory. Thought this might be useful for anyone integrating multiple OAuth providers including Azure Active Directory.

//clear stored credentials

ClearPasswordVault("Microsoft.WindowsAzure.ActiveDirectory.Authentication");

private void ClearPasswordVault(string resourceName)

{

    var passwordVault = new PasswordVault();

    try

   {        

       var storedCreds = passwordVault.FindAllByResource(resourceName);

       foreach (PasswordCredential pc in storedCreds)

       {

           passwordVault.Remove(pc);

       }

       WriteLog(string.Format("Removed {0} passwords for {1}", storedCreds.Count, resourceName));

    }

    catch

    {

        WriteLog("No passwords found in the vault");             

    }          

}