Azure Serverless C2S
•Descargar como PPTX, PDF•
0 recomendaciones•49 vistas
Présentation en français sur le Serverless dans l'environnement Microsoft Azure. Fait à Tours le 19 Juin 2019
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (11)
Similar a Azure Serverless C2S
Similar a Azure Serverless C2S (20)
Azure Serverless C2S
- 2. • Intervenants • C2S Bouygues • Qu’est-ce que le Serverless ? • Serverless sur Azure Logic App Azure Function Autres • Tooling • REX Projet hyperviseur • Problèmes rencontrés • Conclusion • Questions-réponses • Miam L’architecture Serverless sur Azure Sommaire
- 3. Intervenants • Emilien GUILMINEAU Architecte logiciel Cloud, DDD, Bières @xrevo • Florian ROUSSELET Ingénieur d’études Full Stack .Net Mobilité, Web, Cloud http://blog.florian-rousselet.fr @flo_rousselet L’architecture Serverless sur Azure
- 4. 4 collaborateurs M€ Chiffre d’affaire 140 155 20172016 2018 C2S est le partenaire digital de ces clients Depuis sa création, C2S accompagne ses clients dans les grands projets de transformation digitaux. Nos clients nous font confiance pour le pragmatisme et les valeurs qui nous animent. 15 17 20172016 2018 NOUS METTONS LE DIGITAL AU SERVICE DU PROGRÈS HUMAIN
- 5. 5 NOS DOMAINES D’EXPERTISE PROJETS DE TRANSFORMATION DIGITALE CYBERSÉCURITÉ SMART BUILDING, SMART CITY & IOT DÉVELOPPEMENT LOGICIELS INFRASTRUCTURE SI ET CLOUD EXPLOITATION ET SERVICES MANAGÉS LE SPOT OPEN INNOVATION DÉVELOPPEMENT DE PARTENARIATS
- 6. DEV LOGICIELS : NOTRE POSITIONNEMENT • Design / UX • Web • Frontend • Backend • Mobile • Natif • Hybride • PWA • VR/AR APPLICATIONS METIERS • Cloud • Architecture Cloud, Serverless • API, ESB • IoT • Plateformes • Connecteurs • Data • Base de données • Intégration • Datalake • Datavisualisation BACKEND CLOUD • Intranet • Ged • Sites collaboratifs • Chatbot • Migration • Accompagnement DIGITAL WORKSPACE collaborateurs M€ Chiffre d’affaire 20182017 2019 ACCOMPAGNER AVEC PROXIMITÉ ET AGILITÉ NOS CLIENTS SUR DES PROJETS DE DÉVELOPPEMENT INNOVANTS Une équipe de développeurs logiciel, experts, architectes et scrum master en croissance pour 20182017 2019 29 40 , 2,8 3,5
- 7. L’architecture Serverless sur Azure 1. Ne nécessite aucune gestion des serveurs hôtes (ou processus hôtes). 2. Gère automatiquement la mise à l’échelle et le provisionnement 3. Offre des coûts basés sur une utilisation précise 4. Ses capacités de performances sont définies sur d’autres termes que la taille ou le nombre d’hôtes 5. Dispose implicitement d’une haute disponibilité La définition d’un service Serverless
- 9. SCHEMA
- 10. Logic App • FAAS : Level Noob • Modèle de briques prédéfinies Connecteurs Traitement Transfert • Triggers Timer HTTP Message/Tweet… • Workflow L’architecture Serverless sur Azure
- 11. DEMO
- 12. DEMO
- 13. Azure Function • FAAS : Level Elite • Ecriture du code - Via un navigateur internet - Via Visual Studio • Exécution liée à un plan de Consommation • Mini-Web App / WebJob SDK L’architecture Serverless sur Azure
- 14. DEMO
- 15. Autres briques Serverless • Service SignalR • EventHub / Azure Queue / … • Stream Analytics • Sql Database Serverless • Azure Storage L’architecture Serverless sur Azure
- 16. Tooling • Azure Storage Explorer https://azure.microsoft.com/fr-fr/features/storage-explorer/ • Azure CLI https://docs.microsoft.com/fr-fr/cli/azure/?view=azure-cli-latest https://docs.microsoft.com/fr-fr/cli/azure/reference- index?view=azure-cli-latest az sql server create --name $name --resource-group $group.name - -location $location --admin-user $adminUser --admin-password $adminPwd az sql db create --subscription $account.id --resource-group $group.name --server $servername --name $name --service- objective $sku --collation $collation • Calculatrice Azure https://azure.microsoft.com/fr-fr/pricing/calculator/ L’architecture Serverless sur Azure
- 17. Retour d’expérience : Hyperviseur Urbain • Elément principal de la Smart City. Connecter la ville à ses services. Feux Tricolores Lampadaires Alarmes Géolocalisation Véhicules Météo Crues Chantiers … L’architecture Serverless sur Azure
- 18. SCHEMA
- 19. Hyperviseur - Métriques • Quantité messages injectés 853 Millions (Avril) 25.5€ • Temps de traitement d’un message end to end 200ms à 3sec • Coût total (Avril) 220€ HT L’architecture Serverless sur Azure
- 20. Hyperviseur – Tracing / Logging • Pas de débugage évident des données EventHubs (grosse quantité) • Capture dans DataLake possible • Jaeger : outil de visualisation du flux distribué L’architecture Serverless sur Azure
- 21. SCHEMA
- 22. SCHEMA
- 23. Problèmes rencontrés • Logic App : Manque de souplesse • Function App : C’est du Online • Intégration dans Legacy L’architecture Serverless sur Azure
- 24. Conclusion • ON AIME BEAUCOUP • Redonne la main aux développeurs sur la partie infra, plus de souplesse • Le métier du développeur évolue, moins de code, plus de tooling, scripting TTM plus court • Effet de dispersion • Cartographie des éléments plus complexe • Perd de son intérêt si l’application a besoin d’être permanente L’architecture Serverless sur Azure
- 25. L’architecture Serverless sur Azure
- 26. Merci pour votre attention ! Des questions ?
Notas del editor
- Petit pitch d’intro. Merci d’être là blabla. Demander qui bosse sur Azure/Cloud. Demander qui connait/bosse sur du ServerLess. Profil plus dev ou admin? Etc.. Permet de jauger l’assemblée.
- Lecture bête et méchante du Sommaire
- Slides institutionnels Pas forcément lire tout le blabla. MAJ à l’oral, 220 collaborateurs actuellement. Montrer qu’on fait un peu de tout.
- Slides institutionnels
- Slides institutionnels Et bien sûr parler de Tours !
- Microsoft Azure / Amazon Web Services / Google Firebase / IBM Cloud Functions / Oracle Cloud Entendu parler la première fois en 2011 (avec l’avènement du PaaS). En 2014, Amazon ajoute AWS Lambda aux Amazon Web Services. Lambda permet de lancer des scripts Python Java ou Node.js, ou encore des exécutables Linux, en fonction d’évènements. C’est le principe de la Fonction en tant que Service (FaaS).
- Microsoft Azure / Amazon Web Services / Google Firebase / IBM Cloud Functions / Oracle Cloud Entendu parler la première fois en 2011 (avec l’avènement du PaaS). En 2014, Amazon ajoute AWS Lambda aux Amazon Web Services. Lambda permet de lancer des scripts Python Java ou Node.js, ou encore des exécutables Linux, en fonction d’évènements. C’est le principe de la Fonction en tant que Service (FaaS). … [SLIDE PRECEDENTE] Le Serverless a pu voir le jour grâce au Cloud. Ici on ne se soucis plus de l’infrastructure sous-jacente. Nous utilisons des services à la consommation. Architecture réactive, basée sur des évènements et s’adapte (scaling) selon la demande Paradigme utilisé par tous les fournisseurs de Cloud actuels
- Dans les faits, Microsoft le présente comme tel (pour les Function Apps)
- Ici on visualise le schéma en silo des différents modèles de Cloud. Historiquement, on retrouve le IAAS et le PAAS. Le PaaS est d’ailleurs la première brique du Serverless. C’est grâce à lui que le concept de Serverless c’est démocratisé puisqu’il permet de déployer toute une application sans avoir à se soucier de l’infrastructure sous-jacente (version de Windows, mise à jour, paramétrage réseau/sécurité,…). Grâce à lui on a découvert la joie de déployer rapidement, sans avoir à faire suer l’équipe infra … Est ensuite apparu le CAAS (Container As A Service) et le FAAS (Function As a Service). La différence fondamentale entre le PaaS et FaaS se situe sur le Unit of Scale (la capacité de montée en charge). En PaaS, quand on gère la montée en charge, on fait monter en charge toute l’application, avec toutes ses dépendances, et toutes les fonctionnalités qu’elle contient (même si elle ne sont pas toutes utilisés à la même fréquence), En FaaS, quand on gère la montée en charge, on fait monter en charge chaque Fonction à son rythme. Du coup si dans ma solution VS j’ai 10 Fonction, je peux très bien m’assurer de n’autoriser le scaling que sur 2 d’entres-elle car je sais qu’elles seront très demandées. Il faut savoir que même si on les utilise différemment (vous allez le voir après), chez Azure, PaaS et FaaS sont comme cul et chemise. Les offres de FaaS se base sur du PaaS, puisque vous pouvez décider de ne payer qu’à la consommation vos Fonctions (pratique quand elles ne sont lancées qu’une fois tous les X du mois), ou de les associer à un PlanAppService, pour améliorer les temps de réponses ou augmenter la capacité de traitement en cas de besoin (+ de CPU, + de RAM, + d’I/O disque, …). Note : le schéma ne présente pas le SAAS.
- Azure Logic Apps est un premier système permettant de faire du FAAS (Function As A Service). Grâce à un éditeur visuel, il permet de mettre en relation grâce à un workflow que l’on défini différentes briques techniques. Briques possibles : - Connecteurs : Yammer, Twitter, SQL SERVER etc… (environs 200) - Traitement : Parsing JSON, Modification de données - Transfert : Appel HTTP, Envoi Event Hub, Azure Table Trigger : Élément déclencheur de la Logic App. Plusieurs possible mais qu’un seul sélectionnable à la fois. - Timmer - HTTP : se comporte comme un endpoint - Action externe : Arrivée d’un mail, d’un tweet, d’un message dans ServiceBus… On doit définir un Workflow afin d’enchainer les éléments (connecteurs/traitements). On peut y mettre des boucles, des conditions, différentes branches. On peut attendre des résultats avant de lancer d’autres process. Variables possibles, on peut les définir, les modifier, incrémenter Divers : - Un process de retry est intégré bydesign dans chaque brique. - Editeur graphique dans le portail Azure ou Visual Studio - Derrière c’est un JSON qui est généré, modifiable à la main mais complexe - Workflow : Edition/Suppression complexe car dépendance forte -
- On ouvre le portal azure. On code la LogicApp devant eux. Une fois codées, on affiche un bitly de l'URL de la FunctionApp (codé auparavant), et un QRCODE (du bitly). Ici, on leur demande d'aller sur l'URL donnée. Et on affiche à coté le livetweet. #ServerLessC2S . Demo : BackEnd Function App sera appelé sur son HTTP endpoint dédié Elle se connecte à la BDD et log l'entrée Logic App : Timer Trigger (3sec), va lire les données en BDD et les compter. Enchaine avec la production d'un tweet sur le #ServerLessC2S Resources : SQL SERVER / SQL DB 1 LOGIC APP DE SECOURS 1LOGIC APP LIVECODEE 1 FUNCTION APP (BACKEND)
- AFFICHE TON PUTAIN DE LIVE TWEET https://twitter.com/hashtag/prezserverlessc2s?f=tweets&vertical=default&src=hash
- Second système permettant de faire du Serverless mais de manière plus évolué, le FAAS (Function As A Service). Ici on reprend la main sur le code, et on écrit notre Function App : Soit (en mode à l’arrache) dans le navigateur : C# script / JavaScript / … Soit (en mode killer) dans Visual Studio : C#, F#, … Langages possibles : Python, C#, F#, Javascript, TypeScript (Transpiling), Java Trigger : Moins de possibilités (tout ce qui est webhook), mais HTTP/Timer/Queue/Table La liste des connecteurs natifs est moins fourni que sur les LogicApp, mais les possibilités de traitement et la facilité d’écriture d’algorithme est bien meilleur. Tout est une question de trade-off : est-ce qu’on veut aller vite ou loin ?
- Ici on leur montre Visual Studio et le code existant. Endpoint HTTP connexion SQL Live Debug (VS + Chrome)
- Limité le Serverless aux LogicApp et FunctionApp serait bien trop réducteur. Un très bon exemple de service Serverless disponible sur Azure est l’EventHub. Service d’ingestion de données en temps réel. S’ajuste au volume de données de manière dynamique. On peut définir un nombre d’unités de débit (throughput units) par défaut et prévoir un nombre d’unités max pour l’auto-inflate. La notion de consommation de l’eventHub se rapproche dcelle du PaaS, puisque l’on choisi un montant de consommation, que l’on peut faire évoler en fonction du besoin (dynamiquement ou à la main). Le choix de cette approche (montant de consommation) est lié au fait que l’EventHub peux rapidement coûter cher. Possibilité de Capture vers un Azure BLOB Storage ou Azure DataLake afin de faire de la rétention/traitement à long terme.
- Rapidement, SignalR est un outil maintenant proposé en SAAS (avant librairie à embarquer) et qui permet d’ajouter des fonctionnalités temps-réels à des applications Web. Permet le suivi d’un processus par exemple sans rafraichissement de page. Marche sur un système d’abonnement et de notification client/serveur. Possible de faire du Broadcasting, de créer des groupes d’users ou d’envoi à utilisateur unique. Stream Analytics : Service d’analyse en temps réel, à la demande, de flux données. L’outil permet aux développeurs de pousser du code SQL, permettant de consommer des données entrantes et de la transformer (à destination de rapport PowerBI par exemple), avec une capacité de montée en charge dynamique assez impressionnante. L’outil peut notamment se plugger sur du EventHub pour analyser en temps réel des millions d’évènements à la seconde. C’est l’exemple typique du Serverless, où on pousse du code, et on se charge de gérer le curseur de scaling (permet de définir la capacité de traitement autorisé). Tout comme l’EventHub, on défini d’abord un montant max (sur le nombre d’unité de traitement), et l’on fait augmenter cette unité par jalon. Sql Database : Vous connaissez Sql Server ? Vous en avez marre de vous palucher les installations/configurations de toutes vos instances de déploiement ? La nuit vous rêvez d’un monde où il vous suffirait de provisionner un serveur, une base de données, de pousser vos SP et vos VIEW dessus puis de l’utiliser, et de pouvoir augmenter sa capacité de traitement au besoin ? … bah voilà, c’est pour vous ! C’est ce qu’on appelle du DBaaS, et c’est juste magique.
- QUI : Azure Storage Explorer (le lancer?), outil qui permet de se connecter via son compte Azure à différents espace de stockage : Blob Containers / File Share / Queues / Tables Modification, suppression renommage. Ajout dans Queue etc… Azure CLI : Outil en Ligne de Commande afin d’exécuter des actions sur un tenant Azure. CRUD sur des resources Azure. Pas spécifique au serverless mais outil indispensable. Calculatrice Azure : Permet de mesurer le coût d’une solution Azure, regroupe les différentes briques, permet l’export d’un rapport pour un client par exemple.
- Un hyperviseur (aussi appelé hyperviseur urbain) est un élément principal de la « Smart City ». Smart City par ByES (https://www.bouygues-es.fr/villes-et-territoires/smart-city) Valorisons le patrimoine d’équipements publics et optimisons sa gestion Améliorons l’efficacité et la coordination des services Diminuons les consommations énergétiques, notamment de l’éclairage et des bâtiments publics Développons de nouveaux services : information, transport, wifi, videoprotection, mobilité électrique, éclairage, stationnement intelligent. Stimulons le développement du territoire par l’open data pour les start up et les PME.
- Voilà à grosse maille la gueule du bordel ! Les FA de récupération timé Le combo EventHub/Storage Le TPS Processor L’EventHub de sortie L’hyperviseur Le TPS Processor (again!)
- Qui : A extraire de Jaeger
- Vu la quantité de données Liste de messages et récurrence des appels, le débogage est loin d’être évident. On va pas stocker chaque donnée entrantes dans un SQL Server au cas où. Azure propose la mise en place d’un outil, « Capture », celui-ci permet de stocker en masse les données dans un DataLake. Cette option coûte 60€/mois/eventHub mais impacte donc la facturation cliente. Le choix s’est porté sur Jaeger sur les environnements de DEV/INT/RECETTE et de GRAYLOG sur PROD (historique client), agrégateur de Log.
- QUI :
- QUI :
- Suite à une recommandation de Microsoft, notre première approche de notre projet fut d’utiliser des LogicApps pour se brancher aux connecteurs (TPS). Cela marchait très bien, mais nous avons rencontré des soucis lors de la partie configuration/déploiement. Pour mettre en place du multi-environnement, il faut pouvoir cibler des éléments précis de chaque environnement. Pour ne pas mélanger le DEV avec l’INTEGRATION, PROD etc… Et cela le designer de Logic Apps ne le permet pas de manière native, il couple fortement une Logic App avec une autre brique Azure (EventHub par ex) avec l’ID unique de cette brique. On pourrait « hacker » le système en modifiant le JSON généré mais dès réouverture du designer celui-ci overwrite pour réappliquer son ancien modèle. Bref, on se bat contre le système. Nous avons donc décidé de tout réécrire en Function Apps afin d’avoir plus de souplesse. Function App : Un paradigme qu’il faut comprendre est qu’une Function App est FAITE pour être en ligne. Récupérer de la donnée en mode PULL, être présent en tant que Endpoint (API), participer à une chaîne de traitement etc.. Tout ça est fait pour répondre efficacement et de manière concurrente. L’un des désavantages est donc du coup son ouverture permanente sur internet. Il faut donc prévoir un filtrage IP par exemple afin de sécuriser l’accès à notre fonction. ASE coûte cher. Function Premium : https://azure.microsoft.com/en-us/blog/announcing-the-azure-functions-premium-plan-for-enterprise-serverless-workloads/ Legacy : En relation avec le point précédent, et selon la complexité de l’historique, mettre en relation de manière évidente les ressources que l’on a besoin (ex VM offline derrière NSG/Firewall) et nos propres ressources (dans un autre resources group) peut s’avérer complexe (Virtual Network Peering)
- Globalement le serverless est un modèle d’architecture très intéressant. Il permet aux développeurs de reprendre la main sur la partie infra, de s’astreindre de ces équipes et de gagner en vélocité dans la phase de développement projet. Attention cela n’est pas la solution ultime à tous les problèmes, il faut bien étudier notre projet avant de démarrer. A noter qu’au final le métier du développeur évolue, on met en place plus d’outils tiers, on réalise des scripts de déploiement. Tout cela permet de réduire les temps d’intégration/déploiement. Avec 2 actions manuelles, le Packaging/Déploiement complet de notre solution prend 30min max. Par contre cela induit un effet de dispersion des connaissances, il faut savoir maitriser plus d’outils. Un peu comme avec le phénomène Full-Stack à un moment. Où le dev front s’est mis à faire du back (et/ou) inversement. En plus de gérer le/les front/s ET le back, maintenant on gère en plus la partie « infra ». Cartographie plus complexe, de manière évidente, on crée plusieurs petits sous-logiciels plutôt qu’une très grosse brique. Le fonctionnement même du Serverless se base sur l’évènementiel (récurrent, call HTTP etc..) et donc il perd de son intérêt si nous sommes dans un système qui a besoin de tourner de manière permanente, il faut peut être plus s’orienter sur un Site Web standard ou une VM par exemple.
- Voilà c’est fini, nous vous remercions pour votre attention durant cette session, nous allons prendre quelques questions (s’il y en a) et ensuite on va pouvoir échanger autour de petits fours et un peu de boisson.