Windows Azure Internals

Et on commence par un superbe trailler pour le livre de Mark Russinovich : « Trojan Horse »

🙂 🙂 🙂 🙂

La session commence par l’architecture des datacenter azure.

Après un rappel des chiffres (des centaines de milliers de serveurs dans 8 régions),  on attaque le cœur du cloud OS avec :

  • La structure du Fabric Controler (FC) qui est comparé au Kernel de l’OS puisqu’il gère toutes les ressources du datacenter.
  • L’organisation du datacenter et la gestion des clusters (rack de 1000 serveurs) par le FC
  • L’aspect distribué du FC avec son instanciation sur certains serveurs du cluster (des sortes d’agent)

On enchaine sur une petite démo d’interrogation du FC à l’aide d’un outil : « FCClient »

Ensuite on passe à l’architecture réseau du datacenter et son évolution depuis l’ancienne version (DLA) vers la nouvelle (Quantum10) qui a permis de passer de 120Gbs à 30 000 Gbs (bande passante agrégée)

Le sujet suivant est le load balancer : le nouveau load balancer est un load balancer software qui est en fait une application azure. Et on enchaine sur une démo avec psping (psping permet de mesurer la latence et la bande passante entre deux points). Le but de la démo est de montrer la différence de latence qu’en on passe par les ip dynamique ou les vip. à le load balancer n’introduit qu’environ 0,5 ms

On passe ensuite au processus de déploiement :

  • Démarage du nœud
  • Boot PXE
  • Installation de l’OS (PE) et de l’agent

Puis : les interactions entre le portail et le FC via RDFE (Red Dog Front End) : et au passage on a droit à une petite anectode sur Red Dog ;-). Et on rentre donc dans le détail sur le rôle de RDFE.

Maintenant c’est le tout le processus de déploiement d’un package qui est expliqué (toutes les étapes sont gérées par le FC) et notamment les contraintes d’allocation des ressources (pré requis hardware, software, prise en compte de la fragmentation des ressource).

C’est maintenant le tour au rôle PaaS de passer à la moulinette :

  • Mark explique l’usage des disques lors du déploiement
  • On a droit à une petite astuce : le contenu du rôle est copié  4 fois à il nous conseille d’enlever un maximum de choses du package et de les stocker dans le storage : ensuite on les charge à la demande.

Et puis on passe au Iaas.

D’abord comment fonctionne les disques / le driver et le cache. Au passage on apprends que le cache n’est activé que sur le disque de l’OS.

On a droit ensuite à des recommandations sur l’utilisation des différents types de disques. à et une démo sur les perf des différents type de disques J

Sujet suivant : comment fonctionne les updates :

  • Update du code de l’app
  • Update de l’OS

Suite des sujets :

  • Le monitoring des nœuds et des rôles
  • Le déplacement d’une instance de rôle
  • Réallocation d’une instance

La session se termine sur les retours de l’incident qui à lieu le 29 février 2009 une petite vidéo sur le centre des opérations Windows Azure et Mark nous explique tout le détail de l’incident.

Super session comme toujours avec M. Russinovitch

Roch

Building Real-Time Web Apps with ASP.NET SignalR par Guillaume

SignalR est une librairie permettant de faire du temps réel et du push en http, avec des mécanismes de fallback pour des navigateurs anciens.

SignalR fait maintenant partie de ASP.Net, sera bientôt déployé avec ASP.Net, et est décomposé en 2 API (client + serveur)

Côté serveur ont fait une classe héritant de Hub, dans laquelle on met des méthodes qui seront accessibles cote client, sur le même modèle que MVC. Cote client, on va utiliser la librairie javascript associée, créer des méthodes et se connecter sur le hub. Le hub peut appeler les méthodes déclarées dans le client et vice versa. Un système de projection expose automatiquement les entites et methodes du serveur, dans l’API client.

On voit ça applique à une appli dans laquelle on peut déplacer un élément, et voir le résultat en temps réel sur un autre navigateur.

SignalR peut être utilisé pour des apps de monitoring, travail collaboratif, suivre la progression de traitements longs, …

On voit ensuite un jeu (shootr.signalr.net). On est invite a se connecte et a jouer tous ensembles sur nos tablettes ^_^

