A la poursuite du NoOps, ce rêve insaisissable
NoOps… Comment reprendre le contrôle de ses infrastructures et de ses opérations pour remonter la chaîne de valeur, interroge fort justement Deloitte.
Alors que l’IT est trop souvent considéré comme un centre de coûts, le NoOps offre la possibilité de réaffecter des talents issus des opérations à des tâches d’ingénierie et de développement. Mais existe-t-il, questionne Deloitte dans son Tech Trends 2019 ? N’est-ce pas… juste un leurre ?
Derrière le concept du NoOps se cache la démocratisation du DevOps où les opérations passent davantage de temps à accompagner les développeurs en amont pour construire des systèmes plus sécurisés, performants, résilients et hautement disponibles, explique Deloitte. Les développeurs jouissent d’une certaine autonomie pour opérer leurs infrastructures. AWS, Google ou Microsoft proposent sur leur plateforme des solutions packagées pour automatiser ces tâches. Néanmoins, le mouvement NoOps ne suscite pas toujours l’engouement des opérations IT qui y voient une menace pour l’emploi. Le CIO doit présenter cette transformation comme une opportunité. Durant la phase de transition, les opérations traditionnelles perdureront mais progressivement, le temps libéré permettra aux équipes d’étoffer leurs compétences pour se préparer à leur nouveau rôle aux côtés des développeurs. Le NoOps est l’opportunité de passer d’un mode d’opération réactif à un mode proactif.
Les limites du NoOps
Aussi attractif que soit le serverless, il faut avoir néanmoins conscience que ce type d’architecture n’est pas approprié à tout type d’usage, prévient Deloitte. Elle peut devenir un avantage considérable lorsqu’il s’agit de s’affranchir d’un coût fixe mensuel propre en passant à un coût à la transaction.
Récemment, Digital Ocean -fournisseur de services cloud- a interrogé 5 000 développeurs sur les difficultés rencontrées dans un environnement serverless. Les résultats sont intéressants : 27 % déclarent que la supervision et le debugging d’environnements serverless représentent un vrai défi. Au lieu de se connecter à un unique serveur, les opérateurs doivent en effet se connecter à une multitude de services. Heureusement, de nouveaux outils (service Mesh par exemple) sont en train de voir le jour pour adresser cette problématique.
Bien évaluer les coûts de sortie du serverless
Par ailleurs, 25 % craignent un risque de dépendance au fournisseur -le fameux Vendor Lock-in. Tout comme le PaaS, le serverless propose des solutions séduisantes, mais qui tendent vers le logiciel propriétaire. Les offres FaaS (Function-as-a-Service), proposées par de nombreux fournisseurs et consistant uniquement à exécuter du code sont moins concernées par ce phénomène de Lock-in. De même, les projets open source développés au-dessus de technologies containeurs également open source (Kubernetes) garantissent une certaine forme de portabilité. Cependant, les offres serverless émergentes étant nombreuses; il est nécessaire de bien évaluer les coûts de sortie associés pour mesurer les risques.
Migration. 16 % confirment qu’il n’est pas simple de transposer une application existante vers une architecture serverless. Cela nécessite très souvent de ré-architecturer entièrement l’application sur base de micro-services event-driven. Pendant des années, le maintien en condition opérationnelle des systèmes critiques de l’entreprise a représenté une part trop importante de leur budget. Aujourd’hui, les technologies cloud offrent la perspective du «NoOps» dans un monde serverless afin d’aligner davantage les opérations l’IT sur les attentes des métiers. Elles offrent aussi aux développeurs une opportunité de travailler de manière plus autonome.
Serverless : par où commencer ?
Tout comme le cloud de manière générale, les architectures serverless sont un changement de paradigme. Il ne s’agit pas de les voir comme un concurrent des architectures IaaS ou containeurs, mais plutôt comme un complément et de définir l’approche la plus pertinente pour chaque besoin applicatif. Le serverless se prête bien, entre autres, aux cas d’usages suivants
- Tâches planifiées : exécution de traitements nécessitant puissance de calcul, I/Os disques ou débits réseaux (ETL, traitements multimédias…);
- Traitement des données temps réel : traitement et/ou réponse temps réel à un flux de données continu (capteurs IoT, Analytics,
cybersécurité, etc.);
- Applications Web & API HTTP/REST : fourniture de back-ends dynamiquement scalables et sécurisés pour des applications
mobiles ou client lourd;
- Logique Métiers : orchestration des micro-services pour exécuter une suite d’étapes;
- Contrôle intégrité des données : audit automatique des données pour garantir un certain niveau de qualité dans les changements appliqués;
- Automatisation opérations IT & gestion des menaces cybersécurité : automatisation et auto-remédiation des activités d’exploitation IT. Comme pour les architectures micro-services, il ne faut pas sous-estimer la complexité des environnements serverless.
Ces articles parlent de "Cloud"
Private cloud, Public cloud, Hybrid cloud, Multi-cloud