Nuestra evolución tecnológica

Mi primer día laboral @sodepsa, fue el 6-May-2013.

La difusa imagen de la cabecera, es la evolución de las distribuciones de Linux, rotada 90 grados. Gran parte del éxito de Linux se debe a la solidez de dos de sus más emblemáticas distribuciones: Debian y Red Hat (ver imagen en  Distrowatch).

Aquí presentamos nuestra evolución tecnológica; desde que me uní a este gran equipo.

Mis primeros chats cuando usábamos el Openfire como servidor de jabber interno.

haquino
2013-05-06.094744-0400PYT.html
dcricco
2013-05-07.145354-0400PYT.html
lpfannl
2013-05-07.170209-0400PYT.html
gzacur
2013-05-08.094440-0400PYT.html
rvillalba
2013-05-09.141443-0400PYT.html

Como profesionales de TI, nuestras decisiones empiezan por los Sistemas Operativos que elegimos como base para nuestros proyectos tecnológicos.

Sodep y Linux fueron un perfect match desde los inicios.

En el 2013 nuestro datacenter consistía en:

• Krillin: Un PFSense como router/firewall
• Kakaroto: Un hypervisor KVM, corriendo Debian 6.0 (Squeeze)
• Kakashi:  Backup y monitoreo de servicios. Una Mac Book 2007 (corriendo Ubuntu 10.04 LTS; con Icinga/Nagios).

La gran mayoría de las VMs corrían Ubuntu.

“Todos los animales son iguales, pero algunos son más iguales que otros” G. Orwell

También todas las distribuciones Linux son compatibles, pero algunas son más compatibles que otras.

Nuestra preferida es Ubuntu; porque nos hace la vida mucho más fácil. Tengo 21 años de experiencia utilizando Unix/Linux; trust me on this one, si sos un developer, el Sistema Operativo debe ser un medio y no una obligación o un obstáculo.

La distro con mejor balance entre innovación y estabilidad por muchos años; es Ubuntu.

Nuestro principal negocio es el software factory; por ende el cliente es quien decide la tecnología de su preferencia.

Cuando TI es una herramienta para tu negocio; por lo general se busca lo que funcione por el mayor tiempo posible; con el menor mantenimiento en lo que respecta a los servicios de soporte (Sistema Operativo, base de datos, servidor Web, etc.), sin sacrificar la seguridad durante el proceso.

Nos concentraremos en las tecnologías que recibimos del cliente, y las que luego nos tocaron sugerir para proyectos de reingeniería o innovación, con mayor libertad de elección.

2013

Esto pasaba por Stack Overflow. Menos del 50% de las compañías tenían una app mobile.

Al igual que el mercado, centrábamos nuestros desarrollos en Web backend y frontend.

Cuándo llegué; había trabajado muy poco con Spring;  en más de una ocasión debatimos con @danicricco sobre la utilidad de JSF y de JEE 6 (clásico) vs. Spring para cierto tipo de aplicaciones empresariales.

Como víctima personal del Síndrome de Estocolmo en TI y 7+ años desarrollando sobre JEE; era un defensor de la tecnología; básicamente me era útil a pesar de sus limitaciones y era relativamente fácil de conseguir colaboradores locales.

Nuestro stack en 2013:

Backend:

• Java 6 y 7
• Spring Framework 3
• JEE 6 y 7
• Apache Tomcat 6 y 7
• JBoss 5
• PostgreSQL

Frontend

• Javascript, JQuery y JQuery UI
• JSF
• Apache Freemaker

Mobile

• Android
• Eclipse + Plugin, como IDE

Cloud provider

• Rackspace

Project Management

• Redmine (con un plugin desarrollado in-house para armar sprints de Scrum)
• Scrum

Herramientas de soporte al desarrollo

• SVN y Git
• Apache Maven
• Jenkins
• MyEclipse con licencia por usuario

2014

Por Stack Overflow pasaba esto.

Cambios estratégicos

1. Dejamos de usar plain JEE 6, JSF y JBoss para pasar a Spring + Tomcat y frameworks livianos Javascript para el front.  Es lo mejor que te puede pasar si sos programador de backend Java, te permiten concentrarte en lo más importante de tu desarrollo.
2. De SVN migramos todo a GIT.
3. Pasamos al JIRA(🐢) por su flexibilidad y adaptación a Scrum.
4. Adoptamos Digital Ocean como Cloud provider, por practicidad (manejo más sencillo) y mayor cantidad de países para sus datacenters. Además a precios muy convenientes.
5. Dejamos Oracle Java, y pasamos a usar exclusivamente el stack proveído por el Ubuntu LTS del momento, esto nos aseguraba 5 años de soporte al usar OpenJDK.

