Over the past few years, there have been dramatic developments in how we design and roll out services and systems to users. Apart from simple 'brochure Websites' and sites, based on the content publishing platforms, the default target of choice seems to have become the ubiquitous 'Cloud.' When I went to my first introduction open day to Azure, a number of years ago, I came away thinking 'interesting concepts, but nowhere near ready for prime time.' That was in the early days of Azure of course, when everyone was still learning. In those days (only a scant five or so years ago), building at extreme scale, for peak efficiency and then sharing that scale out to others was a big big challenge. At the time, there were many new paths being explored and a whole host of new design patterns known as 'Cloud patterns' were tested and developed. There are the options, open to us now, that simply were not there a few short years ago, and we are required to bear these in mind when designing the solutions for the new Cloud based Web.
![]()
There are many worthwhile frontend changes that have emerged over the past few years, which many of us are using. Typically, one of the most expensive parts of the production chain is how and where we store the data related to our Application. This is what we are going to address here. If you have always traditionally used the same old stack, you need to think about checking out what's new in Cloud database offerings and adjusting your thinking for design to be in line with this. If you do not, you can be sure your competitor will, so it's worthwhile.
(Oh, and by the way - when I say competitor, I don't simply mean a company competing for the business your company gets, I also refer to other software developers and engineers in your company/organization or area, who are competing for the next promotion, career progression or job that you may go for!).
Our most traditional method of handling data has been to analyze, de-normalize and stick it into a relational database like SQL Server. Apart from some small scale Applications, it seemed that an RDBMS ended up as the default staging ground for all of our data. From an in-house (or 'on premises') point of view, this was fine, but costly, requiring not only operating system licenses but also the database access and the management licenses. When we move to the Web, our default thinking is to de-normalize and fit everything into the SQL Server. This may or may not be the optimal solution and even when it is, we need to ask ourselves; what kind of SQL service is best suited to our needs. (Note I said service, not server!).
![]()
When we look at putting a system into the production on Azure, we do not just have SQL data storage on offer as we also have document databases, Blob storage, Table storage and the File storage. To say nothing of the standard RDBMS offerings that are available to us that we can spin up in Virtual Machines (VMs). While VMs are really great to allow us maximum flexibility and doing exactly what we want, they also come at the price of having to manage them. I was recently designing an architecture for a new Website - whereas a short while ago, I would definitely have decided to use SQL, I really questioned the use case of it this time and ended up deciding on a filtered Blob storage solution, using Azure DocmentDB. For a large volume of data, it works out at about 0.10 cent per month, versus a minimum of $50 , if I were to run a SQL instance.
Therefore, your homework for this week is not to learn something new, but to make yourself aware of some new things that are out there as alternatives to simply fall back on SQL as the default storage.
Here are some links to get you going,