Evento: Renfe as a Service (RaaS): redefiniendo la movilidad con AWS y NTT DATA

El 8 de noviembre de 2022 de 11:00 a 12:00 CET vamos a realizar un webinar técnico de Desarrollo de Aplicaciones Modernas. Os vamos a contar el caso de éxito que hemos realizado en nuestro cliente RENFE y que hemos titulado: Renfe as a Service (RaaS): redefiniendo la movilidad con AWS y NTT DATA.

En esta sesión descubriremos cómo ha sido el proceso de creación de dōcō, la nueva aplicación de RENFE para moverse y viajar por todo el país de puerta a puerta. En este camino, NTT DATA ha utilizado la arquitectura de la solución en base a servicios serverless nativos de AWS que la arquitectura de referencia Lambda de NTT DATA aprovecha para extraer el mayor provecho.

Programación y ponentes

Arrancará la sesión Federico García Doblas, jefe de Área de Arquitectura de Sistemas y Plataformas Cloud en RENFE contando el proyecto RaaS y las motivaciones de por qué han seleccionado a NTT DATA como partner de confianza para llevar a cabo este gran proyecto en el que hemos propuesto una arquitectura 100% serverless.

Continuará con la sesión Ernesto Bethencour, Solutions Architect en AWS, para contar los servicios de AWS que hemos utilizado en este proyecto y que permiten una solución de arquitectura 100% serverless. Nos hablará de Lambdas y del stack DevOps gestionado de AWS.

Terminaré la sesión, en mi rol de Technical Manager en NTT DATA, para contar cómo hemos resuelto las necesidades que tenía RENFE utilizando una arquitectura 100% gestionada por AWS.

Os mostraremos nuestras principales motivaciones para confeccionar la propuesta de valor de este proyecto:

• Hemos definido una Arquitectura de referencia, creada en base a estándares entre las diferentes áreas (Arquitectura, Desarrollo, Seguridad, Comunicaciones, Calidad, …) marcando la línea que tienen que seguir las aplicaciones, la cual incluye estándares de calidad.
• Para provisionar una infraestructura optimizada, hemos implementado una provisión automática y optimizada, provisionando los servicios de la arquitectura a través de autoservicio que utiliza Infraestructura como Código (IaC). Incluye la documentación de entrada en los proyectos (denominada Welcome Pack), y entregamos un estándar de arquetipos para las arquitecturas que hemos desplegado. Tenemos pipelines de lambdas en Java y en NodeJs, de Salesforce, de APIs de MuleSoft, de reactJs y de imágenes para contenedores Drupal. Se incluyen estándares para la monitorización de las trazas técnicas y de negocio, nomenclaturas de etiquetado para identificar los costes en el Billing y gestionamos las versiones de los aplicativos. Provisionamos tanto los repositorios de código como los pipelines de despliegue y la infraestructura para desplegar ese código así como los permisos necesarios para que todo ello funcione, siguiendo los principios de Zero-trust. Creemos firmemente que las arquitecturas seguras se implementan desde el diseño (security by design) además de seguir el Well-architected Framework.
• Para conseguir una plena autonomía de los equipos, los despliegues deben ser ágiles, implementando un CI/CD (Continuous Integration / Continuous Delivery) y QA (Quality Assurance) de caja. Los equipos de Desarrollo deben ser los owners de sus aplicativos y tener a su disposición el conjunto de herramientas y permisos para poder monitorizar el negocio y resolver los problemas que puedan encontrar sin depender de otras áreas. Un punto importante es que en los despliegues por entornos hemos implementado un mecanismo de notificación de despliegues, para que las áreas que lo requieran puedan estar informadas, además de implementar un mecanismo de aprobación de pases al entorno de producción.
• Dado que se ha automatizado el trabajo de numerosos equipos multidisciplinares, un punto importante es definir correctamente un modelo de Gobierno para que los equipos sepan encajar sus responsabilidades y que la automatización sea una realidad, adaptando el modelo de trabajo a las necesidades del producto que hemos implementado.
• Con todo esto, hemos conseguido nuestro objetivo principal que es la Reducción del T2M (Time to Market).

Nuestras principales motivaciones para definir una arquitectura 100% serverless han sido:

• Ser capaces de satisfacer la demanda en tiempo real abstrayéndonos de la infraestructura subyacente.
• Permitir reducir las tareas de administración y operaciones.
• Tener mejor tolerancia a fallos.
• Permitir el escalado de forma independiente.
• Conseguir un mapeo detallado del consumo de los servicios.
• Soportar una rápida incorporación de nuevas tecnologías.
• Desacoplar la gestión de las APIs de los microservicios.
• Mejorar la agilidad en la implementación.
• Aumentar el enfoque del desarrollador sobre el negocio.
• Separar la lógica de negocio de los otros componentes de aplicación: capa de orquestación, capa de autorización, capa de datos y capa de observabilidad.

