Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.

 iPaaS : quelques cas d’usages à considérer

Les DSI doivent répondre à différents cas d’usages d’intégration, auxquels le Cloud est lié: des applications Cloud à intégrer entre elles ou avec le SI interne, une intégration avec des partenaires ou filiales et enfin un débordement du SI vers le Cloud.

Ces cas d’usages se traduisent par des besoins d’échanges de fichiers de grandes tailles en différés, de messages au fil de l’eau, d’appels de services synchrones… Les systèmes d’échanges assurant alors les fonctions de transfert, routage, transformation et connectivité aux applications dans le Cloud et dans le SI interne.

Trois typologies de déploiement permettent de supporter ces cas d’usages

Le plus naturel consiste à utiliser un système d’échange existant on-premise (SI interne). L’intégration avec les applications dans le Cloud est faite via des connecteurs spécifiques (particulièrement pour le SaaS). Mis en œuvre initialement pour une intégration majoritairement interne au SI, le système d’échange est utilisé pour l’intégration avec le Cloud. Ce choix n’est pertinent que pour un nombre restreint d’applications Cloud, sans échanges importants entre elles.

Avoir une plateforme unique d’échange dans le Cloud public est une autre typologie possible. Elle sera alors principalement utilisée pour l’intégration entre applications dans le Cloud.  Elle peut également être utilisée pour devenir le point unique d’échanges avec des partenaires et filiales. Toutefois, le passage systématique par le système d’échange dans le Cloud pour l’intégration d’applications internes au SI peut être rédhibitoire (volume, latence…). Ce peut être un choix uniquement tactique, pour une adoption rapide.

L’utilisation de deux systèmes d’échanges en « miroir », un dans le SI (potentiellement existant) et un autre dans le Cloud, est la typologie la plus avancée. Il n’y a alors qu’un lien unique entre les deux plateformes, donc un seul point d’entrée dans le SI interne sur lequel la sécurité est renforcée. Elle permet de couvrir efficacement l’ensemble des échanges internes et Cloud.  Une gouvernance des échanges est ici indispensable pour maîtriser leur répartition entre les deux plateformes. Des réponses doivent également être apportées pour assurer la consolidation de la supervision, le déploiement des flux…

Au final, le choix de typologie dépend avant tout de l’existence de systèmes d’échanges au sein du SI et du nombre d’applicatifs dans le Cloud à la cible.

Un marché de l’iPaaS hétérogène

L’iPaaS est une suite de services Cloud supportant ses caractéristiques principales : self-service, élasticité, mesurable et mutualisation des ressources. Il permet l’intégration entre des éléments du Cloud et on-premise et peut assurer différentes typologies d’intégration : processus (BPM, workflow…), services (ESB / SOA), applications et données (ETL).

Dans les faits, les solutions iPaaS n’ont pas toutes ces caractéristiques clés, et peuvent être de différentes natures :

D’un côté, il y a les pure players de l’intégration Cloud. Leurs solutions sont construites sur le modèle du Cloud, ils en respectent les préceptes. Leur maturité est cependant encore à challenger dans un marché qui n’est pas encore entièrement consolidé. De l’autre, il existe des solutions n’ayant aucune caractéristique Cloud mais ayant des connecteurs vers les grands noms du SaaS (Salesforce, WorkDay…). Elles servent avant tout d’accélérateur pour une connexion simplifiée. Mais il ne faut pas non plus mettre de côté les solutions classiques on-premise d’éditeurs historiques de l’intégration directement déployées sur une offre PaaS. Ces solutions ont pour elles leur maturité acquise dans l’intégration interne au SI. En revanche les caractéristiques du Cloud ne sont pas toutes assurées…

Il est donc nécessaire de prendre en compte son existant afin de faire les choix les plus pertinents.

Quel chemin emprunter pour aller vers le Cloud ?

Le chemin vers l’intégration Cloud peut prendre différentes voies selon l’existant en termes d’échanges au sein du SI de l’entreprise. Pour un SI déjà outillé avec une ou plusieurs plateformes d’échanges, ce qui est le cas chez les grands comptes, il est important de capitaliser sur celles-ci en se concentrant sur deux problématiques clés. La première : est-ce que la solution propose des connecteurs Cloud vers les applications SaaS utilisées, ou même un framework de développement pour s’adapter à toute application SaaS ? La seconde : est-ce que la solution est proposée par l’éditeur dans une version iPaaS ? Cela permet de mettre en œuvre une typologie de déploiement en miroir, tout en conservant les mêmes compétences internes.

Si l’extension du SI vers le Cloud n’entraîne pas une rupture des architectures d’échanges inter-applicatifs déjà en place (SOA, EDA…), il sera cependant nécessaire de décliner les patterns établis afin de tirer entièrement parti des promesses du Cloud et de prendre en considération ses contraintes.

Cet article L’iPaaS, pourquoi ne peut-on pas faire l’impasse ? est apparu en premier sur RiskInsight.

Une adoption motivée par réduction des coûts et recherche d’agilité

Malgré la dynamique du marché et la promesse de gains sous-jacente, les DSI des grandes entreprises tardent à se mettre en mouvement, réagissant plus au Cloud qu’elles ne l’anticipent. Elles le privilégient essentiellement pour des usages à risques techniques limités et à ROI rapide, principalement en IaaS et en SaaS.

SaaS : une utilisation massive des services standardisés

Le SaaS est aujourd’hui le principal vecteur d’adoption du Cloud. L’adoption du SaaS est centrée sur les fonctions support dont l’usage est standardisé (bureautique, messagerie, CRM, paie…). Le SaaS est également fortement sollicité pour les services de sécurité (antivirus, proxy, services de tests d’intrusion…) qui nécessitent une puissance de calcul importante, des évolutions en cycle court ainsi qu’une disponibilité maximale pour des employés de plus en plus mobiles.

PaaS : une adoption encore confidentielle

C’est le segment le moins bien appréhendé par les grands groupes aujourd’hui. Il correspond à la fourniture d’une plateforme d’exécution de code informatique. Il permet la mise à disposition d’une application en limitant très fortement les opérations sur les couches sous-jacentes (systèmes, bases de données, serveurs d’applications…). Le PaaS reste aujourd’hui cantonné chez les grands comptes à des usages « jetables », comme des prototypes ou des sites web temporaires (événementiels).

IaaS : des déploiements essentiellement en mode « privé »

Le modèle IaaS, fourniture de machines virtuelles (VMs) et ressources associées depuis un Cloud, qu’il soit public ou privé, permet d’introduire davantage d’agilité. Les grandes entreprises déploient aujourd’hui beaucoup de IaaS privés, dans l’optique de capitaliser sur leurs compétences internes et leurs investissements en infrastructures. De son côté, le IaaS public est mis en œuvre de façon très ciblée, par exemple pour une filière web, ou dans une logique de « bac à sable ».

Pour autant, grâce à la consolidation à grande échelle, c’est le modèle public qui permet d’obtenir les gains fonctionnels et financiers les plus importants. C’est pourquoi les stratégies de déploiement de IaaS privés sont ou doivent être considérés comme une étape sur une trajectoire plus ou moins long terme de généralisation d’IaaS public.

Un avenir qui promet plus d’innovation et de valeur ajoutée

La 1ère phase d’adoption du Cloud est motivée par la recherche d’économies et l’optimisation du niveau d’agilité. Ces prochaines années, le marché devrait évoluer pour offrir des solutions avec une valeur ajoutée de plus en plus forte, pour répondre à la fois aux offreurs en quête de relais de croissance et aux entreprises utilisatrices souhaitant optimiser leur marge en se recentrant sur leur cœur de métier.

Le SaaS devrait s’imposer dans les entreprises comme le choix par défaut. Les éditeurs de logiciels vont proposer de manière systématique leurs solutions en mode SaaS, en partenariat avec les fournisseurs IaaS. Ils s’assureront ainsi des revenus constants et proposeront à leurs clients des services très industrialisés, flexibles et au meilleur coût.

L’usage du PaaS devrait exploser lorsque les problématiques de portabilité des applications, bien souvent surestimées, seront résolues. Il devrait alors devenir le socle d’exécution par défaut de toutes les applications qui ne seraient pas consommées en SaaS. Ces plateformes vont s’enrichir pour fournir aux développeurs un maximum d’accélérateurs et de nouvelles possibilités (composants et connecteurs pré-packagés, services de sécurité, réseaux de distribution de contenus… ) et donc en faire un choix par défaut dans les filières de développement.

Par ailleurs, les éditeurs de progiciels devraient rapidement proposer leurs solutions en mode pré-packagé pour les plateformes PaaS du marché. Le IaaS devrait perdurer pour adresser des besoins applicatifs très spécifiques. Mais il ne permettra pas d’aller chercher toutes les économies d’échelle d’une approche Cloud.

 Ce sont le SaaS et le PaaS qui porteront le marché demain.

