Al introducir una nueva herramienta, lenguaje de programación o dependencia en su entorno, ¿qué pasos toma para evaluarlo? En este artículo, analizaré un marco de seis preguntas que utilizo para tomar estas determinaciones.
¿Qué problema estoy tratando de resolver?
Todos quedamos atrapados en las minucias del problema inmediato en cuestión. Una evaluación honesta y crítica ayuda a divulgar las causas principales más amplias y evita las microoptimizaciones.
[ También te puede interesar: Seis pasos de implementación para los servicios de Linux y sus herramientas relacionadas ]
Supongamos que tiene problemas con su sistema de gestión de configuración. Las tareas operativas diarias están tomando más tiempo del que deberían, y trabajar con el idioma es difícil. Un nuevo sistema de gestión de la configuración podría aliviar estas preocupaciones, pero asegúrese de analizar más ampliamente el contexto de este sistema. Tal vez cambiar de máquinas virtuales a contenedores inmutables alivie estos problemas y más en su entorno, al tiempo que representa una cantidad de trabajo equivalente. En este punto, también debe explorar la viabilidad de soluciones más integrales. Puede decidir que este no es un proyecto factible para la organización en este momento debido a la falta de conocimiento organizacional sobre los contenedores, pero aceptar concienzudamente esta compensación le permite poner los contenedores en una hoja de ruta para el próximo trimestre.
Este ejercicio intelectual lo ayuda a profundizar en las causas fundamentales y resolver los problemas fundamentales, no los síntomas de problemas mayores. Esto no siempre será posible, pero sea intencional al tomar esta decisión.
¿Esta herramienta soluciona ese problema?
Ahora que hemos identificado el problema, es hora de una evaluación crítica tanto de nosotros mismos como de la herramienta seleccionada.
Una tecnología en particular puede parecer atractiva porque es nueva porque lee una publicación de blog interesante sobre ella o quiere ser el que dé una charla en la conferencia. Las campanas y los silbatos pueden ser agradables, pero la herramienta debe resolver los problemas principales que identificó en la primera pregunta.
¿A qué estoy renunciando?
La herramienta, de hecho, resolverá el problema y sabemos que estamos resolviendo el correcto problema, pero ¿cuáles son las compensaciones?
Estas consideraciones pueden ser puramente técnicas. ¿La falta de herramientas de observabilidad impedirá una depuración eficiente en la producción? ¿La naturaleza de código cerrado de esta herramienta hace que sea más difícil rastrear errores sutiles? ¿Vale la pena administrar otra dependencia más por los beneficios operativos de usar esta herramienta?
Además, incluya los contextos organizacionales, comerciales y legales más amplios en los que opera.
¿Está cediendo el control de un flujo de trabajo comercial crítico a un proveedor externo? Si ese proveedor duplica el costo de su API, ¿es algo que su organización puede pagar y está dispuesta a aceptar? ¿Se siente cómodo con las herramientas de código cerrado que manejan un poco de información confidencial? ¿La licencia de software dificulta su uso comercial?
Si bien no son preguntas fáciles de responder, tomarse el tiempo para evaluar esto por adelantado le ahorrará mucho dolor más adelante.
¿Está el proyecto o proveedor en buen estado?
Esta pregunta viene con el apéndice "para el resto de sus necesidades". Si solo necesita una herramienta para que su equipo supere un obstáculo de cuatro a seis meses hasta el Proyecto X es completa, esta pregunta se vuelve menos importante. Si se trata de un compromiso de varios años y la herramienta impulsa un flujo de trabajo comercial crítico, esto es una preocupación.
Al pasar por este paso, haga uso de todos los recursos disponibles. Si la solución es de código abierto, revise el historial de confirmaciones, las listas de correo y las discusiones del foro sobre ese software. ¿Parece que la comunidad se comunica de manera efectiva y trabaja bien en conjunto, o existen divisiones obvias entre los miembros de la comunidad? Si parte de lo que está comprando es un contrato de soporte, use ese soporte durante la fase de prueba de concepto. ¿Está a la altura de sus expectativas? ¿Vale la pena el costo de la calidad del soporte?
Asegúrese de dar un paso más allá de las estrellas y bifurcaciones de GitHub al evaluar también las herramientas de código abierto. Algo puede aparecer en la página principal de un agregador de noticias y recibir atención durante unos días, pero una mirada más profunda puede revelar que solo un par de desarrolladores principales están trabajando en un proyecto y han tenido dificultades para encontrar contribuciones externas. Tal vez una herramienta sea de código abierto, pero un equipo financiado por la empresa impulsa el desarrollo central y es probable que el soporte cese si esa organización abandona el proyecto. Tal vez la API ha cambiado cada seis meses, causando mucho dolor a las personas que han adoptado versiones anteriores.
¿Cuáles son los riesgos?
Como tecnólogo, entiende que nada sale según lo planeado. Las redes se caen, las unidades fallan, los servidores se reinician, las filas en el centro de datos pierden energía, regiones enteras de AWS se vuelven inaccesibles o los secuestros de BGP redirigen cientos de terabytes de tráfico de Internet.
Pregúntese cómo podría fallar esta herramienta y cuál sería el impacto. Si está agregando un producto de proveedor de seguridad a su canalización de CI/CD, ¿qué sucede si el proveedor deja de funcionar?
Esto trae a colación consideraciones técnicas y comerciales. ¿Las canalizaciones de CI/CD simplemente se agotan porque no pueden comunicarse con el proveedor, o tiene un "error de apertura" y permite que la canalización se complete con una advertencia? Este es un problema técnico, pero en última instancia, una decisión empresarial. ¿Está dispuesto a pasar a producción con un cambio que ha pasado por alto el análisis de seguridad en este escenario?
Obviamente, esta tarea se vuelve más difícil a medida que aumentamos la complejidad del sistema. Afortunadamente, sitios como k8s.af consolidan escenarios de corte de ejemplo. Estas autopsias públicas son muy útiles para comprender cómo puede fallar una pieza de software y cómo planificar ese escenario.
¿Cuáles son los costos?
Las consideraciones principales aquí son el tiempo de los empleados y, si corresponde, el costo del proveedor. ¿Es esa aplicación SaaS más barata que más personal? Si ahorra a cada desarrollador del equipo dos horas al día con esa nueva herramienta de CI/CD, ¿se amortiza durante el próximo año fiscal?
Por supuesto, no todo tiene que ser una propuesta de ahorro de costos. Tal vez no sea neutral si le ahorra al equipo de desarrollo un par de horas al día, pero está eliminando un gran obstáculo en su flujo de trabajo diario, y estarían mucho más felices por eso. Es probable que esa felicidad valga el costo financiero. La incorporación de nuevos desarrolladores es costosa, así que no subestimes el valor de una mayor retención al hacer estos cálculos.
[ Una guía gratuita de Red Hat:5 pasos para automatizar su negocio. ]
Resumir
Espero que haya encontrado este marco útil y lo animo a que lo incorpore en sus propios procesos de toma de decisiones. No existe un marco único que funcione para todas las decisiones. No olvide que, a veces, es posible que deba seguir su instinto y tomar una decisión. Sin embargo, tener un proceso estandarizado como este ayudará a diferenciar entre aquellos momentos en los que puede analizar críticamente una decisión y cuando necesita dar ese salto.