A lire sur: http://cloud-experience.fr/les-applications-critiques-peuvent-elles-se-satisfaire-du-cloud.html
le 7 mars 2013
le 7 mars 2013 |
C’est une question que se posent les clients lorsqu’ils dessinent leur stratégie cloud. Et souvent une frontière se trace d’elle-même entre les applications non-critiques, celles qu’on peut facilement passer ‘dans le cloud’, et les autres. Mais avant de débattre sur la frontière, reposons-nous les questions de base. |
C’est quoi une application critique ?
Partons de l’hypothèse qu’une application critique, c’est une application essentielle à l’activité de l’entreprise, et dont l’indisponibilité –courte ou longue selon les cas- a un impact direct sur le chiffre d’affaires, les obligations contractuelles ou même la réputation de l’entreprise. Ceci étant dit, on n’a toujours pas dit quel type d’application était critique, et quel type ne l’était pas. Prenons deux exemples.
Si l’on est un site de vente en ligne de chaussures (je suis certain que vous voyez à qui je pense…) on imagine bien que l’indisponibilité des sites marchands est critique pour le business et que les clientes vont se ruer dans la seconde sur le site de votre concurrent. Mais au titre des applications critiques de ces marchands de chaussures, n’oublions pas les applications qui gèrent la logistique, les livraisons, la facturation et j’en oublie. Pas de chaussures à livrer, pas de business. C’est aussi critique que de prendre les commandes.
A
l’inverse, si l’on est un constructeur d’avions, en matière de
criticité, on pense davantage à la gestion de la chaîne de production,
la gestion des flux de matières, ou encore les engagements vis-à-vis des
compagnies aériennes clientes par exemple sur les services de
maintenance. A ce jour, très peu d’avions se vendent sur Internet…
Donc, à ce stade, faire une typologie critique/pas critique uniquement basée sur le type d’application n’est pas suffisant. C’est le contexte business de chaque entreprise qui prévaut.
Une application critique aime-t’elle le changement ?
Ma réponse est : non ! Tout simplement parce qu’on est dans un contexte de production, et que le moindre petit changement (passage de correctif, montée de version, etc…) est vécu par les équipes d’exploitation comme une prise de risque. Et personne n’aime prendre de risques, dès lors qu’ils ne sont pas mesurés.
La gestion des changements pour les applications critiques ne peut être ni improvisée, ni décrétée unilatéralement par un tiers (ou alors avec force précautions…). Dans ces conditions, un prestataire de cloud public qui pour des raisons financières sordides (ou pas) forcerait la montée de version de tel ou tel middleware, logiciel de bases de données ou autres se verrait mis à l’index par ses clients.
Le principe de précaution s’impose. Mais prenons garde à ne pas le transformer en principe d’immobilité….
Le cloud : so what ?
Tout d’abord, une application critique n’est pas forcément monolithique, et on retrouve probablement le principe des trois ‘tiers’ avec une partie frontale pour gérer les flux avec les clients internes ou externes, une partie purement liée au traitement de l’application, et enfin la partie traitant de la gestion des données. Je ferai volontairement abstraction du débat sur la localisation des données critiques, ce sujet a déjà été abordé par ailleurs. Ceci posé, passer en mode cloud la partie frontale, et pourquoi pas les serveurs d’applications peut apporter à notre application critique une élasticité fort agréable en période de pics de charge, voire même des possibilités de débordement si nécessaire. Pour les serveurs d’applications, restez quand même vigilant sur qui maîtrise la gestion des changements.
Mais, au-delà du débat technique, le passage en mode cloud des applications critiques induit dans la plupart des cas une étape de replatforming (c’est le mot moderne pour « migration »). Qu’est-ce qui dans votre ‘vieille’ application est portable, qu’est-ce qui ne l’est pas ? Comment évaluer les coûts en ressources de tout ordre pour réussir ce projet ? Un audit préalable de votre parc applicatif critique, de son degré d’adhérence, ou de portabilité, vous éclairera sur ce point.
Si votre application critique est arythmique, c’est-à-dire avec une charge à peu près stable dans le temps, sans pics de charge atypiques, alors la possibilité d’élasticité apportée par le cloud n’est pas un argument dans votre cas.
A l’inverse, pour des variations de charges prévues, voire même imprévues, le bursting procuré par le cloud est une excellente solution, qui vous permettra d’éviter d’investir dans une sur-capacité juste nécessaire pour ces périodes de charge intense. Vive le cloud !
De la même façon que la virtualisation des applications critiques est passée en l’espace de 3 ans d’un tabou total à une réalité, la cloudisation des applications critiques est en marche… Et vous, qu’en pensez-vous ?
Partons de l’hypothèse qu’une application critique, c’est une application essentielle à l’activité de l’entreprise, et dont l’indisponibilité –courte ou longue selon les cas- a un impact direct sur le chiffre d’affaires, les obligations contractuelles ou même la réputation de l’entreprise. Ceci étant dit, on n’a toujours pas dit quel type d’application était critique, et quel type ne l’était pas. Prenons deux exemples.
Si l’on est un site de vente en ligne de chaussures (je suis certain que vous voyez à qui je pense…) on imagine bien que l’indisponibilité des sites marchands est critique pour le business et que les clientes vont se ruer dans la seconde sur le site de votre concurrent. Mais au titre des applications critiques de ces marchands de chaussures, n’oublions pas les applications qui gèrent la logistique, les livraisons, la facturation et j’en oublie. Pas de chaussures à livrer, pas de business. C’est aussi critique que de prendre les commandes.
A
l’inverse, si l’on est un constructeur d’avions, en matière de
criticité, on pense davantage à la gestion de la chaîne de production,
la gestion des flux de matières, ou encore les engagements vis-à-vis des
compagnies aériennes clientes par exemple sur les services de
maintenance. A ce jour, très peu d’avions se vendent sur Internet…Donc, à ce stade, faire une typologie critique/pas critique uniquement basée sur le type d’application n’est pas suffisant. C’est le contexte business de chaque entreprise qui prévaut.
Une application critique aime-t’elle le changement ?
Ma réponse est : non ! Tout simplement parce qu’on est dans un contexte de production, et que le moindre petit changement (passage de correctif, montée de version, etc…) est vécu par les équipes d’exploitation comme une prise de risque. Et personne n’aime prendre de risques, dès lors qu’ils ne sont pas mesurés.
La gestion des changements pour les applications critiques ne peut être ni improvisée, ni décrétée unilatéralement par un tiers (ou alors avec force précautions…). Dans ces conditions, un prestataire de cloud public qui pour des raisons financières sordides (ou pas) forcerait la montée de version de tel ou tel middleware, logiciel de bases de données ou autres se verrait mis à l’index par ses clients.
Le principe de précaution s’impose. Mais prenons garde à ne pas le transformer en principe d’immobilité….
Le cloud : so what ?
Tout d’abord, une application critique n’est pas forcément monolithique, et on retrouve probablement le principe des trois ‘tiers’ avec une partie frontale pour gérer les flux avec les clients internes ou externes, une partie purement liée au traitement de l’application, et enfin la partie traitant de la gestion des données. Je ferai volontairement abstraction du débat sur la localisation des données critiques, ce sujet a déjà été abordé par ailleurs. Ceci posé, passer en mode cloud la partie frontale, et pourquoi pas les serveurs d’applications peut apporter à notre application critique une élasticité fort agréable en période de pics de charge, voire même des possibilités de débordement si nécessaire. Pour les serveurs d’applications, restez quand même vigilant sur qui maîtrise la gestion des changements.
Mais, au-delà du débat technique, le passage en mode cloud des applications critiques induit dans la plupart des cas une étape de replatforming (c’est le mot moderne pour « migration »). Qu’est-ce qui dans votre ‘vieille’ application est portable, qu’est-ce qui ne l’est pas ? Comment évaluer les coûts en ressources de tout ordre pour réussir ce projet ? Un audit préalable de votre parc applicatif critique, de son degré d’adhérence, ou de portabilité, vous éclairera sur ce point.
Si votre application critique est arythmique, c’est-à-dire avec une charge à peu près stable dans le temps, sans pics de charge atypiques, alors la possibilité d’élasticité apportée par le cloud n’est pas un argument dans votre cas.
A l’inverse, pour des variations de charges prévues, voire même imprévues, le bursting procuré par le cloud est une excellente solution, qui vous permettra d’éviter d’investir dans une sur-capacité juste nécessaire pour ces périodes de charge intense. Vive le cloud !
De la même façon que la virtualisation des applications critiques est passée en l’espace de 3 ans d’un tabou total à une réalité, la cloudisation des applications critiques est en marche… Et vous, qu’en pensez-vous ?
Aucun commentaire:
Enregistrer un commentaire