Simple web application on Azure
There was written plenty of articles how to create an architecture of simple web application for any cloud platform. In this article I would like to describe some possible solution for Microsoft Azure. Although there could be a small differences between the platforms, following architecture and design can be simple reuse for other platforms as well.
Let’s start with short description of application and its features.
Yet Another ToDo web application with qualities like fast, reliable , secure and highly available (it is all of web application, isn’t it).
the list is very short to demonstrate some really simple application
- Users will sign up with facebook, google, twitter, microsoft, or similar accounts. Application will allow sign up with user name and password as well. We assume 100k total users and 10k daily active users.
- Each day user will create a list of items she wants to accomplish.
- each day there will be fresh new list.
- list from previous day will be archived in read-only mode.
- During the day user will check the task she already accomplished.
- Application will be port to mobile platforms, or as extension to plugin for other software like Chrome or Office
- Adding statistic and analytic tools into web application.
- Extending the task model to have categories to sort related tasks and hierarchy level to define parent tasks for week, month or year.
Proposal of decomposition
Before we will dive in architecture itself, let’s identify the key technical features our application should have. I think nobody will be surprised if we will select traditional 3-layered application.
It is obvious in the Microsoft stack to create simple web application using classic ASP.NET framework, however if we will take in mind first consideration we will probably port application to mobile, it is not the best decision. I would suggest to create application using some framework for Single Page Application like Angular, Ember or React (We do not target old browsers, since we know our users).
The business requires our application is fast and highly available. Everybody guess it – of course I am heading to CDN.
Block 2: CDN in selected regions.
Business logic layer
This one is a little tricky since the application is so simple there is almost no need to have this layer officially defined. However there are features like login or statistic and analytic which will warrant its existence. Let me define this layer as public API rest service providing data for authorized users and registered applications.
Block 3: public API rest service.
Block 4: identity provider(s).
One consideration is that our users will be from around the world and we would like to server them the data as quickly as possible. We will need to have our data store distributed in different regions (it is partially valid for middle layer as well). This sounds simple and unimportant until we consider that users travel the world and they could be using application in different region then they are originally from. But it is an implementation detail.
Another reasoning is how much data we will store for each user and which data application will use more often. We know that we will need daily tasks only and older tasks are archived for read only mode. We can consider that fact in our data store design as well.
And the last but not least could be a question how much we will change the database schema and how we will work with historical data which could be uncompleted by this fact. I think again it is more an implementation detail for now.
Block 5: distributed data cache.
Block 6: data store, relational or non-sql.
In this article I have just briefly outlined a few blocks from which we could create our simple web application. And due to many uncertainties of our idea of application we would like to implement really simple and cheap system which could be enhance if needed in future as business will grow and we will have more money to spent on our infrastructure and sub-systems.