El otro día estuve en el London Puppet User Group meeting y disfruté bastante de las charlas especialmente la segunda en la que mostraron un enfoque diferente en la definición de recursos orientado a provisionar varios servidores a través de Open Nebula y dejarlos configurados y operativos, todo ello a través de Puppet. Pena que todavía no he tenido la suerte de poder acercarme a London Devops y me alegro infinito de que Madrid Devops siga viento en popa, desde aquí mis felicitaciones a Mari Carmen por el empeño que está poniendo y a todos los que os acercáis a compartir por ese foro, ¿se nota que os echo de menos?

Una de las primeras cosas que me vinieron a la cabeza es que no estoy seguro de si la orientación que está tomando la gente de Puppet Labs va muy en la línea de lo que yo busco en su producto. Por un lado, mantener dos desarrollos separados para la edición Enterprise y la edición Comunidad y por otro, el enfoque hacia grandes corporaciones y hacia la incorporación de elementos cómo gestión de CMDB, Workflows, etc para mí rompe un poco con la mentalidad Unix: pequeñas herramientas que hacen muy bien su trabajo y que en conjunto te dan una gran flexibilidad. Personalmente me gustaria que se trabajara más en la parte de orquestación y en romper el enfoque nodista, decidir el estado de mis nodos, por uno mucho más orientado a conjunto o a servicio.

Me encanta mcollective, creo que es una herramienta muy potente, pero no dejo de verla cómo un loop ssh para ejecutar un comando en el resultado de la busqueda de nodos que cumplen ciertas características y no lo termino de enlazar con una orquestación más basada en estados cómo es puppet sino en acciones.

Por cierto, si tenéis tiempo libre y os interesa el tema de Puppet os recomiendo que le echéis un vistazo a los videos de la pasada Puppet Conf y también a este repositorio Git que ha compartido la gente de Wikimedia con los manifiestos que ellos están usando para gestionar su infraestructura.

Otra reflexión sobre puppet, antes de pasar a otro tema, me vino del descubrimiento que en las plantillas para ficheros tipo erb podía utilizar todo el código Ruby que quisiera y esto solucionó algunos de los problemas que me estaban rondando últimamente para definir algunas plantillas algo complejas. Desde entonces un run-run en mi cabeza no para de decirme si aplicando el mismo concepto no sería mucho más potente el uso de Chef que utiliza una sintaxis más amplia y te permite utilizar el juego completo de instrucciones de ruby en tus manifiestos. Hace tiempo que no pruebo Chef, pero comentando esto con gente de la conferencia me comentaban que la orientación de Chef no cambia únicamente en eso sino que también hay que tener en cuenta que al contrario que Puppet, la ejecución de la configuración en Chef en varias ocasiones consecutivas sobre el mismo entorno en el mismo estado podría no dar lugar a los mismos efectos. Aquí me vendría bien ayuda de gente que se haya pegado más con los dos sistemas, ¿cómo véis el estado del arte los Chefistas y los Puppeteros?

Y de paso aprovecho también para volcar a texto otra de mis inquietudes de los últimos meses. Hace ya tiempo que quiero ampliar mis habilidades aprendiendo y cogiendo práctica con un lenguaje de scripting que me ayude a ser más eficiente y amplie mis posibilidades. Al principio python parecía el camino adecuado, pero cada día que pasa siento que hay más y más herramientas de administración escritas en ruby, con lo que me crece la duda, por ahora sigo poco a poco la senda de python y ya sé que la respuesta a la pregunta es: aprende los dos, pero cómo el tiempo es limitado habrá que dividir los esfuerzos o priorizarlos, ¿cómo lo véis?

