Qu'est-ce qu'une architecture ?
«Si les architectes travaillaient comme
les informaticiens, le premier pic-vert venu détruirait toute la
civilisation !»
Auteur : oublié !
Introduction
- Depuis quelques années le terme d’architecture est devenu un des buzzwords les plus utilisés.
- En tant que professionnel, j’ai commencé à utiliser le terme d’architecture dans les années 90.
- Pour moi le sens était évident, il l’était sans doute beaucoup moins pour mes clients …
Historique
- Les premières acceptions du terme adressent l’organisation interne des ordinateurs.
- Le jeu d’instructions : qui est l’élément fondamental.RISC versus CISC par exemple.
- L'organisation des composants de bases : bus (combien ? Largeur ?), mémoires, ALU, registres, E/S …
- L’architecture des ordinateurs est toujours une
discipline classique du domaine des «computer sciences»
depuis les débuts.
- Mais ce n’est pas avec ce sens que l’expression
prendra ses lettres de noblesse et deviendra le buzzword que l’on
connaît.
Une notion encore équivoque
- Cela s’est-il éclairci depuis les années 90 ?
- Oui et non.
- Oui car certaines notions se sont vulgarisées, et en
fait certains éléments d’architecture se sont
imposés de fait (LAN et TCP/IP par exemple)
- Non car la situation s’est complexifiée et
raisonner en terme d’architecture s’impose à
d’autres niveaux : middleware et applicatif aussi !
Des architectures à l’architecture
- Les années 70 : une architecture implicite.
- Le constructeur est l’architecture.
- On choisit un constructeur et on hérite d’une
architecture - en prime - que l’on identifie pas
spontanément comme telle.
- 1974 : IBM SNA. 1979 : BULL DSA
- Remarque : on a commencé à vraiment beaucoup
parler des architectures constructeurs lorsque ceux-ci entamaient leur
déclin à la fin des années 80 !
Les architectures constructeurs des années 70
- Discours : évoluer tout en préservant l’investissement du client (louable).
- Situation : coexistence de différents systèmes issus du même fournisseur et néanmoins incompatibles.
- Buts sous-jacent : présenter une image de cohérence à ses clients !
- Donner l’impression que l’on domine la situation !
- Se réfèrent à des standards (OSI ARCHITEL CCITT)
- Intègrent la modélisation qui vient du monde des «télécommunications».
- Intègrent non seulement les couches 1-4 des
réseaux, mais aussi : API (LU 6.2), DB, messagerie, annuaire,
archivage, présentation documents …
- Le tout plus ou moins présomptueusement ! (plutôt plus rétrospectivement ...)
Réalité
- Il s’agit surtout de pouvoir relier un terminal au mainframe et d’imprimer ses documents.
- Il faut faire cohabiter des architectures
d’ordinateurs incompatibles : importance du protocole. (LU 6.2 un
très bon exemple encore)
- Il faut aussi composer avec un nouvel acteur incontournable sur le marché : le réseau X25.
Les troubles fêtes
- Fondeurs de silicium et LANs
- 1971 : Frederico Faggins signe l’INTEL 4004 (il fera le Z80 aussi en 74)
- 1974 : ARCNET – John Murphy – Data point (monochip 25000 transistors)
- 1975 : Ethernet – Xerox Palo Alto Research Center – Bob Metcalf
- 1977 : IPX TCP
- On note que toutes les technologies
d’aujourd’hui sont nées dans les années 1970
en marge des grands constructeurs.
- Les troubles fêtes commenceront vraiment à
empêcher les autres de danser dans les années 90 avec
l’explosion de la bureautique, des réseaux locaux (ARCNet
et StarLan, puis d'internet.
- 1988 : Intel 386 Netware 386
- Apple MacIntosh
- Diffusion des PCs en masse
- Internet
- Le stockage et le nombre de MIPS des micros en viennent
à dépasser largement ce que gère
l’informatique centrale. Il est temps de prendre des mesures, de
mettre de l'ordre, de s'interroger sur l'architecture !
Les Standards
- Les troubles fêtes vont trouver un allié de poids : les standards !
- De facto pour la plupart mais opérationnels : sur un
même LAN vous pouvez utiliser les cartes / hubs / switchs de 100
constructeurs différents : ça marche !
- Les standards sont la nouvelle religion, l’IETF est leur bible !
La notion de protocole
- La
glue dont s’étaient servis les grands constructeurs pour
plâtrer leur architecture s’est répandue partout
sous le nom de protocole !
- Nous sommes entrés dans l’aire d’une
informatique quasi essentiellement constituée par des programmes
qui dialoguent avec d’autres programmes suivant les règles
d’un protocole standardisé.
Technologie = support du protocole ?
- A noter : on assimile de plus en plus technologie / protocole
- Un protocole s’implante le plus souvent sous forme de code exécuté par un processeur.
- Sous forme de code en circuit ASIC. (cas des protocoles de niveaux 2 par exemple)
Quelques vedettes du câble et du petit écran
- CSMA/CD STP VLAN
- ARP TCP/IP NAT OSPF BGP MPLS
- NTP DNS WINS LDAP SLP SIP RTP
- NCP SMB NFS
- LPD LPR TELNET SMTP SNMP FTP
- Cas particulier de protocoles = les DDL : HTML XML
- Au secours ! Ils sont partout !
Ils n’en finissent pas de monter !
- Les protocoles montent vers les couches hautes.
- Middleware : SOAP à l’origine = Simple Object Acces Protocol
- Les protocoles forment des alliances, s’appuient les uns sur les autres, se renforcent ou se fragilisent.
- Bref ils forment la nouvelle architecture informatique !
Apprécier et choisir des protocoles
- La théorie des protocoles est encore faible, ce n’est pas une discipline enseignée en tant que telle.
- Comment apprécier un protocole sans entrer dans ses détails ?
- Si on lit les drafts du moindre protocole on
s’aperçoit que c’est long, fastidieux et qu’on
a du mal à prendre de la hauteur.
- On peut utiliser des méthodes
d’appréciations plus globales, à la fois techniques
et socio-techniques.
Exemples d’appréciations techniques globales
- Volume du code : en nombre d’instructions/nombre de transistors.
- Nombre de transitions et d’états (si on est
capable d’exprimer le protocole sous la forme d’un automate
à états finis)
- Un petit protocole sera toujours plus efficace, résilient, portable dans différents environnements.
Exemples d’appréciations socio-techniques
- Niveau du protocole dans le modèle OSI
- Dépendance vis-à-vis d’autres protocoles ?
- Symetrique : peer to peer (=> combien de client dans un même domaine ?)
- Asymétrique : client / serveur (=> combien de clients servis / serveurs ?)
- Comment une instance se fait-elle connaître ?
- Quelle résolution de noms utilise-t-il ?
- Implique l’usage d’un annuaire central ? Si oui lequel ?
Choisir une architecture
- C’est d'abord choisir de mettre en oeuvre certains protocoles en connaissance de cause !
- Comprendre leurs logiques, leurs contraintes, leurs besoins, leur histoire, leur futur …
- Les faire coopérer, leur donner une étendue,
un champ d’action, des limites et des responsabilités
…
- Bref manager ses protocoles !
|
