Comenzamos una nueva entrevista con un invitado con un perfil de administrador de sistemas en GNU/Linux y antiguo trabajador de Red Hat, su nombre es Jorge Rúa.

Antes de todo, gracias por aceptar la invitación y apoyar a este proyecto. La primera pregunta es una presentación por parte del entrevistado, para que los lectores te puedan conocer un poco.

Entrevista En Diferido:¿Te puedes presentar en unas líneas?

Jorge Rúa: Buenas, es un placer participar en la entrevista. Muchas gracias por la invitacion y un saludo a todos los lectores.

Me presento brevemente, me llamo Jorge Rúa y soy Staff Systems Engineer en ServiceNow en la oficina de Dublin, para los que no la conozcan es una multinacional norteamericana que ofrece su producto como SaaS. El producto en si esta enfocado a ITSM, ITOM, automatizacion, workflows, etc. Anteriormente he trabajado en Madrid como Cloud Consultant para Red Hat Iberia, etapa de la que guardo buenisimos recuerdos.

Mi labor dentro del equipo de ingenieria es definir nuevos diseños de arquitectura, mejora de procesos, automatizacion, etc. Concretamente trabajo en un area donde manejamos el Core, esto es DNS, LDAP y CDN. Tambien somos encargados de construir los nuevos racks desde el momento en el que nos los entregan. Este proceso lo hemos conseguido automatizar completamente, sobre esto hicimos un podcast en directo con los amigos del canal de Eduardo Collado, por si alguien le interesa.

EED: Para empezar , unas cuantas preguntas cortas para conocerte mejor y conocer tu entorno tecnológico.

¿Qué ordenador utilizas habitualmente?

¿Sistema operativo?

¿Servicio en la nube con el trabajas?

¿Herramienta impresindible para tu trabajo?

¿Herramienta de virtualización?

¿Lenguaje de programación?

¿Red Hat o Debian?

JR: Por desgracia, suele ser estandar de facto el trabajar con MacBooks en el 99% de las empresas norteamericanas. No es un equipo que me disguste, puesto que me parecen componentes de primera, sin embargo no me dan la flexibilidad que yo necesito. Entiendo que esto a una mayor parte de usuarios les vaya al dedo, pero echo de menos cierto control sobre el sistema.

Sistema operativo pues en cuanto a mi trabajo MacOS, sin embargo uso mucho VMware fussion para virtualizar Fedora, Centos8, etc para mis pruebas.

Recientemente nuestra empresa firmo un contrato estrategico con MSFT para llevar algunos clientes nuestros a Azure, es ahora mismo con los servicios en la nube que mas contacto estoy teniendo.

Mi herramienta favorita es ansible y terraform, ambas enfocadas a la automatizacion y al IaC, enfoque del que soy un gran defensor. Es decir, en vez de aplicar iterativamente cambios sobre una maquina, lo que se hace es generar un nuevo asset, normalmente mediante un pipeline, donde se comprueba si es valido antes de entregarse cotejando parametros de seguridad, entre otros. Una herramienta para generar estos assets es por ejemplo packer. Puedes generar desde golden images/vm templates hasta contenedores. El concepto es el mismo, acuñado por Martin Fowler, Phoenix Servers, en referencia al fenix que puede resurgir de sus cenizas.(para que se entienda, al igual que cattle vs pets, si un server se rompe, se pone otro en su sitio, sin perder ni 1 minuto en intentar arregarlo manualmente)

Sobre virtualizacion normalmente trabajo con vSphere, aunque como comente antes tengo algunas cosillas sobre KVM y VMWare Fussion. Ovirt/RHEV me parecen unos productos muy a tener en cuenta, puesto que no todas las empresas necesitan de todas las caracteristicas que ofrece VMWare. Para esas empresas que esten usando VMWare a "medio gas" oVirt/RHEV es una alternativa mas que interesante.

