Pourquoi le schéma habituel d’explication du modèle “as a Service” est-il trompeur ?

Nous avons tous découvert le concept du “as a Service” et nous l’avons ensuite expliqué avec le schéma traditionnel comparant “on premise”, “IaaS”, “PaaS” et “SaaS”. Cette une représentation semblait a priori satisfaisante.  

Après quelques années de retour d’expérience sur le sujet, chez LPB Conseil, il nous semble que cette représentation est non seulement incomplète mais surtout masque la véritable problématique du “as a Service” : il ne s’agit pas tant de savoir “QUI GÈRE” mais “COMMENT GERER” !

Dans cet article, tenterons de vous donner quelques clés pour établir votre stratégie de “cloudisation”.

La thèse du schéma traditionnel : les niveaux d’externalisation

Dans le Schéma traditionnel, on nous explique qu’il y a quatre niveaux d’externalisation :

• En local ou OnPremise : l’infrastructure est totalement hébergée chez vous et vous en avez toute la charge. Il en est de même pour les couches applicatives.
• Infrastructure as a Service : la partie matérielle ainsi que la couche de virtualisation est hébergée chez un fournisseur. Vous conservez à la gestion depuis la VM (machine virtuelle) jusqu’à la couche applicative
• Platform as a Service : une certaine plateforme applicative ou un environnement est géré par le fournisseur. Vous gérez une partie applicative ainsi que la sauvegarde des données.
  Chose amusante : dans ce modèle d’explication, rares sont les Consultants qui seront en capacité de vous donner une explication qui n’ait pas l’air fumeuse ou approximative !
• Software as a Service : vous – le client – ne gérez rien du tout. Tout est inclus dans la gestion par le fournisseur. Comme nous l’avons vu dans l’article https://blog.lpb-conseil.com/stockage-sauvegarde-cloud, nous vous conseillons tout de même de réaliser un certain nombre de vérification avant de confier la sauvegarde de vos données à un tiers.

Expliqué rapidement, ce modèle semble cohérent. Il permet de convaincre un DSI dans un modèle majoritairement OnPremise (local donc), qu’il doit se positionner dans un degré d’externalisation.

Il doit placer le curseur du pas du tout au tout externalisé.

Ce schéma laisse penser qu’il existe une certaine progressivité voire un niveau de maturité en termes d’adoption du Cloud Computing. Nous le verrons plus bas, cette proposition est totalement fausse.

Pourquoi est-il dangereux de résumer sa stratégie au IaaS, PaaS et SaaS ?

Résumer sa stratégie d’externalisation à quatre niveaux – du rien au tout – est très simpliste voire dangereux.

Tout d’abord, il est évident que l’externalisation de certains blocs n’est pas pertinente : pilotage d’une ligne de production, systèmes d’imagerie ou autres systèmes totalement autonomes ou directement lié à une machine.

A contrario, l’externalisation semble évidente pour d’autres blocs applicatifs. Totalement tournés vers l’extérieur de l’entreprise ou soumis à des pics d’utilisations très variables – il serait absurde de ne pas les externaliser : sites web, applications mobiles, etc.

Pour établir sa stratégie Cloud, il est donc raisonnable de mixer les types d’externalisation en fonction des contraintes physiques, des opportunités technologiques ou des usages.

Nous ne saurions que trop vous recommander de vous appuyer sur un cabinet de Conseil pour établir votre stratégie de “cloudisation”. Cela vous permettra de disposer d’un véritable retour d’expérience et de vous inciter à dépasser les limites de votre imagination.

Décryptage du modèle “as a Service” 

Nous avons vu plus haut qu’il était possible voire recommandé de mixer les approches “As a Service” entre-elles voire avec l’hébergement local.

Dans ce cadre, on pourrait se demander quel modèle est adapté à quel contexte ?

Le modèle “OnPremise” vs “Infrastructure as a Service”

Pour beaucoup, la dichotomie OnPremise / IaaS se résume à une problématique d’infrastructure interne vs Externe. De mon point de vue, cette vision est totalement fausse.

En effet, l’IaaS se caractérise par une offre standardisée de VM (Machine Virtuelle) idéalement en self-service. En suivant des principes de catalogue de services largement portés par les bonnes pratiques ITIL, il serait totalement possible de reproduire ce modèle totalement hébergé en local.

Techniquement, il s’agirait de disposer d’une infrastructure virtualisée avec un système d’orchestration des VM (voir https://www.openstack.org/ ou https://www.vmware.com/products/vrealize-orchestrator.html). Rien de très compliqué à mettre en oeuvre. 

En revanche, le défi organisationnel est de taille. Il s’agit de définir un catalogue de services standardisés en termes d’infrastructures associant : SLA, performance, tarifs, sécurité, etc.

Définition (compréhensible) du PaaS

Faisons fi de la vision “niveau d’externalisation” et adoptons une vision organisationnelle.

Dans un monde idéal, un développeur souhaiterais disposer d’environnements prêt-à-l’emploi pour :

• Mettre en place un cycle de vie des environnements : développement, recette, pré-production et production
• Dupliquer un environnement existant pour créer une nouvelle version : fork d’un projet avec des fonctionnalités spécifiques
• Dupliquer un environnement pour le repackager : revente d’une application existante pour un autre client
• Utiliser des environnements pré-configurés et à jour : plateforme WordPress, Drupal, …

Là encore, c’est davantage un enjeu organisationnel que technique qu’il est nécessaire de relever.

Il s’agit en effet de standardiser des usages pour des populations de développeurs. C’est tout.

Le SaaS, une toute autre problématique

Lorsqu’on définit le SaaS d’un point de vue SI, on parle en fait d’application 100% standards. Il est par définition impossible de customiser pour l’utilisateur. Le produit vous plait tel qu’il est, sinon vous ne le prenez pas. C’est tout.

Partis sur cette base, nous voyons qu’une fois encore la problématique n’est ni technique, ni de savoir qui opère l’application.

La problématique est uniquement organisationnelle : mes métiers ou utilisateurs peuvent-ils se conformer aux processus informatisés standards de l’outil ? Si non, passez votre chemin.

Le “As a Service” : problématique de standardisation et non pas d’externalisation

Finalement, nous avons vu que pour une DSI, la problématique du “As a Service” tourne autour de votre organisation en mode Service. En effet, il serait tout à fait possible – et pourquoi pas recommandé ? – de mettre en place une organisation “As a Service” en interne.

Pourquoi ne pas adopter une organisation “As a Service” y compris pour les briques du SI hébergées en local ?

En effet, en appliquant les bonnes pratiques ITIL de façon puristes, on arriverait à :

• Des services totalement standardisés
• Des contrats de services tant sur les aspects coûts que niveau de services (qualité, performance, sécurité, …)
• Une relation client-fournisseur et une refacturation y compris en interne

En définitive, ce modèle ITIL poussé vous amène à la création d’un Cloud Privé (ou hybride) où toutes les prestations fournies sont maîtrisées, standardisées et refacturées… qu’elles soient hébergées en interne ou en externe.

En guise de conclusion, voici une proposition de représentation du modèle “as a Service” tel que nous le concevons :