El comienzo de un nuevo año es siempre el período de las buenas resoluciones y del balance del año pasado.

No, no te preocupes, no voy a anunciar el plan de las grandes maniobras de Qualilogy para 2015. En primer lugar, no hay un plan, y luego yo soy uno de esos 90% que no cumplen sus resoluciones, y no creo que hacerlas públicas va a mejorar esta baja tasa de éxito.

Simplemente, hace ya tiempo (1) que reflexiono acerca del impacto que el Cloud podría tener en la gestión de las aplicaciones y las buenas prácticas de programación.

Ahora bien, en 2014 he tenido varias veces la oportunidad de tratar de estos temas con diferentes interlocutores sin encontrar la más mínima reacción, o a lo mejor una cortés indiferencia: desde colegas y amigos consultores en calidad que nunca han encontrado a clientes preocupados con las aplicaciones en la nube, o directivos TI que ven claramente el Cloud como una nueva tecnología de moda, así como el Big Data, las aplicaciones móviles y el Internet of Things, y van a escuchar, hastiados, las interminables consideraciones sobre la urgente necesidad de incluirlas en su estrategia de TI con el riesgo de no poder cumplir con las evoluciones cada vez más rápidas en el negocio.

La « capacidad de respuesta a las demandas del mercado » y « mejorar el desempeño de los servicios de TI » son los argumentos más usados en la introducción de cualquier presentación, y por lo tanto los clichés más aburridos.

A la hora de imaginar lo que nos espera en este nuevo año, ¿es posible ver en 2015 más aplicaciones en la nube?

¿Dónde está el Cloud?

Las etapas del ciclo de vida de un nuevo mercado son bien conocidas: en una primera fase, los precursores tecno-entusiastas son los primeros ‘early adopters’ antes de que los beneficios de esta nueva tecnología sean demostrados y el mercado entre en una segunda fase de adopción, si no masiva, al menos más amplia, y de crecimiento.

Creo que estamos probablemente entre estas dos fases. Además, basta con ver la madurez de ofertas de gigantes como Amazon, Microsoft, Google, etc. y también la ausencia de IBM, HP y otros CA, que podríamos considerar como una ruptura de mercado significativa de una nueva ola tecnológica. Bueno, no voy a preocuparme por ellos: son más ricos que yo y ya han demostrado en repetidas ocasiones su capacidad para coger los trenes en marcha.

Pero hay una brecha que cubrir para pasar a la segunda fase: las ventajas para los primeros usuarios no son necesariamente relevantes para los directivos TI, si no responden a un problema o no tienen suficientes beneficios.

¿Quien está en el Cloud ?

Una startup que empieza sin tener su aplicación móvil en la nube, hoy en día, simplemente no hay.

Y si decides poner en marcha tu pequeña empresa, por supuesto que tienes otras prioridades que contratar a un director de TI y un equipo de programadores: tu eliges un programa de contabilidad y de gestión de pedidos en el Cloud. Y cuando puedes desarrollar un poco tu actividad, un Salesforce porque unos pocos previsiones comerciales y sobre todo un poco de visibilidad en lo que realmente hacen tus vendedores, sabes que siempre es mejor que navegar sin compás.

Pero cuidado: aquí es donde empiezan los problemas. Puede ocurrir que el programa no esté siempre disponible, o con un rendimiento totalmente asqueroso: todavía se puede entrar los pedidos con un poco de retraso, o explicar a tus empleados que su cheque llegará en el primero o segundo día del mes, debido a problemas informáticos. A veces, no siempre. Pero nunca debes dejar una oportunidad a tus Sales para que ellos digan que « eso no funciona ». ¿De verdad crees que van a dejar en tus manos una herramienta para vigilarles, sin quejarse por el tiempo que pierden a utilizar la maldita cosa?

Presión sobre el CIO

Si yo fuera el director de sistemas de información de mi compañía de seguros, estaría un poco preocupado. Hace ya tiempo que he sucumbido a los LinkedIn, Twitter y otros Facebooks para instalar su app en mi smartphone. Bueno, es cierto que en el metro, eso ayuda a tomar apariencia de alguien importante y muy ocupado, no como ese fulano adicto al Candy-no-sé-qué hasta olvidar de cortar el sonido.

En cambio, me he dado cuenta de que mi banco me acosa cibernéticamente con correos electrónicos para descargar su app en mi móvil. Sin mucho éxito: ya es bastante malo estar en el metro sin aún más molestarme a revisar mi cuenta bancaria, o pasar mi tiempo borrando sus mensajes para su última offerta de crédito milagrosamente preferencial y reembolsable en 50 años.

También me di cuenta de que mi compañía de seguros aún no ha dado ese paso. No sé si los miembros de su Board están en Facebook, pero estoy seguro de que sí, están en un banco y que, como yo, van a notar que nuestra querida compañía de seguros, de la que son los miembros más prominentes, no es ‘digital’. Eso puede poner un poco de presión sobre el CIO de la empresa.

