Semaine 1 Flashcards
Nomme les étapes (5) d’évolution des technologies informatiques.
- Les technologies mainframe et client / serveur
- Les technologies Web
- Le device agnostic (Des interfaces device agnostic sont des interfaces qui sont utilisables sour tout type d’appareil)
- Le cloud computing
- Les technologies de passage à grande échelle
Illustre l’entropie du SI.
Objets :
- Objet connecté (poste assisté)
- Interfaces homme / machine (poste interactif)
- Batch / processus (poste automatisé)
Services :
- Cloud
- Applications Web
- Applications client / serveur
- Monde mainframe
Comment une entreprise peut faire face à l’entropie du SI (système d’information)?
Elle doit accepter l’entropie du SI.
Besoin d’agilité pour s’adapter à de nouvelles réalités :
- Facebook est devenu un canal incontournable d’accès à l’information, presque une nouvelle télévision
- Google a secoué le monde de l’édition avec Google Books
- Uber a transformé le métier des taxis
- Les opérateurs télécoms luttent pour ne pas devenir de simples tuyaux, laissant la valeur ajoutée aux géants du Web
Quelles sont les caractéristiques d’un SI (système d’information)?
- Une conception centrée sur l’utilisateur (l’expérience utilisateur doit être satisfaisante et fluide, grand soin accordé à l’ergonomie et aux temps de réponse)
- Conception en itérative impliquant le client (vérifier continuellement la satifaction utilisateur)
- Un haut niveau de qualité de maintenabilité
- Dev-Ops avec un redéploiement assurant la continuité de la disponibilité
- L’évolution de l’informatique a conduit à des SI hétérogènes et difficiles à maintenir
- La multiplication des interfaces et des objets connectés augmente la pression sur le SI, l’intégration de plus en plus forte entre systèmes internes et externes poussent à considérer le SI de plus en plus distribué, et la transformation digitale le force à évoluer rapidement
- Il devient donc vital de trouver des moyens de faciliter les transitions continues du SI
- Une nouvelle culture du changement et de l’amélioration en continu doit s’établir
- Il faut itérer pour trouver la meilleure recette
Qu’est-ce que l’agilité dans le contexte des SI?
Les caractéristiques des SI favorisent l’orientation vers une ‘‘agilité’’ à plusieurs dimensions :
- Adapter rapidement un système aux exigences en changement continu
- Redéployer agilement un changement apporté au niveau développement
- Modifier une partie d’un système avec un minimum de modification au reste du système et avec un minimum d’effort de rebâtir le système
Pourquoi les systèmes monolithiques sont généralement inadéquats?
- Applications où le code de mise en oeuvre des règles d’entreprise, l’accès aux données et l’interface utilisateur sont mis en place dans le cadre d’un seul, grand programme informatique
- Généralement déployé sur une seule plateforme, souvent mainframe
Nomme des exemples d’architecture de monolithes.
- L’architecture mainframe
- L’achitecture client / serveur
- L’architecture Web 1.0
Décris 2 architectures de services.
- Un service est un composant d’un système informatisé qui met à disposition de ses clients (acteurs humains, matériels ou logiciels intervenants dans des processus métiers) un accès centralisé à une ou plusieurs fonctions métiers.
- Un service SOA dialogue avec ses consommateurs sous une forme structurée, tant sur le plan technique que sur le plan métier.
Quel est le lien entre l’encapsulation et la qualités des services?
Objectif : encapsulation + concept d’API
API : un service comprenant plusieurs opérations formalisé à travers un contrat de service. Le contrat fait abstraction de l’implémentation et comprend : Interfaces des opérations, descriptions des services, contraintes de qualité de service
Les caractérisques d’un service idéal :
- Réponse disponible
- Exactitude
- Performant
- Robuste
- Facile d’utilisation
- Préférablement indépendant du contexte du client
Encapsulation à travers des services : Utilisateur utilise seulement les interfaces
Nomme des exemples d’API.
Un service ‘‘gestion des clients’’ offre une ‘‘vision client’’ unifiée. Il récupère:
- La fiche d’identité du client et les noms des contacts dans le logiciel CRM
- Le contrat du client dans l’ERP
Le service ‘‘gestion des stocks’’ met à disposition les informations récupérées:
- Tarifs, caractéristiques techniques et promotions. Ces informatios sont puisées de plusieurs ressources d’une façon transparente au client.
Qu’est-ce que l’architecture orientée services (SOA)?
Service Oriented Architecture (SOA) est un style architectural / modèle pour créer et utiliser les processus d’affaires comme ‘‘services’’.
Une approche pour la contruction de systèmes informatiques distribués basés sur l’encapsulation des fonctions d’entreprise comme des services qui peuvent être facilement accessibles d’une manière faiblement couplée (le graphe de dépendance entre service est loin d’être un graphe complet).
La logique commerciale ou les fonctions individuelles de l’application sont modularisées et présentées comme des services aux applications (terme API) client / consommateur.
Un changement d’orientation des ‘‘applications’’ vers les processus métier : correspondance processus métiers(s) -> services(s).
Une architecture dans laquelle les processus sont construits en tout ou en partie par l’assemblage de services réutilisables.
Qu’est-ce que l’orientation SOA?
L’orientation SOA est une façon de penser en termes de services et de développement axé sur les services et les résultats des services.
Quels sont les concepts SOA?
- Le concept d’application composite
- Application composite est une application construite en composant des appels de services
- Les applications composistes peuvent être intéractives ou automatisées
- Un service peut donc être consommé soit par :
- Un utilisateur, via une applicatrion composite intéractive
- Un logiciel traditionnel (applicatif non SOA, qu’il soit intéractif ou pas)
- Un processus métier
- Un autre service SOA
Le concept de solution métier, front end et back end
- Solution métier : une solution qui offre une valeur ajoutée au client utilisateur et répond à un besoin métier
- Un besoin métier est souvent couvert par :
- Une application front end destinée aux opératrionnels (commerciaux, techniciens, clients
et
- Une application back end destinée (par exemple) aux administrateurs de référentiels
Qu’est-ce que le concept de DevOps?
Le concept de DevOps est issu de la volonté de briser la frontière entre:
- Les développeurs dont l’objectif premier est de livrer des nouveautés, éventuellement en introduisant des technologies émergentes.
- La production dont le but est avant tout de garantir la stabilité de l’infrastructure grâce à des technologies maîtrisées.
Il s’agit d’essayer de résoudre une tension entre des objectifs locaux qui peuvent sembler opposés, même si, au final, tout le monde œuvre pour les utilisateurs de l’entreprise. En outre, uen étude de 2006 a montré que 51% du temps total des activités Ops est consacré au déploiement applicatif, souvent parce que les Dev leur remettent du code impropre à la mise en production. Une meilleure collaboration apparaît donc indispensable.
Pour améliorer cette collaboration, DevOps propose trois ensembles de bonnes pratiques.
- Les Devs partagent leur outillage d’indistrialisation des développements en proposant aux Ops le ‘‘contionuous delivery’’, c’est-à-dire un outillage sophistiqué de déploiement du code produit permettant la mise en production automatique. Les mises en ligne sont donc fréquentes, parfois, plusieurs fois pas jour chez certains géants du Web. Au premier abord, ces mises en ligne fréquentes peuvent paraître risquées. En pratique, on constate qu’il est plus aisé de déployer quelques lignes de code qu’une mise à jour majeure. Le risque de problème (régression, corruption de données, etc.) est moins important, le retour en arrière plus facile. Il est d’autant plus facile qu’on aura adopté une stratégie de mise en conteneur avec un outil comme Docker. Par ailleurs, lorsque le processus de déploiement devient habituel et banalisé, il est beaucoup mieux maîtrisé : lorsque l’on fait une mise en production une fois par an, c’est un moment de grand stress et l’on a parfois oublié comment on avait résolu les problèmes rencontrés l’année passée.
- Les Ops partagent leur outillage de gestion de plate-forme en proposant aux Devs ‘‘l’infrastructure as code’’, c’est-à-dire la possibilité de déployer sur la plate-forme via des scripts automatiques sans intervention manuelle. ‘‘Infrastructure as code’’ permet d’accélérer les phases d’approvisionnement et de mise à disposition des environnements. Un avantage majeur de ces scripts est de rendre les opérations de mise en production reproductibles et testables. Il est ainsi possible de déployer 10 machines virtuelles ou cinq conteneurs de manière totalement maîtrisée. ‘‘Infrastruture as code’’ est un prérequis au continuous delivery.
- Les deux équipes partagent des rituels réguliers comme des décisions prises en commun sur l’architecture, des revues sur les métriques de la plate-forme, des revues ‘‘post mortem’’ suite à des incidents… Chez Amazon, on dit même ‘‘you build it, you run it’’, c’est-à-dire que les Devs sont impliqués dans les opérations. L’idée sous-jacente est simple : être réveillé à 3 heures du matin parce qu’une mise en production se passe particulièrement mal est très formateur et sensibilise les développeurs aux problématiques Ops. Inversement, les Ops sont invités à se sensibiliser aux méthodes et outils utilisés par les Dev, pour diminuer l’aversion aux risques, naturelle dans une direction de la production ‘‘classique’’
DevOps constitue l’intégration des Ops dans une démarche agile. Il facilite les mises en production régulières, donc le fonctionnement itéractif. Il pousse les Ops à recourir aux tests, comme le font les Devs.