Una parte de la charlas posteriores entre cervezas y pizza que me encantó era lo que comentaba uno de los asistentes: “Yo no quiero a los desarrolladores anden tocando en mis servidores”, pero estuve pensando y creo que no sólo es la idea correcta sino que habría que ampliarla “No quiero a nadie rondando en mis servidores, ya sean de los equipos de desarrollo u operaciones y menos aún alguien de fuera”, si hay que hacer retoques en los entornos de producción estos deberían hacerse siempre desde las herramientas de gestión de configuración y cambios de tus entornos y a través de unos workflows definidos y probados ampliamente, nunca tener que realizar acciones directas sobre las máquinas. Otro de los comentarios fue que “los equipos de desarrollo quieren estar modificando continuamente lo subido y a veces van demasiado rápido”, y creo que aquí está otro de los puntos clave del cambio que estamos intentando llevar a cabo con mentalidades ágiles y devops: nuestro objetivo debe ser el de habilitar el cambio y potenciarlo, eso sí poniendo los mecanismos necesarios para asegurar el éxito: integración continua, desarrollo guiado por pruebas, automatización del despliegue, paso rápido entre entornos de pre y pro o despliegue continuo son los habilitadores para ello y tenemos que encontrar la mejor manera de integrarlos en nuestros ciclos para ganar en agilidad.

Y en el terreno herramientas, no puedo dejar de comentar una de mis favoritas en los últimos días es Vagrant, si no la habéis probado no tardéis mucho en hacerlo. Hace tiempo que estaba buscando un sistema que me permitiera gestionar facilmente máquinas virtuales en mi portátil de forma que si necesito probar algo en una Debian, Redhat o lo que sea pueda levantarla rapidamente tener un entorno configurado rápidamente y hacer la prueba y destruir la máquina. Para ello Vagrant es ideal, es un conjunto de scripts en Ruby, elo aquí de nuevo, que usan Virtualbox por debajo normalmente en modo no gráfico y que te permite levantar una serie de plantillas de máquinas virtuales (os recomiendo vagrantbox.es para descargarlas), además tiene integración con puppet y chef de forma que puedes indicarle que ejecute un manifiesto al arrancar y que te deje el entorno ya configurado según unos parámetros. Impresionantes las posibilidades también para los equipos de desarrollo a los que se puede pasar un entorno similar al de producción y ellos pueden ejecutarlo en sus máquinas para desarrollar, hacer pruebas, etc… Vamos, no hay día que no me levante al ritmo de un comandazo “vagrant up”!

Por último voy a dejar a continuación tres juegos de transparencias que me han gustado bastante en los últimos días y que creo que son bastante explicativas de todo esto al rededor del movimiento Devops:

Y lo más importante, si has llegado hasta aquí por favor deja tu comentario en la entrada para que generemos algo de debate al rededor del tema. Muchas gracias a todos.

Artículos relacionados:

• Charla: Gestionando nuestros servidores con Puppet
• Mudanza virtual de servicios a la devops
• Experiencias en la administración de sistemas con Software Libre
• Gestionando servidores con Puppet

- Cómo nuestro trabajo tiene un componente alto de resolución de incidencias y solicitudes que deben ser atendidas en un periodo muy corto de tiempo no pudiendo esperar a ser incluidas en el siguiente sprint al finalizar las dos semanas de este optamos por dedicar un porcentaje de nuestro esfuerzo diario al sprint en curso y el resto del porcentaje a las tareas del día a día, resultando ser bastante efectivo y sólo en algunos casos comiendose el tiempo de uno el otro.

- Inicialmente para que el salto de concepto no fuera demasiado grande no empezamos usando historias de usuario sino algo más parecido a una división por tareas y las valoraciones de dificultad estaban más enfocadas sobre el tiempo que le llevaría a cualquiera de nosotros llevar a cabo la misma que en la dificultad intrinseca de la misma. – Para evitar eternas discusiones de si eso era la forma “verdadera” de hacer Scrum les decíamos que nosotros hacíamos Scrutch no Scrum.

- La reunión de planificación del Sprint resulta mucho más útil que el modelo tradicional en la que alguien se encarga del diseño y el calculo de esfuerzos y luego todo el equipo debe responder por ello. Así todo el equipo recibe una visión temprana del volumen de trabajo y las dificultades y crea también una especie de compromiso con lo pronosticado, mucho mayor que si alguien te impone una cifra. Además el Planning Poker es divertido y también saca un poco la personalidad de cada uno a la hora de estimar tareas, ejercicio muy recomendable junto con las reuniones de retrospectiva.

