David Chappell is perhaps one of my favourite speakers from the conference. He tackled an objective look at Microsoft's new Azure platform in this session and gave what I thought was the clearest overview of the vision.
Azure is Microsoft's new distributed platform that they define as "Windows in the cloud" and "Infrastructure in the cloud". It's like having a huge data centre available on-tap, without having to invest heavily in capital expenditure, you simply rent the size of cloud you want, and scale up/down as needed.
It offers not only the ability to deploy your applications to a scalable platform but also provides the ability to consume standard Azure service offerings including (amongst several others);
- .NET Services
- SQL Data services
- Live services
The fabric of Azure essentially provides a layer on top of thousands of virtual machines, all running windows server 2008, 64bit. Each virtual machine has a 1:1 relationship with a physical processor core. The fabric layer provides an abstraction on top of this virtualised hardware, so we can't access the virtual machines directly (eg: RDP to them), but we can build .NET applications in certain roles and deploy out to them.
This is an extremely beneficial deployment model for whomever is building the next facebook, myspace or amazon out there - being able to build for the cloud and deploy incrementally to a scalable off-premises infrastructure allows new killer applications to fail fast or scale fast without huge capital outlay.
This of course is not actually new - Amazon's elastic compute cloud, storage solutions, google's app engine, gears etc all offer the same sorts of cloud infrastructure and utility computing. In fact, for existing apps that can't be ported to use Azure functionality like storage, Amazon's EC2 platform provides a good alternative as this allows you to supply virtual machine images into the infrastructure, whereas Azure abstracts this away.
The roles initially available are the web role and worker role. These correlate directly to an IIS hosted web application and standard .NET executable applications respectively, but deployed and hosted through the Azure fabric and the core services that this provides.
These core services include the storage service which allows us to store;
- Blobs
- Storing a simple hierarchy of any binary representation of data directly into the Azure storage services.
- Tables
- Storing structured data into hierarchical tables (not RDBMS tables).
- Queues
- Storing data into queues that allow communication between web and worker role instances.
Data in storage is exposed to applications via a RESTful interface with a query language based on the LINQ C# syntax. Data can be accessed by Applications or from other on-premises or cloud based applications.
In addition to the core Azure components of the web / worker roles and storage, it also offers a suite of pre-built ancillary services that can be consumed as mentioned above - presumably we'll pay extra for these, but the only comment Microsoft would make on pricing during the conference was that they will be competitive.
Azure .NET services
This provides;
- Access control services
- Service bus
- Workflow
Access control services
Different organisations identify users with tokens that contain different claims. Each organisation might have different semantics and applications, especially across organisations, can be presented with a confusing mess.
Azure's solution to this problem is to have an access control service that implements a security token service (STS) in the cloud. It accepts an incoming token (of various types if necessary) and issues out another one that may or may not differ from the incoming one. This allows for scenarios of single sign on across enterprises and organisations etc, from multiple sign on sources.
Service Bus
Exposing internal applications out onto the internet isn't easy. Network address translation and firewalls get in the way of efficiently and securely exposing your on-premises application to other users.
In Azure, the service bus provides a cloud-based intermediary between clients and internal applications. Organisation X may expose application A by connecting it to the service bus - it initiates the connection, over standard ports, and keeps the connection open, thereby ensuring NAT doesn't interfere. Meanwhile, Organisation Y opens their connection to the service bus and connects to these intermediary end-points that map back to the actual organisation's end points.
Of course all of this is controlled and secured with integration to the access control service.
Workflow
Where should workflow logic that co-ordinates cross organisation composite applications be run?
Azure helps to make this clear by having the workflow service run WF based workflows in the cloud. There are some limits on what activities can be used (eg: no code activities), but having the workflow run in the cloud overcomes the problem it is meant to address.
SQL Data Services
Formerly known as SSDS - this is now just SDS - is built on SQL server and provides a mechanism for working with a fixed hierarchy of data tied to a data sync service based on the sync framework. Whilst this sounds much like the storage service, the ultimate aim of SDS is to provide more database relevant facilities like reporting, analysis, ETL and more.
It's important to distinguish that SDS is built on SQL server, but it is not SQL Server. It's a hierarchy storage solution. Each data centre has authorities and each of these has data containers, which in turn consist of entities and entities have properties. Each property has a name, a type and a value.
This may seem a little limiting, but one key advantage is never having to worry about managing SQL servers or SDS itself. You just see data, not the database - all scalability and management etc is taken care of, on behalf of your application by the Azure platform.
SDS data is accessed via SOAP and REST (including ADO.NET Data services) and, just like with the storage service, it provides a query language based on the LINQ syntax with queries returning entities. Unlike storage services however, SDS supports database type functionality with order by and join operations.
Live services
Live services and the live framework offers something called a live operating environment (LOE) that allows for;
- Accessing live services data, and personal data
- Contacts
- Hotmail
- Calendar
- Search
- Maps
- Creating a mesh of devices
- My vista desktop
- My MAC OSX desktop
- My windows mobile device
- All running the live operating environment, with data synchronised across all devices and into the cloud.
- Creating mesh enabled web applications that can run through your browser, on your desktop or on any device within your live mesh.
Applications that are built to run within the mesh, on all of the LOE devices - create and consume both cloud and local data by using the live framework to access live services data via it's exposed REST interface (data is presented in the AtomPub format).
Applications are rich internet applications (RIAs) built using silverlight, javascript, flash etc and run from the desktop or from the cloud on the devices within the mesh. A user can add devices into their mesh and can then select to install mesh applications (from a catalog) to the LOE in the cloud that are then also presented via the LOE on the mesh devices.
Conclusion
Microsoft are investing heavily in Azure and there's no doubt that cloud computing and more specifically utility computing will be a significant factor in the future and the Azure platform overall offers some exciting opportunities to exploit and monetise ideas with much lower commitment and risk.
No comments:
Post a Comment