Presión sobre el ciclo de vida de aplicaciones

Predecir la proliferación de apps móviles o la adaptación de sitios web existentes a una versión móvil (o ambos) no es realmente una revelación. ¿Cómo puede esto ayudar al Cloud para reducir la brecha entre la fase de los tecno-visionarios avanzados y la fase de adopción masiva por los actores más tradicionales?

Estas nuevas aplicaciones requieren una nueva estrategia de marketing, llamada « inbound marketing » (2), que consiste en atraer clientes a su sitio web a través de su promoción en las redes sociales, subscribirse a una newsletter, y blogs, podcasts y vídeos que mejoran las clasificaciones en los motores de búsqueda (Search Engine Optimization ou SEO).

Quién dice SEO dice « analytics », el estudio de todas las estadísticas de visitas y comportamiento de los visitantes de su sitio, por personas especialistas en « inbound marketing » que analizan estos datos, bajo el liderazgo de un Chief Digital Officer con el fin de identificar los mejores métodos para atraer y convertir visitantes en clientes potenciales. Pasan su tiempo en, por ejemplo, comprobar que un botón en la parte superior derecha de la página web, o en la parte inferior de un blog, o por medio de un popup, da mejores resultados en términos de registros en una newsletter o de descargas de un PDF.

Y por supuesto, van a pedir a los desarrolladores que mantienen regularmente esta app o este sitio web, que implementen estos cambios de acuerdo con sus análisis. Y claro, no en un mes, más bien al final de la semana. Esto pone más presión sobre los ciclos de vida de estas aplicaciones y los equipos de proyectos, fomenta la adopción de prácticas ágiles y de integración y de entrega continua.

Si estás capaz de entregar una nueva versión cada semana, pero no puedes implementarla correctamente en producción, tiene un problema. El clásico problema de DevOps cuando tu aplicación debe funcionar sobre differentes servidores de differentes tecnologías y edad, con diferentes sistemas operativos, diferentes versiones de Java, Tomcat u otro Websphere, etc. Y el ingeniero de sistemas que no logra que funcione en tal servidor llama al desarrollador que responde que sí, funciona en su propia máquina, y entonces el problema no es suyo.

También tu aplicación puede comportarse de manera diferente en algunos móviles o tabletas. La gestión de las pestañas en una página no es la misma con iOS y Android, y unos smartphones tienen un flujo super-lento y que prohíbe determinadas prácticas de programación. Así que se puede encontrar, para administrar una misma aplicación, proyectos independientes con un lenguaje específico para las diferentes categorías de móvil, lo que aumenta aún más la complejidad y la presión sobre los equipos de desarrollo y la producción.

Hay diferentes maneras de resolver estos problemas (los « containers Docker », por ejemplo), pero el Cloud es una solución que tiene muchos beneficios, pues se implementa la aplicación en una única infraestructura, centralizada, en lugar de dispersarla en varios servidores. Y a evitar dolores de cabeza en el manejo de los problemas de rendimiento y de indisponibilidad, ya que la nube tiene en cuenta las exigencias de elasticidad y la capacidad de responder automáticamente a los cambios en frecuencias de visitas. Tu CIO no quiere recibir una llamada del CEO porque quería poner a prueba en su smartphone esta nueva campaña de marketing y está esperando más de 10 segundos para acceder a cada página.

Transformación de las aplicaciones existentes

Si tu aplicación se basa en un nuevo desarrollo con un lenguaje específico para aplicaciones móviles (Objective-C, Android, etc.), resultará más fácil de tomar en cuenta las APIs específicas de cada proveedor de Cloud, y necesarias para el buen comportamiento de la aplicación (API REST, gestión segura de inicio de sesión, etc.). Creo que poco a poco vamos a ver nuevas mejores prácticas de programación específicas a la nube.

Si tu aplicación se basa en una código existente, tendrás sin duda que hacer las adaptaciones necesarias. No se puede simplemente empujar una aplicación en el Cloud y esperar aprovecharse de sus beneficios en términos de escalabilidad, sin una refactorización. O una reingeniería para cambiar la arquitectura del código, con un nuevo lenguaje.

Algunas aplicaciones también tendrán que adaptarse. Compré un altavoz Bluetooth hace poco y el vendedor me ofreció un seguro contra daños y robo con el pretexto de que se trataba de un aparato portátil que podría ser dañado o robado más fácilmente. Del mismo modo que te ofrecen un seguro médico y de repatriación cuando compras un billete de avión en Internet. Mi banco también me sugiere regularmente un contrato con un mutua privada (debido al mínimo nivel de servicio de la salud pública en España).

