This is my second, in a three part series on MDC Chicago 2009.
Azure Services Platform
I ended up going to the first two Azure sessions. I had intended on only going to the overview and then skipping to Oslo, but after watching the overview, I wanted to see what was involved in deploying an application to Azure.
Azure is short for the Azure Services Platform, and consists of Windows Azure, .Net Services, SQL Services and Live Services (I have also seen slides that show SharePoint Services and Dynamics Services). Microsoft is attempting to build a flexible services platform allowing for the ability to easily scale out (assuming you don't code poorly), which is based on Internet standards such as Http, ReST, etc.
It is easy to get the platform (Azure Services) and Windows Azure confused, so I will try to stick to the convention of calling out Windows Azure, with just Azure referring to the entire platform.
You can use all of the same tools that you do now, like Visual Studio and Asp.Net, but they are also going to allow for interoperability with Java, Ruby, and PHP to name a few. The move to the cloud is viewed as an evolutionary step, not a revolutionary change. A simple analogy can be made between the desktop operating system and how it abstracts the hardware and low level operations, and Azure abstracting the data center and infrastructure.
Windows Azure
The Windows Azure portion of the platform is divided between applications and storage. The storage abstractions currently provided are: Large pieces of data - Blobs (file streams in a future release) Service State - Simple non relation tables, (caches in a future release) Service Communication - Queues (locks in a future release) It is important to note that the storage providers in Azure do not make up a relational database. Advanced data storage is provided by another part of the platform, SQL Server Data Services. The storage can be accessed from your Windows Azure applications, as well as from anywhere on the Internet using ReST.t On the application side, there are two roles defined, web and worker, with each role configurable to run as 1 or more instances which allow for scaling. The easiest way to describe the roles is that the web role is your asp.net application, and the worker role is a background process or service. The demo showed an Asp.net application being created and deployed, but I didn't see anything that would prevent a Asp.Net MVC, or WCF application from being deployed (although a wcf application might be better suited for .Net Services) but don't quote me on that. The demo also showed work being passed from the web role to the worker role by way of a queue. Again, the queue could also be accessed via the ReST interface from your on-premise applications. Code that runs in the worker role is isolated from the outside world, in that you can not control it from the code running in the web role, or from a location outside Azure. However, given the description in the presentation, it should be able to initiative an outbound connection. The worker role code should be used for used long running processes, like a credit card authorization service.
The Windows Azure portion of the platform is divided between applications and storage. The storage abstractions currently provided are:
It is important to note that the storage providers in Azure do not make up a relational database. Advanced data storage is provided by another part of the platform, SQL Server Data Services. The storage can be accessed from your Windows Azure applications, as well as from anywhere on the Internet using ReST.t
On the application side, there are two roles defined, web and worker, with each role configurable to run as 1 or more instances which allow for scaling. The easiest way to describe the roles is that the web role is your asp.net application, and the worker role is a background process or service.
The demo showed an Asp.net application being created and deployed, but I didn't see anything that would prevent a Asp.Net MVC, or WCF application from being deployed (although a wcf application might be better suited for .Net Services) but don't quote me on that. The demo also showed work being passed from the web role to the worker role by way of a queue. Again, the queue could also be accessed via the ReST interface from your on-premise applications.
Code that runs in the worker role is isolated from the outside world, in that you can not control it from the code running in the web role, or from a location outside Azure. However, given the description in the presentation, it should be able to initiative an outbound connection. The worker role code should be used for used long running processes, like a credit card authorization service.
.Net Services
.Net Services consists of three parts, a message bus, access control and workflow. This enables you to begin taking advantage of the Azure platform by moving some of your existing components to the cloud, while your other components remain in your current data center (on-premise). The message bus allows for firewall friendly communication between you and your business partners. All communication starts out in relay mode, which routes traffic thru the message bus. In the background, your application with the help of the message bus is attempting to establish a direct connection, and if it is successful, the relay connection will be dropped in favor of the direct connection. Services are published to a service registry and exposed via an RSS feed for discovery and subscription. The access control piece provides for centralized authentication and authorization. Currently, Card Space, Windows Live, and Username/Password are supported authentication providers. When a client logs in, they are authenticated and then provided with a saml token that identifies what access they have. This token is then provided by the client in the request to your services. There is a web interface for you to manage users and their permissions. Finally there is the workflow aspect, which sounded like Windows Workflow (WF), but in the cloud. There wasn’t too many details presented on this at MDC, so I’ll have to go watch some of the PDC videos and do some additional research.
.Net Services consists of three parts, a message bus, access control and workflow. This enables you to begin taking advantage of the Azure platform by moving some of your existing components to the cloud, while your other components remain in your current data center (on-premise).
The message bus allows for firewall friendly communication between you and your business partners. All communication starts out in relay mode, which routes traffic thru the message bus. In the background, your application with the help of the message bus is attempting to establish a direct connection, and if it is successful, the relay connection will be dropped in favor of the direct connection. Services are published to a service registry and exposed via an RSS feed for discovery and subscription.
The access control piece provides for centralized authentication and authorization. Currently, Card Space, Windows Live, and Username/Password are supported authentication providers. When a client logs in, they are authenticated and then provided with a saml token that identifies what access they have. This token is then provided by the client in the request to your services. There is a web interface for you to manage users and their permissions.
Finally there is the workflow aspect, which sounded like Windows Workflow (WF), but in the cloud. There wasn’t too many details presented on this at MDC, so I’ll have to go watch some of the PDC videos and do some additional research.
Sql Data Services
Sql Data Services can be thought of as the premium storage solution of the Azure platform (compared to the simple storage provided by Windows Azure). Like the Windows Azure storage, it is accessible from anywhere on the Internet, not just from within Azure. As of the current CTP, only the database part of Sql Data Services is available, but analytics and reporting pieces are under development. The presenter stated that Sql Data Services was the furthest along out of all of the Azure platform services and to expect some more functionality before it goes live. The presentation did go into some detail about how you go about creating and using Sql Data Services, but my notes are not good enough to write up here without further research. I can say that it’s not the same as creating a traditional database with tables, rows and columns in SQL server. That is, this is not a hosted SQL server instance.
Sql Data Services can be thought of as the premium storage solution of the Azure platform (compared to the simple storage provided by Windows Azure). Like the Windows Azure storage, it is accessible from anywhere on the Internet, not just from within Azure. As of the current CTP, only the database part of Sql Data Services is available, but analytics and reporting pieces are under development. The presenter stated that Sql Data Services was the furthest along out of all of the Azure platform services and to expect some more functionality before it goes live.
The presentation did go into some detail about how you go about creating and using Sql Data Services, but my notes are not good enough to write up here without further research. I can say that it’s not the same as creating a traditional database with tables, rows and columns in SQL server. That is, this is not a hosted SQL server instance.
Live Services
There wasn’t a whole lot of technical details on how live services fit in. Most of the presentation was at a higher level and talked about how Live Services has been around for awhile (currently has 460 million unique users), and how it will enable developers to span the cloud, client and device. An verbal example was given were a developer created a java script or SilverLight application that a user was able to install to their mesh, thus installing it on all of their computers and devices. From there, the user would be able to share that application with friends, and your application would spread like a virus. There was a separate session on Live Services which I didn’t attend, so that’s one more thing on the “requires further research list”.
There wasn’t a whole lot of technical details on how live services fit in. Most of the presentation was at a higher level and talked about how Live Services has been around for awhile (currently has 460 million unique users), and how it will enable developers to span the cloud, client and device.
An verbal example was given were a developer created a java script or SilverLight application that a user was able to install to their mesh, thus installing it on all of their computers and devices. From there, the user would be able to share that application with friends, and your application would spread like a virus.
There was a separate session on Live Services which I didn’t attend, so that’s one more thing on the “requires further research list”.
Building your first Windows Azure Application
Following the overview of the Azure Services Platform, was a session on writing, and deploying an application to Windows Azure. There are a couple of prerequisites for developing for Windows Azure: Windows Azure SDK - Jan 2009 CTP. (Unsure what version the demo was done on) Visual Studio Tools for Azure Sql Server 2008 or Sql Express 2008 IIS 7 .Net 3.5 SP1 Vista SP1 (If installing on Vista) Run VS as a Admin (required for local dev fabric)
Following the overview of the Azure Services Platform, was a session on writing, and deploying an application to Windows Azure. There are a couple of prerequisites for developing for Windows Azure:
A comment was made during the talk about getting things setup, that you must have a sql server instance name ./SqlExpress in order for Azure to work. However, I am not sure what version of the CTP the demo was using, as the January 2009 CTP was officially released after the conference. This is the one time were you need to run Visual Studio as a full administrator. This is because the local dev fabric is started by Visual Studio when debugging, and the dev fabric requires full admin rights. Developing an application for Windows Azure is pretty straight forward. In the first part of the demo, a simple Asp.Net web forms application was developed and deployed without any special coding at all. In fact the application was first launched as a regular web application, and then launched on the local dev fabric for Azure. So what is this local dev fabric anyway? The local dev fabric is a local version of the Windows Azure platform that allows you to debug and test your applications before deploying them to the cloud. You start up your Azure project from VS instead of your web project to launch the Dev Fabric. Once launched a simple windows form application shows up that allows you to view the number of roles you have running, and a debug window. The debug window shows Azure system events, as well as user defined logging, which can be called by RoleManager.WriteToLog. Configuring your Azure application requires you to manually edit two configuration files. This reminds me of manually editing WCF config files when WCF was first released. We were assured that additional tooling will be made available in the future for managing these config files. Deployment to the cloud is a manual process at this point in time, and it, and all management is done on a web page. There are two pre-defined “environments” that your application lives in, Staging and Production. The difference between the two was described as a configuration change, and not a separate instance of your application. It took over five minutes for the application to start up the first time, so be aware of this.
A comment was made during the talk about getting things setup, that you must have a sql server instance name ./SqlExpress in order for Azure to work. However, I am not sure what version of the CTP the demo was using, as the January 2009 CTP was officially released after the conference. This is the one time were you need to run Visual Studio as a full administrator. This is because the local dev fabric is started by Visual Studio when debugging, and the dev fabric requires full admin rights.
Developing an application for Windows Azure is pretty straight forward. In the first part of the demo, a simple Asp.Net web forms application was developed and deployed without any special coding at all. In fact the application was first launched as a regular web application, and then launched on the local dev fabric for Azure.
So what is this local dev fabric anyway? The local dev fabric is a local version of the Windows Azure platform that allows you to debug and test your applications before deploying them to the cloud. You start up your Azure project from VS instead of your web project to launch the Dev Fabric. Once launched a simple windows form application shows up that allows you to view the number of roles you have running, and a debug window. The debug window shows Azure system events, as well as user defined logging, which can be called by RoleManager.WriteToLog.
Configuring your Azure application requires you to manually edit two configuration files. This reminds me of manually editing WCF config files when WCF was first released. We were assured that additional tooling will be made available in the future for managing these config files.
Deployment to the cloud is a manual process at this point in time, and it, and all management is done on a web page. There are two pre-defined “environments” that your application lives in, Staging and Production. The difference between the two was described as a configuration change, and not a separate instance of your application. It took over five minutes for the application to start up the first time, so be aware of this.
My thoughts on the Azure Services Platform
When I first head about Azure during the week of PDC, I was less then impressed and not all that interested. I have/had a personal dislike of cloud based services (services which I don’t control, can’t see my whole database, etc). In the case of the Azure Services Platform, this dislike was based on not fully understanding the platform. After attending the two sessions at MDC, I have warmed up towards Azure, and am trying to find some free time to try it out. However, I think that I, along with many others, are waiting to see what the pricing structure will be. While I think it’s understood that this is designed for the enterprise, I get the feeling that most of us early adopters are hoping that the pricing scales as well as the performance of the platform. While Windows Azure may seem to be overkill for say hosting a blog, it’s stuff like that, that allot of us early adopters are going to be looking to do, before we stick our necks out and recommend it for the companies that we work for.
When I first head about Azure during the week of PDC, I was less then impressed and not all that interested. I have/had a personal dislike of cloud based services (services which I don’t control, can’t see my whole database, etc). In the case of the Azure Services Platform, this dislike was based on not fully understanding the platform.
After attending the two sessions at MDC, I have warmed up towards Azure, and am trying to find some free time to try it out. However, I think that I, along with many others, are waiting to see what the pricing structure will be. While I think it’s understood that this is designed for the enterprise, I get the feeling that most of us early adopters are hoping that the pricing scales as well as the performance of the platform. While Windows Azure may seem to be overkill for say hosting a blog, it’s stuff like that, that allot of us early adopters are going to be looking to do, before we stick our necks out and recommend it for the companies that we work for.
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.