Mi lenguaje preferido es python aunque me gusta bastante golang, creo que combinando la potencia de C y la versatilidad de python se puede crear cualquier proyecto por ambicioso que sea.

Sobre si Red Hat o Debian? Pues te contesto como buen gallego. Depende. Mira, cuando trabajaba en Red Hat yo usaba Debian, jamas nadie me dijo nada al respecto, salvo algun chascarrillo entre compañeros. Siempre he sido debianita aferrimo y la comunidad debian es la comunidad de software libre por excelencia. El hecho de que no haya una empresa por detras avalando las decisiones hacen de ella un proyecto unico, por ello es el sistema operativo universal. Red Hat es un sistema operativo enterprise(de pago mediante suscripcion) con una robustez increible, casi todas las grandes empresas del mundo usan Red Hat en sus servidores, y el hecho de que la respalde una empresa cuyos trabajadores son contribuidores core en proyectos como el nucleo de Linux, pues resulta garantia de que si pagas por usar este SO vas a tener normalmente el mejor soporte posible. Yo me quedaria con Debian testing para el escritorio/laptop y Red Hat para los servidores. Aunque ahora mismo estoy probando Fedora en mi laptop personal, se que en algun momento volvere a Debian.

EED: Pregunta fija en todas las entrevista, donde solo cambia el contexto. En tu caso, como usuario de Debian.

¿Qué añadirías a Debian?

¿Qué modificarías de Debian?

¿Qué eliminarías de Debian?

JR: Creo que Debian solo necesita un cambio, y es que necesita que la gente sea consciente del esfuerzo y dedicación voluntaria de la gente que hay detrás del proyecto. Al no haber una empresa detrás, como Ubuntu con Canonical, muchos desarrolladores se los ha llevado esta última. Creo que eso es un problema, ya que Canonical bajo mi punto de vista se nutre de un proyecto al que poco o nada devuelve a cambio. Yo a Debian, en lo técnico no tocaría nada, tanto la inclusión de systemd como el uso de gnome como DE por defecto me parece acertado.

Quizás de Debian eliminaría los blobs binarios que normalmente incluyen controladores privativos, aunque no creo que fuese una decisión muy popular.

EED: Has comentado que has trabajado en Red Hat, una empresa que ha tenido éxito con productos de software libre, pero me gustaría saber si la filosofía de software libre también se aplica a la organización u otros aspectos empresa.

¿Cómo se trabaja en Red Hat?

¿Es diferente a otras empresas más "clásicas"?

JR: Red Hat tiene una forma muy peculiar de trabajo, a grandes rasgos es una gran cúmulo de comunidades de software libre. Es fascinante. Por supuesto eso es desde la perspectiva técnica, desde la perspectiva de negocio hay distintas Business Units que se encargan de dirigir el rumbo de los productos.

En RedHat la cultura es completamente distinto a lo que normalmente podríais encontrar en una multinacional norteamericana, aunque ahora al pasar a ser parte de IBM no se si eso llegara a cambiar, yo desde luego espero que no, puesto que acabaría con su esencia.

Un caso parecido a lo de la adquisición de RedHat por IBM ha sido la de nginx por parte de F5 networks, ambas RedHat y nginx comparten algunos genes de la cultura hacker opensource que tanto me fascinan. Por lo que se, nginx sigue manteniendo su esencia después de la adquisición y espero que así sea con RedHat.

Por ponerte un ejemplo de cómo se trabaja en RedHat, se ha definido incluso una metodología de ayuda a la toma de decisiones, denominada Open Decission Framework, por si hay algún curioso aquí os dejo el enlace: https://github.com/red-hat-people-team/open-decision-framework/blob/master/README.md

Otra cosa muy divertida de RedHat es la memo-list, como dije al principio RedHat es un cúmulo de comunidades opensource, y hay literalmente cientos de listas de correo a las que te puedes suscribir para colaborar. Pues bien, una de estas listas a las que estas suscrito por defecto es la memo-list, aquí hay de todo, desde reflexiones filosóficas hasta gente que necesita ayuda en algo que no encaja realmente en la temática de otra lista, muchisima gente que suelta su frustración en ella, me gustaría haber leído los rios de tinta que se tuvieron que generar cuando se anunció la adquisición de IBM, aunque me cogió ya en mi actual empresa lo vivi como algo que me afectaba.

