ALMaaS

…and why not? It means the range goes from Team Foundation Server (TFS) basic – a client install right up to TFS running as a service in the cloud.

To get a team of developers working together with Visual Studio you’d normally install TFS on-premise. That requires servers, infrastructure, database, Active Directory etc. It’s a non-trivial thing to do.

To get access to it in the cloud, you just create an account, create a project and you’re done.

The experience is the same from within Visual Studio Solution Explorer as with a locally installed TFS environment.

With the new ACS in AppFabricLabs you can use identities from the range of supported Identity Providers; Google, Live ID, Yahoo, Facebook. By configuring an ADFS2 server on to your on-premise AD, you can use your local AD credentials, in exactly the same way you would if you had a local instance installed. The experience for a dev would be the same whether their ALM environment is running locally or on Windows Azure.

This is one way to look at the sheer number of ways in which Windows Azure is being used, even within the product groups at Microsoft to enhance and increase their offerings. Isn’t it strange to think that in the future, it’s very likely that new Windows Azure offerings will have been developed using ALM that runs on the very platform that is being developed.

I’m sure we can all think of some absolutely huge projects where an individual’s code production is not the issue, but just the massive task of managing and coordinating all the activity in a meaningful way. Isn’t it great to think there in the cloud, an on-demand service that can grow as the project grows, shrink as the project shrinks and where you only pay for what you use is a definite future reality.

Planky

Technorati Tags: alm,almaas,tfs,tfs basic,tfs standard,visual studio