So I have been experimenting with a few new technologies lately, and my latest endevour has been to play with Azure. My initial thoughts on Azure was, "well sure, its a Server in some location with IIS, should be simple write a WCF Service and access it just as normal". Well that was the theory. So this blog post is going to hopefully get those of you who are completely new to Azure past that initial learning curve without going through the same troubles I did with a little of how I feel a simple generic Architecture should be for a simple Azure solution (in C#).
What is Azure
Well lets start with the text book definition provided: Windows Azure is an open and flexible cloud platform that enables you to quickly build, deploy and manage applications and services.
Well ok, thats good and all, but what does that mean for me? The way I look at Azure is a cheap ticket to a big game. What exactly does that mean? Well Azure is significantly cheaper than other alternatives. Building the infrastructure for your hosted environment can become expensive, and then you have maintenance, personnel hours, upgrades, the list goes on. Azure removes the initial infrastructure investment and also gives you an opportunity to scope out your market. Build it to the size you think it may need to be, build it too small, build it too big. With the click of a few buttons you can scale up or down to meet your needs. You only pay for what you use. So that translates into peace of mind.
Ok, so what does that mean for me as a developer? What do I need to know? How does Azure affect MY life? Well not a whole lot as you will see in the next few series. It keeps all the technologies you used to know love and play with, and keeps them pretty much the same. 😀 That is a good thing I feel. There are a few new things that are Azure specific, but overall I feel that getting up and running with it is relatively straight forward assuming you have a little bit of guidance, which I aim to provide in this series.
Simple Architecture leveraging Azure
Yup, lets talk about it before we build it. We need to at least pretend we program with forethought and a goal in mind. So how does this stuff work. What are these roles, how does it interact with my UI? Well I'll give a short description of each.
Your UI: You can use whatever front end technologies you want. Why? Because Azure doesn't really care. It hosts pretty much just like a normal IIS server. Also you dont HAVE to have a web site to leverage Azure. Hosting leader boards for games, hosting services for line of business applications, the scenarios are endless.
The WCF Role This role if you are familiar with WCF is used just as you used to use it for what you used to use it for. It is essentially your go get me what I want how I want it layer. More often it is reffered to as your middle tier. This services requests from your applications and is where I suggest you put most of your business logic.
The Worker Role I like to refer to my worker role as my server side grunt. This role's main existance is to do things that may take a while, or can be performed on a timed basis, the example often seen here is resizing or processing images to serve up to the Client.
Other Roles (MVC 3, 2, Silverlight, ASP.NET) These are good if you plan to use these paradigms. But essentially it just adds a front end hosted onto Azure as well. Since this may or may not be the situation, we will talk about this in a completely different section of this series. (sort of back on the UI point)
Blob Storage is for storing...well Binary Large Objects. Just big stuff.
The Queue is for passing messages from WCF to Worker, since they can not communicate directly.
The Table, is well a table. The implementation of this table is NoSQL and does not guarentee ACID. It is just a simple table out in Azure space with no relational capabilities, but still a useful tool.
So how do they fit together? Well I have a diagram that I drew up for how I felt about it. As with every architecture, this is will not work for every scenario, nor is it recommended for every scenario. It is a scenario that worked for my purpose and seems like it may work for many standard situations.
So an explanation of this Architecture.
A user has new content, and wants to store that content, so it accesses your WCF Role, your moving guy. He goes and puts it in the warehouse, and leaves a message for the workers in the Queue (since they dont communicate directly ad lib to story here). The workers all come in on a scheduled time and check the warehouse to ensure that "Alright those bonehead mover guys put the packages in the warehouse in the right spot and there are no peices of the package missing, cuz they are lazy and clumsy". The workers then tell the WCF role that "Hey, good job" or "you bonehead, go fix it, put in another one, you can't put broken junk in my warehouse." The workers also let the users know "hey, there is new stuff for you to check out. The users then go talk to their mover guys to go get the new stuff they heard about.
Ok, so that was a bit of a story for the Architecture, but you know the scenario and Architecture really isn't that unlike that. Your environment is its own organization (moving company or what have you) where everything has its own role to play, and that seems to be to me a generally good methodology for this sort of interaction. Those of you who are good at role management may come up with new ideas, and feel free to share them!
Those of you who are quite astute might notice a few problems in this architecture and diagram that will be addressed later, the purpose of this architecture is to provide a sketched out image for a solution leveraging Azure so that it doesn't seem too frightening, because it really isn't that bad, Azure is not a mysterious beast. It really is quite simple to utilize once you understand the different components.
Feel free to post questions, leave feedback, ask questions. If you find anything inacurate in the article let me know and I will fix it upon verification.