Vivre à la limite : Comment nous en sommes arrivés là

Les développeurs et les ingénieurs qui viennent d’arriver dans le monde de l’informatique et des applications voient souvent le monde à travers le prisme des technologies les plus récentes, les plus innovantes et les plus brillantes du marché. Mais le plus souvent, la vérité est que, comme nos amis d’enfance, vétérans grisonnants de l’industrie technologique, ces concepts et leurs implémentations analogues ont toujours existé. Ils progressent ou reculent simplement au fil du temps, à mesure que les exigences commerciales et les aspects économiques convergent et divergent, par rapport aux contraintes de mise en œuvre et aux infrastructures sous-jacentes. En fait, c’est l’environnement commercial en constante évolution qui génère des besoins et des exigences, ce qui entraîne ensuite des stratégies technologiques spécifiques à redécouvrir ou à mettre de côté.

Dans cette optique, pour la prochaine série d’articles, je parlerai de certaines des technologies liées aux applications dont la vague va arriver au cours des prochaines années, en particulier à mesure que nous évoluons vers une structure de distribution d’applications plus entièrement dispersée et le rôle émergent de l’edge. Mais d’abord, il est utile d’examiner pourquoi et comment nous en sommes arrivés là où nous en sommes aujourd’hui.

Étape 1 : L'ère des centres de données

Commençons notre voyage il y a environ 20 ans, à une époque où la fourniture numérique de services commerciaux (le terme « applications » n'était pas courant à l'époque) se faisait à partir de centres de données détenus et exploités par des privés. Cette stratégie technique était suffisante et appropriée à cette époque, en grande partie parce qu'à cette époque, seules les opérations commerciales les plus critiques étaient « numérisées ».  Voici quelques exemples d’opérations commerciales numériques à cette époque :

• Un détaillant en ligne ne ferait que « numériser » l’expérience d’achat du client et peut-être la gestion des stocks. 
• Une compagnie aérienne ne ferait que « numériser » les systèmes de réservation et de paiement. 
• Le gouvernement « numériserait » les flux transactionnels à forte valeur ajoutée, tels que les paiements d’impôts.

Étant donné que seul un petit nombre de flux de travail d'entreprise, c'est-à-dire les plus importants, étaient fournis et pris en compte numériquement dans le contexte d'une organisation commerciale typique à cette époque (effectifs intégrés verticalement, géographiquement colocalisés avec un contrôle centralisé de l'organisation et de l'infrastructure informatique), il était naturel que cela se reflète organisationnellement dans un centre de données détenu et géré de manière centralisée par l'informatique, exécutant des « applications » monolithiques qui étaient principalement ou entièrement développées en interne. L'infrastructure, la sécurité et les applications (appelées « services commerciaux ») constituaient une seule pile intégrée verticalement. Ainsi, dans un sens très réel, la pile technologique – centralisée et monolithique – imitait les structures organisationnelles et commerciales.

Étape 2 : L'ère du cloud

L’étape suivante dans l’évolution des applications et de leur pile technologique a été motivée par l’expansion de la « numérisation » dans les flux de travail commerciaux secondaires. Cette étape suivante a élargi l’ensemble des flux de travail numériques pour inclure non seulement les flux de travail orientés client (qui sont en outre devenus des produits de base, comme en témoigne la prolifération des applications dans les magasins d’applications), mais a également élargi la portée pour inclure les flux de travail opérationnels internes à l’organisation, souvent considérés comme faisant partie de la tendance à la transformation numérique de l’entreprise.

Par conséquent, les entreprises ont été obligées de repenser leurs stratégies d’organisation commerciale. L’une des implications spécifiques était qu’une plus grande importance était accordée à la rentabilité et à l’agilité, compte tenu du problème commercial lié à l’évolution rapide de l’échelle des entreprises. Cela a orienté le modèle de paiement vers un modèle de tarification des services publics, payant pour ce qui est réellement utilisé, plutôt que de devoir payer à l'avance et prévoir une charge plus élevée éventuellement anticipée. En utilisant la terminologie financière, le modèle de financement de l'infrastructure applicative est passé de plus en plus du modèle CapEx initial à la stratégie OpEx à la carte. Une autre tendance simultanée observée au cours de la même période, également liée à la rentabilité et à l’agilité, a été l’évolution vers une main-d’œuvre plus répartie géographiquement, ce qui a entraîné un besoin de connectivité 24 heures sur 24, 7 jours sur 7, plus omniprésente et plus fiable que par le passé.

Les répercussions de ces exigences – la numérisation d’un nombre beaucoup plus important de flux de travail d’entreprise, le désir de flexibilité du modèle de coûts OpEx et l’exigence d’une connectivité mondiale 24 heures sur 24, 7 jours sur 7 – ont naturellement conduit à un environnement propice à la création d’un réseau mondial de très grands centres de données virtuels hautement disponibles, dont l’utilisation était tarifée comme un service public. Et c'est ainsi qu'est né le cloud public. 

