Oubliez les enfants. Nous en avons besoin pour l’automatisation informatique.
Notre plus jeune a neuf ans (ET DEMI !) N'OUBLIEZ PAS LA MOITIÉ !) et il est actuellement passionné par les robots. Il ne s'agit pas seulement de jouer avec eux, mais de les programmer. Les deux parents étant titulaires de diplômes supérieurs en informatique, vous pouvez imaginer que nous sommes ravis et encourageants face à cette tendance particulière.
Alors bien sûr, les robots qui proposent des modèles de programmation faciles à apprendre sont une chose dans notre maison en ce moment. L’un des jouets de cet été était celui de Wonder Workshop , dont les robots peuvent être programmés via un langage de type « bloc ».
C’est la norme pour les enfants d’aujourd’hui. Cet enfant joue avec un certain nombre de « jeux » sur ses différents appareils, qui utilisent tous le même modèle de type « bloc » pour construire des programmes. Même son robot Lego Mindstorms Ev3 utilise un mécanisme similaire, où les constructions de programmation sont des blocs que vous connectez ensemble. Les variables et les conditions sont définies en les sélectionnant, et aucun « code » réel n'est affiché à l'écran.
Mais tu sais qu’il est là.
À l’époque où j’évaluais les solutions BPM (Business Process Management), elles utilisaient un paradigme similaire pour permettre aux parties prenantes de l’entreprise de définir des processus. Son interface reflétait la nature des processus, c'est-à-dire que vous construisiez un organigramme à l'aide d'un modèle glisser-déposer, mais une grande partie de la construction de l'orchestration était réalisée via une interface plus facile à apprendre. Comme ceux que mon plus jeune utilise aujourd'hui, seulement plus comme Visio. Beaucoup plus comme Visio maintenant que j'y pense.
Oubliez les enfants. C’est dans cette direction que l’automatisation informatique doit aller. Il n’y a aucune raison à la complexité inhérente à l’automatisation informatique d’aujourd’hui, si ce n’est que personne n’a encore reconnu que si nous voulons encourager davantage cette automatisation – et par des personnes qui ne sont pas naturellement des codeurs – nous devons trouver une meilleure façon de construire les flux de travail qui représentent les processus informatiques utilisés pour déployer, gérer et configurer l’infrastructure informatique.
La première chose sur laquelle nous devons nous mettre d’accord est que programmatique ne signifie pas nécessairement « vous pouvez faire tout ce que vous voulez parce que vous codez ». C'est vrai, dans le sens le plus libéral du terme, mais cela signifie également la capacité de modifier ou de définir le comportement par programmation. Il existe un ensemble limité d’actions requises pour exécuter un flux de travail dans l’informatique, et la plupart sont aujourd’hui rendues possibles par l’économie (autre) des API. En fournissant une interface qui encapsule cet ensemble limité d'actions et fournit des constructions logiques claires et faciles à comprendre (si/alors, pendant, fonctions itératives), nous pourrions apparemment éliminer la tendance vers les mécanismes de script non structurés qui introduisent beaucoup plus de dette technique dans les opérations informatiques que la plupart des logiciels développés dans les entreprises dans le passé. Ce niveau d’abstraction restreinte permettrait également aux codeurs non natifs (ingénieurs et architectes réseau et stockage) de produire des flux de travail bien construits et hautement maintenables (un moteur important de normalisation). Associé à une dorsale sans serveur pour exécuter les workflows , ce modèle réduit l’investissement requis pour créer, maintenir et exécuter des workflows adaptés aux opérations informatiques.
C’est important, car nous devons aborder l’automatisation informatique dans une optique de durabilité. Un script fonctionne très bien aujourd’hui, mais peut-il évoluer avec les personnes et les processus à l’avenir ?
Maintenant, nous n'avons peut-être pas besoin d'une solution aussi simple (ou colorée), mais la prémisse sur laquelle l'interface est conçue est importante, je pense, pour s'adapter alors que nous regardons vers l'avenir de l'automatisation informatique et la façon dont nous construisons (et maintenons) le code qui fera finalement fonctionner l'informatique. Malheureusement, nous avons tendance à transférer la complexité des systèmes sous-jacents à la conception des systèmes (et donc des interfaces) qui interagissent avec eux et les contrôlent. Nous voulons exposer tous les boutons et boutons possibles. Au minimum, un courtier API qui fournit un moyen d'agréger la complexité naturelle des API transformées en CLI en tâches opérationnelles plus compréhensibles serait une aubaine pour ceux qui sont chargés d'automatiser les réseaux informatiques et les services d'application. La connexion peut être un processus complexe comprenant plusieurs étapes qui se répètent à chaque fois. Les regrouper en un seul « service » les rend répétables et infiniment plus auditables en plus d’être cohérents. Combinez cela avec une interface (plus) intuitive et nous obtenons un gagnant en matière d’automatisation informatique.
Les interfaces des applications de « codage » pour enfants d'aujourd'hui prouvent qu'il est possible de le faire sans donner aux utilisateurs l'impression de regarder un ENIAC sans manuel pour les guider. Nous pouvons faire mieux, et si nous voulons étendre la transformation numérique interne pour suivre le rythme de l'entreprise, nous devons le faire.