DevOps Practices Tutorial: Preparation Instructions

My DevOps Practices Tutorial covers a set of tools that my not be easy to setup, so I created a Vagrant configuration to simplify this setup. It does not matter if have no idea about vagrant (you will learn about it during the tutorial) but ensure to perform the following tasks before attending the tutorial session:

  1. Install Git
  2. Install Virtual Box (version 5 o newer)
  3. Install Vagrant (version 2 o newer)
  4. Download this vagrantfile and place it in a directory
  5. Open a terminal and move to the directory where you placed the vagrantfile
  6. Run the command vagrant up, it will download some stuff from the cloud, so it may take some time (depending on your connection it could take around ~10 minutes)
  7. When the vagrant up completes, you should the message «Welcome to NicoPaez DevOps tutorial»

Tareas de un DevOp Engineer

Hoy un colega me consultó si tenía alguna descripción de las tareas que debería hacer un DevOp Engineer y eso motivo a escribir este artículo.

Debo empezar diciendo que no estoy muy convencido de que exista la profesión  DevOp Engineer, o sea: me consta que existe pero dudo que sea conceptualmente correcta su existencia. Al margen de esto: actualmente estoy trabajando como DevOps Engineer en un proyecto, ¡ja!.

Vamos por partes: la idea de DevOps es derribar los silos organizacionales para optimizar el flujo de entrega de valor. Si tenemos un área de operaciones y un área de desarrollo, deberíamos apuntar a que comiencen a trabajar de forma más integrada. En principio no creo que eso requiera de la aparición de un nuevo rol porque en principio no hay una nueva tarea. Alguien podría pensar que sí hay una nueva tarea dentro del grupo de operaciones (o del de desarrollo) y que esa tarea es encargarse de la interacción con el otro grupo. Esto podría tener sentido (de hecho es una de las tareas que estoy haciendo en mi proyecto actual) pero no estoy convencido porque se corre el riesgo de seguir operando como silos.

Por otro lado, dependiendo del estado en que nos encontremos, puede que como parte de la iniciativa DevOps decidamos empezar a utilizar nuevas herramientas (por ejemplo para automatizar tareas). Entonces podría tener sentido incorporar un nuevo rol con conocimiento de  dichas herramientas y de los conceptos que las mismas implementan. Este es justamente mi caso: la organización a la que pertenece el proyecto en el que estoy trabajando ha decido dockerizar su infraestructura y justamente esa la razón de mi involucramiento en el proyecto.

Dicho todo esto, podríamos decir que las tareas de un DevOp Engineer incluirían principalmente:

  • Facilitar el trabajo conjunto de las área de Desarrollo y Operaciones
  • Asistir a los equipos de Operaciones y Desarrollo en las tareas de definición e implementación de arquitectura (lógica y física) de aplicaciones
  • Asistir a los equipos de Operaciones y Desarrollo en la definición e implementación de la infraestructura de CI/CD
  • Asistir a los equipos de Operaciones y Desarrollo en la definición de procesos de monitoreo.

De estas tareas se desprenden una serie de habilidades/conocimientos de distinta índole: «soft-skills», configuration management, scripting/programación, operación, etc. A mi me suena que una persona aspirante a un puesto así debería tener bastante experiencia en la profesión.

Para cerrar: lo importante es que desarrollo, operaciones y el negocio trabajen en forma conjunta, coordinada e integrada para optimizar el flujo de entrega de valor, la incorporación de un nuevo rol para lograr esto es un detalle de implementación.

 

Spring Config: a key tool for DevOps & Continuous Delivery

Spring Cloud Config (scc) is a tool that provides support to externalize application configuration in a REST Service. The big picture is:

  • Add a SCC client your application so when your application starts, it can fetch its configuration from SCC server.
  • Setup a SCC server, which is a Java REST Service (more specifically is a Spring-Boot application).

The following image offers a overview of how Spring Cloud Config fits in you application architecture.

