202204-Modernizando aplicaciones legacy
0 recomendaciones214 vistas
El documento discute la modernización de aplicaciones legacy, centrándose en un caso real de una aplicación CRM desarrollada en 2007, que utilizaba tecnologías obsoletas. Se comparan las prácticas de desarrollo y operaciones de 2007 con las actuales, subrayando la importancia de aplicar principios de DevOps y mantener los sistemas actualizados para mejorar la eficiencia y reducir riesgos. Además, se destaca la evolución de herramientas y metodologías a lo largo de los años, enfatizando la necesidad de automatización y procedimientos de integración continua.
202204-Modernizando aplicaciones legacy
- 1. Modernizando aplicaciones legacy Cuaderno de bitácora, año 2007
- 2. ¿Modernizando? No vamos a hablar de utilizar tal o cual framework de desarrollo. Frontenders: ésto no va de React Vs Svelte Vs Vue Vs Remix Vs … Backenders: ésto no va de Springboot Vs Go Vs Rails Vs Django Vs …
- 4. ¿Aplicaciones Legacy? ● Wikipedia a. Sin soporte técnico b. Heredado de alguien o de otro sitio o de otra versión más antigua c. Sin testear
- 5. Código “antiguo”, o que funciona
- 6. Entonces, ¿qué vamos a ver hoy? ● Un caso real de una aplicación desarrollada hace mucho tiempo ● Qué impacto ha tenido el paso del mismo en las operaciones ● Qué buenas prácticas de la filosofía DevOps se han aplicado
- 7. 2011 Liferay, Inc - Soporte - Training - Core Eng - Testing CI/CD Pero antes… mi trayectoria TECH 2006 Inicio Ing Téc. Inf. UNED 2007 Vass (Consultora) - SEUR, Carrefour - ISBAN, JCCM 2010 Indra - JCCM 2012 Fin Ing. Téc. Inf. UNED 2014 - Inicio Master UNED - Inicio GDG Toledo 2017 - Fin Ing. Téc. Inf. UNED - SOY PADRE PRIMERIZO 2019 Elastic - OpenSource - Eng Productivity 2005 ACLM 2003 Autónomo DUWEN SL JCCM 2002 - Ing. Sup. Inf. Carlos III - Curso Desarrollo INEM 2000 Diseño Web FEDETO 1993 - CPC - Calculadoras programables
- 8. De ti, hace 15 años
- 9. De ti, hace 15 años Allá por el año 2007, una PYME me encargó el desarrollo de una “pequeña” aplicación de gestión: ● gestión de clientes ● gestión de tareas ● gestión de usuarios Vamos, un CRM al uso con operaciones CRUD por todos lados. Nada fancy. Ese YO de hace 15 años que le cuenta al YO de ahora qué es lo que hizo.
- 11. El software, año 2007 ● Java 6 ● Sin build system: Eclipse, hazlo tú por mí ● Apache Struts 1.3 ● jQuery + jQueryUI: CSS y Javascript de un backender del 2007! ● MySQL ● Código JDBC custom! ● Manual de operaciones TXT (apareció creo que en el 2012!!) ● SCM = carpeta sin versionado ● Windows XP como OS de desarrollo ● Windows XP como OS del servidor de producción
- 12. El software, año 2007 ● Estábamos haciendo este tipo de apps en mi trabajo ○ Struts 1.x ○ Sin build → dependencias a fuego en el “WEB-INF/lib” ○ Despliegue en OC4J ■ alguna dependencia había que instalarla aquí (parentFirst, childFirst…). I.e. XML parsers ○ Oracle DB ● Imité el modelo: Struts 1.x + Tomcat + MySQL ● CSS y Javascript con JQuery + JQuery UI ● Sin backup del sistema de archivos de la aplicación (PFDs) ● Funcionalidad para enviar los logs a mi correo al pulsar un botón
- 14. Las operaciones, año 2007 ● Lo desarrollaba en un Sony VAIO de mi mujer por las noches. Era un Windows. ● Eclipse > Click Derecho > Export to WAR ● Con un pendrive lo llevaba al ordenador del trabajo para continuar cuando podía ● Copiar “EL WAR bueno” al pendrive “DE ORO”, siempre el mismo ● Ir al cliente un viernes por la tarde, y tirarse allí toda la tarde haciendo pruebas ● Parar el servicio Windows del Tomcat 7 (no se toca la versión!) ● Backup de la BBDD usando el MySQL Admin UI (clicky clicky clicky) ● Copiar el SQL al pendrive “DE ORO” ● Ya de noche, cambiazo del WAR en el tomcat ● Arrancar el Tomcat 7 de nuevo ● Cruzar los dedos 🤞
- 15. “En ese momento era lo que mejor sabía hacer”
- 17. Developer Timeline ● @noradrex escribió sobre ello ya por el 2017 ○ https://jbolano.wordpress.com/2016/12/09/developer-timeline-1996-2016/ ● Aunque se hizo hasta el 2016, me sirve para lo que quiero mostrar, que básicamente es ○ Poner en contexto lo anticuado de los sistemas que utilizamos ○ El coste de no ponerse al día
- 18. Developer Timeline: ¿por qué? ● Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto. ● En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. ● En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías, añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve. ● En organizaciones. Para poder establecer el nivel de actualización de una organización de una forma más o menos objetiva.
- 19. ECMAScript 6 Windows 10 Android 6 Ethereum Win 8.1 Slack Coursera iPhone 5 2012-13 Papa Francisco RIP Hugo Chávez Iron Man 3 OAuth 2 Google Drive React Kotlin Docker 2010-11 Bin Laden Iron Man 2 Angular 1 Google Apps Azure iPhone 4 2009 Obama Avatar ECMAScript 5 Bitcoin Windows 7 iPhone 3 Go NodeJS 2007 Netflix Webhooks Windows Vista iPhone 1 1998-99 Matrix XML-RPC ECMAScript 2&3 JSON SOAP VisualStudio 6 Win98 Napster 1997 Titanic ECMAScript 1 DreamWeaver Developer Timeline 1996 Juan Pablo II USB LDAP, XML Outlook Win95/NT Java 1, PHP, VB JVM 2000 Efecto 2000 X-Men REST Subversion Windows 2000 2001-02 11-S LOTR 1 & 2 SharePoint WinXP OS/X Symbian LinkedIn 2004 11-M Bob Esponja Markdown Gmail Facebook 2005-06 Benedicto XVI OpenID Git Youtube AWS Jquery Twitter 2008 Crisis Mundial Iron Man Google Chrome Github Dropbox iPhone2 Android 2014-15 Felipe VI TypeScript 1 Vue JS HTML 5 OneDrive iPhone6 2016-17 Fidel, Trump Money Heist Angular 2 & 5 Android 7 .Net Core Java 9 Meetup Visual Studio .NET C#
- 21. A ti, 15 años en el futuro
- 23. ● Java 8 ● Apache Struts 1.3 ● Bootstrap 2.3.2 + JQuery (mismo CSS y JS de un backender del 2007!) ● Build con Gradle ○ Unit e Integration tests: separados! ○ Dependencias explícitas y pineadas ○ Package (WAR, Docker) ● IntelliJ como IDE (aunque uso Eclipse BIRT para reports en PDF) ● JDBC con una librería, ni hibernate ni JPA (https://github.com/aaberg/sql2o) ● JCS como cache local ● Junit + Static Analisis (PMD, Checkstyle, Spotbugs) ● DB migrations con FlywayDB El software, año 2022
- 24. ● Orquestación con Docker Compose ○ Imagen de Tomcat con el WAR de la aplicación dentro, generada por Gradle ○ Base de datos MySQL persistida con un volumen ○ Backups periódicas (BBDD y archivos) en Alpine Linux, subidas a Google Cloud ○ Filebeat para ingestar todos los logs ○ Metricbeat para recolectar métricas de host y de contenedores ● Trazas de APM y Logs enviadas a Elastic Cloud ● CI/CD con Github Actions ○ Todos los tests on merge commits y PRs ○ Release on Tags > WAR + Docker + ZIP > Upload a Github Release y push a DockerHub El software, año 2022
- 26. Las operaciones, año 2022 ● Código hosteado en Github ● Lo desarrollo en cualquier portátil, aunque uso Mac ● Reproducción del entorno de producción en mi build system ● Release automatizada con Github Actions ● DB migrations embebidas en el propio código (FlywayDB)
- 27. Las operaciones, año 2022 ● Backups automatizados y subidos a un bucket de Google Cloud ○ MySQL y ficheros (15 Gb, al coste de mucho menos de 1€ al mes) ○ Dos al día ● Elastic Cloud para “observar” logs y trazas de aplicación ○ Detección de cuellos de botella y operaciones más utilizadas y/o costosas ● Conexión remota por AnyDESK ○ Login en Github para descargar el ZIP con los descriptores del despliegue ■ Compose, GC credentials ○ Login en Docker Hub para hacer pull de la imagen ○ Restart el servicio de la aplicación con la nueva versión ○ 10 minutos
- 28. 2014 BILIB Cloud - Jenkins git-log 2011 Git SCM: Assembla 2012 Cache (JCS) Unit tests 2013 DB migrations (FlywayDB) SCM: Bitbucket Issue tracking (IDs) Commits con #IssueID 2017 Gradle build system Java 7 Tomcat 7.0.77 Docker 2019 - SCM: Github 2021 - Tomcat 8 - Github Actions - build - test - package 2022 Testing in Cloud?? - APM - Github Actions - build - test - package
- 29. Manu, aterriza ésto al desarrollo de Software Iluminao’!
- 30. ● Github, Gitlab, Bitbucket… on-prem pero con backups! ● Automatización de tareas con Github Actions y/o bots ○ Dependabot! ● Pull Requests y revisión (incluso si soy uno!) ● Git clone y listo para trabajar Versionado de código
- 31. ● Unit tests ● Integration tests ● Static code analysis ● E2E tests ● Deberían ejecutarse ANTES del package ● Promocionar el build para empaquetar si todo OK ○ NO generar paquetes si los tests se rompieron ● Automate all the things! Continuous Integration
- 32. ● Generar paquetes CON CADA MERGE a main (entornos reproducibles) ● Cada paquete es candidato a desplegar/entregar tal y como está ● Velocidad de entrega/despliegue Continuous Delivery
- 33. ● Runtime dependencies explícitas y pineadas ○ Servidor de aplicaciones (Tomcat) ○ Base de datos (MySQL) ○ Buckets ● Queremos CATTLE, no PETS ● Entornos reproducibles ○ Mejora el Onboarding ○ Test as the end-user Infrastructure as Code