De plus, une fois les graines du cloud public présentes, une boucle de rétroaction positive auto-renforçante a été créée. À mesure que le cloud public a gagné en maturité en tant que plate-forme d’application, il a commencé à absorber une grande partie de l’infrastructure réseau de niveau inférieur qui était auparavant gérée par l’informatique d’entreprise traditionnelle. Par conséquent, la portée des équipes d'opérations réseau a diminué au sein de nombreuses entreprises, celles-ci se concentrant plutôt sur le déploiement et la distribution d'applications (également appelés « DevOps ») et la sécurité des applications (également appelées « SecOps »). Bien sûr, ce n’était pas universel ; les fournisseurs de services et les grandes entreprises avaient le besoin et la capacité de réaliser des NetOps en interne pour leurs flux de travail les plus critiques ou les plus sensibles.

Cette histoire représentait la première phase de l’ère du cloud, dans laquelle le cloud public pouvait être considéré comme une forme de centre de données externalisé, à temps et ressources partagés. En d’autres termes, l’abstraction du cloud public était celle d’une infrastructure en tant que service (IaaS).

La phase suivante de l’ère du cloud a été motivée par deux nouvelles perspectives commerciales, toutes deux nécessitant le paradigme Phase 1/IaaS comme condition préalable. La première de ces réalisations commerciales a été rendue possible par la capacité à isoler la fourniture de la valeur commerciale de la mise en œuvre qui a fourni le flux de travail numérique. Plus précisément, les entreprises pouvaient désormais commencer à imaginer une stratégie d’exécution dans laquelle les niveaux inférieurs de l’infrastructure technologique, désormais gérés comme un service fourni par le cloud public, pouvaient être découplés des principales préoccupations des dirigeants d’entreprise, qui concernaient la proposition de valeur de l’entreprise et les différenciateurs concurrentiels. 

La deuxième observation commerciale était que, à mesure que de plus en plus de flux de travail traditionnels devenaient numériques et automatisés, les processus commerciaux de niveau supérieur pouvaient être ajustés et optimisés sur des échelles de temps beaucoup plus courtes. Un article distinct traite cet effet plus en détail, en expliquant comment les flux de travail numériques évoluent d'une simple automatisation des tâches à travers l'optimisation numérique (alias « expansion numérique ») pour finalement aboutir à des augmentations commerciales assistées par l'IA. À titre d’exemples de cette tendance, des flux de travail aussi divers que l’ajustement des prix, la planification du temps des employés et la gestion des stocks ont tous bénéficié d’une adaptabilité rapide, et le terme « agilité commerciale » a été inventé. 

Ces deux constats ont donné lieu à une révélation commerciale, car les entreprises ont réalisé qu'il était souvent plus rentable d'externaliser les domaines qui ne représentaient pas les compétences principales de l'entreprise. Cela a conduit à un accord commercial gagnant-gagnant entre l'entreprise et ses partenaires fournisseurs de cloud, où les deux parties ont été motivées à améliorer encore les services offerts par le cloud public, déchargeant ainsi l'entreprise de charges technologiques supplémentaires. Ce concept a ensuite été étendu par le cloud public pour mettre à disposition des fonctionnalités de plateforme de niveau supérieur, telles que des bases de données, des systèmes de fichiers, des passerelles API et des plateformes informatiques sans serveur, toujours sous forme de services dans le cloud public. En outre, les fournisseurs de cloud public ont également proposé d’intégrer des services over-the-top, le plus souvent dans les domaines de la gestion des performances et de la sécurité.

Le résultat fut qu’à mesure que l’ère du cloud a dépassé le modèle IaaS de la phase 1, elle a inauguré les paradigmes de la phase 2 du cloud, à savoir Platform-as-a-Service (PaaS) et Software-as-a-Service (SaaS). Avec Cloud Phase 2, la plupart, voire la totalité, de l’infrastructure nécessaire pour prendre en charge une application pourrait être externalisée de l’entreprise vers des fournisseurs de cloud qui pourraient optimiser l’infrastructure à grande échelle et mobiliser une équipe plus large de spécialistes pour se concentrer sur tout service d’application largement requis. Même si cela a permis à l'entreprise de concentrer son budget technologique sur la logique métier de base, cela a souvent entraîné un effet secondaire indésirable (du point de vue de l'entreprise) de « verrouillage » envers un fournisseur de cloud particulier. Afin d'atténuer cet effet, les entreprises se sont efforcées de définir et de codifier l'expression de leur valeur commerciale principale à l'aide de technologies indépendantes des fournisseurs, en particulier dans les domaines clés des API et des modèles de calcul, et ont été mises en œuvre à l'aide de la technologie API REST et gRPC, soutenue par un modèle de calcul virtualisé et conteneurisé : Kubernetes. 

Étape 3 : Numérisation des objets et des processus physiques