- La pizarra con los postit y el burndown chart son una medida muy útil para que todo el mundo pueda ver de un vistazo dónde estamos y lo que queda por hacer para llegar al final del sprint a tiempo, además resultó un atractivo para el resto de equipos que no veían muy claro que hacíamos con los postit.

- Otro punto muy positivo fue el de la defnición de terminado para una tarea. Para nosotros en este caso no sólo siginificaba que estuviera hecho sino que estuviera provado, documentado y su correspondiente ticket actualizado, sin los cuales la tarea no se podía parasar a finalizada y así comenzar otra, con lo que todo el mundo tenía muy claro lo que había que hacer.

- Uno de nuestros fallos fue no conseguir una mayor implicación por parte de los distintos product owners, en muchos casos actuando la misma persona, vamos yo, actuaba cómo product owner, scrum master y miembro del equipo, lo que quitaba un poco el factor integrador que nos da el uso de Scrum. Otro fallo en algunos proyectos que implicaban otras areas fue no incluirlos en nuestro Sprint y simplemente esperar que para cuando nosotros estuvieramos en el punto de necesitar sus productos estos estarían listos.

- El product backlog es una herramienta que sigo utilizando para todo tipo de actividades para que nada quede en el olvido, se clasifique y se prepare su entrada a la ejecución.

- La valoración de la satisfacción creo que fue bastante grande y sobretodo una gran mejora frente a no utilizar ninguna metodología, quizá poco a poco se podría ir incorporando más conceptos puros de Scrum y mantener aquellas modificaciones que nos han sido de utilidad.

- Actualmente sólo lo usamos en momentos puntuales cuando aparece un trabajo que nos va a costar más de dos semanas y que debe ser llevado por varios miembros del equipo

- Constantemente pienso que Kanban podría ser una alternativa más global que nos permitiría también meter la gestión de incidencias y tengo pendiente que hagamos algún piloto para ver que tal nos funciona.

Artículos relacionados:

• Trabajar desde casa
• En el openstack EMEA day
• Experiencias en la administración de sistemas con Software Libre
• Sorteo en el departamento de IT

“Fotos de la vida cotidiana en Cambridge.”

From Vida en Cambridge, posted by Javier Turégano on 4/08/2011 (36 items)

Generated by Facebook Photo Fetcher

Artículos relacionados:

• Soltando lastre o el inicio de un viaje
• Aprender español en Cambridge
• Trabajar desde casa
• El tremendo reto de alquilar una casa en Reino Unido

Ver la politécnica en la que pasé tantos años y a los amigos en aquella época me ha dado mucha emoción, más ahora que me siento que estoy tan lejos de mi Albacete querida. Pero hay algunos detalles épicos en este vídeo:

- Las pintas del Po con su media melenilla y del Paliquín, sorry Javi en ese vídeo así te hubiera llamado.
- Cuando arranca el Turbo Pascal en el aula software 5 con los PCs, hoy en día, retro total, qué torrente de recuerdos.
- La publicidad “subliminal” del Fifa 99, menudos vicios en uno de los mejores juegos de fútbol de todos los tiempos.
- La cafetería, los pasillos, y toda la politécnica, qué de recuerdos buenos y malos.

Recuerdo ver el vídeo en el salón de actos en la presentación, no sin algo de verguenza he de reconocer, y si en aquel momento me dicen que iba a disfrutar tanto viendolo en ese momento nunca me lo habría creido.

Por cierto, para los que no me hayáis encontrado la primera vez que aparezco es cuando entra el Po en el aula de prácticas y de pasada se ve mi cara programando en uno de los PCs (3:07) y el segundo que yo ni reconozco es cuando le dan una paliza a la salida de la politécnica (4:40 aprox).

Artículos relacionados:

• Mis inicios en la informática
• III Encuentro ASOLIF
• Trabajar desde casa
• Experiencias en la administración de sistemas con Software Libre