Cet article Le Cloud : quelle réalité marché derrière les nuages ? est apparu en premier sur RiskInsight.

Le Cloud impose-t-il une évolution forcée ?

Le Cloud simplifie l’accès à l’outil informatique en focalisant l’énergie de l’utilisateur sur le choix du service plutôt que sur la démarche de mise en œuvre. Cette facilité d’accès à des services « clé en main » peut inciter les Métiers de l’entreprise à traiter directement avec les offreurs Cloud sans impliquer la DSI. Pour contrôler l’adoption des services Cloud, la DSI doit devenir un acteur incontournable de ses Métiers : non pas en s’imposant mais bien devenant un partenaire légitime du Métier, apporteur de valeur ajoutée aux services Cloud.

Une priorisation des chantiers nécessaire

Le Cloud n’est pas qu’un outil technique à destination de la DSI seule. Il est essentiel de mettre en place sa stratégie Cloud en impliquant la Direction de l’entreprise pour prendre en compte l’existant et les besoins à venir, en déduire le périmètre éligible et enfin choisir ses modèles de sourcing (Public et/ou privé) et le type de Cloud (IAAS, PAAS et/ou SAAS) adapté aux cas d’usage. Deuxième étape pour la DSI : promouvoir cette stratégie auprès des Métiers avec ses sponsors en valorisant les apports de la démarche et en éclairant les contraintes liées à son utilisation.

A ce stade la DSI devra choisir entre 2 positionnements :

1) Un accès direct des métiers aux fournisseurs Cloud

La DSI ne porte pas la responsabilité du choix des fournisseurs mais apporte son expertise sur les dimensions :
•    Contractuelles, en mettant à profit l’expérience de la DSI pour définir les engagements en matière de niveau de service, de traçabilité, de pilotage des coûts…
•    Techniques, en accompagnant les projets sur l’intégration des services Cloud dans le SI de l’entreprise tout en respectant les contraintes internes de sécurité et d’échanges de données
•    Légales, en apportant sa connaissance des contraintes liées à l’hébergement des données (données personnelles, données sensibles d’entreprise, législation française, contraintes sectorielles…)
•    De réversibilité technique et opérationnelle, pour préparer en amont le désengagement d’un fournisseur.

2) Une DSI « broker de Cloud »

La DSI se positionne comme l’interlocuteur unique à la fois du Métier et des fournisseurs Cloud.  Le rôle d’expertise reste d’actualité et voit son périmètre étendu par une fonction de gestion des  relations clients et fournisseurs. La DSI est alors en responsabilité :
•    D’intégrer des services Cloud technique ou métier au catalogue de la DSI
•    De piloter et de garantir la qualité des services exposés par la DSI
•    De définir et de mettre en place les outils permettant une intégration au SI des services Cloud (IAM, échanges, service management…)
•    De faire évoluer ses processus internes pour fournir un service utilisateur unifié indépendamment des modes de sourcing
•    Et bien sûr, de fournir ces services Cloud au meilleur coût du marché à ses utilisateurs !

Bien que la stratégie de positionnement soit à définir suivant le contexte particulier de chaque entreprise, une majorité aura intérêt à adopter un positionnement « broker de Cloud ». Ce positionnement permettra de définir une stratégie IT globale cohérente entre les besoins internes et les possibilités offertes par les fournisseurs. Elle permettra ainsi de tirer toute la valeur économique et qualitative d’une approche Cloud par le biais d’achats massifiés et intégrables de manière standardisée au SI.

Les « temps métiers » et les « temps IT traditionnels» n’ont plus la même échelle, le Cloud est un des vecteurs de transformation qui permet de contribuer à la performance globale de l’entreprise. Néanmoins, pour combler ce décalage, la DSI doit être en perpétuelle transformation pour fournir les moyens nécessaires aux ambitions de l’entreprise.

Cet article Le Cloud computing : vers une DSI orientée service ? est apparu en premier sur RiskInsight.

Des offres PaaS de 1ères générations à faible maturité…

Les premières offres PaaS, lancées en 2010, constituaient une proposition souvent :

• Limitée, avec un nombre restreint de langages de programmation et d’environnements d’exécution supportés.

