Si, à l’heure actuelle, les moyennes entreprises utilisent jusqu’à huit clouds issus de différents fournisseurs, il est prévu que d’ici 2023, 94 % des grandes entreprises devraient pouvoir exécuter leurs charges de travail sur une multitude de clouds différents.
Cette démarche présente des avantages évidents : son large choix de services de qualité permet aux développeurs de toujours faire preuve d’innovation et de rendre les entreprises plus compétitives et plus résilientes.
Néanmoins, une stratégie multicloud ne comporte pas que des avantages. Un patchwork de différents clouds peut être difficile à superviser et à sécuriser, et le fait de tous les mettre en conformité peut s’avérer très coûteux. Il est conseillé de consacrer des compétences et des connaissances à des clouds spécifiques, ou alors de les répartir sur l’ensemble des clouds – au risque que les ressources soient distribuées de manière inefficace. Effectuer un suivi des dépenses (et voir si cela représente un bon rapport qualité-prix) peut devenir un exercice d’analyse important.
La question se pose alors : comment une entreprise peut-elle résoudre ce paradoxe ?
La réponse est la suivante : il est nécessaire de repenser le développement d’applications – non pas en fonction de ses éléments techniques constitutifs (tels que des conteneurs, des clusters, Kubernetes ou des maillages de services) mais comme une plateforme de bout en bout, orchestrée par une seule et unique console. Cette approche permet au personnel non technique d’accéder à l’univers du DevSecOps et d’obtenir facilement les informations opérationnelles nécessaires à la prise de décisions commerciales judicieuses.
La répartition du budget constitue donc un élément clé de cette approche. Dans une configuration multicloud, il n’y a pas de manière uniforme de faire les choses : les clusters exécutés sur différents clouds doivent respecter des règles et des processus différents, qu’il s’agisse de l’approvisionnement, des accords de niveau de service, des systèmes d’exploitation, des « patch cycles » (cycles de correction), des types de stockage ou des systèmes de mise en réseau. Les outils peuvent également varier. Ainsi, à mesure que l’activité se développe, il devient de plus en plus difficile de savoir où vont réellement les coûts et quel sera le retour sur investissement. Il y a donc un risque que les zones de dépassement de budget ou de sous-dépense soient masquées et laissées à l’abandon par la suite.
A l’inverse, une plateforme d’application principale offre une vue d’ensemble unique de tous les clusters, ce qui permet d’identifier plus facilement les coûts et les éventuelles dépenses plus efficaces. Le gaspillage est d’autant plus réduit que la plateforme est capable d’agréger et d’augmenter les capacités des différents clouds, ce qui facilite la création de clusters normalisés et ciblés, qui n’accèdent qu’aux données nécessaires en fonction des différentes tâches à accomplir. Par conséquent, le travail des développeurs n’est pas ralenti par le processus de configuration, ce qui leur permet de se consacrer davantage à la création d’applications complètes et hautement performantes, et donc d’apporter plus de valeur à l’entreprise.
La mise en conformité est un autre point sensible qui peut être géré en rassemblant les workloads multicloud sur une base commune. Aujourd’hui, les données sont devenues l’un des aspects les plus réglementés de l’entreprise. Tout effort visant à accorder plus de liberté et d’agilité aux développeurs doit être équilibré par une compréhension scientifique des données qu’ils utilisent et produisent. Le même principe s’applique à la sécurité : une configuration multicloud peut augmenter la surface d’attaque potentielle, tandis que les vulnérabilités peuvent être plus difficiles à repérer. Ainsi, sécuriser l’ensemble de sa structure constitue un réel défi lorsque l’on protège de nombreux fiefs indépendants au lieu d’un seul grand royaume.
A l’ère du multicloud, la plateforme d’applications vise à assurer la conformité et la sécurité. En centralisant les politiques et les protocoles de sécurité, elle contribue à garantir des normes cohérentes entre les différents clouds. Cette visibilité des données est non seulement cruciale pour les obligations de conformité, mais elle peut également être exploitée par les développeurs pour optimiser les flux de données entre les API. Une tendance parallèle est la mentalité « shift-left », qui intègre les considérations de sécurité à la source – c’est-à-dire lorsque les développeurs commencent à écrire le code. Cela permet d’améliorer le time-to-market et l’agilité, et de prendre en charge des aspects essentiels du développement d’applications modernes tels que la collaboration, la répétitivité et la disponibilité.
C’est en ajoutant cette intégration et cette orchestration entre les clouds que la stratégie d’une entreprise passe du multicloud au cloud hybride. Les avantages du cloud hybride sont amplifiés par la croissance du edge computing. L’écosystème est diversifié et complexe. Les dispositifs en périphérie ont tendance à être construits dans l’optique d’accomplir une tâche bien précise et proviennent donc souvent de plusieurs fournisseurs, ce qui peut avoir pour effet de créer un certain chaos. En revanche, le fait de tout unifier au moyen d’une plateforme d’applications évolutive apporte une cohérence et une flexibilité qui favorisent l’innovation.
La logique est la même si votre paysage informatique conserve des éléments sur site. Les entreprises sont confrontées à des décisions difficiles sur la manière de moderniser leurs applications existantes. L’utilisation d’une couche d’abstraction commune pour créer l’interopérabilité entre les environnements sur site et dans le cloud facilite le « lift and shift » ou le remaniement d’éléments spécifiques du code.
Cela étant dit, une plateforme d’applications est une tapisserie complexe où se mêlent de multiples capacités et protocoles. En concevoir une à partir de rien risque de dépasser les ressources utilisées par de nombreuses équipes informatiques et de nécessiter des investissements importants, ce qui peut, de fait, engendrer des risques. De plus, avec l’évolution rapide de DevOps au fil du temps, il est indispensable que toute plateforme soit améliorée en permanence.
Au lieu de cela, les entreprises peuvent opter pour leur réaction habituelle lorsqu’elles sont confrontées à une nouvelle opportunité technologique : se tourner vers des partenaires technologiques qui peuvent leur permettre de la saisir. Lorsqu’une plus grande partie des équipes peut être affectée au développement de première ligne plutôt qu’à l’ingénierie back-end, la productivité de l’entreprise s’en trouvera augmentée et la compétitivité du marché devrait suivre.
Cliquez ici pour lire l’article depuis sa source.