La verdad es que con las ganas que le ha puesto a la página web estoy seguro que le van a llover los alumnos, el próximo paso empapelar Cambridge con cartelitos de spanishincambridge.co.uk.

Artículos relacionados:

• Soltando lastre o el inicio de un viaje
• Medio año de emigrante
• LaVidaEsCine
• La Mandarina

Bajo las escaleras hasta la planta de abajo mientras todo está en silencio y arriba siguen durmiendo. El ritual de abrir la “oficina” se ha convertido en abrir las cortinas que dan a la calle, encender el interné que ahora me ha dado por apagar por la noche y el portátil.

Debí haber captado el primer sintoma, que para ser Lunes había muy pocos correos en mi bandeja de entrada pero decido tomarlo por algo normal ya que lo revisé anoche antes de irme a dormir, deformación profesional. Comienzo a revisar la lista de tareas para esta semana y a organizarme. A continuación enciendo mis dos inseparables compañeros de trabajo desde que estoy en la isla: el chat y el skype. Otra nueva pista ignorada, apenas si hay gente del curro en el chat, pero aún así mi mente dice que debe ser por vacaciones o que aún no han llegado a la oficina. La idea de ir hasta la oficina me hace recordar los días de Agosto por la calle ferrocarril de Getafe, ida y vuelta a la oficina bajo un sol de justicia y ni una sombra dónde esconderse. Calor, que envidia, semanas leyendo en facebook a la gente quejarse del calor y yo creo que este año no “pisaré” una piscina. Aunque, hoy parece que el sol también se ha aparecido por aquí y puedo estar en manga corta, ¡milagro!. Este tema, a diario, genera comentarios de mis compañeros cuando me conecto por videoconferencia con ellos, ¿pero que haces con un jersey puesto en pleno Agosto? Ea, hijos mios, aquí esto es así. Para chincharles tengo puesto un cartel que pone Home justo detrás mio perfectamente visible por la cámara web, muahahaha.

Mi mirada a través de la ventana abandona al cielo claro de hoy y termina posada en la lavanda de la entrada de la casa. Decenas de abejas y abejorros también han empezado ya la jornada, incansables, inagotables, bien cansinos, siempre están ahí de flor en flor. No os creais que es un trabajo carente de riesgos, ya que por la zona acecha una araña bien “gordaca” que está haciendo el Agosto a costa de los abejorros cazandolos en su tela mientras se encuentra in itinere de una lavanda a otra. No sé si el seguro de Abajorros S.A. cubre este tipo de accidentes pero por lo observado son cada vez más comunes.

De nuevo de regreso a las 20 pulgadas que se han convertido en mi otra ventana, esta vez digital, por la que me relaciono con mis compañeros de curro. Pena que por aquí no se puede compartir el café con porras de las mañanas y los chascarrillos, de byte en byte, parecen un tanto descafeinados. El primer mes intenté pasarme a la costumbre inglesa del té, pero después de probar unos cuantos tipos de té me he dado cuenta que no hay quien le gane al cafecito de por la mañana para despertar. Mmmm, café, creo que debería meterme algo en el cuerpo para intentar arrancar. Pero primero voy a mirar si tengo alguna cita hoy en el calendario corporativo… Noooooooooooo, otra vez, ¿cómo ha podido volverme a suceder? El calendario dice: Asunción de la virgen ¿por qué nadie me ha avisado que hoy es fiesta? Cachis en la mar, mira que ando perdido en eso de las fiestas últimamente, quizá efectos de seguir haciendo el calendario de Getafe a pesar de estar en otro país.

Me encuentro fuertemente tentado de volverme a la cama, pero decido ponerme al día con los comentarios del Barca-Madrid de ayer y luego voy y me pongo a escribir todo esto. No prometo no irme a la cama después, que conste.

