Check this link below
Azure is a highly scalable cloud platform but still does not offer any out of the box features through the management portal for scaling your roles based on the increasing loads. It however exposes the APIs it internally uses to scale up/down when you place a request through the management portal.
Here are some approaches you can use to implement dynamic scalability of you Azure roles.
One of the major issue in having a LOB hosted in Azure was the that Azure does not have a SMTP server available on the cloud.
You would be used to using System.Web.Mail from your application to send mails but this requires a SMTP server the application can connect to. This is the part which is not available in Azure. But the ship is still afloat!!
You could do one of there:
Talk to 3rd party providers who can help sending emails
Connect to you on-premise SMPT servers / Email Forwarders
Use APIs / Services exposed by mail servers to send mails.
The 3rd approach could possibly be the best way to implement this as you can leverage Exchange Online services. http://www.microsoft.com/online/exchange-online.aspx claims, all you need to pay is $5 per user per month and considering the minimum you go for is a 5 user package, you are still paying 25 $ a month which works out pretty economical considering the advantages you get like:
Improved e-mail security
“From virtually-anywhere” access to e-mail for your employees
Enhanced operational efficiency for your IT staff
25-gigabyte (GB) mailbox storage per standard license
Exchange online also exposes web services which you could use within your Azure application to send emails.
Here is what you need to do to get things going.
Get a Trial Subscription for Exchange Online. Create user accounts and remember the username, password.
Next you need to connect to Exchange Webservices. how do you the address of that? here they are:
Add to service reference to your Azure project and you are all ready to use the APIs to Read/Write/Monitor mails and mailboxes.
Wondering what the code should be? Here you go:
var Username = RoleEnvironment.GetConfigurationSettingValue("EWSUserName"); var Password = RoleEnvironment.GetConfigurationSettingValue("EWSPassword"); var service = new ExchangeService(ExchangeVersion.Exchange2007_SP1); service.Url = new Uri("https://red001.mail.microsoftonline.com/ews/exchange.asmx"); service.Credentials = new WebCredentials(Username, Password); var message = new EmailMessage(service); message.ToRecipients.Add(txtTo.Text); message.From = new EmailAddress(txtFrom.Text); message.Subject = txtSubject.Text; message.Body = new MessageBody(BodyType.HTML, txtBody.Text); message.Send(); lbStatus.Text = "Mail send sucessfuly to " + txtTo.Text + "..";
Here is the sample I had created to test this.
At PDC 2010 we announced the availability of Azure Connect (formerly Project Sydney) which is a part of Azure Virtual Network. This feature allows a easy way of migrating complex application over to Azure.
Azure connect aims at providing a easy but secured way to link your on-premise machines to the roles hosted in Azure so they communicate among themselves with much ease. So no more Service Bus and ACS.
You can now sign up for the Windows Azure Connect CTP via the Windows Azure Management portal.
* All relays for Windows Azure Connect during the CTP are located outside of Windows Azure Data Centers, thus network traffic between Windows Azure roles and Connect relays will be charged as normal Windows Azure bandwidth usage.
So what does Azure Connect exactly do? Its an easy mechanism to setup IP-based network connectivity between on-premises and Windows Azure resources. This enables direct IP-based network connectivity with you existing on-premises infrastructure.
Some application scenarios for Windows Azure Connect include:
*Enable enterprise apps, which have migrated to Windows Azure, to connect on-premises servers (e.g. SQL Server ).
*Help applications running on Windows Azure to domain join on-premises Active Directory. Control access to Windows Azure roles based on existing AD accounts and groups.
*Remote administration and trouble-shooting of Windows Azure roles. E.g. Remote PowerShell to access info from Windows Azure instances.
Most of these were earlier implemented using Azure AppFabric Service Bus. So its even more important to understand how they are different and when to use what. First thing to keep in mind is that they do not compete instead, they go hand in hand. Here is however a chart of technical specifications of both of these:
|Purpose||An IP-sec connection between the local machines and azure roles.||An application service running on the cloud.
|Connectivity||IP-sec, Domain-joint||NetTcp, Http, Https|
|Components||Windows Azure Connect Driver||Service Bus, Access Control, Caching|
|Usage||• Azure roles connect to local database server.
• Azure roles use local shared files, folders and printers, etc.
• Azure roles join the local AD.
|• Expose the local service to Internet.
• Move the authorization process to the cloud.
• Integrate with existing identities such as Live ID, Google ID, etc. with existing local services.
• Utilize the distributed cache.
Having understood the specifications of the technologies, lets understand when to use these based on the scenarios.
|I have a service deployed in the Intranet and I want the people can use it from the Internet|
|I have a website deployed on Azure and need to use a database which deployed inside the company. And I don’t want to expose the database to the Internet|
|I have a service deployed in the Intranet and is using AD authorization. I have a website deployed on Azure which needs to use this service|
|I have a service deployed in the Intranet and some people on the Internet can use it but need to be authorized and authenticated|
|I have a service in Intranet, and a website deployed on Azure. This service can be used from Internet and that website should be able to use it as well by AD authorization for more functionalities|
Roadmap of Azure Connect
* CTP released – end of 2010
On-premises agent for non-Windows Azure resources
Supports Windows Server 2008 R2, Windows Server 2008, Windows 7, Windows Vista SP1, and up.
Enable connectivity using existing on-premises VPN devices
Today we are releasing an update to the Identity Developer Training Kit; we are also releasing the first MSDN-hosted Identity Developer Training Course, an online version of the kit where all the labs instructions and setup files are unbundled and individually accessible. Both are heavily cloud-flavored.
January 2011 Identity Developer Training Kit
Besides the usual WIF workshop videos & decks and the labs on WIF + ASP.NET, WIF+WCF, delegation, WIF & Silverlight integration and ACSv1, the news in the January release are:
· New lab on using the ACS December Labs release for federating with multiple business identity providers (ie ADFS2), using the ACS management API and more
· The introductory lab on web identity providers, rules and HDR has been updated to the December Labs release of ACS
· The Windows Azure Single Sign On lab and the WIF+WCF on Windows Azure lab have been updated to the Windows Azure SDK 1.3 and the new Silverlight portal
o In addition to the update, the single, extra-long exercise in WIF+WCF on Windows Azure has been refactored in 3 different exercises
· New slide deck on identity and the cloud, complete with speaker notes, ready for you to re-deliver (taken from this, but with all the ink transformed into PowerPoint animations )
· The setup of all labs have been revved to the latest version of the dependency checker
· The resources list has been updated
Please continue to send us the bugs you find and we’ll queue them up for the next releases. Also, please let us know if there is a topic you would like us to cover in a lab! Although I can’t promise it will make it into the kit, it will certainly help in the prioritization process.
January 2011 Identity Developer Course on MSDN
Back at PDC09 we published our first online courses under http://channel9.msdn.com/learn, and the identity course was released in that wave. The community really appreciated the chance to access directly the instruction pages containing the solution to their problem at hand, instead of downloading entire kits.
Some of the courses are in the process of being migrated to MSDN, where they can enjoy improved discoverability and integration with the rest of the developer content, extra features such as PDF versions of the labs instructions and so on.
Today we are releasing our first MSDN version of the identity developer training course, which is fully aligned with the offline kit release described earlier. For a brief time the MSDN and Channel9 versions will coexist, but we will soon take the Channel9 one down and put proper redirection mechanisms in place
On my last post I wrote how to enable ping between the local machine and an Azure VM running your role.
Now it is time to enable a full Folder Share the two machines.
To enable file sharing on Azure VM, follow the steps below:
First make sure the Windows Azure Connect connection is established. e.g. make sure you can ping your Azure VM from your home machine and vice versa. (see last post)
1. Remote Desktop to your Azure VM
2. Run “wf.msc” to open the Windows Firewall console
3. Create a new inbound rule to allow file share:
a. Right click “Inbound Rules”, choose “New Rule …”
b. Select “Predefined”, choose “File and Printer sharing” from the drop down list
c. Follow through the wizard, leave everything checked as they are
d. “Allow the connection” and Finish
4. Create a folder on the VM machine, e.g. d:\Share
5. Create a network share by running this command: “net share MyShare=d:\share /grant:account_on_vm,FULL”
7. Restart the SMB service (net stop lanmanserver && net start lanmanserver)
8. Now you should be able to connect to this share from the other Connect machine. e.g. Run “net use * \\RD00155D328A7A\MyShare”, where RD00155D328A7A is the hostname of your Azure VM.
Return of the Windows Azure GAC Viewer
I’m pleased to announce that the excellent utility – the Azure GAC Viewer – is once again online and available for general use. You can access it at http://gacviewer.cloudapp.net. This tool shows you a dynamically generated list of all of the assemblies present in the GAC for an Azure instance. Additionally, it also allows you to upload your project file (*.csproj or *.vbproj) to have the references scanned and let you know if there are any discrepancies between what you are using and what is available (by default) in Azure. You can then adjust your project file (copy-local=true) to ensure your application can run successfully.
If you are familiar with the tool, you may be thinking “Wait! you aren’t Wayne Berry, and besides, the URL has changed!” – and you would be correct on both counts. Wayne developed the tool and posted about it back in September of last year. Since that time, however, Wayne has accepted a position on the Windows Azure team and is unable to continue to maintaining the site full time. As a gesture of kindness to the community, he has passed the source code to me and given me his blessing to re-launch the tool.
As it stands today, the tool is nearly exactly as Wayne developed, with a few tweaks to have it use Guest OS 2.1 rather than 1.6. I’ve also added a contributors page to give credit to Wayne and to the organizations that are allowing me to maintain and keep the site online.
In the future, I hope to make the source code available on CodePlex as well as to add to the list of tools that live on the site. If you have any bugs with the current site or ideas for future changes, please feel free to contact me.