¿Crees que mi tienda de electrónica o tu compañía aérea o mi banco se han lanzado al mercado de seguros? No, utilizan los servicios de una compañía de seguros y sus aplicaciones en « marca blanca », es decir, configurable y personalizable para cada cliente para integrarlas en su propio sitio web y/o aplicación móvil. Lo que implica además una mayor presión sobre los equipos de desarrollo que mantienen estas aplicaciones y deben adaptarse a las frecuentes peticiones de diferentes clientes y a las especifidades de sus sitios, y por lo tanto una mayor presión sobre los equipos de producción. Son argumentos adicionales que militan en favor del Cloud.

Creo que también vamos a ver más y más empresas de servicios integrar el Cloud en su oferta. Algunos ya lo están utilizando en modo PaaS para el desarrollo y el mantenimiento de aplicaciones externalizadas, por lo que la continuación lógica sera de verlos proponer a sus clientes hacer las entregas en la nube, una buena forma de demostrar que han dominado esta tecnología, y integrarla en la renovación de sus contratos. Beneficios para el cliente y una ventaja competitiva para estas empresas de servicios.

Aplicaciones Mainframe Cobol

¿Qué hay de las aplicaciones Mainframe Cobol? ¿Pueden ser candidatas a una migración en la nube?

Si tomo de nuevo el ejemplo de mi compañía de seguros, hace ya tiempo que los empleados no trabajan directamente con un terminal 3270 (bueno, en teoría). Cuando voy a mi agencia bancaria, veo la persona que me recibe consultar mi cuenta a través de una aplicación Windows. Aun que parece a un viejo OS/2 o a una aplicación que ha conocido un revamping.

Sin embargo, estas aplicaciones ‘front-end’ son sólo la interfaz cliente de aplicaciones ‘back-end’ Cobol. Una transferencia bancaria, un cambio en el contrato de seguro o una suscripción a un nuevo servicio a través de esta interfaz será realizada por una transacción mainframe. Luego, programas Batch trabajarán durante la noche para pasar esta operación a otras aplicaciones, incluyendo la contabilidad.

Si, como lo hemos visto, estas aplicaciones ‘interfaz’ se multiplican en varias versiones de sitio web y apps para móviles, la presión va a caer también sobre los equipos mainframe. Un cambio en el front-end no siempre requiere una evolución correspondiente del programa ‘back-end’, pero cuando eso sucede, el desarrollador Cobol no podra responder « dentro de tres semanas ». También tendrá que adaptarse y adoptar las mejores prácticas Agile y encajar en el ciclo de integración continúa, e incluso de despliegue en producción.

Creo que esto va a animar a los directivos TI a pensar a llevar estas aplicaciones Cobol en el Cloud, por lo menos aquellas que son  ‘back-end’ de apps y sitios web móviles. Pero hoy no sé si existe una solución que permite empujgar estas aplicaciones Cobol tales como están, en la nube. Creo que deberíamos ver más proyectos de reingeniería de aplicaciones Legacy en Java, previa a una migración en el Cloud. Sé que este tipo de proyecto puede ser costoso y complicado. Pero si tenemos en cuenta que el coste del MIPS mainframe (entre $3.000 y $5.000 mínimo, la mayor parte en el software) es muy superior al coste del Cloud, la transferencia del Cobol a otra tecnología tiene un altissimo retorno de inversión.

¿2015, el año del Cloud para los desarrolladores?

No quiero caer en las predicciones que hacen de cada año, el año de la Nube. El Cloud ya está bien instalado por todo lo que es IaaS, y cada vez más para PaaS. Lo que puede, en los próximos meses, alentar una fase de adopción más generalizada para empujar aplicaciones en modo SaaS en la nube:

• Presión sobre el CIO para una estrategia digital con más aplicaciones y versiones móviles de sus sitios web, más Analytics y un Chief Digital Officer como stakeholder de estas aplicaciones. Podemos notar que los informáticos somos buenos candidatos para este puesto.
• Presión sobre los equipos de desarrollo y de producción para entregar y desplegar con mayor frecuencia más versiones de estas aplicaciones. Generalización de las prácticas Agile, de integración/entrega continua, de DevOps, pero eso no puede resolver todo. El Cloud permite ir más allá.
• Presión para transformar las aplicaciones existentes, Legacy o no, para empujarlas en la nube, y migrar las aplicaciones Cobol ‘front-end’ a la tecnología Java u otra compatible con el Cloud. Proliferación de las empresas TI que integran el Cloud en su oferta.

Y, por último, creo que deberíamos empezar a ver buenas prácticas de programación y métricas específicas al Cloud. Pero yo no sé si esto es una predicción o una ilusión.

                                          

[1] Ver La calidad en el Cloud, Elasticidad del código (1) et (2).

[2] A diferencia del « outbound marketing » , que consiste en ir hacia el cliente mediante campañas de correos electrónicos, llamadas telefónicas, publicidad, etc.