Regresa

Infraestructura como código, automatización patentada de OEM y NetBrain

NB autor by Paul Campbell 22 de enero de 2019

Automatización, orquestación, DevOps, secuencias de comandos y más dominan mis feeds de redes sociales. La automatización es el acto de realizar tareas manuales de manera repetible con solo presionar un botón para lograr simplicidad, escalabilidad y mantenimiento de registros. Dependiendo de su OEM, hay muchas maneras de lograr esto, pero ¿cuál es la mejor para usted?

Infraestructura como código frente a automatización patentada
Lo que hemos visto hasta ahora es que los OEM siguen presentando sus propias formas individualistas de realizar su automatización. Luego, tiene enfoques agnósticos de OEM como Ansible, donde ve la infraestructura como código, independientemente del OEM. Con la infraestructura como código, ejecuta consultas específicas que se manejan adecuadamente según el OEM que se encuentre debajo. No hay nada intrínsecamente correcto o incorrecto en ninguno de los dos enfoques. Desde mi punto de vista, he visto un gran éxito con las herramientas de automatización OEM. He visto un éxito similar con enfoques de terceros para la infraestructura como código.

El objetivo de la automatización es ayudarlo a lograr un rendimiento variable hoy que produzca resultados exponenciales mañana.

Lo que falta en cualquiera de los métodos es un enfoque combinado. Creo que aquí es donde NetBrain destaca. ¿Es tan profundo como una instalación completa de Ansible Tower? No. Pero ese es el punto cuando hablamos de automatización. Con demasiada frecuencia escucho a la gente decir: "No puedes automatizar mi ¡mañana!"

¿Sabes qué? Suelen ser correctos. El objetivo de la automatización es ayudarlo a lograr un rendimiento variable hoy que produzca resultados exponenciales mañana.

 La automatización ofrece resultados finales, si la usa
Tome, por ejemplo, una hora de tiempo que se puede ahorrar por semana para "Bob" o "Cheryl" en su trabajo. No parece mucho al valor nominal. Sin embargo, 1 hora a la semana son 52 horas al año, o 1 semana y 1.5 días al año. ¿Qué pasa si el equipo de Bob y Cheryl tiene seis personas y este primer paso de automatización hace lo mismo para todos? La empresa ve 7 semanas y 2 días de productividad de vuelta. Esto fue solo una hora. ¿Y si hiciéramos dos, tres o cuatro horas por persona? Asombroso, y no tan fantasioso como la gente piensa.ahorro exponencial 2Con esto, digo, ¿por qué no invertir en algo que proporcione más valor que solo "automatización"? La infraestructura como código es excelente, pero ¿tiene personas que entiendan el código? Los enfoques específicos de OEM son geniales, pero ¿tiene el talento hoy para ejecutarlo? ¿O puede volver a capacitarlos para que estén actualizados?

El mismo argumento podría hacerse sobre NetBrain, y he estado en ambos lados: aprendiendo a usarlo y tratando de convencer a la gente para que lo adquiera. Cualquier nueva tecnología requiere capacitación adicional, aceleración y adopción. Creo que la diferencia es una fusión de alcance y facilidad de uso. Nadie adoptará una nueva tecnología si es más difícil de usar, independientemente de lo buena que sea. ¿Hay alguien todavía rockeando un Zune? No, lo dudo mucho. (Para el tipo en la parte de atrás, lo entiendo, te encanta). Pero como empresa, debemos mirar hacia el estándar que estamos estableciendo para nuestros individuos.

Automatización más allá de "Net New"
NetBrain la automatización le brinda la oportunidad de automatizar no solo el aprovisionamiento (gestión de cambios), sino también sus operaciones. La mayoría de las discusiones sobre automatización parecen centrarse en las implementaciones de "nuevas tecnologías" en comparación con lo que tiene hoy y cómo va a gestionar las "nuevas tecnologías" después de que se implementen. La mayoría de las veces, son equipos separados. Debemos tener cuidado de comprender los beneficios para ambos equipos, no solo para uno. Porque cuando hablamos de un ingeniero de desarrollo que ama la infraestructura como código y crea un canal de soporte para ella mientras que los ingenieros de soporte no la entienden, se está encontrando con un cuello de botella y un detrimento para su negocio.

Relacionado: