Smashing Podcast Episodio 42 con Jeff Smith: ¿Qué es DevOps?

En este episodio, estamos hablando de DevOps. ¿Qué es, y es una cadena para agregar a su arco de desarrollo web? Drew McLellan habla con el experto Jeff Smith para averiguarlo.

Mostrar notas

• Jeff en Twitter
• Libro de Jeff Operations Anti-Patterns, DevOps Solutions
• DevOps alcanzables

Actualización semanal

• Cerrando la brecha entre diseñadores y desarrolladores escrito por Matthew Talebi
• API útiles de React para crear componentes flexibles con TypeScript escrito por Gaurav Khanna
• Soluciones inteligentes de CSS para desafíos comunes de interfaz de usuario escrito por Cosima Mielke
• Consejos y trucos para evaluar diseñadores de UX/UI escritos por Nataliya Sambir
• Solución de problemas de CLS en un sitio web de comercio electrónico impulsado por Next.js escrito por Arijit Mondal

Transcripción

Drew McLellan: es un profesional de DevOps que se enfoca en los niveles alcanzables de implementaciones de DevOps, independientemente de dónde se encuentre en su viaje. Es director de operaciones de producción en la plataforma de publicidad digital Centro, además de ser un orador público, compartiendo su conocimiento de DevOps con audiencias de todo el mundo. Es el autor del libro Operations Anti-Patterns, DevOps Solutions para Manning Publishing, que muestra cómo implementar técnicas de DevOps en el tipo de entornos imperfectos en los que trabaja la mayoría de los desarrolladores. ¿Clooney lo considera el mejor fabricante de aviones de papel de una generación? Mis amigos de Smashing, denle la bienvenida a Jeff Smith. Hola Jeff. ¿Cómo estás?

Jeff Smith: Estoy genial, Drew, ¿cómo estás?

Drew: Estoy bien. Gracias. Eso es bueno escuchar. Así que quería hablarles hoy sobre el tema de DevOps, que es una de sus principales áreas clave. Muchos de nuestros oyentes estarán involucrados en el desarrollo web y de aplicaciones, pero tal vez solo tengan una cierta familiaridad con lo que sucede en el lado operativo de las cosas. Sé que aquellos de nosotros que podríamos trabajar en empresas más grandes tendremos equipos completos de colegas que están haciendo operaciones. Estamos agradecidos de que sea lo que sea que hagan, lo están haciendo bien. Pero escuchamos que DevOps se menciona cada vez más, y se siente como una de esas cosas que, como desarrolladores, realmente deberíamos entender. Entonces, Jeff, ¿qué es DevOps?

Jeff: Entonces, si le preguntas a 20 personas qué es DevOps, es posible que obtengas 20 respuestas diferentes. Así que te daré mi opinión, está bien, y debes saber que si estás en una conferencia y mencionas esto, podrías pelear a puñetazos con alguien. Pero para mí, DevOps se trata realmente de esa relación entre, y nos enfocamos en desarrollo y operaciones, pero realmente esa relación entre equipos y cómo estructuramos nuestro trabajo y, lo que es más importante, estructuramos nuestras metas e incentivos para asegurarnos de que sean alineados para que estemos trabajando hacia un objetivo común. Y muchas de las ideas y conceptos centrales de DevOps provienen del viejo mundo donde el desarrollo y las operaciones siempre fueron antagónicos, donde había un conflicto constante. Y cuando lo piensas, es por la forma en que se incentivan esos dos equipos. Se incentiva a un equipo para impulsar los cambios. Otro equipo tiene incentivos para mantener la estabilidad, lo que significa menos cambios.

Jeff: Cuando haces eso, creas este conflicto inherente y todo se derrama a partir de ahí. Entonces, DevOps se trata realmente de alinear esos equipos y objetivos para que estemos trabajando hacia una estrategia común, pero también adoptando prácticas de ambos lados, para que el desarrollador entienda más sobre las operaciones y las operaciones entiendan más sobre el desarrollo, como una forma de ganar y compartir. empatía entre nosotros para que entendamos la perspectiva de dónde viene la otra persona.

Jeff: Pero también para mejorar nuestro trabajo. Porque nuevamente, si entiendo su perspectiva y la tomo en cuenta en mi trabajo, será mucho más beneficioso para cada uno de nosotros. Y hay mucho que las operaciones pueden aprender de los desarrolladores en términos de automatización y cómo abordamos las cosas para que sean fácilmente reproducibles. Así que es esta mezcla y habilidades. Y lo que está viendo ahora es que esto se aplica a diferentes combinaciones de grupos, por lo que está escuchando cosas como DevSecOps, DevSecFinOps, DevSecFinHROps. Simplemente va a seguir creciendo y creciendo y creciendo. Así que es realmente una lección que podemos acabar con toda la organización.

Drew: Es tomar algunos de los conceptos que entendemos como desarrolladores y difundir nuestras ideas más en la organización y, al mismo tiempo, aprender lo que podamos de las operaciones para tratar de hacer avanzar a todos.

