loading...

Resumen para un DevOps day

yeisoncruz16 profile image Yeison Cruz ・4 min read

Después de escuchar a muchas personas durante dos días dando charlas acerca de DevOps, "¿que es?", sus inicios y "¿para que sirve?", logre sacar algunas conclusiones que espero les sean de ayuda para tener en cuenta al momento de hablar de DevOps.

Las deducciones o afirmaciones aquí mencionadas son netamente personales y tambien citaré algunas frases de los expositores.

DEVOPS : Dev (desarrollo) Ops (Operaciones)

imagen obtenida de este post https://twitter.com/DevopsdaysMed/status/1283219819496603648/photo/1

Daré inicio a este articulo citando la frase de Denovan Brown, "DevOps es la unión de personas, procesos, y productos para permitir una entrega continua de valor a los usuarios finales".

Desde este preciso instante ya podemos ver que hablamos de una filosofía más no de una lista de herramientas, administrador de servidores o un grupo de personas. Ahora empezamos a verlo desde otra perspectiva, ahora estamos hablando de una cultura tanto personal como organizacional con la finalidad de entregar más calidad en el menos tiempo posible.

Ahora, ¿porque una cultura?, porque DevOps le permite de los equipos y a las personas definir como van a interactuar unos con los otros incluso sin estar dentro de la misma área de trabajo.

Ya sabemos que es DevOps, pero ahora hablemos un poco de lo que no es:

  • Una persona encargada de administrar servidores.
  • Un listado de herramientas.
  • No es asunto de TI.
  • No es un area de la empresa.
  • y por último, hacer CI/CD no es hacer DevOps, esto va más allá.

Bien! Ya tenemos claros algunos conceptos, y podremos sacar provecho de algunos de los consejos brindados por estas personas.

"Una ficha de dominó puede derribar otra con un tamaño 50% mayor" (Lorne Whitehead).
Claramente podemos ver la importancia de tener siempre un desarrollo progresivo en nuestros proyectos, para el usuario final es mucho más valioso poder interactuar con un sistema básico HOY, mañana un poco mejor y pasado mañana aún mejor, que tener ALGO con más herramientas pero dentro de 1 año.

"No existen pequeños errores". Esto también se puede convertir en un efecto domino, cuando por ejemplo olvidamos cambiar una sola variable antes de ir a producción, pero resulta que esa variable es la que habilita el debug de todo el sistema.

"DevOps es un vehiculo cuyo único destino es la productividad". Ya sabemos que no lo podemos ver como simplemente un grupo de personas encargadas de administrar servidores, debemos verlo como ese conjunto de acciones que nos ayuden a mejorar, sí tener CI/CD mejora mi productividad entonces hace parte de DevOps, sí tener Contenedores Docker hace que mi forma de desplegar sea mucho mas rapida y entregar valor al cliente mas rapido entonces hace parte de DevOps. Y asi podemos continuar con el sin fin de acciones que nos hacer ser mas productivos.

"Microservicios son un camino a la productividad", divide y veceras, siempre sera mucho mas facil tener todo un proceso de calidad a un pequeño sistema que simplemente un complejo sistema de calidad a un gran poryecto. ¡No lo sé, Piensalo!

"No deje de lado los las pruebas automatizadas". No somos perfectos y con consigueinte nuestro software tampoco lo sera, sí sabemos que nuestro software va a fallar, pues entonces que falle rapido y en nuestras manos, asi sera menos costoso dar soporte y generar mas valor. Además, esta en nuestra humanidad, Fallar + Aprender = Crecer.

"Things that have never happened before, happen all the time". No se preocupe, siempre vamos a tener algo que no sabemos como resolver, pero de eso se trata DeVops, prepararnos para evitar los fallos y cuando falle tengamos una mejor idea de que podemos hacer. Metricas, Rollback, Logs, Upgrades, Autoscaling, system recover...

"Jenkins está obsoleto", Naturalmente no es que sea una mala herramienta, aun lo es, y no tengo nada en contra, pero si lo pensamos bien, es una herramienta a la cual le tenemos que instalar y dar soporte. Administrar nuestra aplicacion ya es bastante carga como para que tengamos una preocupacion más, ahora tenemos algunas alternativas mas escalables como Github actions, Buddy.works, Gitlab, circle ci, codefresh.io, aws codepipeline, google cloud build y muchas mas.

"No matter how much we prepare... We really don't know very much". ¿Que?, ¿Como?, ¿Donde?, ¿Cuando?, no importa lo que hagamos, siempre vamos a tener alguna falla o algo por mejorar, lo importante es que trabajemo en reducir esa posibilidad tanto como sea posible, se mencionó mucho
'Ingeniería del caos' y como ha sido la clave para mejorar.

"¿Porque las personas ponemos resistencia?", Es normal y siempre va a pasar, cuando crear practicas DevOps va haber resistencia, pero eso tambien es parte del proceso, una vez mas es escencia del ser humano, entonces lo unico que podemos hacer es ser pacientes y buscar la alternativa para que estas practicas sean bien acojidas.

Hasta aca, he logrado hacer un resumen de algunas notas que tomé y de otras cosas que me acuerdo, la verdad es que fue un dia muy productivo y espero que estas notas les sean de utilidad.

Dejaré algunos posts a continuacion.

https://twitter.com/DevopsdaysMed/media

Posted on by:

yeisoncruz16 profile

Yeison Cruz

@yeisoncruz16

I am a technology lover, focus on the AWS services learning every day.

Discussion

markdown guide