IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Open source et architecture logicielle

[Actualité] Les hébergeurs imposent-ils leurs architectures aux projets

Note : 2 votes pour une moyenne de 5,00.
3 Commentaires
par
autran
, 25/12/2015 à 18h19 (1491 Affichages)
Les systèmes d'information web sont aujourd'hui majoritairement hébergés dans des datacenters, alors que cet hébergement était il y a encore dix ans assuré au sein des DSI et opéré par du personnel en interne. Ce changement de stratégie d'hébergement est bien entendu une réponse à la recherche de réduction des coûts.
Mais en renonçant à héberger sa solution technique, la DSI ne renonce-t-elle pas également à la maîtrise de son architecture ? En effet les hébergeurs ne sont-ils pas en position d'imposer aux projets leur architecture cible ?

La bonne gouvernance recommande de choisir l'architecture d'un projet lors de sa phase de cadrage avant tout développement. Ce choix est en grande partie fait à l'issue d'une phase d'étude qui prend en compte les besoins futurs du système (performances robustesse...) et de la maturité des différentes technologies. Bien entendu, certaines données d’environnement comme le niveau de compétences des équipes de développement ou les contraintes de temps de développement entrent en compte dans cette analyse.

Mieux encore, dans certaines DSI ayant un haut niveau de maturité, des normes d'architecture existent pour faire converger les socles et les processus de développement. En effet, l’équipe d'architecture peut identifier, qualifier et mettre en place des socles techniques. Et dans le même temps, la DSI doit faire monter en puissance des développeurs sur les technologies retenues.
Selon cette dynamique, la DSI maitrisera (d'un point de vue technique) sa solution de la phase de conception jusqu'à la phase de déploiement.

Mais l'objectif final d'un projet de système d'information, dont le but est d'apporter de la valeur ajoutée à l'entreprise, est d'être mis en exploitation au profit du client. Or la tendance actuelle est de faire appel de manière quasi systématique à un hébergeur du cloud pour des raisons bien connues de réduction des coûts, de mutualisation des infrastructures, et de maîtrise des cyberrisques. L'un des impacts de cette pratique est une divergence possible entre les choix initiaux d'infrastructure et l'offre de l'hébergeur. Cet impact est si fort que l'étude d'architecture intègre les offres hébergeurs comme une contrainte forte dès la phase amont du projet.

Cette contrainte des hébergeurs est d'autant plus prégnante que leurs offres sont quasiment uniformes, lissées par la compétitivité et la recherche d'une lisibilité « toujours plus simple » au profit des décideurs des différentes directions métier de l'entreprise. Ce qui nous amène in fine, à un bouquet d'offres extrêmement pauvre.

Et vous ?

Sur vos projets, percevez-vous ce risque ?

Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Viadeo Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Twitter Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Google Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Facebook Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Digg Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Delicious Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog MySpace Envoyer le billet « Les hébergeurs imposent-ils leurs architectures aux projets » dans le blog Yahoo

Mis à jour 26/12/2015 à 06h39 par ClaudeLELOUP

Catégories
Sans catégorie

Commentaires

  1. Avatar de BufferBob
    • |
    • permalink
    le fait de centraliser l'hébergement permet également une centralisation de la sécurité, ce qui dans l'écrasante majorité des cas est une bonne chose
    quid de la mitigation des attaques DDoS par exemple si chaque boite hébergeait elle-même son contenu ? quid des risques qui pèsent, dès lors que le SI final, la compta et cie. sont à quelques postes, voire un sous-réseau du serveur compromis ? sans parler du coût écologique de déployer un dispositif à chaque sortie de site plutôt que sur l'ensemble de l'AS

    par ailleurs ça me semble un point de vue très centré sur le développeur, il faut bien se dire que les tech dans les datacenters ne sont pas eux non plus particulièrement ravis de devoir dealer avec des instances tomcat sur leurs serveurs (parceque c'est gourmand en ressources) et les équipes sécu non plus (parceque c'est totalement opaque)

    quant à la question de la recherche systématique du moindre coût au détriment éventuel du client... on se lance d'emblée sur le bienfondé du système capitaliste et De La Très Haute légitimité de l'Entreprise à fructifier ou on s'efforce de rester sur du consensus mou en tournant autour du pot et en essayant de désigner un autre coupable ?
    "uniformisation et profit", est-ce qu'il ne s'agit pas là simplement des deux mamelles du monde moderne ?
  2. Avatar de Gugelhupf
    • |
    • permalink
    Les hébergeurs Cloud sont obligés d'imposer une architecture à vos projets. Ayant moi-même développé des composants PaaS durant ma deuxième année de Master (cf: multicast-wrapper : un projet pour une communication inter-node au sein de l'IaaS, et abstract-datasource une implémentation JDBC pour que nos clients puissent accéder à nos instances PostgreSQL), je sais pertinemment qu'il faut gérer de nombreuses notions : sur quel node sera exécuté le code ? est-ce que le contexte de session sera bien répliqué ? quel est le taux d'utilisation du client par rapport au contrat qu'il a signé ? etc cela impacte les API PaaS fournit et donc votre manière d'écrire du code mais pas toujours ! car l'objectif est de rester le plus fidèle possible aux standards du langage proposé.

    Les hébergeurs Cloud proposent certes des API spécifiques pour leur plateforme (pour leurs services payants surtout), mais certains comme Google App Engine (celui que je connais le mieux) fournissent tout de même un moyen au développeur d'utiliser des spécifications standard du langage proposé pour développer presque "normalement". J'ai d'ailleurs rédigé un article sur les contraintes de code et runtime que peuvent imposer des plateformes Cloud comme celui de Google ici : https://gokan-ekinci.appspot.com/fr/...as-constraints

    Personnellement je ne pense pas que développer une application sur le Cloud soit une grosse contrainte au niveau architecture du projet ou un impact négatif sur l'évolution/innovation de ce dernier (comme je l'ai dit plus haut on peut essayer de rester fidèle aux spécifications standards d'un langage, et proposer des API spécifiques pour les services payants), en tout cas celui qui s'engage à développer pour le Cloud doit tout simplement connaitre les contraintes de son Cloud avant de s'engager.
  3. Avatar de elssar
    • |
    • permalink
    Il faut bien comprendre qu'il n'existe pas 1 hébergement mais des hébergements.

    De notre côté nous avons des clients en mode IaaS, qui ont une autonomie assez forte sur leur architecture. D'autre qui sont en mode PaaS et qui sont en effet moins autonomes sur cette partie. Et enfin d'autre qui sont en collocate (emplacement dans le data loué).

    Nous avons des gros clients étrangers (google, amazon, M$) qui sont uniquement sur du collocate, et c'est souvent à leur sauce, la cage d'amazon n'a par exemple pas du tout les même sécurités que la cage google, parce qu'ils importent leur normes, ingénieries etc et ils ont totalement la main à l'intérieur de leurs cages.

    Dans ce contexte ceux qui subissent l'architecture sont souvent les clients qui demandent justement un fort encadrement. Il y a parfois des grosses boites qui n'ont pas la compétence/savoir en interne (pour plusieurs raisons) et ils demandent donc justement de l'aide sur cette partie architecture qu'ils ne maitrisent pas et qui peut très rapidement devenir extrêmement complexe.