Jeff: Absolutamente, sí. Y otro aspecto de las operaciones, y lo mencionaste un poco en la introducción, creemos que es solo para estas organizaciones más grandes con equipos de operaciones dedicados y cosas así, pero una cosa en la que pensar es que las operaciones están sucediendo en su organización, independientemente del tamaño. Es solo una cuestión de si lo hace usted, o si hay un equipo separado que lo hace, pero de alguna manera está implementando el código. De alguna manera tienes un servidor funcionando en alguna parte. Por lo tanto, las operaciones existen en algún lugar de su organización, independientemente del tamaño. La pregunta es, ¿quién lo está haciendo? Y si se trata de una sola persona o un solo grupo, entonces DevOps podría ser aún más importante para usted, ya que necesita comprender los tipos de cosas que hacen las operaciones.

Drew: Como desarrolladores profesionales, ¿qué tan importante cree que es para nosotros comprender bien qué es DevOps y qué significa implementar?

Jeff: Creo que es muy importante, especialmente en esta fase del viaje de DevOps. Y la razón por la que creo que es importante es que, una vez más, creo que siempre somos más eficientes cuando entendemos lo que hacen nuestros homólogos. Pero la otra cosa es poder tener en cuenta las preocupaciones operativas durante el desarrollo del diseño y la implementación de cualquier tecnología. Así que una cosa que he aprendido en mi carrera es que aunque pensaba que los desarrolladores eran los amos del universo y entendían todo lo que tenía que ver con las computadoras, resulta que ese no es el caso. Resulta que hay muchas cosas que subcontratan a operaciones en términos de comprensión y, a veces, eso da como resultado opciones de diseño particulares o opciones de implementación que pueden no ser óptimas para una implementación de producción.

Jeff: Pueden estar bien en el desarrollo y las pruebas y cosas así, pero una vez que llegas a la producción, es un juego de pelota un poco diferente. Así que no quiere decir que necesitan poseer todo ese conjunto de conocimientos, pero al menos necesitan saber lo suficiente para saber lo que no saben. Entonces saben cuándo involucrar a las operaciones temprano, porque ese es un patrón común que vemos cuando el desarrollo toma una decisión. Ni siquiera diré que tomes una decisión porque ni siquiera son conscientes de que es una elección, pero sucede algo que conduce a una decisión subóptima para las operaciones y el desarrollo no estaba completamente al tanto. Entonces, tener un poco más de conocimiento sobre las operaciones, incluso si es suficiente para decir, tal vez deberíamos incorporar a las operaciones en esto para obtener su perspectiva antes de seguir adelante. Eso podría ahorrar mucho tiempo, energía y estabilidad, obviamente, en lo que respecta a cualquier producto que esté lanzando.

Drew: Veo tantos paralelismos con la forma en que hablas de la relación entre desarrollo y operaciones como la que tenemos entre diseño y desarrollo, donde tienes diseñadores trabajando en cómo funciona y se ve una interfaz y teniendo una buena comprensión. de cómo se construirá realmente en el rol de desarrollo, y llevar a los desarrolladores a consultar realmente puede mejorar la solución general solo con una comunicación clara y una comprensión de lo que hacen los demás. Parece que es el mismo principio que se desarrolla con DevOps, lo cual es muy, muy bueno de escuchar.

Drew: Cuando pienso en las cosas que escucho sobre DevOps, escucho términos como Kubernetes, Docker, Jenkins, CircleCI. He oído hablar de Kubernetes durante años. Todavía no tengo idea de qué es, pero por lo que dices, parece que DevOps no se trata solo de... No estamos hablando solo de herramientas, ¿verdad? Pero más sobre procesos y formas de comunicarse en flujos de trabajo, ¿es así?

Jeff: Absolutamente. Así que mi mantra durante los últimos 20 años siempre ha sido las herramientas de proceso de personas. Consigues que la gente compre la visión. A partir de ahí, define cómo será su proceso para lograr esa visión. Y luego trae herramientas que modelarán cualquiera que sea su proceso. Así que siempre pongo las herramientas al final de la conversación de DevOps, principalmente porque si no tienes esa aceptación, entonces no importa. Podría pensar en la mejor canalización de implementación continua que haya existido, pero si a las personas no les convence la idea de enviar cada cambio directamente a producción, no importa, ¿verdad? ¿De qué sirve la herramienta? Esas herramientas definitivamente son parte de la conversación, solo porque son una forma estandarizada de cumplir con algunos objetivos comunes que hemos definido.

Jeff: Pero debe asegurarse de que los objetivos que se definen tengan sentido para su organización. Tal vez la implementación continua no tenga sentido para usted. Tal vez no quiera enviar cada cambio en el momento en que sale. Y hay muchas empresas y organizaciones y razones por las que no querrías hacer eso. Entonces, tal vez algo como una canalización de implementación continua no tenga sentido para usted. Entonces, si bien las herramientas son importantes, es más importante centrarse en lo que va a generar valor para su organización y luego modelar e implementar las herramientas necesarias para lograrlo.

