Some people might look at the title of this blog post and wonder what I’m talking about. “The whole point of Azure,” they might say, “is scalability!” Which is true but only in a way. Azure Web and Worker Roles are scalable in the fact that you can turn on as many as you’d like to meet demand. This is very useful if your website is featured on the national news or Slashdot or Fark, but it can be costly too. The goal of a website should be to serve as many pages as possible before you need to add that next instance. And that’s what I am talking about with Building Scalable Websites, going somewhat outside of Microsoft’s standard playbook for building websites and moving into a way to build a website that’s as efficient in delivering content as possible. I am a small company, I don’t have a budget that can afford any more compute hours than absolutely necessary. Fortunately, building a scalable website tends to minimize those compute hours.

There are a lot of paradigms that programming seems to shift through. I’m not the first to compare web sites to mainframes, but I think that today’s web has moved past the mainframe/dumb terminal phase of life and into the mainframe/pc phase of life. When the web was an infant, web servers delivered up static content. Then they began running scripts. When Microsoft entered the fray with IIS and Active Server Pages (ASP), they were scripts I knew how to write. This ASP had a lot of functionality in it and every keystroke might generate a return to the web server to process that script. If clicking a checkbox should make some text appear, the click would be sent to the server which would process the new page and re-render it back to the browser. This was the same type of behavior that dumb terminals used with main frames.

With time, however, came progress. ASP gave way to compiled ASPX, which cut down on some of the server processing but there were still a lot of round trips because the client, the web browser, was still pretty simple. Granted, you could write an executable program for your users to download and install, but this generated it’s own unique headaches, not the least of which was making sure users had the latest version of the software installed.

Today we live in a world where browser are far more intelligent then they used to be. Javascript and CSS can do miraculous things, HTML 5 (check out this website to see what it can do) promises even more. And yet, we still write code that is server-centric. In many ways, programmers like myself approach writing server side code as though we are programming a mainframe used solely by dumb terminals instead of terminals where we can offload processing that’s not essential to clients who have the intelligence to handle it. It does take a little more planning and forethought, but the benefits are worth it, because the less code that needs to run on the server, the more clients it can handle before we need to add instances.

I’m basing this framework on MOOP programming principles. MOOP stands for Matter Out Of Place, often used to talk about littering but it can also talk about clutter or anything that isn’t where it should be. And, while I’m developing a MOOP framework for Windows Azure, the MOOP Programming principles can be applied to almost any type of programming.

So, what are the MOOP programming principles? A place for everything and everything in its place. Which means defining the various places you have to work with, defining what determines that an object lives in a particular place and defining how all of the places fit together.

Within Azure, I can see the following places:

• SQL Azure
• Web Role
• Worker Role
• Blob Storage
• Client browser

In addition, these places can be further broken down. The Web Role might have very specific, one use objects and it might have very generic use objects defined as well. One example of this is that my framework uses a generic handler to handle 99% of the interactions with the database. But some interactions require a specialized routine that the generic handler can’t handle as well for various reasons.  In those instances, it is necessary to deploy an actual handler specifically for that one task.

Over the next week, as I roll out blog entries related to both MOOP programming principles and the Azure MOOP Framework, this will all become a lot clearer. But this post is really just intended to start you thinking about where your programming efforts are going and to ask you if your web server is working like a mainframe with dumb clients or one with smart clients that can take some of the processing and offload it from your webserver?

Until next week,

Josef Finsel,
Azure Evangelist and Sr. Consultant, Azure-Architect.com