Des guidances seront publiées très prochainement pour approfondir les concepts.

SignalR peut utiliser websocket, a condition que le browser le support, et que le serveur et l’infra réseau le supporte. Si ce n’est pas le cas, SignalR va utiliser des messages par iframe ou du http long polling.

SignalR a plusieurs librairies clientes (javascript, .Net, iOS, etc) et d’autres sont en cours.

Le cœur de SignalR a été reecrit pour ameliorer les perfs, et peut traiter au moins 100000 messages/secondes/serveur, et supporte du scaling horizontal avec un système de service bus géré soit avec azure, soit reddis, soit sql server.

SignalR utilise maintenant des perfcounters pour faire du tracking, et dans les sources de SignalR, on trouve un outil de loadtest.

Guillaume

Building Real-Time Web Apps with ASP.NET SignalR par John

SignalR est une libraire permettant une communication en temps réel entre un client et un serveur (COMET, HTTP Streaming, WebSockets). C’est une abtraction d’une connexion  temps-réel en HTTP pour .NET

Après une courte introduction la session commence par une démonstration de la création d’un projet ASP.NET SignalR et de la mise en place d’un Hub et d’un client en Javascript.

Quelques exemples de jeux dont ShootR (shootr.signalr.net) qui est un jeu en temps réel où le serveur maintient la boucle de jeu.

SignalR utilise un API très simple à deux niveaux. Le bas niveau s’occupe des connections, déconnections et du broadcast sur tous les clients. Le haut niveau, les Hubs, construits au-dessus de la couche bas niveau s’occupe de la génération automatique de proxy Javascript.

Ensuite une démo de la création d’une connexion persistante avec à la fois les Connection et les Hubs.

Quid des websockets ?

Elles marchent si :

  • Le server est ASP;nET 4.5 sur Windows 2012
  • Le client utilise IE10 ou Chrome, Safari, Firefox
  • Votre proxy de load balancing le supporte
  • Votre NAT le supporte
  • Tout le monde entre le client et le supporte le supporte
  • Vous aimez coder des sockets pures
  • Vous gérez le scaling vous-même

SignalR lui fonctionne partout et essaie les websockets en cas d’échec les connections suivantes sont essayées :

  • Server Sent Event
  • Forever Frame
  • Long Polling

Ensuite on a une petite démonstration montrant comment avec le débuggeur inclus dans IE10, voir les connections entre le client et le serveur.

Il existe des clients SignalR pour :

JS, .NET SL5, Windows Store App, iOS (community), MonoTouch (community)

Dans le futur il y aura :

WP8, MonoTouch, MonoDroid et autres…

S’ensuit une démonstration montrant plusieurs types de clients connectés au même hub.

Quelques informations sur la performance ensuite.

Très grande performance sur une seule machine (100 000 messages par seconde avec une empreinte mémoire faible).

Tout étant asynchrone dans SignalR il fait une bonne utilisation des ressources.

On a aussi la possibilité de faire du scaling grâce à l’intégration d’un bus permettant de faire dialoguer différents nœud (serveurs) entre eux. Ce bus peut tourner dans le service bus azure.

Ensuite ils nous ont présenté la façon qu’ils utilisent pour faire des tests de performance sur SignalR.

Nouvelles fonctionnalités de la version 1.0.0 alpha 1

  • Meilleurs performances
  • Refonte de l’API d’invocation du client
  • Autenthification sur les HUB
  • Modules pour les HUB
  • Keep-alive sur le client

Version finale fin 2012.

Une session bien sympathique permettant de découvrir SignalR et ses capacités.

John

Continuous Integration with Windows Azure Websites

Beaucoup de démos en perspective.

Le speaker commence par rappeler l’importance de penser au déploiement dès le début du projet et de l’automatiser pour minimiser les risques et le faire plus souvent.

# Integration continue avec Team Foundation Service (tfs.visualstudio.com)

La première démo fait un tour rapide de TFS : dashboard, source control et surtout les builds, en utilisant un projet MVC avec des tests.

On crée ensuite un web site via le portail, et on le connecte au TFS ce qui crée automatiquement une définition de build avec test + déploiement !

# Deploiement Continue avec codeplex et github

Cette fois-ci on prend un projet node.js sur github.com