Jeff: Pero no se conecte en línea y averigüe lo que todos están haciendo y diga, oh, bueno, si vamos a hacer DevOps, tenemos que cambiar a Docker y Kubernetes porque esa es la cadena de herramientas. No eso no es. Puede que no necesites esas cosas. No todo el mundo es Google. No todo el mundo es Netflix. Deja de leer publicaciones de Netflix y Google. Por favor, deja de leerlos. Porque emociona a la gente y dicen, bueno, esto es lo que tenemos que hacer. Y es como, bueno, están resolviendo problemas muy diferentes a los problemas que tú tienes.

Drew: Entonces, si digo que estoy comenzando un nuevo proyecto, tal vez sea un negocio nuevo, creando software como un producto de servicio. Tengo tres desarrolladores, tengo un repositorio de Git vacío y tengo sueños de OPI. Para estar totalmente involucrado en un enfoque DevOps para construir este producto, ¿cuáles son los nombres de los componentes básicos que debo tener en términos de personas y procesos y por dónde empiezo?

Jeff: Entonces, en tu ejemplo específico, el primer lugar con el que comenzaría es aprovechar la mayor parte tanto como sea posible y usar algo como Heroku o algo por el estilo. Porque te emocionas mucho con todas estas cosas de AWS, Docker y, en realidad, es muy difícil crear un producto exitoso. La idea de que te estás enfocando en la parte de DevOps es como, bueno, diría que externalices la mayor cantidad posible de esas cosas hasta que realmente se convierta en un punto crítico. Pero si está en ese punto en el que dice que está bien, estamos listos para tomar estas cosas internamente y estamos listos para llevarlo al siguiente nivel. Diría que el primer lugar para comenzar es, ¿dónde están tus puntos débiles? ¿Cuáles son las cosas que te están causando problemas?

Jeff: Entonces, para algunas personas es tan simple como las pruebas automatizadas. La idea de que necesitamos ejecutar pruebas cada vez que alguien realiza una confirmación, porque a veces enviamos cosas que quedan atrapadas en las pruebas unitarias que ya hemos escrito. Entonces, tal vez empieces con la integración continua. Tal vez sus implementaciones tarden horas en completarse y son muy manuales, entonces ahí es donde se enfoca y dice, está bien, ¿qué automatización necesitamos para poder hacer esto con un solo clic? Pero odio prescribir un general, aquí es donde comienzas, solo porque tu situación particular y tus puntos de dolor particulares serán diferentes. Y la cuestión es que, si es un punto doloroso, debería estar gritándote. Debería estar absolutamente gritándote.

Jeff: Debería ser una de esas cosas en las que alguien dice, oh, ¿qué apesta en tu organización? Y debería ser como, oh, sé exactamente qué es eso. Entonces, cuando lo aborda desde esa perspectiva, creo que los próximos pasos se vuelven bastante evidentes para usted en términos de lo que necesita desempaquetar en la caja de herramientas de DevOps y comenzar a trabajar. Y luego se convierten en estos cambios incrementales mínimos que siguen llegando y te das cuenta de que a medida que obtienes nuevas capacidades, tu apetito por las cosas de calidad inferior se vuelve muy pequeño. Entonces pasas de, oh sí, las implementaciones toman tres horas y está bien. Le pones un poco de esfuerzo y lo siguiente que sabes, en tres semanas, es como, hombre, no puedo creer que la implementación todavía esté tomando 30 minutos. ¿Cómo bajamos esto de 30 minutos? Tu apetito se vuelve insaciable por mejorar. Así que las cosas simplemente se derraman a partir de ahí.

Drew: He estado leyendo su libro reciente y destaca lo que llama los cuatro pilares de DevOps. Y ninguno de ellos son herramientas, como se mencionó, pero existen estas cuatro áreas principales de enfoque, por así decirlo, para DevOps. Me di cuenta de que el primero de ellos es la cultura, me sorprendió bastante, en primer lugar, porque esperaba que hablaras más sobre herramientas y ahora entendemos por qué, pero cuando se trata de cultura, parece algo extraño. cosa a tener al principio. Hay una base para un enfoque técnico. ¿Cómo afecta la cultura el éxito de la implementación de DevOps dentro de una organización?

Drew: … qué tan exitosa puede ser la implementación de DevOps dentro de una organización.

Jeff: La cultura es realmente la base de todo cuando lo piensas. Y es importante porque la cultura, y profundizamos un poco más en esto en el libro, pero la cultura realmente sienta las bases para las normas dentro de la organización. Derecha. Probablemente haya estado en una empresa donde, si envió una PR sin pruebas automatizadas, eso no es gran cosa. La gente lo acepta y sigue adelante.

Jeff: Pero luego hay otras organizaciones donde eso es un pecado capital. Derecha. Donde si has hecho eso, es como, “Vaya, ¿estás loco? ¿Qué estás haciendo? Aquí no hay casos de prueba”. Derecha. Aunque eso es cultura. Esa es la cultura que hace cumplir esa norma para decir: "Esto no es lo que hacemos".