Some benefits of this strategy are:

  • You decouple the evolution of your application from the evolution of the configuration, that is: you application will be the same in every environment while the configuration will be different in each environment. At the same time the change rate of your application is different from the change rate of the configuration.
  • Your application forgets about where the configuration it stored because it delegates that concern to SCC server.
  • SCC server supports several storage options: Git, File System, Vault, Database, ConfigMaps, etc. The default option is Git which is great because it «force» you to have your configuration versioned.
  • SCC provides several common features related to configuration management like: check the current configuration values, configuration reloading, encryption of secrets and support for different configuration formats among other things.

While working with SCC I faced some issues regarding how to specify its configuration so I want to share some details here.

To make SCC Server read configuration from a remote Git repository:

spring.cloud.config.server.git.uri=https://.....

(this would work fine for public repositories, but if you need to use a private repository, which is a common case, you will need to specify some more parameters like strictHostKeyChecking and privateKey that are very well explained in the official documentation). When SCC server starts, it will clone the remote repository into a local directory whose location will be generated randomly at runtime (but it is also possible to specify the clone location).

To make it work with a local git repository (which contains a .git subdirectory), just use:

cloud.config.server.git.uri=file:///your/local/git/repo

To make ir work with a local «plain» directory we need to specify active profile as «native» which makes SCC server to read the config from a plain local directory (not a git directory)

spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file:/your/directory

It worth mentioning that even when Spring Cloud Config is built on Java, you can use any client technology to consume it because it exposes a REST API. The Spring team provides a Java client, but there are also clients for other technologies.

 

Nueva edición del Taller de Prácticas DevOps incluyendo OpenShift/Kubernetes

El próximo jueves 3 de mayo voy a dictar una nueva edición de mi taller de prácticas devops, pero esta vez con nuevo agregado: OpenShift, la plataforma de gestión de contenedores desarrollada por Red Hat y basada en Kubernetes.

Hacía tiempo que tenía ganas de incorporar al taller algún ejercicio de Kubernetes pero no lograba buscarle para vuelta para que me dieran los tiempos. Finalmente decidí sacar un ejercicio de Puppet para agregar uno de OpenShift/Kubernetes.

Los interesados en participar pueden completar este formulario y los contactaré en breve:

Volver

Se ha enviado tu mensaje

Advertencia
Advertencia

¡Aviso!

 

Banca DevOps, nuevo proyecto

Desde hace un tiempo hay en Argentina un auge de transformación digital en el sector bancario, el cual suele incluir iniciativas Agile + DevOps. En ese contexto, fui contactado hace un par de semanas por un banco para colaborar en la optimización de su flujo de valor (en realidad el pedido vino por otro lado y después de un par de charlas derivó en esto).

Luego de un par de conversaciones con las personas que me convocaron, nos pusimos de acuerdo y accionamos. La idea es comenzar trabajando sobre un equipo en concreto, y luego incorporar gradualmente otros equipos. La intención es poder ir resolviendo problemas reales de los equipos y definir reglas/patrones a partir de generalizaciones de lo realizado en cada equipo.

Una de mis premisas de trabajo cuando participo de este tipo de iniciativas es definir criterios claros y objetivos de éxito. Muchas veces he visto iniciativas fundamentando su éxito en frases tales como «La gente se siente más contenta», lo cual puede estar bien para «la gente», pero muchas veces resulta insuficiente para quien paga. Tal vez sea una limitación mía, pero no he tenido éxito convenciendo gerentes con «sensaciones». Tal vez sea por mi perfil ingenieril: las sensaciones me parecen importantes, pero a la hora de tomar desiciones quiero números concretos. En este sentido, en el contexto de esta nueva iniciativa, hemos definido dos métricas iniciales como referencia: lead time y risk exposure.

Continuará…

Notas del Taller de CD + DevOps @Uruguay

La semana pasada estuve facilitando mi taller de Continuous Delivery y Prácticas DevOps en Uruguay.

