Había una vez un WordPress

Erase una vez un bonito blog WordPress … que corría feliz y libre por las tierras de una instancia. Allí era muy amígo de MySQL que también había nacido en esa misma instancia, y que se dedicaba a guardar los datos que, casi en secreto, le daba WordPress. Entre los dos habían creado una parcela en wp-config donde plantaban y cosechaban archivos. El orgulloso dueño de la instancia agregaba cada tanto algun plugin para lograr mejores resultados o modificaba el entorno para hacerlo más bonito, con cambios desde el galpón de themes.

Fue una época de felicidad.

Pero aparecieron «Los Innovadores» que le plantearon al dueño de la instancia muchas dudas: ¿que pasa si se cae? ¿hasta cuántos clientes simultáneos puedes recibir? ¿cómo lo migras? ¿es resiliente?

Y así el dueño de la instancia no conseguía conciliar el sueño. Por las noches se levantaba y miraba temeroso la instancia, consultaba las gráficas y el monitor, hasta hablaba con otros dueños de otras instancias.

Una noche, en que el dueño de la instancia caminaba por enésima vez en su sala, abrumado por el temor de que algo le pasara a su bonito blog, se presentó un hada que brillaba en la oscuridad y, tras enterarse de las preocupaciones del dueño de la instancia, solo le pronunción un conjuro mágico:

ku-ber-ne-tes

El rostro del dueño de la instancia se iluminó con el brillo equivalente al que emitida el hada. Esa noche, luego de mucho tiempo, logró volver a dormir y se selló el destino del blog.

A la mañana siguiente WordPress fue arrancado de la instancia que lo vió nacer para ser clonado en un laboratorio de última tecnología y nunca más se tuvo noticia ni de él ni de su felicidad. Ahora WordPress era una imágen que se ponía a correr, ya no en una instancia… ahora en un cluster, que es un lugar que no se sabe bien dónde queda.

MySQL, su fiel y productivo compañero, tuvo una peor suerte: fue sacrificado.

De aquella hermosa instancia solo quedó una valija con lo que había en la parcela wp-content y un pequeño estuche que contenía aquello que con amor habían juntado WordPress y MySQL: los datos SQL.

Ahora el blog pasó al control profesional de un Team de Desarrollo. Los datos SQL fueron entregados a la custodia de un Señor RDS, quién con mucha sobriedad entregó a cambio un Contrato de Calidad de Servicio. El contendio de aquella hermosa parcela wp-content fue desplegado en un volúmen (¿EBS?) que con entiquetas y unos pases mágicos de volumen claim permite que accedas a su contenido.

Nunca más se sintió felicidad, pero ahora el Team de Desarrollo tenía respuestas para todas aquellas dudas que atormentaron en el pasado.

Hasta el día que un desarrollador junior del del Team de Desarrollo abríó un mensaje en el Slack que decía:

«Voy a hacer una modificación, pero quisiera hacerlo en una copia ¿cómo hago?»

Eso… eso es otra historia… más triste aún.

Tabla periódica del DevOps

La empresa XebiaLabs mantiene una tabla periódica de las herramientas para DevOps que es una forma muy interesante de tener tanto nombre y herramientas ordenados en una forma visual y comprensible.

Las herramientas listadas tiene cada una un enlace que lleva a información adicional.

Fuente: PERIODIC TABLE OF DEVOPS TOOLS

Carguemos las pilas

Creo que he llegado a una nueva marca sin publicaciones en el blog desde abril pasado.

Una de las razónes es Deployando.Me el podcast de tecnología para sysadmin y devops que trato de mantener en forma períodica ¿ya lo escucharon?

Otra de las razones son nuevos proyectos laborales, viajes al exterior para distintas tareas profesionales y un montón de etcéteras que puedo encontrar, pues razones hay muchas pero…

el que no publica soy yo, y no es porque falte material o falte qué compartir.

Entonces, va este artículo como auto-compromiso de seguir publicando.

podcast: deployando.me

deployandome300x300 Comienzo una nueva etapa, un nuevo emprendimiento: el podcasting. Ayer publiqué el episodio Nro. 1 de deployando.me, el podcast para sysadmins y devops.

Ha sido un camino muy interesante hasta ahora. He escuchado algunos podcast de como hacer podcast (¿metapodcast?) y ha sido Podcast Pro una de mis referencias principales. También, he leido unos cuantos sitios con tutoriales y sugerencias para podcasters, como este, este y este otro artículo. Por supuesto, escucho y analizo otros podcast y podcasters de diferentes temáticas.

Me entusiasma el hecho de que el podcasting es algo evolutivo, que se sabe cómo empieza, pero no se tiene claro cómo o cuándo termina; confieso que no tengo planes más allá de un par de episodios por adelantado, ni aspiraciones más que las de satisfacer el autodesafío del podcasting.

Por eso, me entusiasma ese desafío y compromiso implicito del podcast. Un podcast que termina en unos pocos capítulos o un podcast de una periodicidad incierta tendrá una baja incidencia; pero un podcast regular que acumula una tradición de ediciones se vuelve un referente. Los ejemplos de esto sobran en cualquier catálogo de podcast.

Y así nace: deployando.me

Los invito a escuchar la edición Nro. 1 de deployando.me sobre Let’s Encrypt.

A suscribirse a los canales de podcast de iTunes, de iVoox, o directamente a sindicar el RSS en su programa de podcast favorito.

Por supuesto, si tienen cualquier comentario, sugerencia o crítica constructiva me pueden contactar o dejar comentarios del podcast.

Nota: este artículo me recuerda al primer artículo que iniciaba este blog en el 2004: En el ir y venir aquí estamos

Un blog en el 2015

De mi lectura diaria, me encuentro con un artículo publicado en Blog de Aula CM con 50 pasos para hacer o crear una página web o blog en 2015 que, en primera instancia, me resultó fuera de época (tal vez por la aclaración ‘2015‘) y trajo a mi mente la aparente caída de popularidad de los blogs frente a otras opciones para escribir y compartir en Internet.

Yo mismo mantengo una cierta pluralidad de lugares de producción de contenido. Este blog es el orígen fundamental de lo que comparto, pero también tengo el wiki, mi twitter y un emergente canal de youtube.

Varios conocidos coinciden en que un blog es una forma perenne de compartir sus conocimientos y con varios de ellos mantenemos vivo el Agujero del Mate.

Tengo otros amigos que optan por publicaciones en Facebook o Linkedin.  Sin ánimo de desmerecer el aporte intelectual siento que sus artículos se pierden fácilmente en una avalancha artículos («post«) de «copiar y pegar» del resto de los participantes de la red social en cuestión.

Tal vez no mucha gente le dedique actualmente tiempo a los blogs y prefiera «copiar y pegar» (lo hago en la sección «lo leí por ahi«), pero sigo reivindicando el blog personal en el 2015 como una fuente de referencia seria que generar identidad y permite compartir rápidamente.

lorem ipsum: nuevo aspecto para 2015

lorem-ipsum-big

Este blog comienza una nueva etapa: un nuevo aspecto con el nuevo dominio.  Igual manteniendo siempre la impronta de mi personalidad, de documentar lo que me llama la atención y de compartir algunas de mis opiniones.

En sus primeros 10 años desde que empecé el blog en 2004, siempre se llamó Río Pilas, en honor al río con el que compartimos nombre y que correo por Costa Ríca.  A partir de ahora se llama pilas.guru que es cómo deseo identificarme en La Red.

Espero seguir compartiendo mis pruebas, avances y conocimientos;  mis descubrimientos y mis aciertos y desaciertos.

Errores más comunes al usar WordPress

En el sitio jeffbullas.com, Ajeet Yadav ha publicado el artículo «The 15 Most Common WordPress Mistakes to Avoid», que describe algunos de los problemas más típicos que se encuentran cuando se navega entre blogs.

Desde mi punto de vista, los más representativos son:

#2. Mantener el usuario ‘admin’ para publicar artículos

Publicar con el usuario admin que ya se sabe que tiene todos los permisos (y no solo publicar) fomenta los ataques por fuerza bruta para lograr acceso. Crear otro usuario (con nombre distinto) para administrar y un usuario con permiso de publicar es una buena medida de seguridad.

#4. Mantener el subtítulo “just another blog”

Mantener el subtítulo por defecto, demuestra que no se le ha dedicado tiempo a conocer la herramienta, o uno es demasiado nuevo con ella.

#6. Categorías o etiquetas complicadas o inexistentes

A veces las categorías son extremadamente complicadas, pero a veces son inexistentes. Los blogs son fácilmente navegables y se obtienen buenos resultados de búsquedas si se han pensado las categorías y las etiquetas.

#8. No tener formulario de contacto

Es conveniente recibir feedback de los lectores y un formulario es mandatorio.

#11. Ignorar las actualizaciones

A veces se olvida que los códigos de WordPress son software libre y extán publicados, los analiza la gente buena y ‘los malos’. Los desarrolladores hacen un excelente trabajo mejorando el software, pero requiere de que los usuarios mantengan actualizado el código. Si no se hace, es muy probable que un día utilicen su espacio web para fines indeseados.

#13. Hacer difícil la navegación desde móviles

Hoy día es casi mandatorio que los temas elegidos puedan ser vistos desde móviles, o sindicados mediante RSS.

Seguramente leyendo el artículo de Ajeet Yadav se encuentren más cosas sobre las cuales prestar atención, pues hace una descripción más completa que la mía de cada problema y como actuar sobre el mismo.

Reivindicando la Terminal

Muchas veces nos subimos a la ola del desarrollo de aplicaciones cada vez más complejas y quedamos atrapados en una espiral de featuritis incremental. Entonces, cada tanto es bueno volver a los orígenes y ver como muchas problemas tienen soluciones simples que hemos olvidado (al menos yo).

Así me encontré con el artículo de José Román Hernández en Emezeta blog titulado La gran guía de supervivencia de la terminal de Linux.

En el artículo, José describe aplicaciones para uso exclusivamente en terminal para:

  • Explorar archivos
  • Multitarea y multiventanas
  • Leer el correo
  • Productividad y organización de tareas
  • Redes sociales
  • Gestores de descargas
  • Lectores de feeds
  • Ofimática y visores de documentos y textos
  • Navegadores web
  • Lectores de PDF
  • Reproducción de música
  • Reproducción de videos

todos con la característica de ser aplicaciones para la Terminal.

Creo que este es un muy buen complemento para conversar sobre la Actividad Terminal la próxima oportunidad que tenga para exponer sobre el tema.

¿Qué es un DevOps?

220px-Devops.svg DevOps MVD es un grupo de MeetUP que se ha formado en Montevideo con la idea es compartir entre desarrolladores y sysadmins distintas experiencias que mejoren nuestras capacidades DevOps; pero ¿qué es ser un DevOps?

En estos días llegó a mis manos un artículo que responde exactamente esa pregunta, así que esta es la traducción del artículo What Is a DevOps Engineer? publicado el 23.mayo.2013 en el Blog de Puppet Labs.

¿Qué es ser un DevOps?

(Por: Aliza Earnshaw – Traducción: Rodolfo Pilas)

La demanda de las personas con habilidades de DevOps está creciendo rápidamente porque las empresas están obteniendo grandes resultados de ellos.

Las organizaciones que utilizan prácticas de DevOps son abrumadoramente eficientes: actualizan código hasta 30 veces más frecuentemente que sus competidores, con un 50 por ciento menos de posibilidades que sus instalaciones fracasen, según muestra nuestra encuesta El Estado de DevOps del 2013.

Con todas estas ventajas, se podría pensar que había un montón de ingenieros DevOps por ahí. Sin embargo, sólo el 18 por ciento de los encuestados dijo que alguien en su organización realmente tenía este título.

¿Por qué sucede esto?

En parte, es porque la definición de lo que es un DevOps está aun en evolución. Sin embargo, esto no impide la contratación de DevOps. Entre enero de 2012 y enero de 2013, los listados de empleos para DevOps en Indeed.com aumentaron 75 por ciento. En LinkedIn.com, menciones de DevOps como una habilidad aumentó 50 por ciento durante el mismo período.

Nuestra encuesta reveló la misma tendencia. La mitad de los encuestados de más de 4.000 (en más de 90 países) dijeron que sus empresas tienen en cuenta las habilidades DevOps la hora de contratar.

¿Cuáles son las habilidades DevOps?

Los encuestados identificaron las tres principales áreas de habilidades para el personal DevOps:

  • Codificación o scripting
  • Reingeniería de procesos
  • Comunicarse y colaborar con los demás

Estas habilidades, apuntan a un creciente reconocimiento de que la complejidad del software de hoy en día se encuentra  en la creación y también en garantizar que el nuevo software funciona a través de un conjunto diverso de sistemas operativos y plataformas.

Del mismo modo, actualmente las pruebas e instalación se hacen con mucha más frecuencia. Es decir, pueden ser más frecuentes: si los desarrolladores se comunican rápido y regularmente con el equipo de operaciones, y si los operadores aportan su conocimiento del entorno de producción para el diseño de las pruebas y puesta en producción.

La discusión de lo que distingue a los ingenieros DevOps sobrepasa lo que se ha escrito en blogs y foros, y ocurre cuando los técnicos se reúnen.

Hay un montón de cosas para hablar, por ejemplo, cómo impulsar la codificación -no sólo el código- por encima del muro en las operaciones. Werner Vogels, el CTO de Amazon, dijo en una entrevista que cuando los desarrolladores asumen más responsabilidad de las operaciones, mejora la tecnología y el servicio a los clientes.

«El modelo tradicional trata de pasar el software por encima de la pared que separa el desarrollo de las operaciones y una vez del otro lado, olvidarse de él. No en Amazon. Usted lo construye, Usted lo corre. Esto hace que los desarrolladores estén en contacto con la operación del día a día. También quedan en contacto día a día con el cliente».

Sobre el bucle de realimentación con el cliente, Vogels dijo, «es esencial para la mejora de la calidad del servicio.»

Desde hace mucho tiempo desarrollador y empresario rico Pelavin de Reactor8 también ve los beneficios de la cultura DevOps en términos de una mayor responsabilidad de todos:

«He visto a las organizaciones donde los ingenieros tienen beepers, por lo que ellos son advertidos por el beep si algo sale mal [en la instalación y ejecución]. Eso los empuja hacia el resto del ciclo de vida del software. Creo que es una gran idea».

Eso es un cambio real para entornos no-DevOps, en los que los desarrolladores impactan los últimos cambios del día y se van a sus casas… o a la sala de ping-pong.

Y al final ¿qué es un DevOps? ¿Y quién los contrata?

No hay una carrera formal para convertirse en un ingeniero de DevOps. Ellos suelen ser los desarrolladores que se interesen en el despliegue de sus aplicaciones y en la red de operaciones; o los administradores de sistemas que tienen una pasión por secuencias de comandos y codificación e intervienen pasar a la parte de desarrollo, donde pueden mejorar la planificación de la prueba e instalación. De cualquier manera, se trata de personas que han empujado más allá de sus áreas de competencia definidas y que tienen una visión más integral de sus entornos técnicos.

Los DevOps siguen siendo un grupo muy pequeño, por lo que es razonable que pocas compañías tengan ese cargo. Kelsey Hightower, que dirige las operaciones aquí en Puppet Labs, describe a estas personas como las «Fuerzas Especiales» en una organización.

«El ingeniero DevOps encapsula profundidad de conocimientos y años de experiencia práctica», dijo Kelsey. «Está probado batalla. Es la persona que combina las habilidades del analista de negocios con las plantillas técnicas para construir la solución – además de que conoce bien el negocio, y puede ver cómo cualquier problema afecta a toda la empresa «.

Si DevOps se entiende como una forma de pensar, puede resultar confuso. Por suerte, muchas personas han probado definiciones como para permitirnos hacer una lista de los atributos principales del DevOps:

  • Capacidad para utilizar una amplia variedad de tecnologías y herramientas de código abierto
  • Capacidad para codificar y hacer scripts
  • La experiencia sistemas y operaciones de TI
  • Comodidad con las frecuentes pruebas de código incrementales e instalaciones
  • Buen conocimiento de las herramientas de automatización
  • Capacidad de gestión de datos
  • Un fuerte enfoque en los resultados del negocio
  • Confort con la colaboración, la comunicación abierta y pasar a través de fronteras funcionales

Incluso con un amplio acuerdo acerca de los atributos fundamentales del DevOps, nace la controversia alrededor  del término «ingeniero DevOps.» Algunos dicen que el término en sí mismo contradice los valores DevOps.

Jez Humble, el co-autor de Continuous Delivery, señala que sólo con llamar a alguien un ingeniero DevOps puede crear un tercer compartimento además de dev y ops«… claramente es una forma inadecuada (e irónica) para tratar de resolver estos problemas.»

Dice que DevOps propone «estrategias para crear una mejor colaboración entre los compartimentos funcionales, o acabar con esos compartimentos funcionales en conjunto y la creación de equipos multifuncionales (o alguna combinación de estos métodos).» Al final, Humble cede terreno al decir que está bien llamar a la gente haciendo DevOps por este término, si Usted quiere.

Para convertirse en un ingeniero DevOps: ¿Qué se necesita?

¿Se ha convencido de que DevOps es su futuro? Si es así, querrá empezar a ampliar sus habilidades y experiencia para competir por estos nuevos puestos de trabajo.

Por un lado, está bien reforzar sus habilidades de codificación, familiarizarse con las herramientas de automatización, pero también buscar proyectos y nuevas funciones que permitan ejercitar las habilidades «accesibles» que se encuentran en la esencia del DevOps. Además encontrar oportunidades para colaborar dentro y fuera de su equipo. Tal vez, ayudar en  su empresa para pasar a un régimen de pruebas rápidas y alto ritmo de instalación. Y estar abierto a escuchar las ideas de los demás. Tenga en cuenta que DevOps se trata tanto de hacer las cosas de una manera particular, y más acerca de cómo mover el negocio hacia adelante y darle una ventaja tecnológica más fuerte.

Más información sobre DevOps:

How Do You Make $100K in IT? Look to the DevOps Shops
Bridging the Two Worlds: IT and Networking
Hiring for the DevOps Toolchain: The Need for Generalists
DevOps Resources