Retour

Infrastructure en tant que code, automatisation OEM propriétaire et NetBrain

by Paul Campbell Le 22 janvier 2019

Automatisation, orchestration, DevOps, les scripts et plus encore dominent mes flux de médias sociaux. L'automatisation consiste à effectuer des tâches manuelles de manière reproductible en appuyant simplement sur un bouton pour plus de simplicité, d'évolutivité et de tenue de registres. En fonction de votre OEM, il existe de nombreuses façons d'y parvenir, mais qu'est-ce qui vous convient le mieux ?

Infrastructure en tant que code vs automatisation propriétaire
Ce que nous avons vu jusqu'à présent, c'est que les équipementiers continuent de proposer leurs propres méthodes individualistes pour effectuer leur automatisation. Ensuite, vous avez des approches indépendantes des OEM comme Ansible, où vous visualisez l'infrastructure en tant que code, quel que soit l'OEM. Avec l'infrastructure en tant que code, vous exécutez des requêtes spécifiques qui sont gérées de manière appropriée en fonction de l'OEM en dessous. Il n'y a rien d'intrinsèquement bon ou mauvais dans l'une ou l'autre approche. De mon point de vue, j'ai connu un grand succès avec les outils d'automatisation OEM. J'ai constaté un succès similaire avec des approches tierces de l'infrastructure en tant que code.

Le but de l'automatisation est de vous aider à obtenir un rendement variable aujourd'hui qui donne des résultats exponentiels demain.

Ce qui manque à l'une ou l'autre méthode, c'est une approche mixte. Je crois que c'est là NetBrain se démarque. Cela va-t-il aussi loin qu'une installation Ansible Tower à part entière ? Non. Mais c'est le point lorsque nous parlons d'automatisation. Trop souvent, j'entends des gens dire : « Vous ne pouvez pas automatiser mon demain!"

Savoir quoi ? Ils ont généralement raison. Le but de l'automatisation est de vous aider à obtenir un rendement variable aujourd'hui qui donne des résultats exponentiels demain.

 L'automatisation fournit des résultats nets - si vous l'utilisez
Prenez, par exemple, une heure de temps qui peut être économisée par semaine pour « Bob » ou « Cheryl » à leur travail. Cela ne semble pas beaucoup à sa valeur nominale. Cependant, 1 heure par semaine, c'est 52 heures par an, soit 1 semaine et 1.5 jour par an. Et si l'équipe de Bob et Cheryl comptait six personnes et que cette première étape d'automatisation faisait la même chose pour tout le monde ? L'entreprise voit 7 semaines et 2 jours de productivité revenir. C'était juste une heure. Et si on faisait deux, trois ou quatre heures par personne ? Stupéfiant, et pas autant un fantasme que les gens le pensent.économies exponentielles 2Avec cela, je dis pourquoi ne pas investir dans quelque chose qui apportera plus de valeur qu'une simple « automatisation » ? L'infrastructure en tant que code est formidable, mais avez-vous des personnes qui comprennent le code ? Les approches spécifiques aux OEM sont excellentes, mais avez-vous le talent aujourd'hui pour les exécuter ? Ou pouvez-vous les recycler pour être à jour ?

Le même argument pourrait être avancé à propos de NetBrain, et j'ai été des deux côtés : apprendre à l'utiliser et essayer de convaincre les gens de l'acquérir. Toute nouvelle technologie nécessite une formation, une montée en puissance et une adoption supplémentaires. Je crois que la différence est un fusion de la portée et de la facilité d'utilisation. Personne n'adoptera une nouvelle technologie si elle est plus difficile à utiliser, quelle que soit sa qualité. Est-ce que quelqu'un balance encore un Zune? Non, j'en doute fortement. (Pour le gars à l'arrière, je comprends - vous l'adorez.) Mais en tant qu'entreprise, nous devons regarder vers la barre que nous fixons pour nos individus.

Automatisation au-delà du "Net New"
NetBrain l'automatisation vous offre la possibilité d'automatiser non seulement le provisionnement (change management) mais aussi vos opérations. La plupart des discussions autour de l'automatisation semblent être centrées sur les déploiements « net new » par rapport à ce que vous avez aujourd'hui et sur la façon dont vous allez gérer le « net new » après sa mise en œuvre. Le plus souvent, ce sont des équipes distinctes. Nous devons prendre soin de comprendre les avantages pour les deux équipes, pas seulement une. Car lorsque nous parlons d'un ingénieur de développement qui aime l'infrastructure en tant que code et construit un canal de support pour cela alors que les ingénieurs de support ne le comprennent pas, vous rencontrez un goulot d'étranglement et un préjudice pour votre entreprise.

See NetBrainAutomatisation adaptative du réseau en 2 minutes

Services Connexes