En mi vida laboral y personal he ido cambiando y adaptándome a lo largo del tiempo a diferentes tecnologías, herramientas y Sistemas Operativos. Desde mis comienzos en informática, cuando tenía 11 años, ya me apañaba mejor con entornos de terminal mas que con entornos gráficos.

Recuerdo incluso que realizaba menús gráficos en Basic para que mis hermanos pudieran arrancar los juegos en MSDOS sin tener que teclear ni un solo comando.

Más tarde, en la universidad, empecé a usar Linux/Unix, y cuando comencé mi vida laboral empecé en entornos Microsoft/Windows. Con el tiempo llegue a ser Arquitecto Soluciones Microsoft aunque en proyectos personales siempre utilizaba entornos Linux. A día de hoy utilizo casi de forma exclusiva Linux tanto en entorno personal como en entorno profesional.

Como veis he disfrutado y sufrido los dos mundos principales de atajar los problemas IT. Después de vivir todo esto, puedo decir que cada tecnología sirve para solucionar de forma efectiva un problema y no hay blancos o negros totales. Lo importante es analizar lo que necesitas y lo que mejor se adapta a tus recursos tanto tecnológicos como humanos.

Actualmente estoy inmerso en muchos proyectos de transformación tecnológica en el ciclo de vida del software e implementando la cultura DevOps en muchos clientes que desean acelerar sus desarrollos y optimizar su esfuerzo económico y humano. Así que me encuentro con muchos equipos, en muchos clientes y con muchos compañeros y personas de diferente origen tecnológico pero con el mismo objetivo de acelerar y reducir el Time-To-Market. Una de las preguntas que me asaltan continuamente es si se puede hacer el trabajo de "DevOps con Windows". Y mi respuesta siempre es la misma: se puede pero complica mucho la vida. Entonces, ¿se puede hacer DevOps con Windows? Desde el respeto a Microsoft: NO. Y ahora expongo mis razones:

1) En fase de construcción: En muchos entornos los desarrolladores programan en Windows y el entorno productivo o de despliegue son Unix/Linux. ¿Se puede desarrollar en una máquina Windows y de forma trasparente y directa subir a producción en un entorno Linux/Unix? Muchas veces no, hay que compilar en una arquitectura parecida o igual que la del entorno de producción y ahí detectar los problemas para corregirlos para asegurarnos que en el entorno final funciona. Problemas de referencias, rendimientos, ... Si vas a programar, ¿no sería mas rápido probar en tu máquina en un entorno similar al productivo con Linux?. En la mayoría de los casos se ahorra un montón de tiempo en despliegues continuos e integración por probar las cosas en local antes de commitear. Sin hablar de problemas de encoding de ficheros entre Microsoft y Unix...

2) En control de código: La mayoría de proyectos gestionan su código en Git, muchos desarrolladores programan en Windows pero otros sobre Linux. Un problema, por ejemplo, que me he encontrado es con el de fichero .gitignore. Hay ocasiones en las que hay problemas entre clientes de git si es Windows o Linux y las exclusiones no son triviales, al final los ficheros .gitignore se convierten en fichero de políglotas que dan dolor de cabeza, y ahí estamos los que hacemos DevOps intentando atajar los miles de casos para minimizar el "daño". Os recomiendo leer esta pregunta en stackoverflow. Siempre hay formas de atajar los problemas que vienen de desarrolladores sobre Windows, pero no dejan de ser parches en mi opinión.

3) En el empaquetado: La generación de ficheros/artefactos cambia mucho dependiendo de donde se compila el código. Por ejemplo un WAR generado en Windows y en Linux están construidos de forma perfecta pero su contenido a veces es diferente, no mucho, pero si lo suficiente para comportarse de forma diferente. En StackOverflow hay gente reportando este tipo de problemas.

Podríamos estar hablando de problemas en fase de desarrollo, que podrían llegar a solucionarse pero que los que intentamos minimizar el hueco entre Dev y Ops tenemos que estar continuamente solventando. Pero nuestra pregunta es "¿Se puede hacer DevOps con Windows?".

