Categories
54cuatro

App Modernization – modernizando las aplicaciones – 2/2

En el post anterior, analizamos estrategias de modernización de aplicaciones hacia la nube. En este post, vamos a analizar la modernización desde la vista de las áreas de desarrollo.

¿Qué hacer?

Seguimos manteniendo una aplicación legada, seguimos desarrollando sobre una plataforma obsoleta; o ¿arrancamos de cero?

Reescribir el código no es una tarea simple. Nos enfrentamos con código mal escrito, poco performante, y además es una tarea que requiere mucho tiempo.

Adicionalmente en caso de decidir reconstruir software, luego viene una etapa de migración del “viejo código” al “nuevo código”. Eso involucra 2 métodos.

  1. Una migración BigBang. Esta estrategia consiste en un apagado del sistema antiguo y un encendido del nuevo.
  2. Una migración gradual, donde se vayan reemplazando modularmente partes del “viejo código”, por el nuevo.

¿Cuando deberíamos refactorizar y mantener una aplicación como está?

Si el código actual funciona, y pueda ser mejorado, decidir seguir manteniendolo es una buena decisión.

Si el código tiene mucha inversión, se adapta a los nuevos tiempos y cumple su funcionalidad, mantenerlo es buena decisión.

Si el código no requiere de evolutivos/cambios, y no genera costos operativos altos, mantenerlo es una buena decisión.

¿Cuando deberíamos arrancar con cambio desde cero?

Aquel código legado, que corre en estructuras monolíticas y que requiere modernización para ir hacia arquitecturas SOA/Microservicios, requiere ser recreado bajo estándares modernos.

Aquel código que no puede adaptarse a metodologías Ágiles/#DevOps, requiere ser recreado.

Si la plataforma es insegura y el riesgo de robos de información o de fallas es alto, recrearlo es una buena decisión.

¿Por dónde comenzar?

Lo más importante es entender desde la óptica de negocios y desde la óptica de ingeniería en qué situación se encuentra una plataforma, y sea cual fuera la decisión, poder analizar los pro y contras de las tareas a realizar.

Si se ha decidido a realizar una modernización de sus aplicaciones, es necesario poder relevar todos sus componentes y generar un ‘mapeo aplicativo’ que contenga:

  • Detalles de los #frameworks utilizados
  • Detalles de la #infraestructura donde corre la plataforma
  • Detalles de integraciones
  • Detalles de bases de datos

Con toda este levantamiento de información se puede realizar un planeamiento sobre qué estrategia utilizar para modernizar una aplicación, adoptando frameworks nuevos, nuevos componentes de infraestructura como containers, bases de datos administradas, servicios PaaS/SaaS, etc.

En 54cuatro podemos ayudarte a realizar un #assessment y generar un roadmap de cómo modernizar tus aplicaciones. Contactanos para comenzar ya mismo con tu #AppModernization.


[popup_anything id=”2076″]

Categories
54cuatro

Algunas ideas sueltas sobre containers

No es novedad que los #containers ya son un standard de la industria, habilitan desarrollos ágiles, mejoran el #TimetoMarket, mejoran la analítica y generan un #ROI rápidamente comprobable.

Estamos en un momento HYPE de la era #Microservicios. Y vemos mucha adopción de esta arquitectura pero existe mucho camino por recorrer, y aún hay muchos que no pudieron a avanzar en este sentido y ya estamos hablando de #ServiceMesh, un nuevo componente que facilita la comunicación.

Pero que es Service Mesh?

El Service Mesh es una capa que mejora el formato en que las aplicaciones construidas en Microservicios se comunican entre sí. Anteriormente en desarrollos #Monolíticos o #SOA, las llamadas se hacían dentro de cada una aplicación o en comunicación entre capas. Pero en el nuevo esquema, las llamadas son reemplazadas por se realizan a través de comunicaciones #API.

Esto tiene ventajas importantes, ya que permite a los #desarrolladores concentrarse en la lógica del negocio y no tener que trabajar sobre la capa de comunicaciones. Pero existe un faltante de estandarización de la comunicación API, dado que no existe un protocolo definido para la creación de API.

En este punto es cuando Service Mesh se vuelve importante. Porque?

Porque es una malla de servicios que se para por encima de los microservicios, siendo una solución de baja latencia de comunicaciones que nos brindara descubrimiento para nuevos servicios, y con ello la posibilidad de crear reglas de load balancer, autenticación, cifrado, entre otras cosas, y permitiéndonos además tener un monitoreo que asegure la disponibilidad de nuestras API.

Existen muchos Service Mesh en el mercado como #Istio o #Envoy, y a partir de la versión 4 de #OpenShift existe el servicio OSMO (Openshift Service Mesh Operator) que habilita la posibilidad mejor seguimiento, enrutamiento y optimización de la comunicación de las aplicaciones.openshift y service mesh

Si necesitas modernizar la arquitectura escribime o llamame, así podemos determinar el nivel de madurez si tu empresa como para adoptar microservicios, el nivel de práctica #Agile/#DevOps y que con un #assessment podamos acompañarte al próximo nivel.

Publicado por nuestro Sales Director, Rodrigo Yañez en https://www.linkedin.com/pulse/algunas-ideas-sueltas-sobre-containers-microservicios-rodrigo-ya%C3%B1ez/

[popup_anything id=”2076″]