En exemple, les premières versions du PaaS Heroku (de SalesForce) supportaient uniquement le langage Ruby; le PaaS Cloudfoundry.com (de Pivotal) supportait uniquement les langages Java et  Ruby.

• Intrusive, avec une adaptation / réécriture de l’application presque systématique.

Nous pouvons prendre l’exemple d’Amazon qui propose le service SGBD (système de gestion de base de données) spécifique  SimpleDB ou Google qui propose le service propriétaire Google’s Big Table sans oublier leur moteur d’exécution propriétaire : « Google App Engine ».

• Verrouillée (lock-in éditeur), avec un manifeste désintérêt pour l’interopérabilité et la portabilité entre les différentes offres et une volonté des éditeurs d’imposer leurs propres standards.

… et ne couvrant que partiellement les besoins réels des entreprises

Les PaaS de 1ères générations offraient des services peu adaptés aux besoins complexes des entreprises. Au-delà des limitations techniques (citées précédemment), on a pu regretter que ces premiers PaaS :

• Proposent une offre de services incapables de répondre aux exigences et contraintes demandées respectivement par les études et la production et ce notamment en termes de SLAs (confidentialité des données, traçabilité, etc.)

• Impliquent une réversibilité complexe en cas de changement d’offres ou d’internalisation des applications (souvent d’ailleurs pas proposée par les fournisseurs de ces offres).

• Répartissent de manière floue les rôles et responsabilités entre le fournisseur de services et le client.

• Aient une présence limitée de support en France, pourtant nécessaire à l’accompagnement des projets.

Un repositionnement efficace des fournisseurs PaaS

Face au manque d’adhésion des PaaS de 1ères générations, de nouvelles offres ont émergé et un repositionnement a été opéré par les fournisseurs. La nouvelle génération s’aligne enfin avec les vraies attentes des entreprises. Les initiatives en cours s’orientent vers des offres :

• Polyglottes (multi langages) et multi-plate-formes

Salesforce a par exemple enrichi son offre Heroku par le support de nombreux langages (Ruby, PHP, JavaScript, Java), ou encore Cloudfoundry.org supporte maintenant plusieurs langages et frameworks de développements comme  Java, .Net, Ruby, PHP, Python, Scala.

• Spécialisées par cas d’utilisation

En exemple, Cloudbees propose deux offres complémentaires :

– Une offre destinée au développement, où l’unité de facturation est le nombre de build opéré.
– Une offre destinée à l’exécution, où l’unité de facturation est une configuration de la mémoire disponible pour l’application

• Sensibles aux normes et standards (en cours de spécification)

Plusieurs initiatives de standardisation sont en cours sur le périmètre PAAS. Nous pouvons noter en exemple : CAMP, TOSCA ou encore Cloud Foundry Core.

Un virage à prendre ?

Contrairement à une adoption généralisée des services SaaS (déjà utilisés en entreprise depuis une dizaine d’années) et facilitée pour les services IaaS (entreprises ayant généralement atteint un niveau de virtualisation assez poussé pour faciliter le passage vers le modèle IaaS), les entreprises optent pour une attitude prudente vis-à-vis des services PaaS, privilégiant une stratégie d’adoption à deux vitesses :

• Une adoption immédiate des offres PaaS pour des :

– Applications non cœur de métier ;
– Applications non pérennes (jetables) ;
– Prototypes ;
– Bacs à sable innovants.

L’idée est de favoriser des solutions non limitatives en termes de technologies.

• Une adoption après études d’opportunités, choix de solutions et prototypage pour les applications cœur de métier.

Références

Études : Net MediaEurope (Juin 2012),

Normes et standards

• CAMP – https://www.oasis-open.org/news/pr/camp-tc
• TOSCA – https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca
• CF Core – http://core.cloudfoundry.org/definition

Offres

• Heroku – https://www.heroku.com/
• Cloud Foundry – http://www.cloudfoundry.com/
• SimpleDB – http://aws.amazon.com/fr/simpledb/
• Google App Engine – https://appengine.google.com/
• Cloudbees –  http://www.cloudbees.com

Cet article Le PaaS, une solution d’avenir. Comment franchir le pas ? est apparu en premier sur RiskInsight.

D’après Fabrizzio Biscotti, Directeur de recherche chez Gartner « Le PaaS est l’endroit où la bataille entre les fournisseurs et les produits s’intensifie le plus ». Le marché du PaaS privé n’est pas exclu de cette bataille. Il fait face à une concurrence de plus en plus rude et une  évolution de plus en plus vite.