On crée un nouveau web site via le portail, on cree un git repository et on le connecte à github ce qui lance automatiquement une synchro du repository et un deploiement.

Pb sur github tout est public, donc on ne peut pas mettre de clés privées, de mots de passe… Pour cela on ajoute les config via le portail azure dans l’onglet Configure.

# Bring your own CI

La démo est un retour d’experience de murally.

Ils utilisent Jenkins comme moteur de CI : tests, YUI compressor, gzip, upload des assets dans amazon s3, git push

Leur service grossit rapidement et ils font des déploiements plusieurs fois par jour. L’objectif est de développer une feature, la tester, la déployer, mesurer son impact, la mettre a jour, la deployer etc.

Ses conseils :

1. prendre son moteur de CI préfère (team city, Jenkins, cc.net..)

2. utiliser les déploiements bases sur git plutôt que ftp ou web deploy pour pouvoir gérer un rollback rapidement

3. utiliser le même build pour tous les environnements

4. ne pas passer directement de son repository au cloud, mais avoir un point de retention

5. tout le monde dans l’équipe doit utiliser les mêmes outils

6. garder un build rapide (moins de 3 minutes)

7. ?

8. faire de l’intégration continue depuis le premier jour du projet

9. suivre les versions délivrées et utilisées

10. rester calme et être fier de tous ses déploiements (la livraison n’est jamais un stress)

# custom scripts

On peut spécifier son propre script de déploiement en ajoutant un fichier .deployment qui permet de spécifier le script à utiliser : un batch .bat ou un fichier javascript node.js

C’est encore tout neuf (ils ont écrit le script la semaine dernière), donc pour l’instant il manque les templates de scripts, les best practices, la doc, etc. et donc il faut tout faire tout seul.

Pour ceux qui ne sont pas encore convaincu de l’intérêt de l’intégration continue, qu’il regarde cette session ou vienne me voir ;-)! La combinaison Azure Web Sites et TFService est vraiment intéressante : c’est rapide à mettre en place et ça semble très efficace.

Pierre-Yves.

Windows Azure Active Directory: enabling single sign on and directory services for cloud SaaS apps

La session commence par une description  du besoin au travers de scenarios mettant en évidence la limitation de la fédération d’identité et le besoin d’un annuaire.

La fédération d’identité permet d’avoir toutes les informations utiles sur un utilisateur au travers des claims mais ne permet pas d’avoir accès aux autres utilisateurs (exemple : les subordonnés).

Ensuite les avantages liés à l’utilisation d’un annuaire sont abordés : la possibilité d’établir des relations entre les utilisateurs, de créer des regroupements, en plus de l’authentification. Par ailleurs les annuaires utilisent des protocoles standards pour les fonctions d’administration et d’authentification ce qui permet d’utiliser des outils existant.

Qu’est-ce qu’azure active directory :

– Une réplication d’un annuaire d’entreprise dans le cloud

– Un service tournant en local qui effectue la réplication