La troisième étape, actuellement émergente, dans la progression des « applications » est portée par la numérisation des activités quotidiennes que nous ne considérons guère comme des flux de travail. Contrairement aux étapes 1 et 2, où il s'agissait principalement de processus commerciaux et d'un petit ensemble de flux de travail transactionnels des consommateurs qui étaient mis en ligne, cette étape vise à créer des expériences numériques omniprésentes et parfaitement intégrées dans nos actions quotidiennes de la « vie humaine ». L’ensemble des cas d’utilisation est encore en cours de développement, mais nous entrevoyons déjà des aperçus de la route riche et multiforme qui nous attend dans les cas d’utilisation émergents qui exploitent des technologies telles que la réalité augmentée, les systèmes automatisés de surveillance domestique et la gestion de l’énergie au niveau du réseau. Les solutions interagissent notamment avec le monde réel et physique, souvent à l’aide d’appareils intelligents : véhicules autonomes, assistants numériques, caméras et toute une variété d’appareils électroménagers intelligents. 

Du point de vue de l’entreprise, cette prochaine transition mettra davantage l’accent sur l’expérience utilisateur du consommateur numérique. Cette focalisation sur l'expérience utilisateur, associée à l'observation selon laquelle les appareils, et non les humains, constitueront la majorité des clients directs des processus numériques, signifie que les exigences du consommateur numérique en matière d'expérience utilisateur seront beaucoup plus diverses qu'elles ne l'étaient aux stades précédents de l'évolution numérique. Cette prochaine transition, de l’étape 2 à l’étape 3, sera différente de la précédente (de l’étape 1 à l’étape 2). Plus précisément, cette prochaine étape ne sera pas une simple progression extrapolée des mesures habituelles de l’expérience numérique (c’est-à-dire « rendre l’expérience plus rapide et réduire la latence »), mais consistera plutôt à donner à « l’application » un ensemble beaucoup plus large de choix sur la manière de faire des compromis en matière de livraison d’applications, permettant ainsi d’adapter l’expérience aux exigences du consommateur numérique dans le contexte du cas d’utilisation traité.

Du point de vue d'un technologue, l'implication des exigences commerciales est que la diversité accrue des exigences en matière d'expérience de consommation entraînera la nécessité de construire un moyen flexible et adaptable pour échanger, spécifier et optimiser les mesures de distribution d'applications communes : latence, bande passante, fiabilité et disponibilité. Par exemple, un système d’expérience de réalité augmentée peut nécessiter une très faible latence et une bande passante élevée, mais être plus tolérant à la perte d’une petite fraction du trafic réseau. À l’inverse, une caméra domestique utilisée pour un système d’alarme peut nécessiter une bande passante élevée, mais tolérer une latence (relativement) plus longue, de l’ordre de quelques secondes. Un compteur intelligent peut tolérer à la fois une longue latence et une faible bande passante, mais peut nécessiter des niveaux élevés de fiabilité éventuelle, voire ponctuelle, afin que toute la consommation d'énergie soit enregistrée.

La conception et l’architecture d’un système suffisamment flexible et adaptable pour répondre aux besoins de cette prochaine étape de « numérisation » nécessiteront un mécanisme dans lequel les nombreux composants qui composent la fourniture d’une expérience numérique peuvent être facilement dispersés et migrés, si nécessaire, vers divers emplacements dans le chemin de fourniture de l’application. La distribution de ces composants d’application devra être adaptée aux besoins de diffusion (latence, bande passante, fiabilité) en fonction des exigences de l’expérience utilisateur, et les systèmes devront s’adapter en permanence à l’évolution de l’environnement et de la charge. Enfin et surtout, les problèmes de sécurité de l’application (gestion des identités, protection contre les logiciels malveillants, détection des violations) devront suivre de manière transparente les composants de l’application à mesure qu’ils se déplacent dans le chemin de distribution de l’application.

Penché vers la route qui nous attend

Alors, plus concrètement, qu’est-ce que cela signifie, par rapport à où nous en sommes aujourd’hui ?  Ce que cela signifie est ceci :

• Premièrement, étant donné que la majorité des consommateurs d’expériences numériques seront d’autres applications et services numériques, le rôle des API et de la gestion des API occupera encore plus une place centrale.
• Deuxièmement, l’ensemble des lieux de distribution d’applications dont nous disposons aujourd’hui (le centre de données, le cloud et les services fournis par le cloud) ne sera pas suffisant pour répondre aux besoins futurs. Plus précisément, afin d’offrir des expériences client plus riches, nous devrons être en mesure de fournir des aspects de l’expérience d’application numérique plus proches de l’utilisateur final, en utilisant des technologies telles que l’edge intelligent, le contenu du chemin de distribution et les services de calcul, et le SDWAN dans le chemin de distribution. Nous devrons peut-être même étendre le chemin de livraison des applications pour utiliser les technologies sandbox côté client.  
• Troisièmement, la périphérie deviendra de plus en plus le point d’« entrée » dans la diffusion de l’expérience numérique et, par conséquent, elle prendra davantage d’importance en tant que point d’orchestration clé de la diffusion.
• Enfin, en matière de sécurité, elle doit non seulement être innée et omniprésente, mais également indépendante de la manière dont les composants de l’application sont dispersés le long du chemin de distribution de l’application.

Ces trois derniers sujets seront au centre des prochains articles de cette série, où nous parlerons de « l'Edge » et de son avenir, puis de ce à quoi ressemble une vision de la sécurité véritablement indépendante de la localisation.