One frequent question we get is around “process guidance”. Also known by the more modern and fancy acronym “ALM”: Application Lifecycle Management, which replaced the old SDLC term, which in turn (and only if you are old enough like me) meant something completely different, but I digress….
Application lifecycle management on Windows Azure has some special considerations. Among the three things that clearly impact ALM from my perspective are the following:
Let’s look at each of these.
#1 is just a consequence of the available interfaces that Windows Azure exposes. You can’t copy files or deploy an MSI on Windows Azure. You have to package your app with a set of specific tools and then either using the portal or the management APIs upload the result of that packaging to Azure for processing. This is conceptually very similar to what I described years ago on my post about Northwind Hosting on-boarding.
#2 is pretty obvious. You will pay for servers and databases and storage even if you are just testing your application. Windows Azure doesn’t care and doesn’t know you are “just testing”. Which leads to #3: the notion of “production” or “staging’ or “testing” is an illusion. From Windows Azure perspective everything is production. Even today’s “production” “staging” labels are just DNS tricks. You pay the same, the VM is the same, etc.
One last thing that impacts lifecycle is the lack of ACLs on any management tasks. The LiveID account defined for service management can do anything. It’s a root user and you can’t define finer grained access to the service. For example, you can’t say “LiveID1” can create storage accounts, “LiveID2” can delete" services, etc.
Note: for an excellent overview of the account model, see Patrick’s post here.
And there’s only 1 service management LiveID per subscription. If you are working on a team, it means all member of that team that needs access to Azure Portal will have to share that account.
This limitation is partially alleviated by the fact that the Management API uses a different authentication mechanism: certificates. And yes, you can have a few of those. Yet, each will grant access to everything.
Our own current environment looks more or less like this:
It is not difficult to imagine more complex requirements. For example, we don’t really have a “production” service since nobody uses our sample application (a-Expense). But extending the above architecture is not that complex.
Here’s a simple expansion considering 2 environments and an additional role that manages deployments “production”:
Notice that “production” could potentially be another subscription (with its own separate Admin LiveID / Certificates).