Va a ser verdad lo que dice mi mujer que desde que curro desde casa curro más. Lo de la separación es bien difícil, si vengo a ver algo de mis cosas al ordenador termino abriendo el correo del trabajo y encontrandome con algo urgente que demanda mi atención. Además desde que comenzamos las operaciones en Panama y ya tenemos un compañero de IT allí me toca muchas veces adaptarme a su horario, justo el opuesto al nuestro al menos durante la jornada de Verano, para poder coordinarnos.

En fin, el Viernes ya estuve por primera vez en la oficina que hemos alquilado en West Cambridge, justo al ladito del Willian Gates Building para que los tenga bien vigilados. Está completamente vacía y en una semana comenzarán los trabajos de reforma lo que quiere decir que en no mucho más de un mes podría estar trabajando allí. Estoy seguro que voy a echar de menos el caer rodando por las escaleras y en 5 minutos estar ya en el puesto de trabajo, más cuando empiece el frio (Winter is coming) pero durante el rato que estuve trabajando en la cafetería que hay frente a la oficina me dí cuenta que extraño el ambiente y el bullicio de la gente trabajando al rededor. ¡Qué demonios! Y a todos los pesados de mis compis que por mucha lata que dieran me daban mucha vidilla y que os hecho mucho de menos. Snif, snif. Seguiremos reportando.

Artículos relacionados:

• Soltando lastre o el inicio de un viaje
• Aplicando Scrum en el departamento de IT
• Experiencias en la administración de sistemas con Software Libre
• Madrid devops

La ubicación del evento, aka la “venue” para los angloparlanchines, era bastante chula y la sala estaba abarrotada cuando llegué, tarde a pesar de mi madrugón. Me perdí la primera charla introductoria, pero no me dolió mucho porque había estado en alguna anteriormente dónde se había visto lo básico de la tecnología.

A modo de introducción y para los que no lo conozcáis openstack, se trata de un proyecto que persigue la creación de una implementación libre y altamente escalable de “la nube”, principalmente en los temas relacionados con las infraestructuras cómo servicio (IaaS). El proyecto fue iniciado por RackSpace y la NASA pero últimamente está teniendo una gran aceptación y un gran número de empresas cómo Citrix o Ubuntu están participando activamente en el proyecto. OpenStack se divide en varios subproyectos que intentan abarcar los diferentes elementos necesarios para la construcción de estas nubes cómo son la provisión de máquinas virtuales, de almacenamiento o el servicio de imágenes junto entre muchos otros una consola de gestión web. Uno de los puntos fuertes de openstack es su API, o sus APIs ya que tb tiene una versión compatible con Amazon, que nos van a permitir relacionarnos de forma altamente flexible con nuestra nube.

Después de la introducción, las siguientes charlas cubrieron temas variados como por ejemplo cómo están contribuyendo las distribuciones al desarrollo y la integración de Nova con la intervención de la gente de Citrix (Xen Server), Ubuntu y los compatriotas de StackOps a los que fue un gustazo poder saludar por tierras inglesas y que a día de hoy han desarrollado una de las distribuciones de OpenStack más interesantes sobretodo si no quieres complicarte la vida en la instalación. La verdad fue una alegría ver que Ubuntu ya ha incorporado en varias de sus últimas versiones paquetes oficiales de OpenStack y también cómo Citrix también apuesta por openstack para su implementación de nubes, y en gran parte el exito es debido a la independencia de openstack del hypervisor elegido permitiendo así elegir el que más se ajuste a tus necesidades.

También fue curioso las varias referencias que hubo a temas cómo devops o al uso que hacen internamente para el despliegue de múltiples nodos mediante puppet o chef distintas empresas que están trabajando en la implementación de openstack. En Andago llevamos ya bastante tiempo siguiendo la pista de OpenStack y está en el roadmap migrar nuestra nuble interna de computación de un desarrollo previo a medida de IaaS sobre Xen a OpenStack sobre KVM, pero esperamos poder tener el primer piloto disponible en breve.