El taller salió muy bien, hice algunas pequeñas modificaciones respecto de las ediciones anteriores: agregué un bolilla sobre herramientas de infraestructura inmutable y algunos patrones de zero-down-time release. El taller tuvo una asistencia record de 15 participantes y una evaluación final de 4,6/5.

Quiero felicitar y agradecer a mis colegas Pablo y Ely por la organización logística que fue impecable.

La próxima edición del taller será en Buenos Aires el día 2 de Octubre, más información aquí.

 

Agile2017, notes from my DevOps session

Agile2017, notes from my DevOps session

On Monday afternoon I deliver my session «DevOps, an adoption model based on Maslow’s hierarchy». There were about 60 participants, with a good balance of technical and non-technical roles. The session flowed as expected, the participants interacted in a very collaborative way. At the end of the session I asked the participants to rank the session (1 to 5) and I got an average of 4 🙂

Here are the slides I used during the session and here you can find some pictures of the participants and also of the posters created during the session.

Talleres segundo semestre 2017: DevOps, Continuous Delivery y Git

Para esta segunda mitad del año tengo planificado dictar los siguientes talleres:

  • Taller de Git, el martes 29 de Agosto, de 14 a 18 hs. en SADIO.
  • Taller de Continuous Delivery y Prácticas DevOps,  es un taller de 8 horas que dictaré el 15 de Septiembre en Kleer@Montevideo y el 3 de Octubre en Kleer@Argentina. El siguiente video explica brevemente el contenido del taller.

 

Notas del Meetup sobre Patrones de Infraestructura para Continuous Delivery

Si bien había más de 100 inscriptos la cantidad de participantes fue alrededor de 30, lo cual es está dentro de los parámetros esperados para los Meetup gratuitos de Agiles@Baires. La mayoría de los asistentes eran desarrolladores (~80%) y el resto se repartía entre gente de operaciones/sysadmins y gente de gestión. La audiencia estuvo muy participativa, hubo varias consultas e incluso algunos participantes hicieron aportes desde su propia experiencia.

A mi gusto la sesión fluyó muy bien, sobre todo considerando que fue la primera vez que la hice. Fueron alrededor de 80 minutos de exposición, con algunas preguntas intercaladas, y otros 20 minutos dedicados exclusivamente a consultas. De cara a la presentación en Agile, voy a tener que hacer varios ajustes y practicar un poco más, ya que el límite de tiempo que tengo es de 75 minutos y al mismo tiempo al ser una sesión en inglés es posible que no tenga tanta soltura en la oratoria.

Agradezco a todos los participantes por el feedback y les dejo aquí los slides utilizados.

 

Meetup Agiles@BAires: Infrastructure Patterns for Continuous Delivery

El próximo jueves 20 de Julio en el Meetup de Agiles Argentina estaré dando esta sesión. El título está en inglés porque la sesión la preparé originalmente para darla en la conferencia Agile 2017 y darla ahora en Buenos Aires me sirve en cierto modo como un ensayo.

Comparto algunos datos de esta sesión que pueden resultar de interés para la audiencia:

  • Formato: charla tradicional, basada en diapositivas, condimentada con algunas actividades interactivas.
  • Duración: ~80 minutos
  • Audiencia: gente de perfil técnico sin ningún conocimiento previo en particular
  • Palabras clave: continuous-delivery, devops, automation, infrastructure as code

La sesión está estructurada en 2 bloques:

  • un primer bloque introductorio donde repasamos algunos conceptos básicos de continuous delivery/devops
  • un segundo bloque dedicado a presentación de diversos patrones entre los que se incluyen: incremental environments, automation layers, multi-versioning y split pipeline entre otros.

La cita es en la Facultad de Ingeniería de la UBA (Paseo Colón 850), en el aula 403 a partir de las 19 horas (puntual). Obviamente es totalmente gratis pero por favor los interesados registrarse en la página del Meetup.