EED: Has comentado que eres defensor de IaC, infraestructura como Código. Podrias explicar.

¿Qué es IaC?

¿Qué diferencias y ventajas aporta respecto a las demas opciones como PaaS,SaaS,FaaS...?

JR: IaC es en esencia definir tu infrastructura como codigo, bajo este paradigma cambian el como y el cuando se aplican los cambios a tu infrastructura. Tradicionalmente, en un entorno gestionado con puppet por ejemplo, el codigo que define tu infrastructura va mutando, de forma que se van aplicando cambios de manera incremental sobre el tiempo. En IaC el codigo que define la infrastructura va mutando, pero los cambios no se aplican de manera incremental sobre el tiempo, sino que se aplican antes de que se entregue. El ciclo de vida varia, los assets resultantes son immutables normalmente, contenedores, golden images, etc.

La principal ventaja de este enfoque es que no vas a tener snowflakes en tu infrastructura, tienes la certeza de que siempre vas a tener alineada en un punto en concreto, es mala praxis incluso habilitar acceso ssh, puesto que no lo necesitas si estas haciendo las cosas bien.

Este enfoque se usa mucho en PaaS y FaaS, por ejemplo, donde hay un objeto inmutable proporcionando algun tipo de servicio.

EED: Por lo que he entendido tienes un perfil de administrador mas que programador, los dos mundos que existen principalmente en el mundo de la IT. Una pregunta que suelo hacer a los entrevistados que tienen un perfil de administrador.

¿Para ser un buen administrador es obligado ser un buen programador?

JR: Yo creo que si, solo cambia el contexto. El concepto DevOps Engineer a grandes rasgos es un SysEng con capacidades de desarrollador o viceversa. Hoy un SysEng debe dominar protocolos, redes, y por supuesto programacion. Como dije al principio de la entrecista al menos dominar un lenguaje interpretado como python o ruby para poder llevar a cabo el desarrollo de herramientas. Ademas de que por ejemplo si usas Ansible como es mi caso muchas veces necesitas picar alguna libreria o modulo. Es tambien importante tener nociones de clean coding, porque es mas que probable que tu codigo lo tenga que leer y verificar otra persona. En nuestro caso solemos hacer TDD con todos los roles de ansible que desarrollamos, de esa forma sabemos que los nuevos cambios introducidos pasan siempre una serie de tests en cada nueva version que lanzamos.

EED: La siguiente es una pregunta de un lector de las entrevista, que le he añadido una pregunta extra. Creo en tu empresa trabajas como contractor, una figura que no se si exsite en España, asi que...

¿Qué es un contractor?

La pregunta del lector.

¿Cuándo te planteaste el cambio a contractor?

¿Qué le recomendarías a alguien que quiere dar el salto?

JR: Pues en realidad no estoy contratado como contractor, aunque no me importaria estarlo la verdad. Os cuento un poco: a grandes rasgos un contractor vendria siendo algo parecido a un freelance. Por lo que o bien tu persona, o una empresa normalmente denominada umbrella factura a otra a la que le ofreces tus servicios. Por lo que esto es un punto a tener en cuenta, tu eres tu propio jefe, tu tienes que pagar impuestos, tu te pagas tu equipamiento informatico, transporte, seguridad social, etc.

