Windows Azure. Scaling, Caching and Performance
•Als PPTX, PDF herunterladen•
0 gefällt mir•991 views
W
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Alexander Feschenko
Mehr von Alexander Feschenko (10)
Windows Azure. Scaling, Caching and Performance
- 10. Хранилище данных Кеш Web App
Hinweis der Redaktion
- Welcome and speaker’s introductionSet expectations that the session is going to be about identity and access control for applications targeting the Windows Azure platform, as opposed to the services themselves (SQL Azure, Windows Azure management calls, etc.)
- Slide ObjectiveIntroduce the important of ASP.NET in Windows Azure applicationsIntroduce the topics to be covered in this sessionSpeaking NotesWindows Azure can run a very broad variety of application typesASP.NET Applications will be a very common type of applicationWindows Azure supports ASP.NET very wellCore ASP.NET (HttpModules/HttpHandlers)Web FormsMVCBecause of the stateless nature of Windows Azure web roles important things to consider around Session StateAJAX callsWill discuss configuring DNS for Windows AzureWill discuss some advanced features for Windows AzureBoth very much suited to SaaS types of applicationsFinally touch on some Windows Azure common challengesNotesSome notes on Migration http://msdn.microsoft.com/en-us/windowsazure/ff356857.aspxAzure Architecture guidance http://msdn.microsoft.com/en-us/library/ff728592.aspx
- Most of the things I mentioned apply to SOAP web services as well. The WIF wizard works in the same way, ACS can handle the appropriate protocols, and so on. There are some obvious differences, both in expressive power (services can give higher guarantees thanks to the use of more advanced cryptography) and requirements (redirects are not necessary, but the requirements on the client capabilities are more stringent).It is noteworthy that at the moment Silverlight does not have the full capabilities you’d find in WCF based clients on desktop and backend applications, however most of the scenarios can be addressed in the same way with some custom code (see the Silverlight exercises in the identity developer training kit).The REST scenario is not supported out of the box for WIF. The REST protocols are so simple that you can handle those yourself,. However if you want to leverage the handily claims model and config-based authentication mechanisms there are custom extensions to WIF you can leverage.There are various mobile (and not only) scenarios in which you want to call a service, but the identity you want to authenticate is available only via redirect (i.e. browser based) protocols. There’s still work to be done there, but for early thinking about how to tackle the scenario you can refer to the windows phone 7 sample on acs.codeplex.com
- Most of the things I mentioned apply to SOAP web services as well. The WIF wizard works in the same way, ACS can handle the appropriate protocols, and so on. There are some obvious differences, both in expressive power (services can give higher guarantees thanks to the use of more advanced cryptography) and requirements (redirects are not necessary, but the requirements on the client capabilities are more stringent).It is noteworthy that at the moment Silverlight does not have the full capabilities you’d find in WCF based clients on desktop and backend applications, however most of the scenarios can be addressed in the same way with some custom code (see the Silverlight exercises in the identity developer training kit).The REST scenario is not supported out of the box for WIF. The REST protocols are so simple that you can handle those yourself,. However if you want to leverage the handily claims model and config-based authentication mechanisms there are custom extensions to WIF you can leverage.There are various mobile (and not only) scenarios in which you want to call a service, but the identity you want to authenticate is available only via redirect (i.e. browser based) protocols. There’s still work to be done there, but for early thinking about how to tackle the scenario you can refer to the windows phone 7 sample on acs.codeplex.com
- Most of the things I mentioned apply to SOAP web services as well. The WIF wizard works in the same way, ACS can handle the appropriate protocols, and so on. There are some obvious differences, both in expressive power (services can give higher guarantees thanks to the use of more advanced cryptography) and requirements (redirects are not necessary, but the requirements on the client capabilities are more stringent).It is noteworthy that at the moment Silverlight does not have the full capabilities you’d find in WCF based clients on desktop and backend applications, however most of the scenarios can be addressed in the same way with some custom code (see the Silverlight exercises in the identity developer training kit).The REST scenario is not supported out of the box for WIF. The REST protocols are so simple that you can handle those yourself,. However if you want to leverage the handily claims model and config-based authentication mechanisms there are custom extensions to WIF you can leverage.There are various mobile (and not only) scenarios in which you want to call a service, but the identity you want to authenticate is available only via redirect (i.e. browser based) protocols. There’s still work to be done there, but for early thinking about how to tackle the scenario you can refer to the windows phone 7 sample on acs.codeplex.com
- Most of the things I mentioned apply to SOAP web services as well. The WIF wizard works in the same way, ACS can handle the appropriate protocols, and so on. There are some obvious differences, both in expressive power (services can give higher guarantees thanks to the use of more advanced cryptography) and requirements (redirects are not necessary, but the requirements on the client capabilities are more stringent).It is noteworthy that at the moment Silverlight does not have the full capabilities you’d find in WCF based clients on desktop and backend applications, however most of the scenarios can be addressed in the same way with some custom code (see the Silverlight exercises in the identity developer training kit).The REST scenario is not supported out of the box for WIF. The REST protocols are so simple that you can handle those yourself,. However if you want to leverage the handily claims model and config-based authentication mechanisms there are custom extensions to WIF you can leverage.There are various mobile (and not only) scenarios in which you want to call a service, but the identity you want to authenticate is available only via redirect (i.e. browser based) protocols. There’s still work to be done there, but for early thinking about how to tackle the scenario you can refer to the windows phone 7 sample on acs.codeplex.com
- Slide Objectives:Explain that there are different VM instance sizes available within Windows AzureSpeaking Points:---Speaking Points:One of the key areas of feedback has been to reduce the cost and size of Windows Azure instances. At PDC we will announce..Notes:(*) 20GB with a limitation on VHD size if they are deploying VMRole on XSmall: the VHD can only be up to 15GB.each tenant can support 20 instances just like regular subscriptions with Small VM. We do not scale based on core counts.There is no SLA on the network bandwidth for each VM size as this resource is shared among all the VM. That said, we need to provide guidance for customer so they could design their applications correctly. From the engineering side, this is what we mean by Low, Moderate and High. • Low currently means 0-15Mbps with short burst up to 25-50Mbps (Megabit/s). These are sufficient for some web sites with low traffic. • Moderate means 0-100Mbps with short burst up to 200Mbps (100Mbps is the norm). This is what we currently reserve for the Small VM.• High means 200-800 Mbps. If you divide this into 3 spectrums for Medium, Large and XL. Then Medium is in the low end, Large hovers around the middle zone and of course XL takes the high-end spot.These rates should be used as guidance. Nothing can beat a test run to see what the application requires but using these bandwidth ranges, hopefully it reduces the guess work for the customers
- Let’s think for a moment about claims based identity in itself and at the tools we can use to implement it; we will re-introduce cloud-specific considerations later
- See 2nd demo at http://bit.ly/cNdEcM
- Let’s think for a moment about claims based identity in itself and at the tools we can use to implement it; we will re-introduce cloud-specific considerations later
- Most of the things I mentioned apply to SOAP web services as well. The WIF wizard works in the same way, ACS can handle the appropriate protocols, and so on. There are some obvious differences, both in expressive power (services can give higher guarantees thanks to the use of more advanced cryptography) and requirements (redirects are not necessary, but the requirements on the client capabilities are more stringent).It is noteworthy that at the moment Silverlight does not have the full capabilities you’d find in WCF based clients on desktop and backend applications, however most of the scenarios can be addressed in the same way with some custom code (see the Silverlight exercises in the identity developer training kit).The REST scenario is not supported out of the box for WIF. The REST protocols are so simple that you can handle those yourself,. However if you want to leverage the handily claims model and config-based authentication mechanisms there are custom extensions to WIF you can leverage.There are various mobile (and not only) scenarios in which you want to call a service, but the identity you want to authenticate is available only via redirect (i.e. browser based) protocols. There’s still work to be done there, but for early thinking about how to tackle the scenario you can refer to the windows phone 7 sample on acs.codeplex.com