Microsoft experiences azure et asp.net core
•0 likes•368 views
Report
Share
Download to read offline
La plateforme Microsoft Experiences repose sur un système en backoffice bâti sur les derniers produits et services Microsoft. Dans cette session, vous découvrirez au travers d’un cas concret en production, les nouveautés et les bénéfices apportés par ASP.NET Core 1.0, les bonnes pratiques ainsi que les pièges à éviter pour le faire fonctionner de manière optimale dans Azure. Seront également abordés les différentes possibilités offertes par ASP.NET et Azure pour rendre votre plateforme extensible en ouvrant de manière sécurisée l’accès à vos APIs.
More Related Content
What's hot
What's hot(19)
![[DevTestday] Gouvernance Dev/Test Azure](https://cdn.slidesharecdn.com/ss_thumbnails/gouvernancedevtestazure-160411102406-thumbnail.jpg?width=768&fit=bounds)
Viewers also liked
Viewers also liked(7)
Similar to Microsoft experiences azure et asp.net core
Similar to Microsoft experiences azure et asp.net core(20)
More from Sébastien Ollivier
More from Sébastien Ollivier(6)
Microsoft experiences azure et asp.net core
- 1. Asp.Net Core 1.0 et Microsoft Azure Les dessous de la plateforme Microsoft experiences
- 2. Mélanie Daboudet Sébastien Ollivier @m_dab Microsoft Florent Santin @sebastienoll Infinite Square @santinflo Infinite Square
- 3. • Le projet : de inwink à Microsoft experiences • Les choix techniques : - Développement serveur - Base de données • Le déploiement dans Azure • Evolutions et futur agenda N° 3
- 4. De inwink à #experiences
- 5. • Microsoft experiences c’est : • 15 000 participants à l’événement, +100 000 en ligne • Plus de 80 personnes pour gérer l’organisation sur +6 mois • Objectif - disposer d’une plateforme de gestion de l’évènement : • Coordination du contenu (sessions, thèmes, créneaux horaires…) • Logistique (salles, exposants, sécurité…) • Gestion des participants (inscription, accueil, animation, évaluation…) • L’expérience des participants Le besoin fonctionnel Microsoft experiences
- 6. • Plateforme SaaS de gestion d’évènements B2B • Développé pour le Cloud : • Multi-tenants • Scallable • Extensible par API Le produit utilisé inwink
- 8. ASP.NET Core Quoi? Pourquoi faire?
- 9. Les difficultés • Décembre 2015 à Juin 2016, de la beta à la RTM • L’outillage • La gestion de la configuration Les points positifs • La montée en compétences rapide • Open Source • L’orientation packages • Léger, rapide, composable • 100% asynchrone ASP.NET Core Difficultés / points positifs N° 9
- 10. Démo : ASP.NET Core
- 11. Et côté Data ? Quoi? Pourquoi faire? N° 11 SQL Azure DocumentDB Azure storage Redis
- 12. Les difficultés • Un temps d’architecture et d’outillage Les points positifs • Gestion du multi-tenant « confortable » • Isolation des données • Performance cloud • Les nouveautés SQL Server • Entre le SQL et le NO SQL Côté Data Difficultés / points positifs N° 12
- 13. Démo : SQL Azure
- 14. Hosting & Cloud
- 15. Serveur User / events SQL Azure Events détail SQL Azure Storage Blobs / queues DocumentDb RecomendationsEvents détail SQL Azure Redis Cache Azure Quoi? Pourquoi faire? Service plan Mail server function Notification services function Recomendations services function Service plan Authentification server Web App (.NET Core) API API App (ASP.NET Core) Backoffice / event selector Web App Badges, mails Web App Product website Web App Registration website Web App (ASP.NET Core) Speaker backoffice Exhibitor backoffice Companion Web App (node.js/react)
- 16. Les difficultés : • Des choix d’outils en preview • IIS Kestrel • Les scripts d’intégration continue Les points positifs : • Architecture modulaire / modulable / (auto-)scallable • Les services : SendGrid, NotificationHub, Redis, achat de certificat SSL… • Une équipe de dev à l’exploitation ! • App Insight Côté Cloud Difficultés / points positifs N° 16
- 17. Démo : Azure
- 18. Le futur…
- 19. • Migration vers 100% .NET Core • Micro services : • Supprimer les websites au profil des micro services • Encore plus d’utilisation de DocumentDB • De la documentation de l’API pour pouvoir les diffuser • Gérer les releases dans VSO • Du repos Evolution de l’architecture N° 19
- 20. N° 20
- 22. Notez cette session Et tentez de gagner un Surface Book Doublez votre chance en répondant aussi au questionnaire de satisfaction globale * Le règlement est disponible sur demande au commissariat général de l’exposition. Image non-contractuelle
Editor's Notes
- FSA
- FSA
- FSA
- 5min
- MDA
- MDA
- 24 minutes
- SOL Mettre en surbrillance ce qu’on a utilisé, pourquoi faire et pourquoi. ASP.NET Core 1.0, car dans l’aire du temps Fin Décembre 2015. Gros soucis sur la phase RC1 => RC2, du bonheur depuis. Par contre, Core CLR, uniquement pour le serveur d’authent, et le site web Web, .NET Framework 4.6 pour le reste à cause d’Entity Framework 6 pas clair. On peut également dire pourquoi on ne fait pas de l’EF 7.0
- Les difficultés Migration ASP.NET Core RC1 => RC2 : 1 semaine à 4 développeurs L’outillage à un peu bricoler (Dotnet restore…), pas mal d’extensions Visual Studio non encore compatibles (Profiler, CodeClone…) La gestion de la config et des dépendances entre DLL. Interessant mais à maitriser Les points positifs 1 journée pour monter en compétence d’ASP.NET MVC vers ASP.NET Core 1.0 Open Source (beaucoup de temps de lecture du code, notamment sur les libs d’authentification) L’approche 100% packages Leger, rapide, composable avec uniquement le nécessaire: middlewares, middlewares, middwlares 100% asynchrone, c’est comme ça et pas autrement
- SOL ASP.NET Core – 10min Sur le site web : -- Archi ultra simple pour besoin ultra simple Sur l’API : - Le projet.json Le startups (L’injection de dépendance omniprésence ) - Les middleswares - Le appsettings.json (avec les différents environnements) - Injection du bon DB Contexte dans la route
- SQL Azure : - Sharding - RLS - Tables historisées Sharding DocumentDB Pour le stateless : Redis
- Les difficultés Sharding : une phase d’architecture et d’outillage a prendre à compte dès le début (TT, secu) Les points positifs - Le confort côté dev (c’est quoi un tenant?) Une vrai isolation des données De la vrai performance cloud Entre le SQL et le NO SQL – les champs JSON
- FSA SQL – 10min Le projet DB Pro. -- L’historisation -- Le TT pour générer les contraintes en BDD -- Le projet déploiement en DacPac Dans la BDD -- Les tables de sharding -- Set CurrentEvent -- Montrer une table historisée -- Montrer une requête JSON (sur speakers) Dans Visual Studio -- Le bout de code qui set le contexte à chaque requête
- 10min
- SOL
- FSA/SOL Les difficultés : Des outils en preview interessants, mais dur à exploiter et à configurer : Azure Function, Azure function La passerelle IIS Kestrel (web.config, HTTPs, rebonds…) L’outillage à la main de l’intégration continue Les points positifs : Découpage de l’architecture en multiples websites Les services portée de main…. SendGrid, NotificationHub, Redis, achat de certificat SSL… La facilité de mise en place La facilité de déploiement : une équipe de dev à l’exploit ! Auto scalling AppInsight
- MDA Je vais prendre les commandes et vous montrer quelques interfaces pour vérifier sur l’équipe de dev travaille vraiment et Florent vous commentera (il faut bien qu’il travaille un peu) Ouverture dans chrome de l’onglet 1 (visual studio online – sur team project inwink). Florent, tu nous expliques à quoi ca sert? Blablabla Florent, je te demandes de click sur Build en haut, et je raconte une histoire Ok, on peut aller voir la prod? Ouverture dans chrome de l’onglet 2 (le portail Azure) Florent, c’est quoi tout se bazard? Je raconte une histoire Tu peux cliquer sur le truc en haut à gauche avec écrit Ressources group? Oui ! Tu peux cliquer sur inwink-func-prod Oui ! Portail Azure (5min) L’intégration continue dans Visual Studio Dashboard Azure (les métriques) Le requêteur d’AppInsight Les déploiements à chaud (Vip swap) Les Azure functions
- 2min
- SOL