Mi primer año en Bullk

El 2 de Enero cumplí mi primer año en la "startup" Bullk Services y lo quiero festejar con esta imágen de una de las vistas que disfrutamos desde la nueva oficina.

Quiero compartir mi felicidad por este gran año de crecimiento en mi rol de Software Architect y la experiencia vivida dentro de una "startup".

En ocasiones existe mucho miedo con la palabra "startup" y es entendible dado que se asocia el "tamaño" de la empresa con el éxito, futuro o el desarrollo que se pueda tener dentro de la empresa.

Este año tuve la suerte de participar junto a un gran equipo en la creación y mantenimiento de una plataforma pensada para atender soluciones resilientes de gran porte diseñadas con un enfoque "cloud native" que en mi experiencia no hubiera podido experimentar si no aceptaba trabajar en una "startup".

Entiendo el miedo que en ocasiones nos da la palabra "startup" cuando estamos buscando trabajo pero puedo garantizar que las oportunidades de aprendizaje, crecimiento y experiencia que existen dentro de una "startup", no se comparan con las que existen fuera de este tipo de empresas.

Experimentamos grandes desafíos que los encaramos en equipo trabajando todos por un mismo objetivo y con las ganas que nos brinda trabajar en una gran empresa que algunos pueden llamar "startup".

Recomiendo vivir la experiencia y la adrenalina que nos brinda trabajar en una "startup".

Failed to create user (Unsupported or invalid SSH public key format)

Este error me lo encontré configurando un servidor sftp en aws, al crear un usuario con una clave pública SSH2 me daba este error. Revisando la documentación indica que AWS Transfer Family solo acepta claves públcias con formato PEM. 

Para solucionar mi problema tuve que convertir la clave pública SSH2 a PEM, simplemente seguí el siguiente comando:

$ ssh-keygen -i -f ssh2-key.pub > PEM-key.pub

Con esto quedo solucionado mi problema.

[Action Required] AWS Lambda end of support for the Go 1.x runtime

Hace unos días me llegó un mail con el título "[Action Required] AWS Lambda end of support for the Go 1.x runtime". 

En el mail explica los motivos y tiene los links a blogs de como hacer esta migración. Por lo que pude entender y el fondo de esto es que quieren que cuando se usen lambdas en go se usen con la arquitectura arm64 y no con x86_64. En mi caso lo tenía todo con x86_64 y ahora estoy haciendo el cambio ya que como indica la nota es mucho más barato usar esto.

En mi caso el cambio fue mínimo dado que solo tuve que cambiar el nombre del handler por bootstrap y listo, luego también cambiar la configuración en la lambda para que use la nueva arquitectura. Los detalles y la explicación en detalle se encuentra en este link.

Mis primeros 6 meses en una startup Cloud Native

Desde el 2 de enero de este año me encuentro trabajando en una startup cloud native y por ahora estoy mas que feliz. Muchos de mis colegas me comentaban lo negativo de trabajar en una startup y la verdad que hasta el momento no he visto nada de negativo. 

En una startup tienes la oportunidad de hacer todo y aprender de todo dado que al estar arrancando puedes hacer cosas que en una empresa grande ya tienen gente o roles definidos para esas tareas. En particular cumplo el rol de arquitecto y por lo general como arquitecto tienes los conocimientos teóricos como para diseñar aplicaciones pero muy pocas veces puedes realmente llevarlos a la práctica.  

En mi caso me gusta mucho experimentar y estar cerca de las soluciones que diseño, con esto me refiero a poder programar y si es necesario formar parte del equipo que la pone en producción. En mi actual puesto tengo la suerte de poder programar bastante usando Go como lenguaje principal y desplegar nuestras soluciones sobre AWS.

Hace 5 meses solo conocía la teoría de AWS para poder discutir de implementaciones en la nube pero ahora al tener la suerte de trabajar para una startup puedo hacer las implementaciones directamente tocando yo mismo los diferentes servicios en la nube.

Lo bueno de esto es que pude aprender a fondo muchos de los servicios que nos propusimos usar en una solución con una arquitectura orientada a eventos que tuvimos que implementar.  A continuación les muestro una imagen de la consola de AWS con los servicios que use recientemente

Como se puede ver en este tiempo tuve la oportunidad de aprender y poner en práctica mucho de lo que solo sabía en la teoría gracias a trabajar en una pequeña startup. Les recomiendo experimentar y si te gusta estar cerca de la parte técnica y no aburrirte en una empresa grande busques alguna startup que sin dudas vas a poder aprender mucho más rápido que en una empresa grande. Te lo digo por experiencia ya que tuve la suerte de trabajar en empresas de todos los tamaños y me di cuenta que en las pequeñas o startup es donde más se aprende.

A tour of Go

 A tour of Go es un pequeño recorrido por las características del lenguaje. La verdad que es muy recomendable si estas iniciando en go o si quieres tener las básicas del mismo. Tengo que admitir que no le di mucha importancia cuando comencé con esto pero me hubiera ahorrado muchos dolores de cabeza si lo hubiera seguido desde mis inicios en Go.

Echo de menos a GeneXus

 La última semana me ha pasado que extrañe el uso de GeneXus. Extraño la época en que mi tiempo de desarrollo era 100% en GeneXus independientemente del lenguaje para el que estuviera generando. Lo bueno de GeneXus es que puedes generar para varios lenguajes usando la misma base de conocimiento, eso hace que te puedas especializar en la herramientas sin tener que aprender varios lenguajes. 

En la actualidad el 90% de mi desarrollo lo hago utilizando Go, un 5% Java y el restante en Python. Al tener varios microservicios me pasa que en ocasiones tengo que tocar o manejar tres lenguajes cuando antes todo lo resolvía con GeneXus. Entiendo que hay cosas que se pueden lograr con Go que con GeneXus no eran posibles pero siempre le encontrábamos la vuelta. 

Espero en algún momento volver a trabajar con GeneXus ya que cada día que pasa lo hecho de menos.

Git Large File Storage

 El día de hoy  por primera vez desde que uso git tuve un problema al querer subir archivos grandes a github. Contexto: tengo un modelo entrenado con extensión pkl el cual pesa algo así como 280 MB, cuando quise subirlo a mi repositorio me dio el siguiente error:

remote: error: Trace: a30bc8551829cfe15407cd6a30fdf32fa02d500188c7d36f07e868f79f85f1ba

remote: error: See https://gh.io/lfs for more information.

remote: error: File modelacionrename.pkl is 278.13 MB; this exceeds GitHub's file size limit of 100.00 MB

remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.

To github.com:bullkservices/api-predictions.git

! [remote rejected] develop -> develop (pre-receive hook declined)

error: failed to push some refs to 'github.com:bullkservices/api-predictions.git'

Siguiendo el mensaje de error conocí la existencia de git-lfs, básicamente es un proyecto que nos permite almacenar archivos grandes en nuestros repositorios.

Seguí los pasos de la documentación pero mi error seguía sucediendo, investigando un poco me di cuenta que hay que seguir los pasos en orden. 

En mi caso lo que hice fue lo siguiente:

a) Descargar nuevamente mi repositorio

b) Ejecute el comando: git lfs install

c) Habilite el seguimiento de archivos grandes con extensión pkl: git lfs track "*.pkl"

d) En el paso anterior se creo automáticamente el archivo .gitattributes por lo que hice el git add . y commit

e) Agregue el archivo del modelo prediccion.pkl al repo, luego hice push con los cambios

Luego de hacer los pasos en orden pude subir mi archivo grande al repositorio.