Jeff: Cualquiera puede escribir un documento que diga que tendremos casos de prueba automatizados, pero la cultura de la organización es lo que hace cumplir ese mecanismo entre las personas. Ese es solo un pequeño ejemplo de por qué la cultura es tan importante. Si tienes una organización donde la cultura es una cultura de miedo, una cultura de retribución. Es como si te equivocas, verdad, eso es un sacrilegio. Derecha. Eso equivale a traición. Derecha.

Jeff: Creas comportamientos en esa organización que son adversos a cualquier cosa que pueda ser riesgosa o potencialmente fallida. Y eso termina dejando muchas oportunidades sobre la mesa. Mientras que si crea una cultura que acepta aprender del fracaso, acepta esta idea de seguridad psicológica, donde las personas pueden experimentar. Y si se equivocan, pueden descubrir cómo fallar de manera segura e intentarlo de nuevo. Obtienes una cultura de experimentación. Obtienes una organización donde las personas están abiertas a nuevas ideas.

Jeff: Creo que todos hemos estado en esas empresas donde es como, “Bueno, así es como se hace. Y nadie cambia eso”. Derecha. No quieres eso porque el mundo está cambiando constantemente. Es por eso que ponemos la cultura al frente y al centro, porque muchos de los comportamientos dentro de una organización existen debido a la cultura que existe.

Jeff: Y es que los actores culturales pueden ser para bien o para mal. Derecha. Lo irónico, y también hablamos de esto en el libro, es que no se necesita tanta gente como crees para cambiar la cultura organizacional. Derecha. Porque la mayoría de la gente, hay detractores, y luego hay simpatizantes, y luego hay indiferentes cuando se trata de cualquier tipo de cambio. Y la mayoría de las personas son cuidadores de vallas. Derecha. Solo se necesita un puñado de seguidores para inclinar realmente la balanza. Pero en el mismo sentido, realmente solo se necesita un puñado de detractores para inclinar la balanza.

Jeff: Es como, no se necesita mucho para cambiar la cultura para mejor. Y si le pones esa energía, incluso sin ser un líder sénior, realmente puedes influir en la cultura de tu equipo, que luego termina influyendo en la cultura de tu departamento, que luego termina influyendo en la cultura de la organización.

Jeff: Puede realizar estos cambios culturales como colaborador individual, simplemente defendiendo estas ideas y estos comportamientos en voz alta y diciendo: "Estos son los beneficios que estamos obteniendo de esto". Es por eso que creo que la cultura tiene que estar al frente porque tienes que hacer que todos acepten esta idea y tienen que entender que, como organización, valdrá la pena y la apoyarán.

Drew: Sí. Tiene que ser una forma de vida, supongo.

Jef: Exacto.

Drew: Sí. Estoy realmente interesado en el área de la automatización porque a lo largo de mi carrera, nunca he visto alguna automatización que se haya implementado que no haya sido beneficiosa. Derecha. Quiero decir, aparte de la cosa extraña, tal vez donde algo está automatizado y sale mal. En general, cuando se toma el tiempo para sentarse y automatizar algo que ha estado haciendo manualmente, siempre le ahorra tiempo y le ahorra espacio mental, y es solo un peso de encima.

Drew: Al adoptar un enfoque de DevOps, ¿qué tipo de cosas buscaría automatizar dentro de sus flujos de trabajo? ¿Y qué ganancias esperaría ver de eso sobre completar las cosas manualmente?

Jeff: Cuando se trata de automatización, a su punto, muy rara vez hay un momento en que la automatización no haya mejorado la vida. Derecha. El problema que encuentran las personas es encontrar el tiempo para construir esa automatización. Derecha. Y, por lo general, en mi trabajo actual, para nosotros es en realidad el objetivo de la solicitud. Derecha. Porque en algún momento tienes que decir: “Voy a dejar de hacer esto manualmente y lo voy a automatizar”.

Jeff: Y puede que tenga que ser el momento en que recibes una solicitud en la que dices: “¿Sabes qué? Esto va a tomar dos semanas. Sé que normalmente lo solucionamos en un par de horas, pero tomará dos semanas porque esta es la solicitud que se automatiza”. En términos de identificar lo que automatizas. En Central, uso el proceso en el que, básicamente, probaría todos los diferentes tipos de solicitudes que llegaron durante un período de cuatro semanas, digamos. Y los categorizaría como trabajo planificado, trabajo no planificado, trabajo de valor agregado, trabajo duro. El esfuerzo es un trabajo que no es realmente útil, pero por alguna razón, mi organización tiene que hacerlo.

Jeff: Y luego identificar esas cosas que son como, "Bien, ¿cuál es la fruta madura de la que podemos deshacernos si tuviéramos que automatizar esto? ¿Qué podemos hacer para simplificar esto?” Y algunos de los criterios era el riesgo del proceso. Derecha. Las conmutaciones por error automatizadas de la base de datos dan un poco de miedo porque no se realizan con tanta frecuencia. Y los cambios de infraestructura. Derecha. Decimos: "¿Con qué frecuencia estamos haciendo esto?" Si lo hacemos una vez al año, puede que no valga la pena automatizarlo porque tiene muy poco valor. Pero si es una de esas cosas que recibimos dos o tres veces al mes, está bien, echemos un vistazo a eso. Todo bien.