La charla de seguridad en la nube entre otros nos recordó lo importante que es en los casos que estas ofreciendo servicios de computación a clientes externos mediante virtualización la relación que existe entre el servidor anfritión físico y las máquinas virtuales. Hay bastantes iniciativas en este aspecto tanto desde fabricantes de hardware cómo intel a otras basadas en software cómo el uso de SE-Linux para conseguir una independencia total del host anfitrión y sus ahijadas virtuales. Por cierto, mencionaron un tipo de ataque que no conocía llamadobluepill.

Otro de los aspectos importantes que se comentaron durante la sesión fue cómo poder particpar en la comunidad de openstack y cómo se está organizando el desarrollo que muestran una comunidad robusta y sana y con una de las mayores proyecciones dentro del espectro del software libre. Por ahora y hasta no consiga elevar algo más mi nivel de programación en python mi granito de arena en el proyecto ha sido la traducción de gran parte de las cadenas de texto de Nova del inglés al español, aunque aún quedan unas cuantas nuevas que van aparecinedo cada día y os animo a contribuir.

Artículos relacionados:

• Experiencias en la administración de sistemas con Software Libre
• Red Hat EMEA Partner en Valencia
• Desplegando servicios en la nube
• Reciclaje continuo

En uno de los capítulos dedicado a la infraestructura como código nos cuenta cómo el reconstruir todos los servicios de una empresa ante una catástrofe debería ser tan sencillo como provisionar infraestructura en un proveedor de cloud no afectado por la catástrofe, aplicar sobre ella nuestra herramienta de gestión de la configuración para configurar todo lo necesario y rescatar del backup, aquel que estaba offsite y no fue afectado por la catástrofe, la versión más actualizada para los datos. Y si uno lo piensa bien, el tema debería ser así y nuestros esfuerzos como sysadmins deben de estar dirigidos en gran parte a objetivos tan loables cómo salvar a la empresa de la quiebra ante una catástrofe.

Cuando empezamos a implementar la plataforma de salud de Andago, uno de los primeros objetivos que me marqué y que hace tiempo llevaba intentando poner en práctica fue el de tener una buena política de la gestión de la configuración y del despliegue de las aplicaciones. En algunos de los proyectos internos ya se llevaba tiempo trabajando en esto pero normalmente en los proyectos y servicios de cliente no se había podido avanzar tanto como se debería, así que como siempre decimos una oportunidad para empezar de cero es una oportunidad para no volver a cometer los mismos errores.

Una vez definida la política, siempre sujeta a cambios y mejoras, nos pusimos a implementarla. Abriendo nuestro maletín de herramientas devops (marca Acme) decidimos utilizar subversion, puppet y los servicios de Amazon EC2. No voy a ahondar en cómo fue la implementación pero un punto que sí me ha resultado muy interesante ha sido el cambio en el modo de trabajar que hemos tenido que sufrir como equipo. Hace tiempo que venimos practicando Scrum como metodología ágil para los proyectos nuevos a desarrollar pero esta vez le sumamos el cambio que supone trabajar con la infraestructura como código. El trabajo habitual de un proyecto en la parte de configurar servicios en Linux suele ser de trastear mucho en la consola e ir documentando en nuestro wiki de referencia. En este caso el tema cambió y nos dedicamos a escribir el código de Puppet que se encargaría luego de hacer la configuración y además, con unos buenos comentarios, cubre una parte importante de la documentación del servicio.

Por otro lado sumamos que estamos trabajando de forma distribuida tanto en ubicaciones como en horarios, yo desde Reino Unido y luego equipos en España y Panama, el reto era bastante interesante. Lo bueno es que en lugar de estar toqueteando cada uno servidores en remoto lo que estabamos produciendo es código que se iba almacenando en nuestro subversion y que luego puede ser testeado, aplicado y pulido múltiples veces hasta llegar al punto deseado. A través de rsync empujábamos el código a instancias de Amazon y comprobando que todo funcionaba bien. Curiosas las sesiones de despliegue en la que todos en remoto estábamos conectados por ssh al mismo screen y viendo cómo desplegaba nuestra criatura mientras comentábamos la jugada por skype.

El siguiente reto será ir por la integración continua y las pruebas automáticas, es decir todas aquellas cosas que siempre les estamos pidiendo a los desarrolladores pero que luego nosotros no estábamos aplicando a nuestro trabajo.

Por ahora no hemos sufrido ninguna catástrofe para comprobar lo narrado por el libro pero sí hubo un punto de prueba muy interesante. El equipo de negocio decidió que, debido a que nuestro público objetivo en gran medida estaría en Estados Unidos, el despliegue que inicialmente se había realizado en la zona de Irlanda habría que migrarlo a la zona de la costa este de gringolandia. Ciertamente aún no estábamos en producción y seguíamos en las fases tempranas del proyecto y eso facilita las cosas, pero la transición fue bastante parecido a lo descrito al inicio lo cuál no hace más que reafirmar que vamos avanzando por el camino correcto.

Artículos relacionados:

• Pensando en Devops
• En el openstack EMEA day
• Aplicando devops en una empresa TIC
• Experiencias en la administración de sistemas con Software Libre

Presentar en madriddevops era una espinita que tenía clavada ya que es uno de los grupos que más he disfrutado los últimos meses que estuve por Madrid. Las charlas suelen tener un gran nivel en los asistentes con preguntas y comentarios de un altisimo nivel, que incluso se ve incrementado en la tertulia posterior frente a las cañas, dicho sea de paso otro gran acierto del evento.

En la charla conté un poco cómo intentamos aplicar técncias de devops en Andago y entre otras cosas las dificultades para conseguirlo, lo que nos ha aportado y cómo algunas han sido exitosas y otras no tanto, pero que en general son una serie de prácticas revolucionarias en la forma de llevar a cabo nuestro trabajo y que lo han mejorado en gran medida.

Ahora estoy deseando que se celebre la próxima edición de Londondevops, uno de los grupos más activos en este sentido, y ver que se cuece por esta isla, a ver si con eso me quito la morriña de los grandes momentos pasados en madriddevops. Si estáis por Madrid os aconsejo no perder la oportunidad de participar en la próxima charla.

Artículos relacionados:

• Experiencias en la administración de sistemas con Software Libre
• En el openstack EMEA day
• Gestionando servidores con Puppet
• Madrid devops

Así que allá vamos con los Inicios.

Muchas veces digo que nuestra generación es la de los 8 bits, tanto por los ordenadores como por las consolas con las que empezamos nuestras primeras andanzas, en mi caso con un MSX que aún conservo. Quizá de ahí venga el amor a la línea de comando, a hacer programillas para automatizar las tareas más básicas o a interntar optimizar el rendimento de cualquier cosa que nos encontramos. Además con gran probabilidad estos inicios son los que luego hicieron que tiráramos más por los rumbos de UNIX que por las flamantes ventanitas del señor puertas.

Luego ya pasamos a la arquitectura x86, vinieron muchos ordenadores después, muchas horas trasteando con el DOS y probando programas y sacándole el jugo de una forma increible a cada cosa que podía hacer el ordenador. Así que cuando llegó la hora de elegir una carrera lo tenía bastante claro, la informática era lo mío.

Los primeros años de la Universidad los recuerdo con mucho cariño. Recuerdo lo duro que fue pasar los primeros cursos y la dura prueba que suponían las asignaturas como Calculo, Álgebra y Física que eran requisito básico para poder ganarnos el no sé si adecuado título de ingenieros. Aún me cae una gota de sudor cuando recuerdo un ejercicio llamado “Diagonalización de un endomorfismo” y todo un verano “encerrado” en la biblioteca (este otro post explica más bien en qué consistía eso) tratando de dominarlo para que luego años más tarde no sea capaz ni de recordar de qué iba la película.

Una vez superado el primer curso empezaban a aparecer algunas asignaturas más interesantes mezcladas con algunas otras que eran realmente decepcionantes y que no aportaban nada al camino que poco a poco había elegido para mi carrera: la administración de sistemas. Así que una vez superada la ingeniería técnica tenía que decidir por donde iba a continuar mi aprendizaje y así decidí comenzar varios caminos al tiempo:

- Comenzé los dos cursos que me faltaban para la ingeniería “superior o no técnica”, pero para motivarme decidí escoger todas las asignaturas relacionadas con los temas que me interesaban como la seguridad, la administración de redes o los sistemas operativos. No sé si fue un acierto o un error, pero una vez terminadas todas estas asignaturas me encontré con un montón de temas que ya no me interesaban para nada pero que por orgullo fuí sacando poco a poco hasta que decidí abandonar la carrera a falta de 4 asignaturas y el proyecto de fin de carrera. No había nada más que quisiera aprender allí y el título me parecía cada vez algo más algo totalmente innecesario.

– Comencé a trabajar en un pequeño ISP de mi ciudad, pero esto lo dejo para el siguiente post, en el que narraré las experiencias de mi primer trabajo.

– Una vez descartada la Universidad decidí dedicar mis horas de aprendizaje a enfocarme en las áreas que más me interesaban. Realicé el curso CNAP de CISCO por las tardes/noches y aunque no era tan práctico como esperaba amplié bastante mis conocimientos de redes. Finalmente decidí no certificarme porque costaba un pico y porque creí que los conocimientos que había adquirido los tenía suficientemente afianzados como para poderlos demostrar por otros medios. También realicé un curso de Solaris en la Complutense de Madrid, cuando todavía Solaris era el rey de los sistemas operativos de servidor y lo que demandaban las grandes empresas. Mucho más adelante y gracias a mi empleador pude realizar un par de certificaciones en Linux: LPIC-1 y RHCE. De estas me quedo con RHCE que como he comentado en otras ocasiones es el examen que más me ha encantado de los que he hecho en mi vida.

– Trastear, trastear y trastear. Siempre me ha encantado trastear en casa o con los amigos y creo que he aprendido muchísimas cosas de esas horas. Uno de los grandes éxitos de Linux, por poner un ejemplo, es que tienes a tu disposición en casa de la misma tecnología que tienen las empresas para ofrecer sus servicios, lo que es una ventaja enorme para el aprendizaje. Aún recuerdo como en mi piso de estudiante fuimos incorporando a nuestro servidor casero los distintos tipos de redes según estas iban evolucionando y se hacían asequibles a nuestro bolsillo. Primero teníamos toda la casa cableada con coaxial para luego pasarnos a RJ45 progresivamente en los cuartos y montar un puente entre ambas redes para los que aún no habían hecho la actualización y con el tiempo incorporar la tecnología inalambrica a nuestro super puente cuyo objetivo principal era poder echar unas buenas partidas al Counter Strike. En ese servidor teníamos nuestro correo, nuestras webs, nuestro ftp para intercambiar ficheros con la peña o nuestro servidor de Amule que echaba llamas, todo sobre un viejo 486 que ibamos renovando con las piezas que sobraban de nuestros PCs. ¿Se os ocurre un laboratorio mejor?

– Un día sentados en el curro delante del Barrapunto del día y viendo noticias de la útlima Hispalinux me giré hacia mi compañero de sistemas “el Chache” y le dije: “tio, ¿por qué en Albacete no tenemos nada de esto?”, tras hacer la pregunta a varios amigos y compañeros de la Universidad a los que nos encantaba Linux nos lanzamos a iniciar la asociación juvenil Linux Albacete. Es increíble la cantidad de cosas que he aprendido en las horas que le dedicamos a la asociación y así espero que lo sienta todo el que se acercaba a la misma, pues además de promover el uso de tecnologías libres el objetivo era el de compartir conocimiento entre todos nosotros, ¿puede haber algo más bonito?

Bueno, y podemos decir que después de todo este rollo introductorio, queda bastante claro porque decidí dedicarme profesionalmente al mundo del IT con tecnologías libres. En el sigueinte post os contaré las peripecias en mi primer trabajo como administrador de sistemas.

Artículos relacionados:

• Experiencias en la administración de sistemas con Software Libre
• En el openstack EMEA day
• III Encuentro ASOLIF
• Un manchego en el FOSDEM