Frontend

• Backbone y Marionette para SPA.  

   1) porque no es JSF.

   2) por su ligereza para el UI y su manejo de MVC.

• npm, Grunt, Browserify, Watchify y Bower para facilitar el manejo de dependencias, empaquetado, minificado y ofuscado en múltiples ambientes de deploy.
• SockJS para crear WebSockets.
• Freemaker + Javascript.

Backend

• OpenJDK 8 y Spring 4. Es reconfortante la facilidad para migrar entre versiones de Spring. Si te tocó como a mi, migrar entre varias versiones de JEE o JBoss AS, apreciarás esto más que al dulce de leche.
• Web sockets mediante Spring Framework.
• MongoDB. A la fecha tenemos más de 350GB de datos almacenados. Tuvimos 1 sólo problema, en 5 años; y fue por una falta de previsión nuestra al hacer un upgrade.

Cloud provider

• Agregamos Linode como proveedor, porque tuvimos algunos WTFs inexplicables con Digital Ocean con pobre respuesta del soporte.
• Hicimos unos deploys con Azure por requisito de un cliente,  experiencia suficiente para no querer volver a usar nunca. Moraleja: No uses Azure, si correrás VMs con Linux.
• Parse Server como MBaaS.

Herramientas de apoyo, devops + CI/CD

• Artifactory, para el manejo de dependencias maven y gradle.
• Gradle, para proyectos Android.
• Gitblit, una herramienta con administración Web para manejo de repositorios git.
• Eclipse STS.  El Eclipse de Spring.
• Slack para la comunicación.
• JMeter para análisis de rendimiento: Tuvimos la oportunidad de que una aplicación que desarrollamos sea utilizada en 9 países. Entre esos Chile (~2x), Colombia (~6x) y México (~20x) en relación a Paraguay. Un adecuado capacity planning desde 4 continentes y el remote client del JMeter; nos permitieron realizar los ajustes necesarios para que la aplicación funcione correctamente incluso frente a 20+ veces el tráfico para el que fue originalmente desarrollada.

Mobile

• Android híbrido

  1) Phonegap/Cordova. Malísima experiencia; sólo sirven de juguete.

  2) Custom Javascript + Nativo{Android y Objective C}. Buena experiencia en general; para una app que mayormente se usó sólo para mostrar información. Difícil de mantener en el tiempo, y la performance se degrada para pantallas complejas.

• Android Developer Studio. Paramos de sufrir con Eclipse y su plugin de Android, empezamos ya desde los early betas a usar el AS.

2015

Stackoveflow narraba esta historia.

Cambios estratégicos

1. Spring Boot: Otra genialidad de Spring/Pivotal. Empezamos a usar Spring Boot para nuestros desarrollos. Es la evolución natural para un stack Java/Spring.
2. Incluir Quality Assurance estático mediante proyectos Java para reducir e inventariar la deuda técnica.
3. Utilizar TDD en proyectos de integración de servicios, donde la mayor parte de la responsabilidad está afuera.
4. Utilizar IntelliJ en ciertos proyectos como IDE principal para desarrollos Java.

Backend

1. Spring Data en lugar del EntityManager, acompañó nuestro feliz desembarque al mundo Spring Boot.
2. Para los servicios REST empezamos a utilizar Json Web Tokens (JWT) en combinación con Spring Security para autenticación y autorización.

Frontend

1. Cambiamos de Grunt a Gulp para empaquetado de bundles JavaScript.

Mobile

1. En proyectos Android que compartían funcionalidades, empezamos a usar librerías comunes publicadas vía Gradle al Artifactory.
2. Swift para iOS.

2016

Una vuelta por Stack Oveflow

Nuevas estrategias

1. Incorporar groovy rules engine para problemas complejos con múltiples execution paths.
2. Convertir funcionalidades modernas y reutilizables en librerías open source.
3. Tomar la seguridad a nivel de código fuente y procesos de desarrollo como una prioridad.
4. Peer review previo a un merge, como un requisito para cualquier código no trivial.

