SAAS COMPUTER BACKUP: THE SERVICE PROVIDER’S RESPONSIBILITY TO PUT IN PLACE

SaaS (Software as a Service) is software that is made available on, and consumed directly from, the internet. It is managed by one or more providers.  The customer does not have the wherewithal to carry out the backup activities is case of disaster (no access to raw data, source codes, applications that could duplicate the infrastructure, etc.), so it has to rely on the provider’s goodwill.

Levels of disaster recovery are variable for SaaS, depending on the provider’s degree of maturity

Three major trends are emerging:

• Providers who offer an inclusive disaster recovery plan. As part of their standard offering, the provider offers recovery at a remote data center, usually augmented with outsourced backup. However, they rarely offer commitments on recovery times.
  Examples are the big SaaS players (such as: Office 365, SalesForce, and SAP), as well as some intermediate players (such as Evernote, and Xero);

• Suppliers who offer outsourced backup only. In their case, there is no clearly established disaster recovery plan, as such. The customer then has to question the ability of the provider to restore backup files in the event of a disaster at the main site.
  Examples are intermediate suppliers (such as Zervant and Sellsy);

• Suppliers who don’t mention the issue or do not have anything in place. The subject of backup doesn’t even get raised, so it’s better to assume that nothing is being done.
  Small players are usually in this situation.

Getting contracts right is key

In the vast majority of cases, SaaS providers have no provisions in their contracts on how they will manage disaster recovery, even though they might stress their ability to handle that risk. In fact, contracts usually include default Act of God clauses stipulating that the supplier is not liable for a breach of contractual obligations if this is caused by an event beyond their reasonable control. The legal risks must therefore be addressed when framing the agreement, and these types of clauses should be removed to ensure an appropriate level of cover.

Just as they do when framing conventional contracts, customers must ensure that clear service level agreements are in place, in particular for disaster recovery. These need to cover:

• Recovery times (Recovery Time Objective – RTO) and data loss (Recovery Point – RPO) in the event of a disaster;

• The provider’s disaster recovery plan, including crisis management procedures, as well as the obligation to carry out conclusive tests every year with real-world scenarios, as part of the plan, with the customer having the option to review the test report;

• Financial penalties and the right to terminate the contract (in particular, with a provision to recover usable data) if commitments are breached.

IAAS/PAAS disaster recovery: THE CUSTOMER’S RESPONSIBILITY TO PUT IN PLACE

Infrastructure as a Service (IaaS) is a standardized, automated offering of computing, storage, and network resources owned and hosted by a provider, and made available to the customer on demand. A Platform as a Service (PaaS) offering is similar to an IaaS offer, but it is different in that it only applies to software development stack (database, EDI, business process management…) according to Gartner’s definition. Unlike SaaS, disaster recovery remains the customer’s responsibility in both cases: IaaS/PaaS providers make services available in various data centers, and the customer is responsible for their use and configuration. Two solutions are available to customers using these services: to entrust things to a provider, or manage it themselves.

The market for cloud disaster recovery is not a mature one

Cloud disaster recovery providers are referred to by the acronym DRaaS: Disaster Recovery as a Service. Initially, DRaaS providers offered cloud-based IS disaster recovery of an “on premise” datacenter. But, today, they also offer to provide recovery for infrastructure already in the cloud, such as AWS or Azure. Levels of maturity remain very variable, depending on the provider and which cloud is used. Some DRaaS providers require that their own cloud is used for recovery, which means they cannot offer a PaaS recovery service.

As with SaaS, there are no default contractual provisions. Therefore, any guarantees required for data loss or recovery time will need to be negotiated. Suppliers generally promise to be able to tailor their offer to the customer’s requirements! To ensure that the recovery performs correctly, the customer must plan for disaster recovery tests to be carried out regularly (we recommend once a year).

Operating your own disaster recovery plan, using tools offered by the supplier

For “on-premise” infrastructure, you will need to think about, and define, your DRP strategy right from the design phase. This strategy must include the option of performing tests to ensure a sufficient level of confidence in your plan.

Implementation can be simplified by the tools offered by cloud providers, and the high levels of standardization in cloud environments. The major players have set out, in white papers, the key guidelines to follow in pursuing such a project (for example, AWS and Azure).

