www.windowsazure.com has all the required software to start developing against Windows Azure. It is more developer focussed, eliminating various infrastructure details thereby enabling developers to focus more on application development.
Deployments and storage functionality can be tested by developers on local machines using Azure emulators before publishing on Azure
Deployment can be done using,
- Azure management console (web version)
- Visual studio publsh project
- Powershell
All deployments are automated by Azure using the configurations and solution packages provided by developers. Data centers at geographically significant locations, network setup, load balancing, failover storage are all provided by default to all azure applications. Based on subscriptions and configurations provided by developers Azure automatically builds required infrastructure and deploys custom solutions.
Solution package updates can be done in 2 ways:
- In place : Developers publishes updated solution package to Azure. It then takes one server at a time out of rotation from the NLB, applies the solution package and add the server back.
- Branching : Create a staging branch which will have similar vms as the production setup. It will have a private vip and dns. Developers will prepare the staging branch to what is required on production and once ready we just "Swap VIPs" between production and staging as both branches are similar.
Building blocks: Ready to use functionality already built into Windows Azure. All building blocks fundamentally make use of redundancy and failover.
- Storage : BLOB, SQL Azure, Table storage (NoSQL)
BLOB : 3 drives write for each write operation. Geo redundancy between data centers (built-in feature), file system on cloud, can be exposed on http,
Storage Account: Include a public url to allow access over http, choose a region local to where the code will be deployed, primay access key (used to program against it)
Use cloud explorer to manage Blob storage from desktop: http://clumsyleaf.com/products/cloudxplorer
The blob storage is fully accessible using API from code.
SQL Azure:
Relational db in the cloud
patching, clustering and backups are all included and managed by Azure
Table storage: non-relational tables
Messaging using Service Bus Queue: Design loosely coupled architectures. Rather than the FE depending on synchronous callbacks from BE use Queues to store FE requests and then have BE process the queue items asynchronously. Add more resiliency.
The above point can be easily thought through using a order management system, A FE system pushing orders into a queue and a BE system processing them. Add more processing power to FE or BE as required using Azure.
Hybrid systems:
The FE system in the above example could be website hosted in Azure which accepts messages into a Service Bus Queue
the BE could be a console app running on-premise listening and closing to the messages on Azure.
Systems Center could be used to manage on-premise and cloud infrastructure.
Service Bus Relay: Let me explain this with the below e.g.
You have an on-premise database. If you need to expose this database to mobile users via a cloud app then one the ways you can do it with very less code is by using service bus relay which connects Azure to the on-premise database using WCF endpoints and then presenting the information out to the mobile user. As you can see this is a synchronous operation.
Tools:
http://azurestorageexplorer.codeplex.com/
Reference:
http://channel9.msdn.com/Events/windowsazure/learn/Keynote-Getting-Started-with-Windows-Azure
http://blogs.msdn.com/b/morebits/archive/2010/12/20/walkthrough-windows-azure-service-part1-introduction.aspx
Deployments and storage functionality can be tested by developers on local machines using Azure emulators before publishing on Azure
Deployment can be done using,
- Azure management console (web version)
- Visual studio publsh project
- Powershell
All deployments are automated by Azure using the configurations and solution packages provided by developers. Data centers at geographically significant locations, network setup, load balancing, failover storage are all provided by default to all azure applications. Based on subscriptions and configurations provided by developers Azure automatically builds required infrastructure and deploys custom solutions.
Solution package updates can be done in 2 ways:
- In place : Developers publishes updated solution package to Azure. It then takes one server at a time out of rotation from the NLB, applies the solution package and add the server back.
- Branching : Create a staging branch which will have similar vms as the production setup. It will have a private vip and dns. Developers will prepare the staging branch to what is required on production and once ready we just "Swap VIPs" between production and staging as both branches are similar.
Building blocks: Ready to use functionality already built into Windows Azure. All building blocks fundamentally make use of redundancy and failover.
- Storage : BLOB, SQL Azure, Table storage (NoSQL)
BLOB : 3 drives write for each write operation. Geo redundancy between data centers (built-in feature), file system on cloud, can be exposed on http,
Storage Account: Include a public url to allow access over http, choose a region local to where the code will be deployed, primay access key (used to program against it)
Use cloud explorer to manage Blob storage from desktop: http://clumsyleaf.com/products/cloudxplorer
The blob storage is fully accessible using API from code.
SQL Azure:
Relational db in the cloud
patching, clustering and backups are all included and managed by Azure
Table storage: non-relational tables
Messaging using Service Bus Queue: Design loosely coupled architectures. Rather than the FE depending on synchronous callbacks from BE use Queues to store FE requests and then have BE process the queue items asynchronously. Add more resiliency.
The above point can be easily thought through using a order management system, A FE system pushing orders into a queue and a BE system processing them. Add more processing power to FE or BE as required using Azure.
Hybrid systems:
The FE system in the above example could be website hosted in Azure which accepts messages into a Service Bus Queue
the BE could be a console app running on-premise listening and closing to the messages on Azure.
Systems Center could be used to manage on-premise and cloud infrastructure.
Service Bus Relay: Let me explain this with the below e.g.
You have an on-premise database. If you need to expose this database to mobile users via a cloud app then one the ways you can do it with very less code is by using service bus relay which connects Azure to the on-premise database using WCF endpoints and then presenting the information out to the mobile user. As you can see this is a synchronous operation.
Tools:
http://azurestorageexplorer.codeplex.com/
Reference:
http://channel9.msdn.com/Events/windowsazure/learn/Keynote-Getting-Started-with-Windows-Azure
http://blogs.msdn.com/b/morebits/archive/2010/12/20/walkthrough-windows-azure-service-part1-introduction.aspx