¿Cuáles son los trabajos que se llaman comúnmente del "DevOps"?: A modo general y optimista es entregar el cambio que hace un desarrollador como código al entorno productivo lo antes posible con la máxima calidad posible. Además también se encarga de construir o proveer herramientas que hagan al desarrollo ser mas ágil, eficiente y con más calidad. Pero a parte de estas dos grandes funciones también deberían:

• Implementar Integración Continua.
• Hacer Entrega Continua de Producto.
• Detección temprana y preventiva del fallo.
• Monitorizar los cambios y el rendimiento.
• Centralización de logs y trazas.
• Despliegue y mantenimiento de entornos previos y productivos, con orientación a la Infraestructura como código.
• Reducir las tomas de decisión o pasos manuales de los ciclos de software.
• Integrar pruebas en el ciclo del software.
• Desarrollar y promover nuevas herramientas y automatizaciones para permitir un mejor desarrollo y operación.
• Gestionar el ciclo de vida del dato.
• Enfocar la actividad y operación del desarrollo software a los resultados del negocio.
• Favorecer la comunicación y la transparencia entre equipos y personas.
• Acercar la operación de sistemas al desarrollo.

Como se puede desprender de esta lista, las personas que se encargan de implementar la cultura DevOps deben ser desarrolladores de código, pero también especialistas en sistemas e infraestructura. ¿Son entonces superhombres? En algunos casos seguramente, pero en otros son simplemente mediadores y conseguidores de que, equipos históricamente separados (Desarrollo y Sistemas), trabajen con los mismos objetivos y con sinergias valiosísimas para las empresas. Por lo tanto los ingenieros que implementan cultura DevOps o los desarrolladores que se enfrascan con los problemas de sistemas, o los administradores de sistemas que intentan implicarse en la forma de desarrollar y la calidad, tienen que ser capaces de hacer fluir el ciclo de vida del software.

¿Pero qué hay debajo de todo esto? Flexibilidad, creación y potencia. Y a día de hoy las únicas herramientas que permiten todo esto son las Open Source:

• Flexibilidad: las herramientas de código abierto permiten conocer qué hace cada parte del código que forman las mismas y permiten customizar o adaptar a nuestras necesidades el software (con permiso de la licencia :) )
• Creación: al ser código abierto no sólo permite el cambiar y revisar el código sino que ademas nos permite basarnos en código para realizar otras herramientas nuevas que resuelvan nuestro problema.
• Potencia: las comunidades de código abierto tienden a colaborar y compartir sus conocimientos dando lugar a mejoras mas rápidas e innovadoras. Normalmente porque permiten de forma rápida y abierta el interactuar con los usuarios y sus problemas, de tal modo que se detectan las necesidades de forma inmediata a la publicación del mismo.

"Y de aquellos polvos vienen estos lodos", es decir, que de un sistema operativo de código abierto como Linux viene todo el software Open Source que nos va a permitir implementar mejor una cultura DevOps. Por lo tanto veo imprescindible que para realizar estos cambios e implementar soluciones, el mal-llamado "ingeniero DevOps" debe utilizar Linux. Si mas arriba hablábamos de que el desarrollador debe utilizar un sistema operativo para desarrollar parecido al de los entornos de despliegue, al DevOps le va a resultar mas fácil y sencillo desarrollar, probar e implementar soluciones.

Seguramente, alguno este pensando que para Microsoft también hay Open Source. Y realmente tiene razón, lo hay, pero por experiencia cuesta mucho hacerlo funcionar, y siempre dan la sensación de inestabilidad suficiente para pensarse si poner esas herramientas en producción. Al que tenga alguna duda, le insto a echar un vistazo a una imagen del Cloud Native Landscape y que pruebe alguna herramienta de la imagen sobre Windows e intente ponerlo en producción.

Pero todo esto no es simplemente un pensamiento fruto de un silogismo rebuscado, no. En la práctica me encuentro en todos los sitios donde voy con ingenieros que utilizan Windows como su herramienta pero que casi se pasan el 90% de su tiempo con una máquina virtual Linux. Yo siempre les digo: Si el objetivo es agilizar, ser rápidos, ser potentes, ¿por qué trabajar con una máquina virtual Linux?

¡¡¡¡¡ DevOps, da el salto a Linux !!!!!

Para estar al día de próximos posts, ¡síguenos en Twitter!