Candidate Architecture: OpenShift + Java/Spring + React

I am working in a project with some folks at 10Pines. The client is a big company with operations in most countries of LatinAmerica. From a functional point of view, the project is not so complex, but it has some interesting challenges:

  1. The redesign of  delivery process
  2. The enhacement of the SCM strategy
  3. The design and implementation of a new infrastructure based on OpenShift

In this article I want to focused on points 2 and 3.

Regarding SCM we are using Git (BitBucket) to store code …..and configuration, yes, configuration. We store configuration in a Git repository and make it accesible via Spring Cloud Config. At the same time we manage infrastructure as code, that is: the definition of all the infrastructure is written in code, basically Dockerfiles and other scripts. And of course this is also stored in a Git repository.

Regarding the new infrastructure we are using Docker on Kubernetes, or more specifically OpenShift. We consider we are taken too much risk, so we are not using all OpenShift features, for example we are not using the integrated Jenkins or the configMaps. We continue using our previous build process with some minor extensions, that is: our old and solid Jenkins takes care of the CI process, when we have a feature ready we build the corresponding artifact and publish it in Artifactory. Then Jenkins interacts with OpenShift to trigger the build of the corresponding Docker Image. The process of building the Docker image runs inside OpenShift and implies downloading the corresponding artifact from Artifactory. Once the new image is built and publish, a new deployment is automatically triggered. The following picture represents our build pipeline.

openshift_2

In terms of runtime, our application includes 2 artifacts: a RestAPI (built on Spring-Boot) and a React application (that is served by Nginx). Each of these artifacts is packaged into a Docker container. Finally we have 2 pods, each of them runs 2 docker containers: one that contains part of the application and another one that runs Spring Cloud Config. The following picture shows a summary of this runtime architecture.

 

It worth e mentioning that Spring Cloud Config container is instantiated in each pod but it is only accesible inside the pod.

To be continue…

 

 

Anuncios

Contraoferta laboral, mi vuelta a trabajar en una empresa

A pesar de estar trabajando de forma independiente suelo recibir ofertas para sumarme como empleado full-time de una empresa. En general no les presto mayor atención porque estoy muy conforme con mi situación y no tengo intención de volver a trabajar full-time en ninguna empresa.

Pero recientemente recibí una oferta para trabajar en una posición muy interesantes en un esquema part-time. Sin embargo sigue sin convencerme la idea de sumarme a una empresa sin conocerla por dentro. O sea,  me proponen seguir un proceso de entrevistas y si todo va bien… adentro. Demasiado riesgoso para mi gusto.

Trabajando independiente, cuando tengo un nuevo cliente no hago compromisos de más de 2 meses. En general propongo un primer proyecto corto de entre 4 y 8 semanas como para conocernos mutuamente y al cabo de ese período, si ambas partes estamos conformes, entonces vemos de hacer un acuerdo/compromiso de más largo plazo.

Basado en esto, cuando tuve que contestar esta interesante oferta lo hice con una contra-oferta (comparto un extracto del mail en envié):

[…] arrancaría haciendo algo chico en primera instancia y en función de los resultados y la experiencia, decidimos. Se que mi propuesta puede parecerte inusual pero miralo de esta forma: En vez de un proceso de selección basado en entrevistas en las que pueden conocerme parcialmente sin verme en la práctica, les propongo que hagamos un trabajo concreto en un lapso reducido de tiempo que permita conocernos mutuamente y mitigar los riesgos que ambas partes corremos al intentar iniciar una relación sin conocernos lo suficiente. […]

Recursos varios para aprender Node/JavaScript

Como mencioné hace un tiempo, me he visto en la necesidad de meterme de lleno con Node/JavaScript. Para ello he echado mano de 3 recursos:

  • Libros: tengo una lista de libros que me recomendaron, pero por el momento solo he visto dos libros gratuitos de la gente de Syncfusion: Node.Js Succinctly y JavaScript Succinctly.
  • Tutoriales de nodeschools
  • Sesiones de pair-programming con ingenieros experimentados

Y obviamente mas allá de todo esto: práctica, práctica y más práctica.

Si bien aún me queda mucho por aprender, hay algunas cuestiones que ya tengo claras:

  • El lenguaje JavaScript en términos de sintáxis no me gusta
  • La experiencia de desarrollo es muy “suave”, muy parecida a la experiencia en Ruby e incluso mejor en algunas cuestiones.

Continuará…

Encuentro con el Board de Agile Alliance

El jueves pasado en el contexto del Meetup de Agiles@Argentina se realizó un desayuno con el Board de la Agile Alliance. La Agile Alliance (AA) es una organización sin fines de lucro que busca dar apoyo a las personas que pretenden “aplicar agilidad”. En este sentido la AA realiza distintos tipos de actividades entre las que se destacan algunas conferencias muy importantes como AgileXXXX en USA y XP en Europa.

El evento abrió con una breve introducción de Emilio Gutter, un miembro de la comunidad local que colaboró con la AA en la organización de este encuentro. Luego cada miembro del Board se presentó y propuso un temática debate. A continuación los miembros del board se distribuyeron en las distintas mesas y largo la discusión.