– Un portail de gestion (http://activedirectory.windowsazure.com )

– Une Api (Graph API) : ce n’est pas du LDAP ici il s’agit d’une api REST. La justification essentielle de l’utilisation d’une api différente est l’aspect multi-tenant de cet annuaire

– Pour l’authentification on a le choix entre différents protocoles :

  • OAuth2
  • SAML-P
  • WS-Federation

Dans le cas où on ne dispose pas d’un annuaire local il est néanmoins possible d’utiliser cet annuaire, dans ce cas les credentials seront aussi maintenus dans  l’annuaire.

La session continue sur une démo sur les comptes d’entreprise. Il s’agit de la possibilité de s’authentifier sur azure à l’aide d’un compte qui sera authentifié par active directory et permettra de gérer les services azure pour le compte de l’entreprise. La démo est faite avec une authentification par certificat/carte à puce

On continue cette fois ci avec une démonstration sous Visual Studio : il s’agit de l’ajout de l’authentification avec azure active directory dans une application asp.net

Ensuite un peu de slide pour décrire les interactions lors de l’intégration d’une application avec WAAD :

  • L’inscription du service
  • L’authentification d’un utilisateur
  • L’authentification de l’application et l’accès à l’api Graph

L’api Graph :

  • Il s’agit d’une api REST utillisant soit JSON soit XML
  • Permet d’interroger/créer/ mettre à jour/lister les relations …
  • Elle permet de récupérer des résultats différentiels à l’aide d’un cookie

On termine la session avec différentes démonstrations :

  • Comment autoriser une application à utiliser notre annuaire

Pas trop de code dans cette session mais un bon aperçu de WAAD.

Roch

Windows Phone 8: Performance & Optimization for Developers

On commence par une introduction sur la différence entre la performance réelle et perçue et une démonstration entre le temps de chargement entre un Wp7 et WP8

Avant JIT très rapide générant du code de mauvaise qualité

Maintenant JIT très lent générant du code performant. NGEN aide à générer le code en natif avant grâce au fait qu’on est passé avec la CLR .NET normale.

Points de performance améliorés :

  • Demarrage
    • NGEN
  • Splash Screen
  • Fill Rate
  • Panorama & Pivot
  • ListBox devenant blanc
  • ProgressBar (celle par défaut)

Quoi de neuf :

  • LongListSelector (remplace la ListBox)
  • Multi Core
  • Image Decode to Size
  • ViewportControl
  • Natif pur et hybride
    • Windows Runtime projects projects only from Native to managed (mais on peut toujours utiliser des évènements).

Démo d’une mise à jour d’un projet WP7 versWP8 qui augmente les performances du chargement sans rien faire.

Démo d’une ListBox qui n’était pas très réactive remplacé par un LongListSelector (belle amélioration des performances).

Maintenant les limites maximum de mémoire utilisé par les applications sont testée et bloquées à la certification si dépassées.

XNA & SL/XNA sont limités à 150MB (opt-in pour 180MB) quel que soit les spécifications des téléphones.

Pas de limite de mémoire en mode DEBUG.

Améliorations de la gestion de la mémoire (Le panorama utilise maintenant moins de mémoire).

Rappels de compteur de performance :

  • Application.Current.Host.Settings.EnableFrameRateCounter = true
  • Application.Current.Host.Settings.EnableRedrawRegions = true

Projets Hybrides :

  • Il peut être intéressant dans le cas d’applications faisant beaucoup d’appels .NET à l’API native de créer un composant C++ qui englobe tous ces appels en un seul afin d’éviter des problèmes de marshalling.
  • Penser à utiliser des composants natifs pour le traitement d’images ou de vidéos etc…
  • Penser à DrawingSurface et DrawingSurfaceBackgroundGrid

Dans les projects C++ D3D :

  • Penser au scaling (utiliser du fullscreen n’est pas toujours une bonne solution)
  • Le téléphone supporte D3D 9 Level 3
    • Attention car l’émulateur supporte des niveaux supérieurs

Démo Hybrid Maze (http://aka.ms/vwwtxa)

Il parle ensuite du nouveau profiler d’application pour WP8 (pour .NET et Natif) et montre comment l’utiliser.

Une session assez intéressante par un speaker très dynamiques 🙂

John

Deep dive into WinJS

Session un peu décevante car plus introductive que réellement « deep dive », on a cependant quelques tricks intéressants

Nous allons voir :

  • Structurer une appli
  • Navigation
  • Promises
  • DataBinding

Structure

L’objet WinJS.Application contient beaucoup de wrapper et de helpers pour faciliter la vie
(state, settings, …), bien regarder ce qu’il contient. Par exemple, la propriété sessionState est persistée automatiquement au suspend d’une app, ou la propriété onerror qui permet de catcher les erreurs non catchees.

Pour l’activation de l’appli, on peut avoir une grosse méthode pour chaque cas (launch, search,…) mais on peut aussi faire des méthodes ciblées qui souscrivent chacune a l’évènement.

Navigation

La classe Navigator créée par défaut dans les projets permet de simplifier la vie, mais ne pas hésiter a la plier a ses besoins.

Promises

Pour debugger les erreurs dans les promises, on peut activer un parametre dans VS (sous Debug/Exceptions) qui permet de pointer plus facilement sur l’erreur.

Binding

WinJS.Binding.as permet de générer un proxy observable sur un objet.

WinJS.Binding.converter et initializer permettent de créer facilement des méthodes de binding.

Guillaume