Contenido de la presentación

A nivel técnico, os mostraremos cómo hemos implementado nuestra solución usando el Framework de Lambdas Java de NTT DATA, permitiéndonos la abstracción en la integración con los recursos de AWS como las AWS RDS, AWS S3, AWS Secret Manager, AWS ACM, … incluyendo todas las librerías necesarias y las AWS PowerTools para resolver la observabilidad usando AWS xRay y AWS CloudWatch.

Os encantará la demo que hemos preparado en esta parte. Permite ver la potencia de la solución de observabilidad mostrando cuánto tarda cada parte del código, e incluso, el tiempo que tardan las consultas SQL a través de las anotaciones de las AWS PowerTools.

El contenido de la presentación se estructura de la siguiente manera:

Mejoras que nos ofrece el uso de AWS Layers:

• Permite reducir el tamaño del paquete a desplegar debido a que las librerías necesarias para acceder a los recursos están dentro de la layer.
• Ofrece un paquete único de todas las dependencias compartidas y permite que el proceso de actualización de estas sea más fácil.
• Automatización de nuevas dependencias.

Soluciones que hemos implementado a nivel de Observabilidad:

• Incorporación de las anotaciones de observabilidad en el Framework.
• Inclusión de anotaciones para envío de logs a AWS xRay de DML (Data Manipulation Language) DDL (Data Definition Language) y operaciones read/write a Base de Datos.
• Definición de un repositorio de la verdad en los logs para identificar RCA (Root Cause Analysis).

Habilitación de Trazas en xRay:

• Consigue información para mejorar el rendimiento de las aplicaciones, usuarios e infraestructura.
• Permite analizar el rendimiento de las aplicaciones para mejorar la experiencia del viajero.
• Detecta problemas a tiempo antes de que los usuarios finales se vean afectados.
• Utiliza diferentes fuentes consiguiendo investigar rápidamente y comprender la causa raíz.

Las conexiones con el cluster RDS la realizamos con el servicio AWS Proxy RDS:

• Permite controlar los aumentos del tráfico de base de datos reutilizando conexiones cuando la arquitectura de Lambdas escala bajo demanda.
• Los accesos a la BBDD para los mantenimientos necesarios se pueden realizar por el equipo de desarrollo a través del servicio AWS APPStream.

En la definición de la arquitectura de CI/CD (Continuous Integration/Continuos Delivery) hemos seguido los siguientes principios:

Usamos solo servicios gestionados de AWS:

• AWS CodeCommit: repositorio de código.
• AWS CodeBuild: realiza las compilaciones.
• AWS CodeDeploy: implementa los despliegues.
• AWS CodePipeline: orquesta los flujos CI/CD.
• AWS CodeArtifact: almacena los artefactos compilados.
• AWS Parameter Store: almacena los parámetros de configuración por entorno. Las credenciales de acceso se almacenan en registros de tipo seguro.

Hemos implementado una solución basada en eventos para abstraer los pipelines de las diferentes tecnologías implicadas en el proyecto, lo que ofrece las siguientes ventajas:

• Capacidad de leer los eventos de AWS CodeCommit y analizar mensajes en los commits, personalizando las ejecuciones agrupadas por tecnología y por entorno..
• Procesamiento desacoplado a través de una AWS Lambda orquestadora, que analiza el evento y almacena la información en AWS S3 para que los diferentes pipelines dispongan toda la información para realizar el procesamiento. Seguimos la metodología GitFlow.

La garantía en la calidad del código de los despliegues, está resuelto a través de esta suite de herramientas:

• La cobertura de código se realiza usando JaCoCo.
• Los logs se registran usando log4j2.
• Los test unitarios se llevan a cabo con aws-lambda-java-tests, mockito-junit-jupiter.
• Realizamos el análisis de código y de seguridad usando SonarQube.
• El análisis de vulnerabilidades lo resolvemos con Snyk.

Las notificaciones de los despliegues por tecnología lo hemos resuelto utilizando tópicos de SNS y configuramos el listado de las suscripciones en AWS SSM Parameter Store. Por otra parte, cada despliegue al entorno de producción requiere de una aprobación para poder llevarse a cabo. Dicha configuración también está realizada en AWS SSM Parameter Store.

El contenido es completo y muy descriptivo. Lo hemos confeccionado para facilitar la comprensión de la solución que hemos implementado en esta gran iniciativa, teniendo en cuenta que nuestro objetivo es que nuestros clientes puedan aprovechar las ventajas del Framework de Lambdas de NTT DATA.

Esperamos que la disfrutéis.