Pour mieux comprendre cette évolution, voyons quelle est la proposition des offreurs dans ce marché.

Un positionnement en surcouche des modèles traditionnels

Traditionnellement, un modèle PaaS offre un environnement complet de développement et d’exécution. Du côté du PaaS privé, les acteurs se positionnent sur le marché des « Fabric PaaS ». Il s’agit d’un outil de provisionnement d’environnements, constitués de composants logiciels et applicatifs packagés au préalable. Cet outil s’appuie ensuite sur les infrastructures existantes de l’entreprise, qu’elles soient physiques, virtuelles ou déjà dans le cloud. Les acteurs de ce marché sont très dynamiques, avec une offre qui évolue rapidement. On y retrouve aujourd’hui les acteurs de l’édition logicielle traditionnelle avec Tibco Silver et VMware vFabric, des acteurs de niche comme ActiveState Stackato et une offre open source avec Cloud Foundry, souche de plusieurs solutions commerciales.

Agilité, Scalabilité et Consolidation comme crédos

Les fonctionnalités de packaging intégrées à ces solutions permettent de définir des environnements « clés en main ». Ces environnements contiennent  un ensemble de composants applicatifs, conçus à partir d’une palette d’exécutables tels que Jboss, Websphere, Tomcat, Tibco… ainsi que d’autres logiciels non standards. Les déploiements sont ainsi standardisés, dans une optique d’optimisation des temps de création des environnements.

Ces outils gèrent également les performances des applications déployées. Ils adaptent ainsi la capacité mise à disposition aux pics et baisses de charge en rajoutant ou supprimant des ressources sur la base d’un jeu de règles prédéfini. Ils offrent également la possibilité de s’étendre vers un cloud public.

Le troisième apport est l’optimisation de l’usage des ressources. Les mêmes ressources pouvant être affectées à des applications de natures différentes, évitant ainsi les modes de fonctionnement en silo.

Une mise à disposition en 3 étapes

La mise à disposition des environnements passe généralement par trois étapes clés :

• Le packaging qui permet de concevoir la stack* applicative de l’environnement en définissant les différents composants logiciels nécessaires à l’exécution ;

• Le provisioning pour déployer une stack applicative sur une infrastructure à l’aide d’une interface graphique ;

• Le management pouradministrer les stacks déployées, récupérer des statistiques et  définir des règles de scalabilité automatique.

La Fabric PaaS : un outil adapté à vos besoins ?

Avant toute chose, il est nécessaire de mesurer l’adéquation de l’outil avec le besoin attendu. Comment ? Voici quelques critères qui sauront vous aider à prendre la bonne décision :

• L’évolutivité des environnements

Si vous êtes dans un contexte soumis à de fortes évolutions d’environnement, une Fabric PaaS permet de réduire le temps de déploiement et de limiter les interventions humaines.

• Le niveau de demande de création de nouveaux environnements

Une trop faible demande ne permettra pas d’amortir le coût de mise en œuvre par les gains dégagés

• Le niveau de standardisation des demandes

Plus les demandes sont normalisées / standardisées, plus il sera possible d’aller loin dans le packaging et donc réduire au maximum les interventions humaines

• La variation dans le temps du niveau d’exigence en performance et haute disponibilité 

Une Fabric Paas permettra de gérer les capacités de performance au fil de l’eau : assurer le service lorsque le niveau d’exigence est au plus haut tout comme libérer les ressources lorsque le niveau est bas. Plus ce genre de variation sera fréquent, plus l’outil fera preuve d’utilité.

Les promesses des fabric PaaS sont alléchantes. Pour autant il s’agit de produits très récents et demandant des investissements compliqués en période de pressions budgétaires ainsi que des évolutions organisationnelles. Leur avènement nous semble toutefois inéluctable mais à un rythme d’adoption bien plus lent que celui espéré par les fournisseurs.

*Stack : Ensemble de composants logiciels permettant de mettre en œuvre un environnement (exemple : un serveur web + un schéma de base de données)

[Article écrit en collaboration avec Alaa Jamal-Bennis]

Cet article La Fabric PaaS : cœur de la proposition de valeur du PaaS Privé est apparu en premier sur RiskInsight.

Véritable transformation du SI, l’« informatique dans les nuages » s’accompagne de nouveaux besoins, nouvelles pratiques et d’un nouveau modèle économique. A l’ère des investissements lourds en Datacenter et infrastructures succèderont les services hébergés, facturés à l’usage.

