Monday, October 14, 2013

Office 365 app and Azure AD app

Both Office 365 and Azure AD offer application model as an extension mechanism. The two app models are a little bit similar, and I see an increasing trend that these two app models merge into one inclusive app model. After all, in either Office store and Azure AD app gallery, you are selling to the same group of business customers who own an '' identity.

There are, however, some notable differences between these two models. The AAD is more developer oriented as it focuses on pure Graph API, while O365 tries to make you a small add-on to some enclosed O365 system. Even though O365 also supports user-less pure API access, it doesn't actively promote this approach.

As a developer, you'd better know all your options and chose the most suitable integrating capabilities that the system has to offer.

This is why I created this O365_AAD_Demo project, to demonstrate all possible integration scenarios.
  • The Store Web App is both an O365 app and an AAD app;
  • It calls both SharePoint /_api and AAD graph API;
  • It can be invoked either from within O356, the canonical approach, or from outside of O365, the supported but not well documented approach.
  • It supports both user-intervened access, and user-less access (enabled by caching refresh token)
  • Lastly, the O365 and AAD shares the same '' domain, representing the same business entity.

As always, you can find the full source code in the code share folder.

Wednesday, September 25, 2013

Simplification is the ultimate sophistication

"Simplification is the ultimate sophistication." - Steve Jobs

After doing many software projects, I found out that I've always been trying to the same thing: Simplify unnecessarily complex designs. Not only to simplify the architecture design, but also to simplify the way we communicate the solution. Real masterpiece is like an art: Intuitively simple, while ultimately sophisticate.

This philosophy resonates well with SOA design principles. Good design encapsulates intrinsic complexities within its own boundary, while delivers promised capabilities through a very simple interface. Simplicity also fosters other key characteristics of a well-designed online system: reliability, scalability, performance, agility and manageability. 

Designing simple requires profound understanding of innate complexities. It’s a long but rewarding journey, that worth pursuing by every self-esteem designer.

This folder ( contains codes and documents of open source projects I've worked on. Every one of them embodies the same simplification spirit that I fully embrace.

Enjoy the beauty of simplicity!

Tuesday, July 16, 2013

Gateway Service

Gateway is a design pattern, which enables authentication, routing, monitoring, A/B and other infrastructural capabilities that you can add to your web site in a service injection manner. 

By service injection, you don’t need to change your code much, as there is no direct dependency between the Gateway and your web site. You just use the Gateway as a service.

Gateay Live testing sites:  
(username/password): , user2/test@123
User1 will be routed to East, User2 to West

Gateway Source Code: 

Project Cloud Service Fundamentals

Cloud Service Fundamentals (CSF) is an open source project created by Microsoft Azure CAT team. The purpose is to provide best practices on dealing with common Azure project challenges: SQL Azure Retry, SQL Sharding, Logging, Telemetry, Configuration, Caching, Server Affinity, etc.

The project can be found at
Here is a decoupled and componentized version of CSF. The CSF project is decoupled into 4 components: Common Library, CSF Social Web App, Telemetry and Gateway.

Live testing sites:
•CSF Web App:
•Telemetry Report:    dan/test@123
•Code:  (CSF)  ,   (Gateway)

Thursday, May 16, 2013

Choices of deployment on Windows Azure

Azure provides many choices of deployment, for both web/application servers and database servers. You will never fully appreciate how powerful these choices are, unless you actually played with it. 

Last week, I played with it as part of a load test project, and I was amazed by its capability even though I presented these features individually many times before.

My test setting is a very typical LOB web application. ASP.NET web tier, SQL Database, plus IE or Visual Studio load test client running on laptop. I tried many different deployment options, and compared the performance differences. It's very easy to switch from one deployment to another. Just a few clicks on the Azure management portal or simply republish the project from Visual Studio. Here are my learning.

Overall design:

Deployment Options:
Website: Azure Website free tier, Azure Website reserved instances, Web Role instances, multiple number of instances
SQL: Azure SQL Database, SQL Server in Azure VM, multiple sizes of VMs
Load test client: laptop, Azure IaaS VM
Network: Virtual Network, or not

Performance findings:
  • Azure website free tier, performance quota will soon be blown, and request will be rejected. 
  • Azure website reserved instance, and Web role instance. Performance is comparable between these two options. Both can scale pretty well, and performance is stable.
  • SQL Server in VM. Tried different file placement. There is some perf improvement by moving log/temp files to other disks, however the improvement is not significant. Need further investigation.
  • SQL Server in VM. Switching to bigger VM significantly improves performance.
  • SQL Azure vs. SQL Server. This is the most interesting part. SQL Azure 1 GB Database achieved comparable performance as SQL Server in Middle sized VM. The price of SQL Azure is only 1/10 of that of SQL Server in this configuration. The result should be related to my testing workload (a mixture of read/update/insert against NopCommerce web), and should not be generalized without further investigation.

Monday, March 18, 2013

Bowlus for AWS

To learn the upcoming Azure IaaS Virtual Machine, I decided to migrate Cloud Samurai project (code named Bowlus) to IaaS infrastructure. Since Azure IaaS is not GA yet, I did this first on Amazon AWS. This  also gave me an opportunity to learn and compare the IaaS offering from both Azure and Amazon.

After the initial redesign for IaaS, I found the benefit of IaaS is rather obvious:

  • Use the more mature IIS Web Deploy cmdLine tool to provision web site, instead of update IIS configure file directly.
    • Updating IIS configure file is a little bit dangerous, and it will cause troubles when concurrent access is not managed well.
    • Web Deploy is mature tool which is also used in Visual Studio to deploy web site to Azure. 
    • Using Web Deploy generates deployment logs, which helps diagnosis and auditing.
    • De-provisioning web site using Web Deploy is also cleaner and safer.
    • This is only possible under IaaS, since you have to pre-install Web Deploy tool and other dependent services in the VM.
  • Reduce two layers: routing + hosting, into one layer. The design is thus more simple and robust.
    • This change might also work in PaaS. Need further investigation.
    • IaaS gives us more flexibility to manage end points on each VM, and thus makes this design change more natural.
This is the live test link:

This is the new design for AWS: