02Jun

«To container or not to container»

En el mundo del desarrollo web es muy habitual no solo tener que desarrollar aplicaciones para diferentes lenguajes de programación, si no, además tener que actualizar o arreglar sistemas legacy.

Solución … más Docker

Trabajar con varias versiones de un mismo lenguaje, conectores, drivers, etc… puede convertirse en nuestro pequeño infierno diario. En nuestro caso, cuando afrontamos un desarrollo nuevo o modificación, dockerizamos el entorno a trabajar, lo guardamos en nuestro stack de Boilr, que nos servirá en un futuro en caso de encontrar versiones parecidas de las librerías para poder generar un entorno de trabajo con dependencias similares.

Nos facilita cualquier desarrollo, y al cliente se le puede entregar ya la plataforma que tenga dockerizada, por si quiere actualizar su sistema de despliegue y poder aislar las dependencias de su actual entorno.

¿Demasiado Docker?

En algunos casos, pocos casos, puede ser pesado o demasiado rebuscado usar Docker para cualquier stack en el que tengamos que trabajar.

Por experiencia, el caso de la compilación de Javascript o compilación de archivos SASS o LESS puede ser mas que una ganancia de tiempo, una pérdida el invertirlo en dockerizar el sistema ya que no aporta nada a la compilación final.

En algunos casos, como los expuestos, es posible que NodeJS con las dependencias locales o Virtualenv de Python, pueden ser suficientes para ser efectivo en el desarrollo y entregas.

Resumen

En sistemas donde interactuamos con Bases de datos, servicios de cache u otro tipos de servicios, si tendemos en general a usar Docker para trabajar con tranquilidad.

En desarrollo dónde solo interactuamos con compilaciones controladas y que no influye el sistema de compilación, basta con tener las dependencias correctas y no nos aporta nada el uso de Docker mas que el evitar usar una instalación local, no tendemos a usar Docker y trabajamos con dependencias locales.

 

Leave a comment