Les offres Cloud du marché IT  couvrent l’ensemble des modèles de services Cloud : IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service).

Aussi, on retrouve sous la bannière du Cloud des acteurs allant de l’éditeur de logiciels à l’acteur issu du monde de l’e-business en passant par l’expert en solutions de virtualisation….ou l’opérateur de Télécoms.

Que font les opérateurs télécom dans les nuages ?

Pour déployer l’ensemble des services Cloud, la base est indispensable ; et cette base, c’est l’IaaS – les infrastructures…

Experts dans la conception, la production et l’exploitation de solutions de communications entreprises, les opérateurs ont donc une carte à jouer.

Certains opérateurs proposent déjà des offres Cloud, à base de solutions de virtualisation d’infrastructure et d’accès réseaux à la carte / à la demande. C’est le cas de Verizon Business avec CaaS (Computer as a Service)  et de l’offre Flexible Computing d’Orange business Service, déclinée en version premium depuis Décembre 2010. SFR a de son côté lancé en France une offre Infrastructure SI à la Demande le 30 juin dernier. L’opérateur s’est pour cela allié à HP qui fournit l’expertise Infrastructure manquant à l’opérateur.

Des atouts indéniables

Les opérateurs de télécoms bénéficient d’une notoriété et d’un capital confiance inégalés dans le monde des solutions et services informatiques. Par ailleurs, alors que sécurité et  dépendance au réseau sont évoqués comme des freins majeurs, ils y offrent des réponses concrètes.

– Sécurité : les opérateurs proposent des solutions d’interconnexion d’utilisateurs, de sites ou d’infrastructures sécurisés depuis plusieurs années.

– Dépendance au réseau : les opérateurs exploitent des solutions Très Haut Débit de moins en moins chères, avec une disponibilité bien souvent garantie à 100% et des engagements de niveaux de service associés.

Ils disposent en outre d’avantages concurrentiels établis sur ce marché (clientèle mixte entreprises et grand public, expertise en infrastructure et réseau, couverture globale et capacité d’intervention IT locale) et sont rodés au modèle économique de facturation à l’usage, caractéristique du Cloud.

Un positionnement appelé à évoluer

Le positionnement des principaux offreurs du marché se veut de plus en plus « généraliste ». Après avoir capitalisé sur leurs cœurs de métier respectifs (édition, gestion d’infrastructures, réseau) ils cherchent à élargir l’empreinte de leurs offres.

Pour les opérateurs notamment, cela passe par des alliances stratégiques avec les offreurs actifs sur les autres couches de la pyramide. Par exemple, Orange Business Services s’allie à Microsoft pour intégrer des solutions de messagerie et de collaboration de la plate-forme Microsoft Office 365, hébergée dans le Cloud. Dans ce cas, l’opérateur global qu’est France-Télécom Orange, met également à profit son savoir faire et ses ressources disponibles dans l’intégration de solutions informatiques.

Quelles perspectives ?

Le marché du Cloud n’en est vraisemblablement qu’à ses débuts, mais il dispose d’un potentiel de croissance fort que dénotent les investissements consentis sur le sujet et les premiers bilans économiques.

On ne compte plus les parallèles pour évoquer cette croissance attendue, par exemple avec la VoIP, un marché aujourd’hui mature et au cœur de la sratégie des opérateurs de télécoms.

Selon la plupart des acteurs du Cloud que j’ai pu rencontrer, ce marché représenterait 50% du marché total de l’IT dans le monde à horizon 5 ans. Ce palier de 50% demeurera la limite « physique » de développement du Cloud, tout l’IT n’ayant pas vocation à « basculer ».

Pour les analystes il devrait peser en 2015 dans le monde, entre 200 Mrd$ et 500 Mrd$. Le marché Français pourrait être estimé entre 10Mrd€ et 20Mrd€ cette même année (estimation Solucom).

Il y a fort à parier que Stéphane Richard, Directeur Général du groupe France Télécom, avait ces chiffres en tête en l’identifiant comme levier de croissance clé dans le cadre du plan stratégique « conquêtes 2015 ». Chiffres qui vont avec la certitude que les opérateurs disposent des atouts pour qu’une part importante du gâteau leur revienne d’ici 2015.

Cet article Les opérateurs, acteurs naturels du cloud computing est apparu en premier sur RiskInsight.