Un contractor normalmente cobra mucho mas que un permanent, donde la empresa que te contrata paga todo eso por ti. Normalmente se pone una tarifa diaria, por ejemplo a mi me ofrecieron una oferta como contractor cobrando 700 euros al dia. Puede parecer mucho, pero al final tienes que pagar impuestos etc, al final salen unos 7000 euros netos mensuales. Pero tienes que tener en cuenta que las vacaciones no son pagadas, asi que ese mes que no trabajas es dinero que no facturas, por lo que tu sueldo serian esos 7000*11 netos anuales. Otro inconveniente del modelo contractor es la incertidumbre ya que los proyectos suelen ser de corta duracion, pongamos 1 año o como mucho 2. Al finalizar ese periodo de tiempo no habras progresado en tu carrera, es decir seguiras siendo contractor y tu seniority seguira siendo la misma.

Otra contra es que de contractor te pueden dar boleto en cualquier momento, si por necesidades del proyecto deciden reducir costes o lo que sea, date por jodido porque no dudaran un segundo en mandarte a la mierda. Por lo que tambien deberias tener en cuenta que parte de tu sueldo deberia ir a una dotacion para imprevistos como ese.

Cual elegir? Pues depende de lo que te guste, si quieres ver muchos clientes, aprender de cada uno, no casarte con la idiosincracia de una sola empresa y hacer muchisima pasta contractor es lo tuyo, eso si ten en cuenta los riesgos que corres y ese extra overhead de tener que pagar tasas, etc.

Si alguien quiere trabajar en mi empresa estamos buscando gente para la oficina de Dublin,eso si, en modo permanent. Poneros en contacto conmigo y os informo si quereis. (Perdon por el spam)

EED: En una respuesta anterior has indicado que utilizaís TDD.

¿Qué tal la experiencia de uso de TDD?

¿Qué dificultades has encontrado a la hora de implementarlo?

JR: Sobre TDD, lo que mas nos ha costado son los tests de integracion ya que dependen de un servicio externo para poder validarse. Los test unitarios nos han resultado bastante sencillos, usamos pytest, testinfra y tavern para ello. En cuanto a ansible los roles que escribimos los tenemos testados con molecule, esta herramienta ha sido recientemente adquirida por RedHat.

El pasar tests diariamente, o a cada cambio que se realice sobre un proyecto es una garantia de que no se rompe nada. Muchas veces hacemos cambios que a priori podrian parecer inocuos, la realidad es que con la cantidad de librerias que intervienen simultaneamente pongamos en un rol de ansible las probabilidades de que se rompa algo son muy altas.

EED: En la actualidad la nube o cloud es muy utilizada en múltiples ámbitos y se puede considerar casi obligatorio su uso para el desarrollo de aplicaciones. Múltiples empresas proporcionan servicio a través de su nube .

Si tuvieras una empresa que quiere montar su propia nube para ofrecer servicios, has decidido crear una especie "nube frankenstein" donde escoges las mejores partes de otras nubes e integrarlas en la tuya. De esta forma crear la nube perfecta.

¿Cómo sería tu "nube perfecta?

¿Qué componente escogerías de otras nubes?

JR: En ServiceNow nosotros tenemos montada nuestra propia nube, al final tenemos muchísimos datacenters contratados alrededor del mundo y hardware puntero. Creo recordar que un solo armario nos cuesta alrededor de 2 millones de doláres, contando desde los TOR hasta los FlashArrays de PureStorage, lo que se busca es reducir siempre la latencia con tu cliente, para que la UX sea buena.

Si tuviese que montar una nube a escala global, escogería dos datacenters por región para hacer failover en caso de que uno se vaya al palco. Para ADC montaría dos pares de F5 en active-standby, para virtualización vSphere y para almacenamiento Flasharray de Pure.

En caso de que tuviese que usar las nubes de otro proveedor, me consta que Google y Amazon tienen las mejores infraestructura de red. Recientemente hemos hecho un estudio comparativo entre GCP, Azure y AWS y el rendimiento de Google y Amazon fueron ligeramente superiores a las de Azure. Sin embargo nosotros hemos escogido la nube de Microsoft más por decisión estratégica y por precio, que por rendimiento.

Para mi el modelo híbrido de nube es el más interesante puesto que puedes albergar el core de tu negocio en on-prem, y mover partes menos críticas a algún CSP.

