Conclusions clés du webinaire sur « Obtenir la bonne stratégie de votre système de soutien aux entreprises (BSS) sur le cloud ».
Les conférenciers du webinaire : M. Ravi Shankar, chef de produit, logiciel réseau chez STL, et M. Ajay Iyer, vice-président de la R&D des plateformes chez STL.
Avec des technologies comme la 5G, l’IoT, le WiFi6 et autres, l’avenir du BSS est sur le cloud, qu’il soit public, privé ou hybride. Mettre BSS sur le cloud peut aider à réaliser beaucoup de valeur. Cela ne doit pas être considéré comme une migration mais comme un changement qui profitera aux clients en termes d’économies sur le coût total de possession (TCO) et d’accélération de la mise sur le marché.
Connaître l’avenir des technologies est une chose, mais avoir la bonne stratégie pour se préparer à la même chose est un aspect important sur lequel se concentrer. Les clients se trouvent à différentes étapes de leur parcours vers le cloud. Il est intéressant de noter que 10% de ceux-ci sont encore au stade préliminaire d’analyse, 25% utilisent un déploiement de cloud public/privé et les autres sont à un stade avancé d’analyse ou utilisent un déploiement hybride/multi-cloud/multi-edge.
De plus, les principaux défis auxquels chacun d’entre eux est confronté dans son parcours vers le cloud sont différents. Par exemple, 44.4 % sont confrontés à des problèmes en ce qui concerne le budget vs le coût vs les aspects techniques, 30.3% ont indiqué que gérer les aspects liés aux personnes, à la plate-forme et aux processus est un défi, et les autres ont dû relever des défis pour choisir le bon modèle d’exploitation pour l’excellence et sélectionner le fournisseur et le fournisseur de la solution cloud. .
Compte tenu des défis auxquels sont confrontés les clients, il devient extrêmement critique de bien définir la stratégie cloud. Une approche lift-and-shift compromet la transformation cloud.
Les différents aspects qui rendent nécessaire de planifier l’ensemble de la transformation sont:
Les équipes ne sont pas habituées aux changements de comportement pour avoir une expertise sur un nouveau modèleLe modèle de livraison n’est pas conçu pour l’infrastructure cloud Les services gérés de la plate-forme ne sont pas utilisés par de nombreuses applications et, par conséquent, les coûts et les délais de développement sont élevés La stratégie de déploiement n’est pas adaptée pour un cloud optimal utilisations des ressources et, par conséquent, entraîne des TCO très élevés en raison d’un provisionnement excessif Le dépannage devient difficile lorsque les pratiques standard de journalisation et de surveillance du cloud sont non mis en œuvre. Les facteurs ci-dessus rendent essentiel le bon déroulement de l’ensemble du processus de réflexion. «Les CSP doivent obtenir uniquement 10% tort d’être 100% perdu. »
Systèmes de soutien aux entreprises
Quelle est l’approche de STL pour la bonne stratégie de BSS sur le cloud?
L’approche de STL se décompose en 5étapes:
Établir des attentes claires D’abord et avant tout, définissez ce que sera le succès – ce qui commence par définir des attentes claires. Cela inclut de définir exactement à quoi la composition BSS devrait ressembler et quels produits devraient fonctionner dans un cloud public ou un cloud privé ou un type de configuration hybride.
Définir des KPI clairs pour le BSS sur le cloud La base de l’application est les KPI. STL utilise des KPI à travers différents aspects pour assurer une prestation de services transparente.
KPI de développement: Le temps de construction doit être inférieur à 5minutes. Zéro bloqueur de sonar – Il est nécessaire pour pousser beaucoup de code en peu de temps. Couverture de code jusqu’à
% La taille de l’image doit être inférieure à 500 Mo pour l’application cloud nativeLa taille de l’image doit être inférieure à 100 Mo pour CNFLe temps d’application doit être inférieur à une minute – l’application devrait commencer dans moins d’une minute. Déploiement sans contact KPI de sécurité: Zéro vulnérabilité dans le code source de l’applicationExterne (bibliothèques tierces)Image de l’application KPI de mise à niveau et de version: Zéro temps d’arrêtMise à niveau transparente vers N-1 (la dernière version stable)Restaurations automatiques avec rétrocompatibilitéCycles de publication plus rapides KPI Open Source: Zéro verrouillage du fournisseur 50% Composants certifiés CNF KPI de la plateforme : Réparation automatique Mise à l’échelle automatiquePas de reconstruction d’image avec changement de configurationZéro perte de données avec plantage du pod KPI de suivi et de dépannage: Système en temps réel et un disponibilité des métriques d’application sur l’outil de surveillance central Alertes à générer en cas de dépassement de tout seuil (utilisation du processeur, réparation automatique, mise à l’échelle automatique, etc.) Sélectionnez le bon fournisseur de cloud et le bon rapport de mode La prochaine étape de la stratégie BSS on cloud consiste à sélectionner le bon fournisseur de cloud. Lors de la conception de cette partie de la stratégie, nous devons examiner notre type d’application pour nous assurer que le temps de service et l’expérience client final sont garantis.
Les clouds privés sont plus adaptés aux applications nécessitant :
Sessions critiques en temps réel (passerelle de paquets)Transactions à faible latence (facturation en ligne ) Les clouds publics sont mieux adaptés aux applications nécessitant:
Investissement basé sur les dépenses d’exploitationFace à une forte fluctuation de la demandeRedondance pour services critiques (DRM)Empreinte de stockage optimisée pour des avantages économiques plus élevésEssais / Pré-production, environnements UAT Les clouds hybrides sont mieux adaptés aux applications:
Cela peut fonctionner de manière stable sur des clouds privés et ne nécessite une mise à l’échelle que lors d’occasions spéciales. Par exemple : promotions, back up, DR Les clouds périphériques sont mieux adaptés aux applications:
Qui nécessitent une connectivité à très faible latence, la proximité avec le client est extrêmement critique La partie suivante concerne la sélection de la plate-forme. De nos jours, un logiciel cloud natif peut être installé sur n’importe quelle plate-forme cloud. Mais lorsque nous l’concevons correctement, nous sélectionnons en fait une partie des services de la plate-forme dans notre propre pile et d’autres dans le cloud public également.
Définir l’architecture avec le bon fournisseur L’architecture doit être adaptée pour permettre une expérience utilisateur cohérente à travers la configuration, l’approvisionnement, les opérations, l’administration et la gestion . Il est important de garder à l’esprit les utilisateurs opérationnels du système qui sont les utilisateurs quotidiens du système.
Principes à suivre:
Agilité commerciale: minimisation du TTM et du risque de lancement de nouveaux produits/services Engagez la bonne conception : exploitez des fonctionnalités flexibles par le cloud telles que la mise à l’échelle élastique )Sécurité dès la conception: par composant, par service et à l’échelle du systèmeRésilience par conception: parc automatique du système, mise à l’échelle automatique, charges de pointe/hors pointe Confidentialité dès la conception :-protection des données à travers la conception, la mise en œuvre et les opérations en cours Minimisation des coûts d’exploitation: grâce à l’activation de la pile de déploiement basée sur des règles Gouvernance Agile : Gestion centralisée. de produits/processus/équipes sur plusieurs marchés. L’architecture doit être telle qu’elle aide à prendre avantage de la plate-forme construite sur le cloud public et est continuellement mis à jour pour exploiter les innovations. En outre, le BSS devrait soutenir la régionalisation en termes de lois fiscales, de langues, etc.
Concevoir le bon modèle opérationnel Un modèle opérationnel est une seule vitre de contrôle. Les applications exécutées sur l’environnement virtualisé ainsi que sur le cloud public, le modèle d’exploitation doit permettre de les surveiller, de les gérer et de les exploiter de manière transparente.
Solution STL BSS
Comment STL a-t-il fait cela?
STL y est parvenu en suivant une piste CNCF adoption de la carte. Le 10 les points développés étaient :
Conteneurisation – C’était le point de départ. Docker a été complètement pris.CI/CD – Initialement, le pipeline CI/CD était dans VNF, puis il a été déplacé vers kubernetes.Orchestration et définition d’applicationKubernetesHelm – Déplacé de Helm V2 vers V3.Observabilité et analyse – ELK Prometheus & Grafana – Initialement pour les capacités du système d’exploitation, mais ensuite lentement déplacé vers la couche application également.Jaeger & Kiali – Pour les microservices, pour voir une traçabilité complète.Service Proxy, Discovery & Mesh – Là pour les microservices.Mise en réseau et politique (cas d’utilisation avancés) Base de données et stockage distribués – Les bases de données natives du cloud font partie intégrante. Streaming et messagerie – Choisir en fonction de la charge de la messagerie.Container Reg istry & Runtime – Il y a beaucoup d’aspects de conteneurs, donc un propre registre cloud natif a été mis en place. Distribution de logiciels Voie à suivre
Stockage natif cloud intégré aux applications utilisant ROBIN.ioMise en réseau cloud native intégrée aux applications utilisant FD.io Application intégrée de sécurité d’exécution native dans le cloud utilisant FALCON Mise en œuvre de la fédération de clusters à l’aide de KubeFed )Déploiement d’applications sur Edge à l’aide de Kube EdgeDéploiement d’applications automatisées à l’aide de GitOps avec une architecture sans serveur Cloud native AI ML – Déploiement du flux de travail d’apprentissage automatique sur le cloud à l’aide de Kube Flow Automatisation de plusieurs centres de données – à l’aide de ROBIN.io Gestion automatisée de l’infrastructure cloud – à l’aide de ROBIN .io Conclusion
Déplacement du BSS sur le cloud nécessite un processus de réflexion clair. La stratégie déployée doit couvrir les besoins de formation et de certification des personnes, la gestion et le déploiement de plateformes open source et en même temps, remédier aux vulnérabilités. Des points de contrôle doivent être intégrés dans le pipeline pour garantir que chaque ligne de code et même les bibliothèques externes sont exemptes de vulnérabilités. Ainsi, le succès de la transition dépend de l’infrastructure et des capacités de monétisation qui aideront à réaliser la véritable valeur du cloud BSS.
—————— —————————————————————————————————-
FAQ
Q. Quelle est la réduction du coût total de possession attendue?
La réduction du coût total de possession peut être attendue en passant au cloud dans la plage 05-33%. Mais cela dépend de certains facteurs tels que:
Combien de charges de travail vous déployez Qu’il s’agisse d’une stratégie hybride ou de cloud public completSi vous allez avoir reprise après sinistre Quel type de cycles de conservation envisagez-vousQuel type de composants de votre BSS prend en charge la mise à l’échelle et l’autoréparation automatiques L’ensemble dépend sur quel type d’applications vous mettez sur le cloud public.
Q. Dans quelle mesure est-il important d’avoir un portefeuille standardisé lorsque vous passez au cloud?
C’est fondamentalement l’aspect le plus critique lorsque nous parlons de cloud public car dans le cloud public, il s’agit d’avoir la même base logicielle et de la mettre à jour en permanence au fur et à mesure de sa provenance chez l’éditeur. La standardisation nous permet de faire plusieurs choses :
Intégration plus rapideMises à jour plus rapidesCréation de valeur plus rapide Pour les aspects TCO et accélération de la mise sur le marché, le noyau doit être standardisé et le reste des aspects doit être piloté par l’API.
1165511654
