If you are a Web App developer and tasked to either redesign or develop an application that will be deployed (not hosted) on Windows Azure, what are the things that you need to look out for? There are several of course, and in this series of blog entries, I will try to illustrate some key areas that you might want to take a look at first.
But before you do anything, I feel we must clear up a few things.
First, is a definition of what Windows Azure is (and cloud computing in general) and the general ‘attitude’ or mindset that you need to have during design and development.
Then we will need to look at how you would want to approach Software Development for the Cloud.
Also, we will need to have a good grasp on what makes up Windows Azure, its features, services etc. for you to be able to leverage on each and design a good cloud application.
So first let us define Windows Azure.
There are tons of definitions out there that you can search on the web. And I will try to give a definition, from a developer’s point of view.
Windows Azure, can be defined as an Operating System on the Cloud. Read again, an operating system on the cloud; NOT the operating system of the cloud. I have heard a few who thinks azure is the operating system of Microsoft’s datacenters; which of course, is as far, or as near to the truth as one’s imagination.
If you are a developer, you would want to approach developing for Windows Azure with the mindset that it is an Operating System. Very much like in the days when we developed applications for deployment on different systems, we can use that mindset in designing and developing an application for Windows Azure. As a software developer, when instructed to develop an application that will be deployed on a particular operating system, there are things that we consider. Like how that particular OS works, how it reads and writes on the hardware, how its security features are implemented, how it manages the hardware resources etc. This is how one should approach designing and developing an application for Windows Azure, hence the mindset of looking and treating Windows Azure as an Operating System, on the Cloud, should do you fine.
And this brings us to our second point; on “how” you would want to approach software development for the cloud. This will cover a slightly modified SDLC, the design process etc.
Designing and developing for the cloud can be totally different, or exactly the same as what you and your team has been doing, depending on what SDLC or pattern you have chosen to adopt. However, I will not be enumerating programming patterns that you should adopt, that would be too many and enough for a separate blog in itself. Here, I will try to illustrate what I think will be a big change in your team’s methodology.
As you may have already researched, one of the great strengths of Windows Azure (particularly for startups or small ISVs) is that you can deploy your Web Application Straight from Visual Studio.
I don’t adhere to this tho. It is in my most humble opinion that a developer (specifically those who belong to a specialized team) should not have the ability to access the Windows Azure Subscription and deploy straight to it. *This is under the assumption that only the developers have access to Visual Studio.
A lot of problems may arise from this scenario, but I will express just one, my main concern. A developer may inadvertently deploy a version of the application that has not gone through QA or approval for promotion to testing OR production.
So, how to “solve” this problem that is not really a problem.. here is what I would propose to be the flow in a development environment with several stages and specialized people.
Development of course, happens within the development team. Testing will be through the Windows Azure Compute and Storage Emulators. If there should be need to actually test online, it will be a different scenario, that I shall illustrate in the next paragraphs.
After a successful build from the Dev Team, using Visual Studio they can “Package” the solution for deployment or promotion to a Staging Environment. Here we get to discuss another feature of Windows Azure (like being able to deploy from VS), that has not been really getting much of the spotlight.
All Windows Azure subscriptions have two environments; the Staging and the Production environment. The staging environment, as the name dictates, is where the application can be deployed to Windows Azure, run in the exact same configuration as the production, but will not be visible to the public. What this gives, is the ability to test the application in an environment that is as close to the production environment as imaginable. Now the question is; who shall be in charge of promoting, or uploading, the package and configuration file/s to the staging environment?
My suggestion would be to identify an entity in the development team that has previously had a similar role. Like a Deployment Manager perhaps. The one that was in charge, or took charge of caretaking for compiled code. This person shall be the one with access to the Windows Azure subscription, deploy using either Visual Studio or through the management portal, and notify the dev team or QA team of such a deployment.
In the event that the Dev team wishes to deploy to test for performance during development, the same process can be applied in deploying to staging.
Okay, this will be all for this entry. Next blog entry will take a look into specific areas of concern if you are a .Net Web Developer using ASP.net