Backend

1. Groovy: Para examinar gran cantidad de datos en corto tiempo y con la necesidad de categorizar según varias reglas; nos proporcionó una excelente performance con relativa corta curva de aprendizaje.
2. Publicamos @Github nuestros primeros proyectos Open Source, bajo Apache License 2.

 2.1 Implementación de JWT para su uso con Spring Security: Joko Security.

 2.2 Servidor de API REST para notificaciones vía GCM y APNS.

 2.3 Implementaciones de referencia de Joko Security.

Frontend

1. Proyecto open source Joko SPA Starter Kit. Un ejemplo fucionando es una de las mejores documentaciones que se puede tener. Este proyecto sirvió de base para varios proyectos que hoy siguen siendo usados en varios clientes.
2. Implementación de referencia de Joko SPA Starter Kit.

Herramientas de apoyo, devops + CI/CD

1. OWASP Dependency Check: Luego de una capacitación de varios miembros de nuestro equipo en aspectos relativos a seguridad de aplicaciones (Web y Mobile), aprendimos a medir y a tomar acciones sobre nuestra deuda técnica de seguridad. Hasta la fecha, a cada proyecto que entregamos, y a cada proyecto que ofrecemos mantenimiento; hacemos una revisión periódica de análisis de riesgos de seguridad. Nuestros clientes saben que cualquier hacking ético hecho sobre nuestros desarrollos, o requieren mínimas correciones o les informamos de la deuda conocida para que puedan tomar una decisión informada. @Sodep nos tomamos la seguridad muy en serio.
2. Find-sec-bugs (Hoy spot-bugs) para analizar vulnerabilidades del top 10 de la OWASP, a nivel del código fuente Java.
3. Gitblit tickets: Con un workflow similar a los pull requests de Github, nos permitía mediante peer review, colocar un paso previo al merge a un branch a pasar al siguiente ambiente camino a producción. Esto elevó la calidad del código que llegaba a producción.
4. Rocket.chat: Un gran descubrimiento que fue el reemplazo del Slack, utilizable on-premise. En Octubre del 2016 empezamos a usar el Rocket. Fue un salto casi automático; sin las restricciones del modelo freemium de Slack. Hoy, me animo a decir que el Rocket.chat es una mejor herramienta que el Slack, puedes optar por tenerla en tus servidores; o alojado en la Nube; todo esto Open Source.
5. Se retiró la última workstation de desarrollo que quedaba con Microsoft Windows. Salvo las computadoras del área de Administración; todas las estaciones de trabajo y servidores; eran OS X o Linux.

2017

Nuestro buen amigo Stack Overflow nos decía esto.

Decisiones estratégicas

1. ReactJS: Los frameworks Javascript con virtual dom inciaban su popularidad ascendente. Decidimos hacer unas incursiones en ReactJS, la apuesta de Facebook para el frontend.
2. Amazon Web Services: Pasamos de la etapa experimental y de investigación a armar presupuestos alternativos a IaaS; utilizando AWS en producción para varios servicios.
3. Incrementar nuestro portfolio Open Source.
4. Incorporar disciplinas de smoke tests antes de cada release.
5. Iniciar una colaboración con la Universidad Católica Nuestra Señora de la Asunción, emulando el Google Summer of Code: UCA Autumn (ex Summer) of code; como una forma de generar sinergia entre la academia y la industria.

Mobile

1. Generamos proyectos open source templates para aplicaciones mobile Android e iOS.

Backend

1. AWS: Cambiamos la forma principal de deploy a la nube, de un enfoque basado en IaaS a SaaS. Por requisitos geográficos/legales de un cliente; Amazon era el way-to-go. Una combinación de EC2, Elastic Beanstalk, RDS y VPC conformó la nueva arquitectura SaaS based. De nuevo la belleza de Spring nos permitió deployar nuestros servicios con mínimas modificaciones a AWS.
2. Unificamos en una librería, múltiples utilidades comunes de nuestros proyectos, y lo liberamos como open source: joko-utils.

Frontend

1. ReactJS nos permitió generar formularios dinámicos de una manera más eficiente gracias a su concepto de components y props. La reutilización y mecanismos para documentar el uso de cada componente, fue un gran salto para el desarrollo de UIs SPA.
2. AWS: La flexibilidad de Amazon para disponibilizar recursos de manera distribuida mediante Route 53, CloudFront y S3; fue la pareja natural para la infrastructura de Backend SaaS.