Jeff: Ahora, ¿cuáles son las cosas que podemos hacer para acelerar esto? Y la cuestión es que, cuando hablamos de automatización, instantáneamente saltamos a: "Voy a hacer clic en un botón y esto se hará mágicamente". Derecha. Pero hay tantos pasos diferentes que puede hacer en la automatización si se siente mareado. Derecha. Por ejemplo, supongamos que tiene 10 pasos con 10 comandos CLI diferentes que normalmente ejecutaría. Su primer paso de automatización podría ser tan simple como ejecutar ese comando o al menos mostrar ese comando. Derecha. Diga, “Oye, esto es lo que voy a ejecutar. ¿Crees que está bien?” "Sí." "Okey. Este es el resultado que obtuve. ¿Está bien que continúe?” "Sí." "Okey. Este es el resultado que obtuve”. Derecha.

Jeff: De esa manera todavía tienes un poco de control. Te sientes cómodo. Y luego, después de 20 ejecuciones, te das cuenta de que solo estás golpeando, sí, sí, sí, sí, sí, sí. Tú dices: “Está bien. Encadenemos todas estas cosas juntas y hagamos que todo sea uno”. No es como si tuvieras que saltar al fondo, hacer clic y olvidarlo de inmediato. Puedes entrar en esto hasta que te sientas cómodo.

Jeff: Ese es el tipo de cosas que hicimos como parte de nuestro esfuerzo de automatización, simplemente, ¿cómo aceleramos el tiempo de respuesta de esto y reducimos el nivel de esfuerzo de nuestra parte? Puede que no esté al 100 % el primer día, pero el objetivo siempre es llegar al 100 %. Comenzaremos con pequeños fragmentos que automatizaremos en partes con las que nos sintamos cómodos. Si. Estamos muy seguros de que esto va a funcionar. Esta parte es un poco incierta, así que tal vez obtengamos una verificación humana antes de continuar.

Jeff: La otra cosa que vimos en términos de que hablamos de automatización, pero ¿qué valor estamos agregando a un proceso en particular? Y esto es particularmente importante para las operaciones. Porque muchas veces ops sirve como intermediario de un proceso. Entonces su participación no es más que algo de acceso. Derecha. Es como, bueno, ops tiene que hacerlo porque ops es la única persona que tiene acceso.

Jeff: Bueno, es como, bueno, ¿cómo subcontratamos ese acceso para que la gente pueda hacerlo? Porque la realidad es que no nos preocupa que los desarrolladores tengan acceso a la producción. Derecha. Nos preocupa que los desarrolladores tengan acceso ilimitado a la producción. Y eso es realmente una cuestión de seguridad. Derecha. Es como si mi caja de herramientas solo tuviera cuchillos afilados, voy a tener mucho cuidado con quién se lo doy. Pero si puedo mezclar la caja de herramientas con una cuchara y un martillo para que la gente pueda elegir la herramienta adecuada para el trabajo, entonces es mucho más fácil prestarla.

Jeff: Por ejemplo, teníamos un proceso en el que la gente necesitaba ejecutar scripts de Ruby ad hoc en producción, por cualquier motivo. Derecha. Necesita limpiar datos, necesita corregir algún registro incorrecto, lo que sea. Y eso siempre vendría a través de mi equipo. Y es como, bueno, no estamos agregando ningún valor a esto porque no puedo aprobar este boleto. Derecha. No tengo ni idea. Escribiste el software, entonces, ¿de qué sirve que me siente sobre tu hombro y diga: "Bueno, creo que eso es seguro"? Derecha. No agregué ningún valor al escribirlo porque solo estoy escribiendo exactamente lo que me dijiste que escribiera. Derecha.

Jeff: Y en el peor de los casos, y al final, en realidad solo soy un obstáculo para ti porque envías una multa y luego esperas a que regrese del almuerzo. Regresé del almuerzo, pero tengo otras cosas en las que trabajar. Dijimos: "¿Cómo automatizamos esto para que podamos ponerlo en manos de los desarrolladores y al mismo tiempo abordar cualquiera de estas preocupaciones de auditoría que podamos tener?"

Jeff: Lo pusimos en un flujo de trabajo de JIRA, donde teníamos un bot que automatizaría la ejecución de los comandos especificados en el ticket de JIRA. Y luego podríamos especificar en el ticket de JIRA que requería la aprobación de uno de varios ingenieros senior. Derecha.

Jeff: Tiene más sentido que un ingeniero apruebe el trabajo de otro ingeniero porque tienen el contexto. Derecha. No tienen que quedarse sentados esperando operaciones. La pieza de auditoría se responde porque tenemos un flujo de trabajo claro que se ha definido en JIRA que se está documentando a medida que alguien lo aprueba, como alguien lo solicita. Y tenemos automatización que tira de ese comando y ejecuta ese comando palabra por palabra en la terminal. Derecha.