Yo estuve en la mesa facilitada por Declan Whelan en la que hablamos sobre cuestiones técnicas. Entre los temas tratados destacaron: camino de adopción de prácticas técnicas, manejo de la deuda técnica y los riesgos de la agilidad sin prácticas técnicas. A la pasada tomé nota de algunos recursos para investigar:

  • Exercism.io, un sitio con ejercicios de programación que propone una dinámica de feedback comunitario
  • Agile Practice Guide, una publicación conjunta de la Agile Alliance y el PMI sobre como utilizar Agile
  • Theagilerevolution, un sitio de podcasts

En encuentro duró unas 4 horas y para mi estuvo muy bien.

Para cerrar: en la convocatoria había cupo para unas 100 personas y en la previa se agotaron todos los cupos. Sin embargo la cantidad de asistentes no superó las 80 personas. El eterno problema de las actividades gratuitas y la falta de compromiso. ¿Será un fenómeno Argentino o también pasará en otros países?

Proyecto fallido (porque no solo de los éxitos se aprende)

Hacia fines del año pasado una empresa con la que estaba trabajando me pedió que me encargara de automatizar los tests de una aplicación. Como yo ya estaba comprometido en otro proyecto con otro cliente, solo tenía disponible una dedicación reducida de 1 día por semana. A pesar de esto, el cliente quiso que yo me encarga de esa tarea y así lo hice.

La aplicación en cuestión ya estaba productiva y recibía actualizaciones frecuentemente. La idea era que yo avanzara con la automatización de tests trabajando de forma desacoplada del equipo de desarrollo. Y creo que ese fue precisamente uno de los errores. La aplicación no había sido diseñada considerando la testeabilidad lo cual llevó a que me cruzara con una importante cantidad de trabas al intentar automatizar.  Algunas de esas trabas eran esperables, pero al estar trabajando 1 día por semana y sin una dedicación explícita del equipo de desarrollo para darme soporte, el grado de avance semanal fue muy lento, a punto tal que fui yo mismo quien le propuso al cliente terminar el proyecto. A mi entender esta iniciativa requería: una persona full-time (o al menos con una dedicación de 20 horas semanales) y un tiempo explícitamente reservado del equipo de desarrollo.

Haciendo un análisis de lo ocurrido he podido identificar una situación en común con otro proyecto fallido en que participé tiempo atrás: iniciativa técnica con un baja dedicación mía y sin involucramiento explícito del equipo de desarrollo. La lección aprendida es: no involucrarme en proyectos donde no haya una dedicación explícita del equipo de desarrollo y donde yo no pueda dedicar un mínimo de 15 horas semanales.

Primer tema de investigación (casi) completo

En 2016 me uní al Grupo de Investigación en Prácticas y Procesos de UNTreF. Hubo varias cuestiones que me motivaron a unirme al grupo. Por un lado quería hacer una experiencia formal en investigación, por otro lado me pareció una buena oportunidad para estudiar un tema que me venía dando vueltas desde hacía un tiempo. Dicho tema tenía que ver con la gran popularidad de los métodos ágiles y mi sensación de abundancia de individuos y organizaciones “vende humo”. Con esto me refiero a gente más preocupada por decir que “es ágil” que por “realmente serlo”, gente implementado agile en forma incompleta (o flácida en términos de Fowler), mucha daily, mucho post-it y poco código decente. Con esta sensación en mente inauguramos una nueva línea de investigación dentro del grupo: Prácticas Agiles. Formalizamos la sensación con la siguiente hipótesis:

“Dentro del desarrollo de software existen distintos tipos de prácticas: las técnicas y las organizacionales. A partir de esto nuestra hipótesis es que las prácticas técnicas son mucho menos utilizadas que las prácticas organizacionales”

Para validar esta hipótesis realizamos un estudio empírico estructurado en 3 etapas dentro de la dentro de la comunidad ágil de America Latina.  Los resultados parciales de las etapas 1 y 2 los publicamos oportunamente en las ediciones 2016 y 2017 del CONAIISI. Los resultados finales surgidos de la tercer etapa y elaborados a partir de la encuesta que hicimos en Agiles 2017, los volcamos en un artículo que terminamos de escribir esta semana. Lo único que nos está faltando para cerrar esta tercer etapa de este primer estudio es la publicación de este artículo. La publicación resulta relevante por dos cuestiones: por una lado la validación formal de pares (fundamental en el ámbito científico/académico) y por otro la difusión del conocimiento generado. Ayer enviamos el artículo a una conferencia y ahora nos queda esperar el feedback que llegará dentro de un mes aproximadamente.

 

¿Queres aprender sobre escalabilidad de Software?

La gente Auth0 ha comenzado una iniciativa que ha dado en llamar Engineering BootCamp de la cual estoy siendo parte. En términos concretos esta iniciativa consiste en una serie de entrenamientos de entre 20 y 30 horas con un enfoque “hands-on” (algo así como 20% de teoría y 80% de práctica).

El primer entrenamiento será sobre escalabilidad y se llevará a cabo a comienzos de Febrero en las oficinas de Auth0 en Buenos Aires. La participación es totalmente gratuita pero como los cupos son limitados, los interesados deben completar un formulario de postulación y a continuación resolver un pequeño ejercicio de programación. La idea es que este ejercicio nos ayude a asegurar cierto nivel mínimo de conocimiento en los participantes.

Los interesados pueden encontrar más información y completar su postulación aquí. No se dejen estar que la postulación termina hoy (viernes 12).