Una perspectiva tecnológica para 2019
¿Cómo serán las aplicaciones que construiremos en los próximos años?
El objetivo de este artículo es repasar cuáles son, a nuestro juicio, las tendencias emergentes en el mundo del desarrollo y entrega de aplicaciones. Todo ello sin perder la perspectiva de que el desarrollo de aplicaciones a medida no supone la mayor parte del presupuesto de IT de las empresas, que lo dedican principalmente a la adquisición y parametrización de soluciones de terceros, así como a la integración con sus procesos de negocio. Es esta, pues, una visión que necesariamente nace con un doble reto, pues al riesgo de tratar de predecir lo que va a suceder en los próximos años en tecnología añadimos la no aspiración de representar una foto global del mundo de la empresa.
Para quienes no deseen profundizar demasiado, las ideas fuerza que vamos a repasar giran alrededor de los despliegues basados en contenedores, la generalización de las soluciones basadas en inteligencia artificial llegando más cerca del cliente final e incluso llegando al desarrollador, y la descentralización de la propiedad del dato como funcionalidad clave en algunas aplicaciones. Y todo ello, siempre basándose en estándares abiertos, que es por donde vamos a empezar.
Ecosistemas abiertos de desarrollo
Cualquier repaso a un cuadrante o curva de hype reciente muestra en la parte más innovadora tecnologías de nombre futurista que, poco o nada tienen que ver con la construcción de aplicaciones. Coches autónomos, drones, computación cuántica, materiales avanzados…
El desafío para las organizaciones es poder construir un ecosistema lo suficientemente abierto como para abrazar todas estas innovaciones de forma natural y construir con ellas activos digitales. Esto nos lleva a varias ideas muy relacionadas entre sí y que en su día fueron innovadoras, pero que cada vez más se dan por supuestas.
La forma de integrar tecnologías futuras ya está bastante asentada, con la idea de exponer los procesos de negocio como una plataforma de APIs abiertas. El plano técnico ya está más que resuelto (con multitud de productos para la gestión de APIs y los microservicios), pero quizás en el plano del negocio queda más por hacer: las APIs no funcionan únicamente como una herramienta de IT más avanzada que las antiguas arquitecturas SOA, sino también como la base sobre la que las compañías se pueden integrar con terceros, tanto para construir nuevos productos como para eficientar su propia operación.
Si se asume esta visión más transversal de las APIs, parece claro que el gobierno y diseño de las mismas también va más allá de los equipos de IT y debe ser asumido por toda la organización. En este caso vemos a la banca como el sector pionero que, azuzado por la competencia de las fintech y la propia normativa, dispone de su propia denominación: open banking.
Precisamente, el mundo open source sirve no sólo de ejemplo de cómo alinear diferentes visiones de cara a un objetivo común (el bazar contra la catedral) sino también como caldo de cultivo donde crecen las nuevas generaciones de desarrolladores que construirán las aplicaciones del futuro. Así, los vendedores tradicionales de tecnología van a abrazar este paradigma de colaboración, dado que al final la lucha por la relevancia comercial solo se podrá ganar estando en el top of mind del mundo de los programadores.
En general, ningún vendedor de software que aspire a situarse en primera línea del desarrollo de aplicaciones carece de una base de código abierto y de un equipo potente de evangelización de las comunidades, pero el caso de Microsoft es el paradigma de la reinvención. En los últimos años ha pasado a ser un referente en el mundo open source con la apertura de .NET Core y ha reforzado su posición con la compra de GitHub, poniéndose a la altura de referentes tradicionales como Google o RedHat, ambos con una hoja de servicios intachable en cuanto a compromiso con el código abierto.
Un movimiento similar se aprecia en la compra de Heroku por parte de Salesforce, que lo mantiene como un referente multilenguaje y multiframework de la comunidad, limitándose el plan de Salesforce al dotarlo de capacidades nativas de integración con sus diferentes nubes y posicionándolo como la solución más flexible para desarrollar aplicaciones de canal fuera de la nube de SFDC.
La propiedad del dato como feature
Si la propiedad del código ya no es una ventaja competitiva, ésta debe residir en otro sitio y el factor más inmediato es la posesión del dato, de cuyo análisis depende la posibilidad de ofrecer servicios y productos diferenciales.
La implantación de la regulación GDPR, que obliga a comunicar el propósito del tratamiento de los datos al consumidor, así como el impacto mediático de noticias relacionadas con el uso poco ético de los datos, están llevando al consumidor a desconfiar de los grandes proveedores de servicios en la red, tanto Facebook, como Amazon o Google. De entre todos los gigantes tecnológicos, Apple es el único que se posiciona como el garante de la privacidad del usuario y esta es precisamente una de las palancas que utiliza para justificar el mayor coste de acceso a sus dispositivos y servicios. Por otro lado, directivas como PSD2 indican al usuario no solo que los datos le pertenecen, sino que lo empoderan para transportarlos de un servicio a otro.
La pregunta que, razonablemente, se hará el consumidor final es: ¿qué puedo hacer con estos datos que me pertenecen?
La respuesta a este reto debe venir necesariamente por garantizar que cualquier contacto del usuario con los servicios que exponen las grandes compañías utilizan única y exclusivamente los datos imprescindibles y que cualquier dato generado a raíz de esa transacción queda en poder del usuario y éste tiene el control para revocar el acceso a ese dato.
Una opción viable es la construcción de aplicaciones que funcionen sobre tecnologías de blockchain, pero los retos de escalabilidad de las plataformas públicas y la complejidad de la custodia de las credenciales por parte del usuario hacen que, de momento, el uso de blockchain quede restringido a instalaciones privadas entre organizaciones, no como generador de confianza sino como repositorio de una confianza que se genera fuera del contexto de lo digital (como, por ejemplo, sucede en el caso del producto IBM Food Trust recientemente utilizado por Carrefour en una campaña con alto impacto mediático).
Otra alternativa es la separación no ya lógica, sino física de los datos y las aplicaciones que los consumen, que es el enfoque que plantea la iniciativa Solid liderada por Tim-Berners Lee con su startup Inrupt. En la visión de Berners-Lee, el usuario dispone de un servicio de almacenamiento de sus datos personales (alojado por él si tiene esa capacidad o por un proveedor de confianza que puede cobrar por este servicio) donde puede escoger qué aplicaciones tienen acceso a sus datos personales y con qué nivel de acceso (por ejemplo, lectura o escritura). Una aplicación construida conforme a estos principios garantizará al usuario el control de sus datos, el reto en este caso es encontrar un modelo de negocio que justifique este modelo de integración entre la aplicación y los datos del usuario.
La definición de “cloud native” incluye serverless
Serverless (a veces también conocido como FaaS — Functions as a service) es un paradigma de arquitectura técnica que supone delegar en un tercero la gestión de una pieza muy concreta: el servidor de aplicaciones. Esto limita el abanico de posibilidades pero promete una alta escalabilidad a un coste competitivo, con el riesgo de que la lógica de la aplicación queda fragmentada en diferentes bases de código difíciles de controlar. Para mitigar esto hemos visto en los últimos años la aparición de frameworks y herramientas destinadas a controlar los despliegues y entornos de ejecución de estos fragmentos de código, lo que ha contribuido a aumentar su popularidad.
El principal motivo de recelo para adoptar estas técnicas por parte de las organizaciones es el temor a que los vendors de cloud utilicen sus capacidades serverless como punto de entrada a su ecosistema, generando una dependencia a largo plazo del proveedor. Al igual que sucedió en su día con el desarrollo basado en contenedores, la industria reconoce este problema y aparecen soluciones como Knative, que permite el despliegue de funcionalidad serverless sobre entornos basados en Kubernetes. Detrás de esta propuesta están nombres como Google, IBM o RedHat y es de esperar que se una el resto de la industria.
Llevando esta tendencia a sus consecuencias más extremas, convendrá revisar el concepto de nubes híbridas, la solución que utilizan las organizaciones para combinar entornos on premise y cloud para distribuir datos, cargas de trabajo y los procesos de despliegue. En este contexto, las capacidades serverless sobre Kubernetes federado podrían incluso servir para mitigar las dificultades de combinar múltiples entornos cloud.
Edge computing
El agotamiento de la Ley de Moore supone un cambio en la evolución de la tecnología de base. Las expectativas en los próximos años pasan de mejoras lineales en la capacidad de cómputo bruta de los procesadores a mejoras basadas en la eficiencia. Caben esperar procesadores menos potentes, pero más económicos y eficientes en consumo, lo que implica su aparición más lejos de los CPDs (on-premise o en la nube) y más cerca del consumidor final, como ha sucedido con los móviles.
Estas capacidades ya se han trasladado a dispositivos, tan a priori poco sofisticados, como los equipos de reproducción de música, para convertirlos en puertas de acceso a experiencias conversacionales (Alexa, Google Assistant) convirtiéndolos en nuevo canal de interacción. O a cámaras como AWS Lens, que incluye la capacidad de ejecutar modelos de deep learning sobre el vídeo capturado directamente en el dispositivo.
Estos dispositivos (que a día de hoy se dotan de servicios centralizados en la nube) se pueden ver como el inicio de una tendencia descentralizadora que en los próximos años permitirá cumplir la promesa del Internet of Things: la posibilidad de construir aplicaciones transaccionales diseñadas para operar directamente sobre los dispositivos, no contra una infraestructura centralizada.
La clave es identificar qué tecnología es la más adecuada para garantizar la integridad de las transacciones, siendo blockchain una de ellas (pero no necesariamente la única). Un ejemplo es la iniciativa de Mitsubishi UFG que pretende implantar una red de medios de pago para los Juegos Olímpicos de Tokyo, contando con Akamai como el proveedor de infraestructura adecuado para la gestión y despliegue de la solución, utilizando su capacidad masiva de procesamiento.
Como conclusión de este apartado, la propia ubicación del edge va a cambiar, pasando de estar hoy localizado en los proveedores de acceso a Internet que contratan los usuarios, a encontrarse directamente en sus domicilios.
Ciencia del dato: del sandbox a la nube
Ningún proyecto de transformación digital ignora la relevancia de las soluciones basadas en IA como motor de construcción de aplicaciones modernas (entendiendo IA como un abanico amplio que cubre técnicas clásicas de machine learning como de deep learning).
Aquí, el reto reside en la propia metodología de desarrollo. El proceso de descubrimiento, entrenamiento y configuración de los parámetros del modelo es distinto del proceso de construcción del servicio productivo, por lo que es fundamental que los flujos de DevOps que se utilizan para entregar aplicaciones tradicionales basadas en microservicios, contenedores, etc, contemplen igualmente los ciclos iterativos de entrenamiento que exigen estas técnicas de IA.
Un ejemplo, nuevamente basado en Kubernetes, es Kubeflow, proyecto open source que permite cubrir el gap entre los frameworks típicos (Tensorflow, PyTorch, Scikit…) y los despliegues cloud basados en Kubernetes, microservicios, mallas de servicios, etc. El proyecto cuenta con el apoyo de vendedores como IBM, Intel, AWS, Microsoft y Google por lo que probablemente se imponga como toolchain de metodologías DevOps para el despliegue de servicios de IA, en una forma agnóstica al proveedor de cloud.
De forma colateral, la construcción de servicios que expongan capacidades relacionadas con IA dentro de las organizaciones permitirá la integración de estos servicios IA construidos a medida con las herramientas de automatización de procesos (RPA), más allá de las integraciones con servicios cognitivos de los proveedores de cloud que ya incluyen estas herramientas por defecto.
Relacionando la explotación de datos con la nueva ubicuidad del edge computing encontramos enfoques como el de Google, que plantea el concepto de aprendizaje federado como la técnica de entrenamiento de modelos de IA que se encuentran distribuidos a lo largo de nubes de dispositivos móviles sin necesidad de compartir un juego de datos común.
Lenguajes de programación: Python y Kotlin.
Python ha logrado convertirse en el estándar de facto sobre el que desarrollar soluciones de ML/IA. En este plano vemos imponerse a Python sobre alternativas como R por la mayor facilidad de puesta en producción de la solución y sobre todo, por el soporte de primera fila de Python por los frameworks de ML/IA que utiliza la comunidad investigadora (Tensorflow, PyTorch) frente a la ventaja de la que gozaba R en el soporte de técnicas más tradicionales basadas en algoritmos estadísticos.
En cuanto a aplicaciones de propósito general, las organizaciones han abrazado la tendencia del desarrollo basado en microservicios, tanto en ecosistema Java como .NET. En este caso, se echa de menos el equivalente Java al proceso de apertura que comentábamos antes por parte de Microsoft, por lo que emergen jugadores alternativos a Oracle a la hora de liderar la transformación del desarrollo sobre JVM. Uno de estos players es JetBrains, que con su lenguaje Kotlin emerge como solución flexible para el desarrollador, con un sistema de tipos y un modelo de concurrencia que lo hacen más amistoso y ágil, pero garantizando el 100% de compatibilidad tanto funcional como de despliegue con el resto de piezas del ecosistema Java (por ejemplo el popular framework Spring Boot). Con el soporte de Google, Kotlin goza ya del estatus de estándar de desarrollo en Android, lo que garantiza la popularidad del mismo no solo para aplicaciones nativas, sino para desarrollos en backend.
Desarrollo front: estandarización y llegada de la IA
Acompañando a la tendencia de los microservicios en el backend, el mundo de la tecnología que se ejecuta en el navegador del usuario ha visto en los últimos años la aparición de diferentes frameworks para el desarrollo de interfaces basadas en el paradigma SPA: Angular, React y Vue. Esta aparición ha sido más bien explosiva, generando lo que en la industria se conoce como la fatiga del Javascript: la comunidad de desarrolladores ya está suficientemente fragmentada y si bien no se visualiza una consolidación única, es poco probable que aparezcan nuevos frameworks más allá de los tres anteriormente mencionados.
Sin embargo, veremos el navegador, sobre todo en su vertiente móvil, ser utilizado cada vez más como un dispositivo de edge computing, al ser posible la capacidad de carga y ejecución de modelos predictivos y de deep learning directamente en el dispositivo del usuario, sin necesidad de conectar con servicios en la nube para la explotación del modelo.
Un caso es la identificación de imágenes sobre streams de vídeo en tiempo real. Esta funcionalidad se puede ejecutar, por ejemplo, en la nube de AWS mediante el entrenamiento del servicio Rekognition y su integración con Kinesis en tiempo real. Sin embargo, si la salida del reconocimiento de imágenes se va a mostrar al usuario en el mismo dispositivo que está capturando la imagen, entonces tiene sentido entrenar un modelo y aplicarlo directamente sobre el navegador, evitando en este caso el tiempo de latencia de ida y vuelta al servicio en la nube (y sus costes asociados).
Para poder llevar estas cargas de trabajo al navegador están apareciendo no solo frameworks para importar y explotar con el motor Javascript del navegador el modelo (siendo Tensorflow.js el más conocido), sino que se investiga de forma activa en modelos neuronales con menor tamaño y con menor uso de CPU, o que exploten las capacidades de aceleración de las tarjetas gráficas a las que tiene acceso el navegador.
Técnicas de IA aplicadas a la productividad del desarrollo
En este caso conviene aclarar que no se trata tanto de que una IA escriba el código de la aplicación (los programadores ya utilizan de forma habitual generadores de código, que de momento sería complicado batir por parte de una IA), sino cómo conseguir aumentar las capacidades de los equipos de desarrollo mediante el uso de técnicas de aprendizaje automático.
Aplicaciones como source{d} consideran el repositorio de código como una fuente de datos en forma de grafo, lo que permite realizar un análisis semántico y compararlo con análisis ya realizados sobre bases de código preexistentes (públicas o privadas), de forma que el motor de IA pueda sugerir refactorizaciones, plantear casos de prueba, o identificar problemas ocultos en el ciclo de desarrollo a partir del análisis de las frecuencias de entrega.
Este tipo de soluciones tenderán o bien a estar integradas en los entornos de desarrollo locales de los programadores, o bien acompañando a productos tradicionales en la integración continua como Sonarqube.
Igualmente la fundación Mozilla, en asociación con Ubisoft, ha aplicado la herramienta CleverCommit, que utiliza técnicas de machine learning para detectar patrones comunes de errores de programación basándose en el propio histórico de desarrollo. La capacidad de escala de este tipo de herramientas es evidente: Mozilla soporta y mantiene una base de código de millones de líneas escritas en lenguajes diversos: C++, JavaScript y Rust.
El beneficio que prometen estas herramientas es claro: reducir cientos de horas de detección y análisis de riesgo de los errores en el código.