Jeff: No tienes que preocuparte de que lo escriba mal. No tienes que preocuparte de que tome el boleto equivocado. Eso incrementó el tiempo de entrega de esos boletos, algo así como diez veces. Derecha. Los desarrolladores están desbloqueados. Mi equipo no está ocupado haciendo esto. Y todo lo que realmente tomó fue una inversión de una o dos semanas para desarrollar la automatización y los permisos necesarios para que tuvieran acceso a ella.

Jeff: Ahora estamos completamente alejados de eso. Y el desarrollo en realidad puede subcontratar parte de esa funcionalidad a partes inferiores de la organización. Lo han empujado a la atención al cliente. Es como ahora que atención al cliente sabe que este registro necesita ser actualizado para lo que sea, no necesitan desarrollo. Pueden enviar su secuencia de comandos estándar que hemos aprobado para esta función. Y pueden ejecutarlo exactamente con el mismo flujo de trabajo que el desarrollo. Es realmente una bendición por todas partes.

Jeff: Y luego nos permite empujar el trabajo más y más bajo en toda la organización. Porque a medida que hacemos eso, el trabajo se vuelve cada vez más barato porque podría tener un desarrollador elegante y costoso ejecutando esto. Derecha. O puedo hacer que una persona de atención al cliente que trabaje directamente con el cliente lo ejecute él mismo mientras está hablando por teléfono con un cliente para corregir un problema.

Jeff: Creo que la automatización es clave para cualquier organización. Y el punto final que diré es que también te permite exportar experiencia. Derecha. Ahora, puedo ser la única persona que sabe cómo hacer esto si necesito hacer un montón de comandos en la línea de comandos. Pero si pongo esto en automatización, puedo dárselo a cualquiera. Y la gente sabe cuál es el resultado final, pero no necesita conocer todos los pasos intermedios. He multiplicado por diez mi valor llevándolo a la organización y tomando mi experiencia y codificándola en algo que es exportable.

Drew: Usted habló sobre la automatización de tareas que ocurren con frecuencia. ¿Hay algún argumento para automatizar también las tareas que ocurren con tan poca frecuencia que al desarrollador le lleva bastante tiempo volver a ponerse al día con la forma en que debería funcionar? Porque todo el mundo se ha olvidado. Ha sido tan largo. Ha pasado un año, tal vez nadie lo haya hecho antes. ¿Hay algún argumento para automatizar ese tipo de cosas también?

Jeff: Ese es un acto de equilibrio difícil. Derecha. Y siempre digo que lo tomen caso por caso. Y la razón por la que digo eso es que uno de los mantras en DevOps es si algo te duele, hazlo con más frecuencia. Derecha. Porque cuanto más a menudo lo haces, más memoria muscular se vuelve y puedes ejercitarte y solucionar esos problemas.

Jeff: El problema que vemos con la automatización de tareas muy poco frecuentes es que el panorama del entorno tiende a cambiar entre las ejecuciones de esa automatización. Derecha. Lo que termina sucediendo es que su código hace suposiciones particulares sobre el entorno y esas suposiciones ya no son válidas. Entonces la automatización termina rompiéndose de todos modos.

Drew: Y entonces tienes dos problemas.

Jef: Correcto. Derecha. Exactamente. Exactamente. Y dices: “¿Lo escribí mal? ¿O es esto? No, esta cosa en realidad está rota. Entonces-

Jeff: Escribir mal o esto es no, esta cosa en realidad está rota. Entonces, cuando se trata de automatizar tareas poco frecuentes, realmente lo tomamos caso por caso para comprender, bueno, cuál es el riesgo si esto no funciona, ¿verdad? Si nos equivocamos, ¿estamos en mal estado o es que no hemos terminado esta tarea? Entonces, si puede asegurarse de que esto fallará con gracia y no tendrá un impacto negativo, entonces vale la pena intentar automatizarlo. Porque al menos, tienes un marco de comprensión de lo que debería estar pasando porque, al menos, alguien podrá leer el código y entender, está bien, esto es lo que estábamos haciendo. Y no entiendo por qué esto ya no funciona, pero tengo una comprensión clara de lo que se suponía que sucedería al menos en el momento del diseño cuando se escribió esto.

Jeff: Pero si alguna vez te encuentras en una situación en la que una falla podría generar cambios en los datos o algo por el estilo, generalmente me equivoco por el lado de la precaución y lo mantengo manual solo porque si tengo un script de automatización, si encuentro algún documento de confluencia. que tiene tres años que dice ejecutar este script, tiendo a tener un cien por ciento de confianza en ese script y lo ejecuto. Derecha. Mientras que si se trata de una serie de pasos manuales que se documentaron hace cuatro años, voy a pensar que necesito hacer una verificación aquí. ¿Derecha? Permítanme analizar esto un poco y hablar con algunas personas. Y a veces, cuando diseñamos procesos, vale la pena forzar ese proceso de pensamiento, ¿no? Y hay que pensar en el componente humano y en cómo se van a comportar. Y a veces vale la pena hacer que el proceso sea un poco más engorroso para obligar a las personas a pensar ¿debería estar haciendo esto ahora?

