Le succès du SaaS tient en grande partie à la capacité des entreprises à identifier des processus métier standardisés et à les intégrer dans des logiciels. Il en va de même pour les équipes chargées du réseau et de l’infrastructure au sein de l’entreprise.
Le SaaS (Software as a Service) représente aujourd’hui le plus grand marché du « cloud ». Malgré l’engouement suscité par l’IaaS (comme AWS, Azure et Google Cloud), force est de constater que le SaaS a largement dépassé toutes les autres formes de « cloud » en matière de taux d’adoption et de croissance continue.
Et cette croissance ne montre aucun signe de ralentissement. Une enquête menée début 2016 a mis en évidence la poursuite de cette explosion du SaaS : les personnes interrogées ont indiqué que le nombre d’applications SaaS officiellement prises en charge par les services informatiques avait augmenté de 50 % en seulement un an, passant de 8 en 2015 à 12 en 2016. Le rapport prévoit que ce nombre augmentera encore pour atteindre 17 en 2017.
Sachant que le « cloud » existe maintenant depuis dix ans, les taux d’adoption de ces applications traditionnellement considérées comme assez standard sont plutôt impressionnants. Nous parlons ici de CRM, d’ERP, de CMS, ainsi que de suites bureautiques axées sur la productivité et de sites de partage de fichiers.
Vous vous demandez probablement quel est le rapport entre le SaaS et l’automatisation de l’infrastructure. Après tout, ce sont deux choses qui n’ont rien à voir. L’automatisation du provisionnement et de la mise à l’échelle du réseau n’a rien de comparable au SaaS.
Sauf qu’en un sens, c’est bien le cas. Accordez-moi un instant, je vais vous expliquer.
En effet, l’un des thèmes récurrents dans toutes les applications SaaS est la banalisation des fonctionnalités. Le glisser-déposer est un modèle de partage de fichiers désormais bien maîtrisé, que ce soit sur un ordinateur, au moyen de dossiers partagés sur le réseau, ou via une interface accessible depuis un navigateur. Il en va de même pour les documents et les présentations, et même pour la publication de contenu. Il existe un processus assez bien défini qui détermine la manière de procéder pour accomplir telle ou telle tâche ; que l’interface soit un navigateur web ou une application autonome ne change pas vraiment ce processus, mais seulement les icônes et l’interface.
De nombreuses fonctions de l’entreprise sont, elles aussi, fortement standardisées (banalisées). Le processus suivi par un conseiller du service client lorsqu’il répond à votre appel très important (et il l’est vraiment, comme ils nous l’assurent tous) est probablement sensiblement le même, quel que soit votre interlocuteur. Appeler le câblo-opérateur ou une enseigne de vente au détail au sujet d’une commande donne lieu à une expérience assez standardisée. Mais ne me croyez pas sur parole : voici un excellent article de la Harvard Business Review (datant de 2005) qui traite précisément de cette convergence vers la standardisation des processus, laquelle allait peu après donner naissance au phénomène aujourd’hui connu sous le nom de « SaaS ».
“Les processus standardisés facilitent également l’externalisation des capacités opérationnelles. Pour externaliser efficacement des processus, les organisations doivent pouvoir évaluer trois éléments en plus du coût. Le premier concerne l’ensemble des activités du prestataire externe et leur enchaînement. Comme les entreprises ne se sont pas accordées sur ce que recouvrent précisément, par exemple, la comptabilité analytique ou la gestion des avantages sociaux par les ressources humaines, la répartition des services à assurer entre clients et prestataires reste ambiguë. Les organisations ont donc besoin de normes définissant les activités des processus afin de pouvoir communiquer facilement et efficacement lorsqu’elles abordent la question des processus externalisés. De telles normes relatives aux activités et aux flux des processus commencent à voir le jour dans divers secteurs et branches d’activité. Certaines résultent des efforts de groupes spécialisés dans les processus, tels que le Supply-Chain Council, qui compte plus de 800 entreprises membres.”
Une fois qu’un processus est standardisé (banalisé), il devient assez facile de le codifier et de lui ajouter une interface que l’on peut commercialiser. J’avancerais même que c’est la banalisation sous-jacente de ces fonctions métier qui a contribué à propulser les premiers fournisseurs de SaaS sur le devant de la scène. Avec un modèle de données et une interface de base, il était assez facile d’apporter le minimum de personnalisation requis par les clients afin d’adapter le processus à leurs besoins. Et voilà : succès immédiat.
Appliquons maintenant cela à l’infrastructure et au réseau. Il existe un certain nombre de processus liés au provisionnement, à la gestion et à la mise à l’échelle qui sont tellement standardisés d’une application à l’autre que les équipes d’exploitation réseau pourraient saisir les commandes nécessaires les yeux fermés. Les seules différences concernent des variables propres à chaque application, comme les ports, les adresses IP et les routes. Ce sont les changements que les comités de validation apprécient, car ils n’ont pas besoin d’y réfléchir. « Ah, vous allez ajouter une règle de pare-feu pour cette application. Approuvé. »
Tout comme leur exécution ne demande que peu d’attention aux équipes réseau, leur approbation ne nécessite guère de réflexion, car cela a déjà été fait une centaine de fois, le processus est toujours le même et tout le monde sait ce qu’il en est. Ces changements sont cohérents, prévisibles et reproductibles.
Approuvé.
Il s’agit des processus standardisés internes à l’informatique qui se prêtent à l’automatisation et à l’orchestration. Ce sont les meilleurs points de départ si vous cherchez des résultats rapides pour démontrer la valeur métier d’un investissement dans l’automatisation. Créez une interface par-dessus ce processus standardisé et intégrez-la au processus en remplacement des méthodes manuelles utilisées aujourd’hui. Et voilà. Vous avez réduit les coûts d’exécution de ce processus et, avantage supplémentaire, il s’exécutera plus rapidement puisque vous n’aurez pas à attendre la prochaine réunion du comité de contrôle des changements (vous pourrez peut-être même vous en passer, ce qui constitue déjà un avantage en soi).
Oui, cela demande du temps et probablement de l’argent (et peut-être un investissement dans des outils et des formations), mais les coûts à court terme seront rentabilisés à long terme. L’automatisation des processus standardisés et chronophages permet aux ingénieurs et aux architectes de se consacrer à d’autres projets. Des projets qui ont peu de chances d’être automatiquement approuvés par le comité de contrôle des changements.
Le SaaS s’impose lorsqu’il analyse une entreprise, comprend un processus courant et offre un moyen plus simple et plus rapide de l’exécuter. C’était vrai en 2006 et ça l’est encore aujourd’hui. Il en va de même pour les initiatives d’automatisation de l’infrastructure. Identifiez les processus courants et proposez un moyen plus simple et plus rapide de les exécuter, que ce soit pour l’« utilisateur final » ou pour d’autres ingénieurs.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.