Conceptually, these DRP strategies remain close to those used in “on-premise” data centers.

There are four main ones:

• backup and restore: simple backups of data and images of machines on a remote site, which are restored if an incident occurs;
• pilot light: replication of databases and the provision of machines, in the form of images, ready to be used if an incident occurs;
• warm standby: full replication of the main site (data and machines); the recovery site is undersized in performance terms but ready to scale up if an incident occurs;
• multi-site (or active-active): the two sites are identical and share the load from users. If an incident occurs, the remaining site can scale up to cover all users.

Hybrid solutions that are better designed to take account of recovery time requirements, and cost and complexity considerations, can also be considered.

The real contribution that the cloud can make to DRP is the numerous tools that it can offer to simplify its implementation and activation.

As a result, data replication can be simplified for asynchronous geo-replication options (where multiple copies are replicated to other regions). The RPO varies, depending on the types of data and tools involved. Aside from this option, local data redundancy is almost always included.

The high degree of standardization also makes it possible to automate the recovery: the scripts or APIs made available by providers make it possible to automate deployment of infrastructures, resize instances (according to previously defined configuration), distribute loads and traffic, carry out IP addressing, etc., in order to considerably speed up a backup site’s activation time.

The monitoring and alert tools, which are also on offer, are intended to facilitate in-service support and can be used to detect an incident in the shortest possible time, or in some cases, partially automate the activation of a backup site.

Lastly, this ability to provision new resources within a few minutes enables the associated OPEX to be minimized. By using such a strategy, it’s possible to make gains of 40 to 70% on the cost of DRP infrastructure.

Toward greater support by providers?

During 2017, Azure is planning to offer an option to provide recovery for virtual machines hosted on its platform by enhancing its “Site Recovery” service. In fact, “Site Recovery”, in its current form, offers to support traditional site backup, by using the Azure cloud to host the secondary site, but Microsoft wants to extend this service to provide a Recovery as a Service option. This tool would allow the automatic deployment of the secondary site (of the active-passive type), automatic data replication, and easier testing.

This option was available as a “public preview” at the end of May 2017. There is no equivalent project in train from the other main IaaS/PaaS providers.

THE CLOUD AND PROVIDER SYSTEMIC RISK

Backup of cloud-based services is dealt with differently, depending on the type of service used. SaaS recovery must be managed through contracts and are the responsibility of the provider, while IaaS/PaaS recovery, simplified by the tools available, remains the responsibility of the customer.

There is a risk of the widespread failure of a provider’s hosting region as recent incidents have shown. Even though these incidents have been short-lived, or have had minor impacts, the possibility of widespread failure cannot be ignored. The issue of cyber-resilience, then, must still be dealt with. Using a second cloud provider can cover the risk of destruction, or a major outage of a first provider’s infrastructure. This solution is very complex because portability between providers is a difficult issue. For now, there are few companies that have risked it, although  Snapchat is an example: it uses Google’s cloud for its production, and plans to use Amazon’s for its DRP within five years.

Cet article The Cloud: The end of IT backup – or a new way of doing it? est apparu en premier sur RiskInsight.

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.

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 public, moins cher mais non nécessairement moins sécurisé, commence à séduire ces mêmes comptes et non plus seulement les TPE et PME, notamment pour des environnements non critiques ou demandant une forte agilité.

Et si l’’avenir n’était pas le cloud, mais les clouds ?

La proposition de valeur du cloud hybride

Chaque modèle de déploiement (privé, privatif, public) a ses avantages (personnalisation et contrôle des données dans le cloud privé, prix et scalabilité dans le cloud public) et ses inconvénients (coûts d’investissement pour le privé, moindre contrôle des données dans le public). Le cloud hybride consiste en l’utilisation de plusieurs clouds afin d’en maximiser les bénéfices selon les besoins de l’entreprise.

Parmi les grands cas d’usage de l’approche hybride, l’on retrouve :