Drew: ¿Hay otras formas de identificar lo que debería automatizarse a través de una especie de monitoreo de sus sistemas y medición de cosas? Quiero decir, pienso en DevOps y pienso en los tableros como una de las cosas, buenos gráficos. Y estoy seguro de que hay mucho más en esos tableros que solo verse bonitos, pero siempre es bueno tener tableros que se vean bonitos. ¿Hay formas de medir lo que hace un sistema, para ayudarlo a tomar ese tipo de decisiones?

Jeff: Absolutamente. Y eso pasa a la parte de métricas de las cámaras, ¿cuáles son las cosas que rastreamos en nuestros sistemas para saber si funcionan de manera eficiente? Y una de las trampas comunes de las métricas es que buscamos errores en lugar de verificar el éxito. Y esas son dos prácticas muy diferentes, ¿verdad? Entonces, algo podría fluir a través del sistema y no necesariamente dar un error, pero no necesariamente pasar por todo el proceso como debería. Entonces, si soltamos un mensaje en una cola de mensajes, debería haber una métrica correspondiente que diga: "Y este mensaje se recuperó y procesó", ¿verdad? Si no, claro, rápidamente tendrá un desequilibrio y el sistema no funcionará como debería. Creo que podemos usar las métricas como una forma de comprender también diferentes cosas que deberían automatizarse a medida que nos adentramos en esos malos estados.

jeff: ¿verdad? Porque muchas veces es un paso muy simple que se debe tomar para limpiar las cosas, ¿verdad? Para las personas que han estado operando por un tiempo, correcto, la alerta de espacio en disco, todos saben sobre eso. Oh, estamos llenos de disco. Oh, olvidamos que es fin de mes y la facturación se ejecutó y la facturación siempre llena los registros. Y luego el registro VAR está consumiendo todo el espacio del disco, por lo que necesitamos ejecutar una rotación de registro. ¿Derecha? Podrías despertarte a las tres de la mañana para eso, si eso es lo que prefieres. Pero si sabemos que ese es el comportamiento, nuestras métricas deberían poder darnos una pista al respecto. Y podemos simplemente automatizar el comando de rotación de registros, ¿verdad? Oh, hemos alcanzado este umbral, ejecute el comando de rotación de registros. A ver si se borra la alerta. Si es así, continúa con tu vida. Si no es así, quizás despertemos a alguien, ¿no?

Jeff: Estás viendo esto mucho más con la automatización de la infraestructura, cierto, donde es como, “Oye, ¿nuestras solicitudes por segundo están alcanzando nuestro máximo teórico? Tal vez necesitemos escalar el clúster. Tal vez necesitemos agregar tres o cuatro nodos al grupo del balanceador de carga”. Y podemos hacerlo sin requerir necesariamente que alguien intervenga. Podemos simplemente mirar esas métricas y tomar esa acción y luego contratar esa infraestructura una vez que cae por debajo de un umbral particular, pero debe tener esas métricas y debe tener esos enlaces en su entorno de monitoreo para poder hacer eso. Y ahí es donde entra en juego toda la parte de las métricas de la conversación.

Jeff: Además, también es bueno poder compartir esa información con otras personas porque una vez que tienes datos, puedes comenzar a hablar sobre cosas en una realidad compartida, cierto, porque ocupado es un término genérico, pero 5200 solicitudes por segundo es algo demasiado más concreto sobre el que todos podamos razonar. Y creo que muy a menudo cuando tenemos conversaciones sobre la capacidad o cualquier cosa, usamos estos términos ondulados a mano, cuando en cambio podríamos estar mirando un tablero y dando valores muy específicos y asegurándonos de que todos tengan acceso a esos tableros, que no están escondidos detrás de un muro de operaciones al que solo nosotros tenemos acceso por alguna razón desconocida.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Derecha. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Derecha.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. ¿Es esa una evaluación justa?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Derecha. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Derecha. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Derecha. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Derecha. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. ¿Derecha? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Derecha. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Derecha. So you could be doing any manner of testing in there that is extremely complicated. Derecha. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Derecha. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Derecha. Let me get Drew on the phone and see what's going on.” Derecha. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Derecha. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Derecha. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Quería escribirles a ellos, principalmente a colaboradores individuales y gerentes intermedios, para decirles: "No es necesario ser un CTO para poder realizar este tipo de cambios incrementales, y no es necesario tener este toda la revolución de la venta para poder obtener algunos de los beneficios de DevOps”. Así que fue realmente una especie de carta de amor para ellos decir: “Oye, puedes hacer esto en partes. Puede hacerlo usted mismo. Y hay todas estas cosas que quizás no pienses que están relacionadas con DevOps porque las consideras como herramientas y Kubernetes”. No todas las organizaciones... Si estuvieras a favor de este estado de Nueva York, como el gobierno estatal, no vas a entrar e implementar Kubernetes de la noche a la mañana. ¿Derecha? Pero puede implementar cómo los equipos se comunican entre sí, cómo trabajan juntos, cómo entendemos los problemas de los demás y cómo podemos abordar esos problemas a través de la automatización. Son cosas que están dentro de tu esfera de influencia y que pueden mejorar tu día a día.

