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.
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
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
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
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
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
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
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
Notes de l'éditeur
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