• La répartition d’applications sur plusieurs clouds suivant leurs besoins (criticité des données, élasticité et agilité, etc.) permettant de profiter du « meilleurs des deux mondes ». L’entreprise pourra par exemple utiliser un cloud public pour des environnements web faiblement couplés au SI et un cloud privé pour des environnements hébergeant des données métiers critiques. Il s’agit du cas d’usage le plus fréquemment rencontré.
• Le « cloud burst » permettant d’absorber des pics de charge en faisant déborder son infrastructure privée vers un cloud public ou privatif. Cela permet notamment de compenser l’élasticité moindre du cloud privé pour des besoins ponctuels.
• La répartition des tiers d’une application : les couches applicatives et base de données hébergées dans un cloud privé tandis que la couche de présentation sera sur un cloud public (elle ne gère pas de données critique et requiert une forte élasticité)
• L’optimisation des coûts et les performances en utilisant plusieurs fournisseurs de cloud public et en choisissant, en temps réel, le plus avantageux.

Cependant, sans un bon outillage, les coûts induits par la gestion de plusieurs clouds peuvent constituer un réel frein à l’adoption.

Comment piloter un cloud hybride ?

Le Cloud management platform (CMP) fournit à la DSI une interface de gestion unifiée vers de multiples fournisseurs de cloud.

Si de nombreux  outils existent, deux grandes approches se distinguent :

1 – L’approche « Open » : liberté et réversibilité

Cette approche se base sur l’utilisation de plate-formes de gestion de cloud privé comme le très en vogue OpenStack (mais aussi Cloudstack ou Eucalyptus) permettant l’extension de son infrastructure sur un Cloud Public, ou sur des solutions logicielles comme Scalr ou Dell Multi-Cloud Manager (ex-Entratius). Une entreprise pourra ainsi bénéficier d’une grande liberté dans le choix des clouds à piloter (et de fait d’une meilleure réversibilité), tout en limitant ses investissements et en gardant une certaine souplesse dans la personnalisation de l’outil.

Cependant sa complexité de mise en œuvre peut parfois être un frein au déploiement et grever le TCO (total cost of ownership) de la solution (coûts OPEX d’ingénierie notamment). D’autre part, la sécurisation de cette solution, partiellement ouverte sur internet (pour piloter un ou plusieurs clouds publics) reste à la charge de l’entreprise, ce qui pourra refroidir les responsables de la sécurité.

La solution de simplicité pourra alors se trouver dans l’approche “constructeur”.

2 – L’approche « Constructeur » : extension de l’hyperviseur et de son outil de gestion

On a pu voir ces derniers mois de grands constructeurs comme Microsoft et VMware ouvrir leurs Clouds publics et dévoiler leur stratégie : proposer à leurs clients utilisant leur hyperviseur (respectivement Hyper-V et vSphere) de basculer de façon transparente sur leur cloud public ou celui d’un tiers.

Il s’agit pour l’entreprise de s’appuyer sur son existant, sans déploiement supplémentaire et sans bouleverser son organisation. Elle bénéficie de nouvelles fonctionnalités tout en préservant une sécurisation forte.

Cependant le risque de “Lock-in” chez un constructeur n’est pas neutre et la réversibilité sera nécessairement plus difficile qu’avec un outil indépendant. De plus les coûts d’utilisation du cloud public seront souvent plus élevés et les besoins spécifiques de l’entreprise (la personnalisation de l’outil) plus difficiles à faire passer.

S’outiller pour anticiper les changements futurs

L’usage du cloud par les entreprises, dans une stratégie hybride, va se généraliser dans les années à venir, et les changements induits sont multiples. Il est donc nécessaire de les anticiper et de s’y préparer. Pour cela, il est important pour l’entreprise de commencer à aligner ses processus et à réfléchir à sa stratégie d’outillage.

Cependant les outils de pilotage unifiés étant encore peu matures, seules les entreprises allant très fortement vers le cloud ont intérêt à s’outiller immédiatement (pour éviter une explosion de leurs coûts d’opérations). Les entreprises moins pressées, elles, pourront attendre que les outils soient plus mûrs et se limiter pour l’instant à une veille active.

Dans tous les cas réfléchir à sa stratégie d’outillage n’est plus une option, il s’agit de préparer l’avenir !

Cet article Quelles vertus au Cloud hybride ? 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.

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.