Jeff: Entonces, en realidad fue una carta para esas personas, pero creo que hay suficientes datos allí y suficiente información para que las personas que están en una organización de DevOps puedan obtener información y decir: “Oye, esto todavía es útil para nosotros. ” Y mucha gente, creo que identifica rápidamente al leer el libro, que no están en una organización DevOps, simplemente tienen un cambio de título de trabajo. Y eso pasa bastante. Entonces dicen: "Oye, ahora somos ingenieros de DevOps, pero no estamos haciendo este tipo de prácticas de las que se habla en este libro y ¿cómo llegamos allí?"

Drew: Parece que su libro es uno de ellos, pero ¿existen otros recursos a los que puedan recurrir las personas que buscan comenzar con DevOps? ¿Hay buenos lugares para aprender estas cosas?

jeff: si Creo que DevOps For Dummies de Emily Freeman es un excelente lugar para comenzar. Realmente hace un gran trabajo al clasificar algunos de los conceptos e ideas centrales, y por lo que nos estamos esforzando. Entonces ese sería un buen lugar para comenzar, solo para tener una idea del terreno. Creo que Phoenix Project es obviamente otra gran fuente de Gene Kim. Y eso es genial, de alguna manera prepara el escenario para los tipos de problemas que puede crear no estar en un entorno DevOps. Y hace un gran trabajo al resaltar estos patrones y personalidades que ocurren y que vemos en todo tipo de organizaciones una y otra vez. Creo que hace un gran trabajo al resaltarlos. Y si lees ese libro, creo que terminarás gritando a las páginas diciendo: “Sí, sí. Esta. Esta." Entonces, ese es otro gran lugar.

Jeff: Y luego, a partir de ahí, profundizar en cualquiera de los manuales de DevOps. Me voy a criticar por decir esto, pero el Manual SRE de Google fue otro gran lugar para buscar. Entiende que no eres Google, así que no sientas que tienes que implementar todo, pero creo que muchas de sus ideas y estrategias son buenas para cualquier organización y son excelentes lugares donde puedes tomar cosas y decir algo como: "Está bien, vamos a hacer que nuestro entorno de operaciones sea un poco más eficiente". Y creo que eso será particularmente importante para los desarrolladores que están desempeñando un papel de operaciones, porque se enfoca mucho en el tipo de enfoque programático para resolver algunos de estos problemas.

Drew: He estado aprendiendo todo sobre DevOps. ¿Qué has estado aprendiendo últimamente, Jeff?

Jeff: Kubernetes, hombre. Si. Kubernetes ha sido una verdadera fuente de lectura y conocimiento para nosotros. Así que estamos tratando de implementar eso en Centro actualmente, como un medio para empoderar aún más a los desarrolladores. Queremos llevar las cosas un paso más allá de donde estamos. Tenemos mucha automatización implementada, pero en este momento, cuando se trata de incorporar un nuevo servicio, mi equipo todavía está bastante involucrado con eso, dependiendo de la naturaleza del servicio. Y no queremos estar en esa línea de trabajo. Queremos que los desarrolladores puedan llevar una idea desde el concepto hasta el código y la implementación, y hacerlo donde la experiencia operativa esté codificada dentro del sistema. Entonces, a medida que avanza por el sistema, el sistema lo está guiando. Entonces, creemos que Kubernetes es una herramienta que nos ayudará a hacer eso.

Jeff: Es increíblemente complicado. Y es una gran pieza para morder. Entonces, ¿cómo se ven las implementaciones? ¿Cómo aprovechamos estos operadores dentro de Kubernetes? ¿Cómo se ve la CICD en este nuevo mundo? Así que ha habido mucha lectura, pero en este campo, estás aprendiendo constantemente, ¿verdad? No importa cuánto tiempo hayas estado en esto, cuánto tiempo lo hayas estado haciendo, eres un idiota en algún aspecto de este campo en alguna parte. Entonces, es algo a lo que te adaptas

Drew: Bueno, me quito el sombrero como digo, incluso después de todos estos años, aunque entiendo dónde se encuentra en la pila, todavía no tengo ni idea de lo que está haciendo Kubernetes.

Jeff: Me siento similar a veces. Se siente como si estuviera haciendo un poco de todo, ¿verdad? Es el DNS del siglo XXI.

Drew: Si a usted, el oyente, le gustaría saber más de Jeff, puede encontrarlo en Twitter, donde es oscuro y nerd, y encontrar su libro y enlaces a presentaciones anteriores y publicaciones de blog en su sitio, reachabledevops.com. Gracias por acompañarnos hoy, Jeff. ¿Tuviste alguna palabra de despedida?

Jeff: Sigue aprendiendo, sal, sigue aprendiendo y habla con tus compañeros. Hablar hablar hablar. Cuanto más puedas hablar con las personas con las que trabajas, mejor comprensión, mejor empatía generarás por ellos, y si hay alguien en particular en la organización que odias, asegúrate de hablar con ellos primero.