This is a continuation of a series of articles on crowdsourcing application and including the most recent article. The original problem statement is included again for context.  

 

Social engineering applications provide a wealth of information to the end-user, but the questions and answers received on it are always limited to just that – social circle. Advice solicited for personal circumstances is never appropriate for forums which can remain in public view. It is also difficult to find the right forums or audience where the responses can be obtained in a short time. When we want more opinions in a discrete manner without the knowledge of those who surround us, the options become fewer and fewer. In addition, crowd-sourcing the opinions for a personal topic is not easily available via applications. This document tries to envision an application to meet this requirement.  

 

The previous article continued the elaboration on the usage of the public cloud services for provisioning queue, document store and compute. It talked a bit about the messaging platform required to support this social-engineering application. The problems encountered with social engineering are well-defined and have precedence in various commercial applications. They are primarily about the feed for each user and the propagation of solicitations to the crowd. The previous article described selective fan out. When the clients wake up, they can request their state to be refreshed. This perfects the write update because the data does not need to be sent out. If the queue sends messages back to the clients, it is a fan-out process. The devices can choose to check-in at selective times and the server can be selective about which clients to update. Both methods work well in certain situations. The fan-out happens in both writing as well as loading. It can be made selective as well. The fan-out can be limited during both pull and push. Disabling the writes to all devices can significantly reduce the cost. Other devices can load these updates only when reading. It is also helpful to keep track of which clients are active over a period so that only those clients get preference.    

 

In this section, we talk about content delivery network on Azure. This is a distributed network of servers that deliver web content for the crowdsourced application to users. It includes resources for web pages such as JavaScript, Stylesheet and HTML. CDNs that are closest to the application or clients are used so that there is little or no latency. Azure CDN can also accelerate dynamic content which cannot be cached, by leveraging networking optimizations such as the Point-of-Presence (POP) location and the route optimization via border gateway protocol. Benefits of using Azure CDN include better performance, large scaling and distribution of user requests.

 

Azure CDN performs geo-replication and automatic synchronization between virtual datacenters which is a term used to denote shared-nothing collection of servers or clusters. It leverages some form of synchronization with the help of say, message-based consensus protocol. Web-accessible storage is provided by Azure Storage, but the CDN is hosted as its own service and comes with its ARM resource. As with all Azure services, the CDN service also provisions an Azure resource backed by an Azure resource manager template. Azure CDN can be used for enabling faster access to public resources from Azure CDN POP locations, Improving the experience for users who are further away from data centers, supporting the Internet of Things by scaling to a huge number of devices that can access content, and handling traffic surges without requiring the application to scale.

 

Some of the challenges involved when planning CDN involve deployment considerations about where to deploy CDN and a few others. For example, these include versioning and cache control of the content, testing of the resources independent of the publications, search engine optimizations and content security. In addition, CDN service must provide disaster recovery and backup options so that the data is not lost and is highly available. System engineering design looks down upon CDN because of the costs involved. For example, it is easier to scale the servers without requiring the planning of content delivery network which saves costs because the resources are co-located and there are easier options to scale. The customer would integrate the publication of their content which can be done with the help of the CDN.