Herramientas de apoyo, devops + CI/CD

1. Colaboramos con el proyecto open source Dependency-check. Fue aceptado un pull request de mejora para el proyecto @ Github.
2. Empezamos a utilizar Docker para distribución de ambientes de desarrollo y pruebas.

2018

Stack Overflow nos mostraba estos datos.

Nuevas estrategias

1. Utilizar Docker para herramientas de productividad: Sonarque, Gogs (Go git server), varios ambientes de PostgreSQL; entre otros formaron parte de la transición de VMs a servicios basados en Docker.
2. Analizar la migración a la nueva versión LTS del JDK. Java 11 finalmente se asentó como "El sucesor" del Java 8.

Mobile

1. Pasamos a utilizar Amazon SNS, para notificaciones Push. Como la gran mayoría de los proyectos Mobile modernos requieren push notifications; encontramos así una mejor forma de tratar con las notificaciones.

Frontend

1. Iniciamos el primer proyecto de 2+ años; basado 100% en ReactJS.

Backend

1. Empezamos a utilizar Spring Boot 2.x y Tomcat 9.

Herramientas de apoyo, devops + CI/CD

1. Migración a GOGS. Nuestro servidor de GIT Gitblit, dejó de tener mantenimiento. Encontramos un excelente reemplazo en el Gogs, una herramienta escrita en GO y con un flujo de trabajo muy similar a Github.
2. Pull Requests como peer review. Al migrar a Gogs; pudimos hacer el cambio de método para los peer review; y pasamos a utilizar los PR como paso previo a los merge para testing.
3. De 18 estaciones de trabajo para desarrollo; 14 son Linux  y 4 Mac Book Pro.

2019

Decisiones estratégicas

1. Automatizar más las revisiones de código estáticas.
2. Utilizar Web Reactive Frameworks.
3. Actualizar todo el stack tecnológico a sus versiones más recientes.
4. Fomentar el telecommuting. Iniciamos una prueba piloto para los que tenían 2+ años de antigüedad. La popularidad fue inmediata; y a la fecha permitimos que un porcentaje del trabajo pueda ser realizado desde sus casas para todos los que tengan 1+ años @Sodep. Estamos convencidos de que la confianza rinde más que el micro management, y los resultados nos están dando la razón.

Backend

1. Empezamos a usar Java 11 y Spring Boot 2.x. Con esto accedemos a las funcionalidades de tipo non-blocking operations (Web Reactive Framework).
2. Ubuntu 18.04LTS aseguró 10 años de soporte; con esto se convirtió en la opción por excelencia para proyectos de mediano a largo plazo. Recién el Ubuntu 24.04 estaría teniendo una vida más larga. En especial atractivo para el entorno financiero con sus ciclos de vida bastante más largos que el promedio en TI; esto significa una preocupación menos durante muchos años.

Frontend

1. Iniciaremos desarrollos con Vue.js. Según experiencias dentro del equipo; el Vue.js presenta más flexibilidad que React.JS cuando se desea implementar en un ambiente conviviendo con otros varios frameworks, además del ímpetu que está teniendo en la comunidad; nos inspira a probarlo.
2. Migramos a Webpack con Babel, para empaquetado y traducciones de código ECMAScript 2018 para mejorar el developer experience.
3. Integramos Prettier para delegar a la herramienta decisiones de formateo de código JavaScript.

Herramientas de apoyo, devops + CI/CD

1. Luego de capacitaciones sobre Peer Review y QA, decidimos incorporar a nuestro equipo para el segundo semestre; un cargo exclusivo de Quality Assurance para la etapa de desarrollo.
2. Automatizar lo máximo posible los análisis estáticos. El tiempo del reviewer es uno de los más valiosos para la empresa; automatizando controles previos; se optimiza el tiempo del Reviewer para concentrarse en encontrar oportunidades de mejoras en piezas claves del código.

Nos queda agradecer a todo nuestro equipo de colaboradores; sus ganas de progresar y aprender cosas nuevas han sido el mejor motor para promover estos cambios tecnológicos.  De hecho, la mayoría fueron iniciativas nacidas desde los equipos de desarrollo.

Estamos ansiosos por conocer lo que nos deparará este 2019.