Estamos en un momento en el que la mayoría de organizaciones ya están en mitad de procesos de modernizar aplicaciones para ejecutar cargas en Cloud. Y si no lo están, seguramente se plantean procesos a corto plazo.
En nuestra experiencia durante estos procesos de modernización, nos hemos encontrado errores, que nos han generado problemas y malas experiencias al modernizar aplicaciones, pero que nos ha servido para aprender la lección y no volver a cometerlos. Por eso, queremos explicar cuáles son los errores más comunes que nos hemos encontrado y consejos para superarlos y que el proceso de modernización de una organización sea todo un éxito.
Cuando estamos afrontando una modernización de aplicaciones es muy importante tener en cuenta todos los puntos de vista dentro de una organización. En muchas ocasiones nos centramos en uno o dos puntos de vista y no tenemos en cuenta otros que son igual de importantes.
- Podemos generar una solución muy compleja que cumpla todos los requerimientos del negocio, pero que sea inoperable por nuestros equipos de operaciones o imposible de mantener por los equipos de desarrollo.
- También puede pasar que esta arquitectura sea altamente ineficiente, ya que no cumpla los requerimientos de negocio (aunque sea altamente operable y el mantenimiento sea sencillo).
- Adicionalmente, en Cloud han aparecido nuevos jugadores que antes no existían o su rol era diferente, como por ejemplo los costes de infraestructura. Aquí cambia bastante la dinámica, ya que al ser pago por uso, el control de costes y su optimización tiene mucha importancia en las arquitecturas que se definan.
Un ejemplo bastante bueno sería pensar en estas nuevas arquitecturas como un cubo de Rubik: solucionar una cara es relativamente sencillo, pero hacer encajar todas las piezas es bastante más complejo, pero necesario si queremos resolverlo. - Es fundamental reunir a todos los intervinientes dentro de la organización para establecer las bases de esta modernización. En esta dinámica deben de estar todos aunque parezca ineficiente.
- En la definición de networking, por ejemplo, podemos pensar que únicamente es necesario involucrar a los equipos técnicos, cuando en Cloud esta definición está muy ligada a la definición de la organización y por tanto afecta al Governance de esta. Si definimos la organización sin tener en cuenta el Networking o el Networking sin tener en cuenta la organización, vamos a tener muchos problemas.
Uno de los grandes beneficios del Cloud es la reducción de costes y habitualmente es una palanca fundamental para plantearnos una modernización de aplicaciones.
Dentro de los marcos de Buenas Arquitecturas de los proveedores de las 3 grandes nubes (AWS Well-Architected Framework, Google Cloud Architecture Framework y Microsoft Azure Well-Architected Framework) la optimización de costes es un pilar fundamental, pero no es el único.
En todos los casos existen más pilares fundamentales a tener en cuenta, como puede ser la excelencia operativa, la seguridad, la fiabilidad o el rendimiento (e incluso la sostenibilidad).
Centrarse únicamente en el ahorro de costes puede provocar que no cumplamos buenas prácticas en alguno de los otros pilares, generando problemas en el futuro.
Curiosamente, focalizarnos en el ahorro de costes puede llevar a que a la larga (paradójicamente) nuestro ahorro de costes se vea comprometido y que el coste final sea mayor que el que hubiésemos tenido si no nos hubiésemos fijado solo en el ahorro de costes.
Todas las organizaciones ya cuentan con sus equipos, normalmente divididos en silos para gestionar las cargas de On-Prem. De cara a una modernización de aplicaciones, esta metodología de trabajo choca mucho con las buenas prácticas en Cloud y en las nuevas metodologías de trabajo de DevOps.
Un equipo multidisciplinar DevOps, o mejor dicho DevSecOps en Cloud, es más eficiente, debido a que, tal y como están configuradas y orientadas las diferentes nubes, la división entre Desarrollo y Operaciones está desapareciendo e incluso la división de roles dentro de los equipos operativos también.
Todas los proveedores Cloud recomiendan esta metodología que ya tienen implantada de forma interna.
En Cloud hay elementos que están totalmente integrados e interrelacionados. Separar su operación por roles es contraproducente y produce bastantes problemas operativos.
¿Esto significa que tenemos que despedir a nuestros equipos actuales? No, esto significa que tenemos que capacitar a nuestros equipos en estas nuevas metodologías, capacitarlos en tecnologías Cloud y generar nuevos roles.
Por ejemplo, hay un rol necesario y totalmente nuevo en Cloud como es el rol de FinOps que sería el equipo encargado de gestionar, monitorizar y disponibilizar los costes que generamos en Cloud para su optimización.
Aunque podemos pensar que es un equipo muy orientado a la parte financiera, realmente es un equipo que necesita grandes conocimientos en Cloud para poder identificar riesgos o desviaciones de costes en los diferentes proyectos, e incluso es un rol que se puede integrar en un equipo de DevSecOps
Existe otro rol muy especializado en la optimización de costes: el Cloud Economist. Es un término que acuño Corey Quinn y que básicamente son especialistas Cloud centrados en reducir las facturacion en Cloud, eficientando arquitecturas y descubriendo malas optimizaciones de costes.
Kubernetes es una maravilla y no vamos a ser nosotros quien ponga pegas a Kubernetes porque nos encanta y somos muy fans de Kubernetes.
Pero si que es una práctica cada vez más habitual usar Kubernetes para contenerizar aplicaciones legacy sin modernizarlas realmente. Básicamente realizar un Lift and Shift pero en vez de mover de servidor crear un contenedor de este servidor. Contenerizar una aplicación no es contenerizar un servidor; es algo muy diferente, pero se está extendiendo esta mala práctica.
También en ocasiones se intentan contenerizar aplicaciones que por su funcionamiento no tiene sentido contenerizar, como puede ser el caso de una BBDD, que se puede contenerizar pero no tiene sentido, ya que podemos usar un servicio gestionado que va a ser más eficiente y más sencillo de gestionar. Además es una aplicación completamente stateful que deberíamos de evitar contenerizar.
Este tipo de prácticas pervierten el modelo de Kubernetes, generando que en muchas ocasiones el mantenimiento y gestión de estos contenedores se convierta en algo muy problemático y muy costoso.
Una modernización de aplicaciones requiere un gran esfuerzo, involucrar a muchas personas de diferentes ámbitos y gran cantidad de tiempo.
Todo cambio siempre provoca cierta resistencia, y una modernización de aplicaciones, por las implicaciones que tiene, suele provocar una resistencia al cambio grandísima.
Si no se cuenta con un sponsor dentro de la organización que tenga el suficiente poder jerárquicamente para apoyar este proceso hay un riesgo grande de que en algún punto la resistencia al cambio sea lo suficientemente grande para sabotear el proceso.
En algunos casos esto puede llevar a incurrir en alguno de los errores que estamos viendo y en otros casos incluso a la total paralización del proceso.
Por este motivo es importante que este proceso de modernización de aplicaciones esté apoyado por la dirección de la organización y que en muchas ocasiones sea un proyecto estratégico.
Cualquier modernización de aplicaciones empieza por plantearse un Lift And Shift. Siempre pasa y siempre es un error.
De inicio todo parece ventajas: es rápido, la aplicación funcionará igual, reduce costes y se puede dedicar este tiempo sobrante a prepararnos para una segunda versión más optimizada en Cloud.
Si todo parecen ventajas, ¿cuál es el problema?.
Este gráfico de Forrest Brazeal lo explica muy bien
El problema principal de un Lift And Shift es que no estamos modernizando nada, simplemente estamos moviendo una carga de On-Prem y diseñada para funcionar en On-Prem a Cloud.
Realmente nos estamos llevando los problemas que tenga la aplicación y sumando los problemas relativos a ejecutar una carga en Cloud, ya que la aplicación no ha sido pensada para ejecutarse en Cloud y hay ciertas operaciones que varían mucho.
La operación y gestión en Cloud difiere mucho y los equipos más especializados van a ser muy reticentes en operar una carga así, ya que no está adaptada y muchos procedimientos tienen que ser manuales.Si por contra lo delegamos en el equipo que lo llevaba en OnPrem se van a encontrar con que muchas operaciones son diferentes y más complejas, además de poder provocar malas prácticas y usos del Cloud que deriven en caídas, degradación de servicios o impacten en el coste.
Inicialmente vamos a ver una mejora en cuanto a costes, pero rápidamente se va a ir degradando hasta llegar a un punto en que nuestra pequeña bomba de relojería explote y nuestro Journey to the Cloud sea un fracaso.
Esto no quiere decir que un Lift And Shift sea mala idea per se, pero nunca debería de ser un primer paso.
¿Cuándo es una buena idea hacer un Lift And Shift? Imaginemos que tenemos la mayoría de nuestras cargas en Cloud, pero por algún motivo tenemos que cerrar nuestro CPD en el que quedan muy pocas cargas, pero estas no se pueden modernizar, bien porque están al final de ciclo de vida o porque la modernización no se ha podido ejecutar a tiempo. En este caso sí puede ser una buena opción, pero son muy pocas cargas y ya tenemos experiencia suficiente en Cloud.
Los proyectos de modernización de aplicaciones suelen ser monstruos gigantescos y en muchas ocasiones tendemos a querer ejecutarlos lo más rápido posible.
Es cierto que suele haber una presión de fechas. En muchos casos es habitual firmar unos compromisos de gasto, que si bien son una palanca fundamental a veces para que la modernización de aplicaciones avance, son un arma de doble filo y provocan que queramos correr antes de andar. Es importante ir poco a poco y tomarse su tiempo en todas las fases, empezando por el diseño de la solución.
El diseño se va a llevar una parte importante del proyecto. Un mal diseño inicial nos lastra muchísimo durante todo el proyecto, mientras que un buen diseño puede solucionar muchos problemas futuros y ayudarnos mucho.
También es muy importante probar los diseños con alguna POC (Proof Of Concept o Pruebas de Concepto). Muchas veces al implementar un diseño y probarlo vamos a ver fallos y podemos solventarlos con tiempo. Esto no significa probar todo, pero sí las piezas que no hayamos usado nunca, las más críticas o con las que tengamos más dudas.
El último punto en la fase de diseño es la elección del First Mover y del orden del resto de cargas. Es vital elegir un buen First Mover y lo más recomendable es elegir una solución sencilla y significativa de la plataforma, pero que no sea core del negocio y que no tenga una criticidad altísima. Suele ser muy habitual, pretender que esta aplicación sea core del negocio o tenga más criticidad de las que se suelen proponer, pero es una mala idea.
En una modernización de aplicaciones siempre van a surgir problemas, y aquí radica la importancia de las primeras cargas a modernizar. Lo que se pretende en los primeros movimientos es ganar conocimiento, agilidad, confianza, etc.
Si decidimos modernizar nuestro core de negocio primero vamos a tener muchos problemas, generamos frustración, inestabilidad en la plataforma, un impacto altísimo en nuestro negocio y por ende un Journey to the Cloud fallido.
Si elegimos bien nuestros First Movers, también encontraremos problemas, pero menos y la criticidad e impacto será menor. Cuando lleguemos a nuestro core de negocio, la mayoría de problemas ya lo habremos solucionado en fases anteriores y adicionalmente nuestras skills serán más altas, por lo que no afectamos tanto al core de negocio y nuestro Journey to the Cloud será exitoso.
Cuando empiezas a estudiar arquitecturas Cloud en un primer momento es muy habitual igualar términos a On-Prem. Al final cualquier nube tiene servidores virtuales, balanceadores, tarjetas de red, enrutadores, gateways… Pero cuando profundizamos, vamos a ver que tienen muchas particularidades. Aparecen elementos nuevos, elementos efímeros de tipo serverless, elementos gestionados por el proveedor Cloud, elementos que funcionan diferente que en On-Prem y un sistema de permisos a los diferentes servicios bastante complejo..
Todo esto hace que usar cualquier nube como un tercer CPD sea un error. El funcionamiento, operación y diseño en la nube debe ser exclusivo para estas. Hay que ver las opciones disponibles de hibridación con nuestro On-Prem, pero siempre tratando las nubes como algo diferente.
La nube tiene sus pros y contras, pero si la usamos como un tercer CPD solamente veremos sus contras y nos perderemos la mayoría de los pros.
Si te interesa la modernización de aplicaciones, puedes seguir profundizando en el tema en estos podcast sobre la modernización de aplicaciones: moda o necesidad y cambio cultural.
Y también puedes aprender más sobre el tema conociendo más errores y otros consejos. ¿Tienes alguna duda? ¡Déjanos un comentario!
Tell us what you think.