EED: En la empresa que trabajas se deben realizar muchos despliegues , este es un proceso que se debe cuidar mucho que sino se hace bien puede causar muchos problemas.

¿Cómo se realiza un buen despliegue?

¿Qué factores hay que tener en cuenta?

JR: Lo principal es que todos los equipos involucrados estén alineados sobre el procedimiento de despliegue. Por ejemplo es posible que un nuevo despliegue involucre a gente de datacenter, Neteng, seguridad, syseng etc. La figura de Project Manager es esencial para orquestar toda la operación.

Sobre el procedimiento en si, yo diría que cuanto más automatizado sea el proceso mucho mejor, yo soy partidario de crear workflows con un equipo asociado a cada tarea, y poner breakpoints para que se apliquen solamente tras una aprobación manual, de esa forma se tiene constancia del cambio.

Tecnológicamente hablando hay muchas formas de orquestarlo todo, yo os recomiendo ServiceNow + Ansible Tower por ejemplo, de esa forma podéis crear workflows e integrar aprobaciones manuales, llamadas a otros servicios remotos via restapi, etc.

EED: Como última pregunta de la entrevista , una pregunta un poco diferente.

¿Qué te hubiera gustado que te preguntase? Evidentemente la respuesta será tuya.

JR: Mucha gente me pregunta que tal es la vida por Dublin para la gente que se dedica al mundillo de la informatica, como se compara con Madrid o Barcelona etc. Asi que quizas muchos lectores encuentren esa pregunta interesante. Cuando estaba en Madrid, la verdad no me podia quejar, tenia buen ambiente de trabajo y un sueldo decente, aunque la vida de Consultor es bastante complicada yo tenia la suerte de ser un Consultor dedicado a un solo cliente, en uno de los grandes bancos. Creo que hice bien mi trabajo y me consta que el cliente estaba contento conmigo. Sin embargo me tocaba viajar todos los fines de semana a Galicia para ver a la familia y acabe bastante cansado. La razon por la que decidi irme a Dublin es porque ya lo conocia con anterioridad, en 2016 ya estuve 11 meses antes de irme a Madrid a Red Hat, y porque esta empresa me doblaba el sueldo de Red Hat, ademas de otros beneficios como 100.000 euros en acciones, 15% de bonus y mil cosas mas. A algun indeciso que se este planteando irse del pais a probar fortuna, si trabajas en el mundillo de IT, Dublin esta considerado el Sillicon Valley europeo, todas las grandes empresas estan aqui y hay muchisimas oportunidades. Al principio puede resultar duro por el clima, el problema de la vivienda, que es muy cara, pero al final compensa. Si la pregunta fuese: Recomiendas ir a trabajar a Dublin si te dedicas al mundillo de IT? Mi respuesta es rotundamente, Si. Si la pregunta fuese te arrepientes de haber dejado Red Hat, la respuesta seria otro Si, de hecho me costo horrores! Red Hat es una gran familia, los echo mucho de menos.❤

EED: Hoy es el último día de la entrevista y es el momento de la despedida, pero antes me gustaría agradecerte tu participación, espero que haya sido una experiencia interesante y entretenida para tí.

Puedes indicar tus métodos de contacto y si tienes algún proyecto, web, podcast o evento que quieras promocionar tienes este espacio para hacerlo.

Por último, me gustaría que me propusieras a una persona que tú creas que estaría dispuesto a participar en una futura entrevista.

Ha sido un placer , hasta la próxima.

JR: Muchas gracias, ha sido un placer participar. Podeis encontrarme en @jruariveiro en telegram, twitter y github. Me gustaria recomendaros a Eduardo Collado para una futura entrevista.

Doy por finalizada esta entrevista, la próxima será el 18 de Noviembre, a la espera de confirmar el entrevistado.

Todas las entrevistas se realizan en el canal de Telegram Entrevista En Diferido https://t.me/entrevistaendiferido