Ismael Rihawi

Allá por 1980, el futurólogo Alvin Toffler publicó "The Third Wave", libro en el que se inspiró Steve Case para concebir su visión particular acerca del desarrollo del paradigma tecnológico de la información en un contexto de mundo digital y globalmente interconectado. La Tercera Ola, con el foco puesto en "las cosas" que nos rodean, ya está aquí. ¿Cómo hemos llegado a este punto? Grandes referentes cinematográficos de la ciencia ficción auguraron en mayor o menor medida un futuro hipertecnológico, en donde toda representación física conviviera en armonía con un universo de activos y servicios digitales a la carta. Ratos de ocio que siempre observamos con cierto escepticismo, pero que poco a poco comenzamos a ver aproximarse a la realidad tal cual hoy la conocemos. En un universo entendíamos regido a base de impulsos e inercias, surgieron figuras como Steve Case, cofundador de la empresa America on Line (AOL), impulsora de la creación de Internet. Case, ya en 2016, fue capaz de describir con exquisita precisión la evolución de la conectividad en la sociedad de la información, identificando 3 grandes olas con entidad propia que ilustran su distinto grado de madurez en el tiempo. Hablaremos a continuación de los rasgos que definen cada una de estas etapas, centrando nuestros esfuerzos en esa tercera ola: claves del éxito, principales enfoques de implantación y agentes involucrados en trazar las líneas de un porvenir en el que recientemente nos adentramos. Primera ola: comunidades más allá de los límites territoriales Figura 1: Los cimientos se edificaron a base de consenso entre empresas, por aquel entonces de reciente creciente, unidas por un mismo propósito. En el período comprendido entre los años 1985 y 1999, compañías como AOL (de la que Case era su máximo exponente), Apple, Microsoft, IBM, Cisco Systems, HP, Sprint y Sun Microsystems fueron las responsables de crear el hardware, software e infraestructura de redes necesarios para permitir que las personas pudieran comunicarse entre sí, asentando las bases del Internet de la información. Viéndolo hoy en perspectiva como toda una revolución, su expansión fue cuánto menos compleja. Por un lado, los altos costes relativos a la adquisición de ordenadores personales e instalación de líneas para cobertura de servicio en particulares. En lo referente a las empresas, la complejidad y sobrecoste de capacitar a sus profesionales en el desarrollo de nuevas líneas de negocio (Web as Business Infrastructure). Todo ello suscitó un mar de preguntas de distinta índole: desde el riesgo tecnológico de los principales players ("¿puedo crearlo?"), a su verdadero beneficio como escaparate sobre el que presentar la marca ("¿compensa la inversión?"). La llegada de la segunda ola respondería de golpe y plumazo a tanta incertidumbre a unos y otros. Segunda ola: aplicaciones en masa, redes sociales como vía de expresión Figura 2: Los pasos dados hasta entonces nos han permitido contar con un mercado extenso de aplicaciones, actuando como facilities o meros pasa-tiempos. En pleno cambio de milenio, y representando un claro acelerador en la crisis de las 'puntocom', esta época destacó por la creación de un ecosistema desmesurado de aplicaciones de distinta naturaleza, apoyándose en el camino trazado durante la primera ola. Redes sociales, motores de búsqueda, tiendas online y plataformas de pago ejemplifican en buena forma la enorme diversidad. Un aspecto en común unía a todas ellas: posicionar al usuario en el centro de atención, otorgándole el protagonismo para que éste añadiese valor en un entorno de cocreación (Web as Social Media). En paralelo a tal eclosión, nuevas vías de consumo de la información e interacción con el mundo se desarrollaron. Gracias a la creación de dispositivos inteligentes (smartphones, tablets y wearables) y al concepto Cloud, de almacenamiento en la nube, se popularizó el uso frecuente de la red, provocando un aumento exponencial en el volumen de datos generados, rompiendo a su vez con los límites espacio-temporales de la conectividad antes impuestos. Nuevas compañías tecnológicas emergieron ante tal oportunidad, recogiendo el testigo de "la vanguardia por bandera". Google, Facebook, Twitter o Amazon, entre otras, corrieron el riesgo de invertir en un mercado incipiente, sin certezas de recibir a priori una gran acogida ni obtener un claro retorno de inversión. Y vaya que si acertaron. Tercera ola: orientando el foco en las 'cosas' que nos rodean Figura 3: Las nuevas tecnologías al servicio de extender el mundo digital al real. Y llegamos al momento presente, objeto de un exhaustivo estudio por parte de Steve Case en el libro que publicó bajo el mismo nombre que el de su mentor. Motivos no le faltaban para dedicarle tal atención: anunciar un nuevo tiempo de expansión de la tecnología a todos los ámbitos de nuestro día a día, convirtiéndose prácticamente en omnipresente. Tan próxima a nosotros, que permita actuar con antelación efectiva ante problemas y deficiencias reales, ya sea en un entorno de procesos productivos industriales, o en la detección de patologías de distinta consideración en pacientes. Sin embargo, un fin con un impacto social tan acentuado requerirá, al igual que sucedió en la primera ola, del correcto alineamiento de múltiples aspectos que hagan escapar de toda zona de confort. A considerar, la perseverancia en el ejercicio de la innovación, la búsqueda de alianzas multisectoriales para dotar de músculo reputacional y/o financiero al producto, así como una lucha no trivial por el cumplimiento del marco normativo. Recordemos que la complejidad regulatoria ahora abordará cuestiones de magnitudes no desdeñables, como bien pudiera ser la gestión de flotas de drones, la eficiencia en el uso de los recursos en una Smart City, o la implementación de un asistente de Inteligencia Artificial y detección de averías en vehículos autónomos. Cuestiones que revierten en beneficio de la experiencia del usuario, pero que en caso de mala praxis operativa, pudieran poner en riesgo la propia integridad del mismo. En correspondencia con lo anterior, resultará vital potenciar la habilidad de gestión del cambio, determinante para posicionar qué empresas liderarán este escenario en constante transformación. Perdurarán las que sepan bailar según la música, partiendo de un espíritu emprendedor y de auto-disrupción (Apple y Amazon dan buena fe de ello). Además, premiará un modelo de equilibrio entre el retorno financiero y la ejecución de su propósito, viéndose gratificadas aquellas organizaciones que lo lleven verdaderamente a la práctica. La fidelidad de la marca llevada a un siguiente nivel. AI OF THINGS Domótica e Inteligencia Artificial: del hogar inteligente a las Smart Cities 14 de febrero de 2020 Cuando la tecnología madura para unir sociedad y progreso Resolver los retos de la Tercera Ola supone hacer uso de herramientas avanzadas como las que ya disponemos, las cuales han alcanzando un grado de madurez notorio. Formando parte de un engranaje perfecto, son tecnologías que en suma actúan como activadores de todo proceso de transformación digital, y cuyas bondades revertirán en ese grado de personalización del producto o servicio que los consumidores esperan en este ciclo. Es así que toda solución empresarial reunirá en sus distintas etapas de vida cada uno de estos pilares: Internet of Things como elemento múltiple de emisión inteligente, proporcionando un tsunami de datos allá donde se justifique su aplicación. Capacidades de Big Data e Inteligencia Artificial para la captura, normalización y extracción de patrones y tendencias que nos permitan predecir y actuar a tiempo en la toma de decisiones de negocio. Blockchain como canal de compartición del registro de cambios de estado de nuestros activos digitales y conclusiones extraídas sobre estos, representando un medio seguro, confiable y de acceso inmediato para todo organismo involucrado, regido por mecanismos de control vía Smarts Contracts. Los estándares tecnológicos de comunicación requeridos para una correcta transferencia informacional entre los distintos agentes y puntos de control. Mecanismos de Ciberseguridad perimetral, previniendo accesos y usos no autorizados de los datos bajo el cumplimiento de la regulación. Steve Case tenía razón. No temamos surfear la cresta.

Vivimos en un tiempo en el que la sociedad avanza de la mano de la ya tan consagrada transformación digital, extrapolándose ésta tanto al ámbito doméstico como empresarial. Su influencia notoria puede apreciarse en la manera que tenemos de percibir el progreso como un mecanismo natural y constante de cambio, renovación y adaptación al medio. A consecuencia de ello, el tempo natural de evolución de las ocupaciones profesionales en todo el mundo se ha visto alterado. Se ha llegado a un punto en el que el sistema educativo no tiene margen de maniobra para formar a la población en las nuevas competencias requeridas por el mercado laboral. En términos de influencia y desequilibrio en la balanza de la oferta, se plantea una carencia cada vez más pronunciada: la exponencial creación de vacantes (especialmente de tipología digital) imposibles de cubrir por profesionales suficientemente capacitados. Son múltiples los informes que confirman esta tendencia. Por ejemplo, un estudio realizado en 2018 por ManpowerGroup establece que cerca del 45% de las empresas en más de 40 países tienen dificultades para cubrir sus vacantes, derivado mayormente del déficit de conocimientos técnicos (17%) y habilidades profesionales (7%) por parte de los candidatos presentados. Otros aspectos, igualmente importantes, reflejan la existencia de una brecha formativa y una necesidad acuciante de orientación profesional para poder adaptarse al nuevo mercado. Hablamos de personas desempleadas o en riesgo de perder su puesto de trabajo, en su mayoría desconocedoras de las competencias verdaderamente necesarias para una correcta reinserción laboral. Necesidad identificada, respuestas a la altura Los desafíos comprendidos en este cometido entrañan una realidad que afecta a todos los estamentos de la sociedad, siendo los ciudadanos los principales interesados en contar con métodos o procedimientos que permitan dar respuesta a esta nueva problemática. En un contexto en el que ponemos cara a los beneficiaros finales (¡nosotros mismos!), y en donde somos capaces de medir con precisión el impacto social asociado, buscar la solución en los grandes volúmenes de información que generamos cobra todo el sentido del mundo. En línea con lo expuesto, se han presentado dos proyectos desarrollados para Fundación Telefónica España, a libre disposición de todos como bien público, escalables para su implantación en otros países, y fácilmente personalizables en apariencia y/o funcionalidades. Ambas soluciones cuentan con un fuerte componente tecnológico y disruptivo, al estar conformados bajo tecnologías y servicios dedicados Big Data en entornos de Cloud Computing, así como de mecanismos de Inteligencia Artificial (IA) necesarios en el ejercicio de análisis del mercado laboral. Por un lado, una plataforma web, de nombre Mapa de Empleo, en la que se recogen los principales indicadores asociados a los distintos perfiles profesionales más demandados y las competencias digitales solicitadas en las ofertas de las principales plataforma de empleo del país. En segunda instancia, un chatbot que realiza la función de Orientador Profesional Virtual, ofreciendo a aquellos usuarios más necesitados un asesoramiento laboral y formativo personalizado que les permita tomar mejores decisiones en su carrera profesional. Mapa de empleo Representación visual interactiva accesible para individuos, centros de formación, empresas y gobierno que permite la exploración y comprensión de la realidad de la demanda laboral del país, permitiendo conocer: Las profesiones y habilidades más demandadas en cada provincia, a través del análisis de las ofertas de empleo publicadas en Infojobs y otras fuentes durante los últimos 3 meses. Evolución en España en el último año de las ofertas de empleo para las 10 profesiones digitales más buscadas y las 10 habilidades digitales más solicitadas. Ranking de habilidades más solicitadas de cada profesión digital (las más necesitadas de una mayor capacitación), ayudando a centrar el grado de especialización técnica de hasta en 10 skills según orden de relevancia o recurrencia de solicitud en las ofertas de empleo. Categorización de las profesiones digitales y no digitales en base a la clasificación europea ESCO de 2 niveles, aportando una definición oficial de cada perfil o rol. Sin duda, uno de los más importantes debido a la heterogeneidad de denominaciones de una misma profesión. Figura 1: Mapa del empleo de Fundación Telefónica Orientador Profesional Virtual En un nivel mayor de profundidad, además de la información recogida en el mapa de empleo, y con el objetivo de ofrecer un grado de asesoramiento más personalizado, se ha desarrollado un chatbot de nombre Orientador Profesional Virtual. ¿Cuál es su valor añadido? Recomendar, de entre las profesiones digitales identificadas, aquellas que se adecuan más a cada persona, tomando para ello en consideración sus intereses, conocimientos y competencias. Además, gracias a disponer del listado de habilidades digitales más requeridas para cada perfil, ofrece información sobre qué competencias les falta para adquirir cierto grado de especialización, recomendando en consecuencia los cursos de formación de mayor reputación para prepararse para ellas. De esta forma, los usuarios mejoran su empleabilidad efectiva, en base a lo que el mercado demanda, brindando la oportunidad de formarse sobre apuestas seguras de futura aplicabilidad profesional. Figura 2: Orientador Profesional Virtual Magia, fuegos artificiales y…Big Data e IA en estado puro Bajo estas dos vías de explotación de la información y presentación friendly de los resultados, se esconde el verdadero impulso que alimenta de manera dinámica y constante la generación de conclusiones extraídas, el verdadero “cerebro de la bestia”. Un ecosistema Big Data de alto rendimiento y disponibilidad, compuesto por una infraestructura de servicios a medida para el tratamiento de información heterogénea que aborda todos los ciclos de vida del dato, y en donde sobresalen las siguientes funciones: Captura horaria de grandes volúmenes de datos provenientes de diversas fuentes de información de distinta naturaleza, todas ellas relativas a ofertas de empleo y cursos de formación. Procesos de normalización y limpieza de la información sustraída de dichas plataformas, confeccionando un modelo de datos unificado, el cual parte de la desestructuración para afianzar la importancia de una labor de estandarización al detalle. Un claro objetivo en el horizonte: garantizar la calidad del dato y una perfecta adecuación en siguientes etapas analíticas. Modelo de IA responsable del etiquetado de ofertas de empleo, a través de la asignación de las categorías de perfiles identificadas en una ontología inicial por similitud respecto a un conjunto de entrenamiento de muestras de entrada, o bien a partir de la creación de nuevas etiquetas de profesiones demandadas no antes contempladas. Protocolo de minería de texto encargado del procesamiento del contenido de las ofertas de empleo una vez tienen asignado uno o varios perfiles profesionales, con el objetivo de identificar y agrupar las habilidades técnicas que más se solicitan en las mismas. Exportación de la información vigente requerida para aprovisionar las principales fuentes de explotación de los resultados extraídos, accesibles gracias a la implementación de una API de métodos de consulta creada para dicho fin. Figura 3: Visión global de solución Big Data Impulsar a que la sociedad acceda con determinación a la era digital es el principal estimulo que alimenta la dedicación de abordar grandes retos que trascienden lo tecnológico y confluyen hacia lo humano. Un espacio propio en donde un equipo multidisciplinar ve cumplida una clara premisa: situar al dato como máximo estandarte, único garante de la verdad descriptiva del presente, prescriptiva de lo que está por llegar.

En el primer post de esta miniserie dedicada a los datos abordamos aspectos fundamentales que definen el papel protagonista que estos adquieren en nuestros días. Enunciados los rasgos que posibilitan su categorización, así como un amplio abanico de fuentes de origen con los que aprovisionar productos y servicios digitales, dedicaremos un capítulo íntegro a los mayores almacenes de agrupación histórica y consulta universal conocidos en la era moderna: las bases de datos. Fruto de la diversidad de contenidos que se generan actualmente, resultantes de la interacción entre seres humanos y máquinas, y de un cambio de paradigma en la toma de decisiones empresariales, es condición indispensable profundizar en los principales propósitos de su uso recurrente. Más adelante, enmarcaremos distintos motores de bases de datos, atendiendo a criterios de mutabilidad, organización y contenido a alojar sistemáticamente. En última instancia, se identificarán las nuevas tendencias de mercado y consideraciones en la correcta elección de un tipo u otro según finalidad específica. Las bases de datos constituyen un elemento central clave en la generación de valor añadido para consumidores, operadores, empresas y organizaciones, cuya relevancia in crescendo ha calado en todos los estratos de la sociedad actual, con independencia del ámbito profesional y grado de competencias técnicas de partida. ¡A "consultar" nuestro artículo, que es gerundio! “Ya no estamos en la era de la información. Estamos en la era de la gestión de la información.” (Chris Hardwick, actor) Almacenamiento: un paradigma omnipresente Figura 1: Todo proceso operativo lleva consigo un requerimiento de persistencia de la información resultante Las bases de datos constituyen un componente primordial de todo entorno productivo que opera con activos, entendidos estos como entes representativos del consumo de un bien o servicio a objeto de prestación, y para los cuales es requerida una gestión eficaz de la información resultante. Su incorporación permite la captura organizada manual y/o automática de todos los datos relativos a las etapas que conforman su ciclo de vida, aportando un orden con finalidad de consulta y análisis, facilitando su conversión en información útil y de valor añadido. La elección del tipo de base de datos vendrá determinada por el grado de respaldo en términos de funcionalidad y rendimiento que nuestra aplicación de software esté destinada a realizar, cumpliendo con el objetivo de correspondencia 'ad hoc' frente a la misma, a destacar entre muchos factores: Tipado, estructura, modelo o esquema y caso de uso previsto de los datos en el origen. Mecanismo de consulta informacional. Latencia o tiempo de entrega de servicio requerida. Nivel de consistencia de datos. Velocidad transaccional y/o procesamiento (Batch, Near Real-Time, Real Time). ¿Qué ejemplos de uso se presentan en las empresas? Los supuestos son innumerables: desde posibilitar la gestión de la organización de la propia entidad (detalle de empleados e inversores, contabilidad asociada) hasta el seguimiento del inventariado de productos (localización y estado), portfolio de servicios e histórico de clientes (pedidos realizados, preferencias de uso, grado de satisfacción). El aprovisionamiento ordenado de datos heterogéneos en soportes de almacenamiento masivo orientados a la analítica avanzada habilita a las corporaciones un espacio de nuevas oportunidades de negocio, acrecentadas de verse combinada con las capacidades de captura local de datos del Internet of Things. Ocupando por tanto un lugar privilegiado en toda propuesta digital, el predominio cada vez mayor en el uso profesional de servicios "pay on demand" a través de proveedores de computación en la nube, posibilita enormemente la disponibilidad de una amplia selección de bases de datos personalizadas multipropósito. En la aproximación tradicional, su instalación (configuración, licenciamiento) sobre infraestructura propia es una labor de obligatorio cumplimento; en el supuesto del marco Cloud, la ecuación se traduce en reducción de costes y posibilitar de desarrollo de aplicaciones distribuidas de ámbito global, completamente administradas y con rendimiento a escala según el grado de cargabilidad en la demanda del servicio ofrecido. Clasificación multivariante, idéntica finalidad Al igual que sucede con la unidad mínima de información, existen múltiples aproximaciones a la hora de catalogar a las bases de datos, partiendo del hecho de la flexibilidad en términos de utilidad, estructura organizativa y volumen, motivos estos que evidencian la inexistencia de un criterio estándar de partida. Cabe destacar por una parte la organización teórica establecida según grado de acceso a los datos que almacenan entorno a dos principales tipos generalistas: Estáticas: También conocidas como bases de datos de solo lectura (en inglés OLAP, "On Line Analytical Processing"), de naturaleza consultiva, no posibilitando operaciones de escritura, al recoger información veraz (sucesos históricos plenamente contrastados) con una finalidad de estudio a posteriori como apoyo en análisis predictivos. Dinámicas: Uso más generalizado (en inglés OLTP, "On Line Transaction Process"), en donde la información almacenada puede ser además de consultada, modificable en tiempo real. A partir de aquí, otros puntos de vista conviven en la clasificación de las bases de datos; por ejemplo, atendiendo a la forma en la que se organizan los datos para eficientar su posterior consumo, distinguiéndose entonces: Jerárquicas: Con apariencia de árbol invertido y estructura conformada por nodo padre o raíz y nodos hijos u hojas. Especialmente útiles en caso de aplicaciones que requieren de un gran volumen de información y datos muy compartidos, permitiendo estabilidad y gran rendimiento operacional. Por el contrario, no presentan características de gestión eficiente en la redundancia de datos. Red: Evolución respecto al modelo jerárquico, posibilitando el establecimiento de relaciones adicionales entre elementos y optimizando la gestión de la redundancia. En desuso por su elevada complejidad. Relacionales: Surgidas al comienzo de la década de los 70, representan el patrón más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. La base de su operativa se sustenta en el almacenamiento de acuerdo a un esquema predefinido "en tiempo de diseño", propiciando una disposición de los mismos entorno a tablas con filas (registros) y columnas (tipado de atributos que los definen) que respetan los principios de integridad referencial. De fácil comprensión, la información pueda ser recuperada a través de consultas que ofrecen una amplia flexibilidad en la administración de la información. El lenguaje utilizado en dicho procedimiento es SQL ("Structure Query Language"), estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales (RDBMS), brindando funcionalidades de creación, actualización, consulta y eliminación de los datos persistentes. Orientadas a objetos: Más modernas y con mayor capacidad de procesamiento. En ellas no se almacena información sobre un objeto, sino el objeto entero (estado y comportamiento), dotándole de ciertas características que lo definen y diferencian frente a otros similares. Mayor flexibilidad en escritura e inmediatez en lectura. Deductivas: Basados en lógica matemática, permiten realizar deducciones a través de inferencias. Se basa principalmente en el implementación de sistemas basados en reglas y hechos, los cuales son almacenados en la base de datos. Empleadas en el desarrollo de motores de búsqueda. Distribuidas: Bases de datos almacenadas en varias computadoras conectadas en red, de gestión independiente, surgen debido a la existencia física de organismos descentralizados. Multidimensionales: estructura de múltiples niveles, alojando según valor y dimensiones los datos a objeto de consulta. Sin jerarquía establecida, poseen un alto rendimiento en tiempo de búsqueda. Son un tipo de base de datos optimizada para Data Warehouse que se utilizan principalmente para crear aplicaciones OLAP. Perspectivas académicas aparte, la evolución en la tipificación de las bases de datos se centra en dar respuesta a las necesidades de negocio según tipo de contenido a albergar y propósito específico del caso de uso que la aplicación software asociada demande. Este nuevo escenario da pie a enunciar a las bases de datos NoSQL, popular alternativa a las bases de datos relacionales, surgidas a raíz de la explosión de las redes sociales, motores de búsqueda, tiendas online, plataformas de pago y aplicaciones mobile durante la segunda ola tecnológica proyectada por Steve Case. Su aplicabilidad concede una mayor flexibilidad al no requerir de un esquema de definición de la composición de los datos previa a su explotación, permitiendo almacenar y manipular datos no estructurados y semiestructurados. ¿Cuál es entonces la realidad actual de mercado en términos de relevancia y aplicabilidad? La elección del tipo de base de datos vendrá determinada por el grado de respaldo en términos de funcionalidad y rendimiento que nuestra aplicación de software esté destinada a realizar, cumpliendo con el objetivo de correspondencia 'ad hoc' frente a la misma. La tendencia NoSQL y hacia lo 'purpose build' Figura 2: Diferentes distribuciones de bases de datos relacionales y no relacionales (Fuente: alooma.com) Los patrones de diseño e implementación software han evolucionado con el paso de los años, iterando desde sistemas monolíticos tradicionales como Mainframe, posteriormente hacia la arquitectura Cliente-Servidor, evolucionado hacia el modelo estratificado Modelo-Vista-Controlador o MVC (Base de datos, aplicación de negocio e interfaz de presentación) y recientemente, convergiendo hacia las arquitecturas de microservicios con el uso de las aplicaciones distribuidas. Es en este escenario en donde las bases de datos se encuentran evolucionando a la par, tratando de satisfacer los nuevos requerimientos en demanda, conformando una visión global que ejemplifica el grado de personalización de los tipos de bases de datos actuales, ejemplos de casuísticas de implementación y los servicios de aplicación más recurrente: Tipología Casos de uso Distribuciones popularesRelacionalAplicaciones tradicionales ERP CRM e-commerceOracle MySQL Microsoft SQL Server PostgreSQL DB2 Amazon Aurora Amazon RDS Amazon Redshift Azure SQL Database Azure SQL Managed Instance SQL Server on Virtual Machines Azure Database for PostgreSQL Azure Database for MySQL Azure Database for MariaDB Google Bare Metal Solution Google Cloud SQL Google Cloud SpannerClave-ValorAplicaciones web Aplicaciones mobile e-commerceRedis Amazon DynamoDB Azure CosmosDB Google Cloud BigtableEn memoriaAlmacenamiento en caché Gestión de sesiones de usuario Rankings de juegos Aplicaciones geoespacialesRedis Memcached Amazon ElastiCache Azure Cache for Redis Google Cloud MemorystoreDocumentalGestión de contenidos (CMS) Catálogos Perfiles de usuarioMongoDB Couchbase Amazon DocumentDB Google Cloud Firestore Google Firebase Realtime Database ColumnarAplicaciones industriales Administración de flotas Optimización de rutas.Cassandra Scylla HBase Amazon KeyspacesGrafosDetección de fraudes Redes sociales Motores de recomendaciónNeo4j Datastax Enterprise Graph Amazon NeptuneSeries temporalesAplicaciones IoT DevOps Telemetría industrialAmazon Timestream Figura 3: Detalle de tipología de bases de datos relacionales y no relacionales, casos de uso y distribuciones Por último, es conveniente destacar ventajas e inconvenientes de ambos tipos de bases de datos: Razones por las que decantarse por una bases de datos relacional Estándar SQL definido, comúnmente aceptado como estándar universal. Tecnologías maduras, documentadas y con una amplia comunidad de desarrollo. Compatibilidad ACID, satisfaciendo los requisitos de atomicidad, consistencia, aislamiento y durabilidad. Gran número de proveedores ofreciendo sistemas de gestión de bases de datos relacionales (RDBMS). Razones por las que decantarse por una base de datos no relacional Soporte de grandes volúmenes de datos sin una estructura definida de antemano, contexto idóneo en productos y servicios de Big Data e Inteligencia Artificial. Requerimiento de menor administración al contar con capacidades de distribución ('Sharding') y replicación de datos como factores habilitadores de un sistema tolerante a fallos. Modelos de datos simplificados ('Schemaless'). Alta escalabilidad horizontal, ampliando la capacidad sin interrumpir la usabilidad y/o disponibilidad del servicio. Sin necesidad de servidores con gran cantidad de recursos para operar, pudiendo partir de una inversión baja, extensible a medida de ampliarse las necesidades. Damos por completado el reto de profundizar en uno de los elementos esenciales de toda solución tecnológica que más renglones ha llenado. ¡Espero con ello haber avivado tus ganas de nuevo conocimiento! Para mantenerte al día con el área de Internet of Things de Telefónica visita nuestra página web o síguenos en Twitter, LinkedIn y YouTube

En esta serie de dos artículos aspiramos dar respuesta a las incógnitas que rodean siempre al universo de los datos, en aras de corresponder con la célebre cita de 'Los datos son la nueva ciencia. El Big Data son las respuestas' (Pat Gelsinger, exCEO de VMware/CEO de Intel, 2015). Están por todas partes. Representan en la actualidad el eje central de cualquier conversación distendida de ámbito laboral y/o formativo; ya sea en reuniones de trabajo, cursos de especialización, workshops, conferencias o publicaciones divulgativas. Constituyen el principal estímulo de las soluciones digitales aupadas bajo la proclama de posibilitar la toma de decisiones Data-Driven. En el ejercicio de transformar digitalmente a las empresas y capacitar a los profesionales del futuro, los datos hacen viable el portfolio de propuestas de productos en multitud de sectores, propiciando lo intangible hasta el momento en conjunción con las nuevas vanguardias tecnológicas. Siendo por tanto el motor que impulsa el conocimiento y su aplicabilidad en el contexto empresarial, es conveniente hacer frente a una serie de cuestiones clave que garanticen un correcto tratamiento y explotación: ¿Qué propició su diversidad? ¿Qué métodos de clasificación existen? ¿Cuál es el tratamiento que requieren según naturaleza de composición y uso? ¿Qué sistema de almacenamiento se recomienda para cada supuesto? Principios que acreditan su relevancia Figura 1: Clases de tipos de datos genéricos primitivos y compuestos Los datos simbolizan la unidad mínima de información acerca de un hecho o elemento concreto, susceptible éste de la interpretabilidad humana y computacional como vía de adquisición cognitiva. Generados habitualmente por un agente externo a la infraestructura tecnológica, es a este componente al que se le atribuye la responsabilidad de aprovisionamiento, procesado y gestión de la información resultante para su consumo por parte de un usuario final. La deducción de su significado se establece en base a unos criterios de tipado que, elementales y de referencia, describen la representación, estructura, operaciones y rango de valores esperados en esa labor de conversión digital. La agrupación de datos en torno a conjuntos organizados de manera sistemática para su clasificación y consulta recibe el nombre de bases de datos. Aún con un propósito original en su ideación, pueden adquirir nuevos enfoques de dimensionamiento y finalidad, confiriéndoles el estatus de principal vía de aprovisionamiento de las soluciones de Big Data e Inteligencia Artificial. ¿Qué otros tipos de fuentes de datos suelen considerarse significativas para alimentar nuestras aspiraciones de analítica avanzada? Usuarios y sensores aupando la heterogeneidad de los datos Figura 2: Ecosistema digital conformado por usuarios, servicios y cosas inteligentes generando valor en forma de datos La tendencia emergente de nuevas plataformas proveedoras de información con fisionomía de red social, servicios Cloud y aplicaciones Mobile experimentada durante la segunda ola marcó un precedente en el volumen de generación de datos y tipología de los mismos. Un "muchos y muy variados" que ha visto acrecentar su cuenta en esta última etapa de irrupción del Internet de las Cosas, donde el incremento exponencial de dispositivos inteligentes interconectados proporcionan con autonomía datos relevantes del entorno operativo y quiénes conviven en él. Dicho crecimiento propicia una mejora sustancial en el grado de personalización y refinamiento de las conclusiones analíticas que puedan extraerse, al disponer de un mayor contexto del ámbito y entidades implicadas en todo reto de negocio que se plantee. Es por ello que, a las ya citadas bases de datos como enclave de información en el origen, debemos de contemplar adicionalmente los siguientes puntos de partida tradicionales y de nueva índole: Empresas proveedoras de información y/o servicios que exponen a través de una interfaz de programación de aplicaciones (API) información relativa a sus operaciones en tiempo real. Los sistemas de gestión empresarial (ERP), fuente de datos de excelente riqueza para evaluar puntos de riesgo y mejora en el ámbito de la operativa de una organización. Los sistemas de gestión de las relaciones con los clientes (CRM), punto de unión del dossier de productos de las empresas y el grado de satisfacción de los actores que constituyen la principal fuente de ingresos. Los sistemas de gestión de contenido (CMS), capturando toda interacción de los usuarios que operan por la plataforma, reconociendo nuevas oportunidades de negocios, posibles tipos de clientes potenciales, etc. Las redes sociales, que permiten medir las tendencias de fidelización de productos y servicios, definiendo perfiles de consumo, grupos de audiencia y diseño de productos específicos para estos. Aparte, resultan ser una fuente inagotable de datos que proveen información crucial sobre el mercado en el que se posicionan los negocios por sectores, con un desglose pormenorizado de competidores y vías de proyección. Millones de datos recopilados de elementos de sensorización existentes en flotas de dispositivos de Internet of Things, que requieren de una infraestructura unificada de análisis integral para automatizar la toma de decisiones y actuación de considerarse necesario. La elección e integración de una o varias de estas fuentes de datos citadas se verá condicionada al correcto permiso de acceso a los datos de precisarse acuerdos de alianzas (partnerships), una óptima estrategia global de captura programática de la información, así como un debido tratamiento de los datos de carácter sensible en base al Reglamento General de Protección de Datos (RGPD). En el próximo artículo profundizaremos en las distintas clasificaciones de bases de datos existentes, describiendo ventajas e inconvenientes identificadas, citando las distribuciones más populares hasta la fecha, y estableciendo pautas según casuística a la hora de decantarnos por una tipología respecto a otra. Stay "Data" tuned!

En el segundo capítulo de esta serie dedicada a la implementación de una solución tecnológica que aúna dispositivos de Internet de las Cosas y la nube, exploramos el Hub de servicios dedicados a IoT en Amazon Web Services, en sintonía con un dispositivo inteligente compuesto por un microcontrolador ESP32 como es M5Stack Fire Kit. Planteado un supuesto de aplicabilidad posible, el registro en directo de asistentes a un evento multitudinario, esta labor requirió de tareas técnicas como hitos reales de proyecto. ¿A destacar? Alta del dispositivo, generación de certificados X.509 para identificación y acceso remoto bidireccional local/Cloud, puesta a punto del entorno de desarrollo, implementación y flasheo de lógica de negocio y mecanismos de publicación y suscripción de mensajería en topics MQTT. Este procedimiento secuencial de acciones pudiera repetirse tantas veces como puntos de interacción inteligente ("things") se requirieran en correspondencia con el dimensionamiento final de la infraestructura (véase número de accesos al recinto, volumen de inscritos al evento, personal contratado para la organización del mismo). ¿Y ahora qué? Llegados aquí, es turno de incorporar a nuestra propuesta el enorme potencial de recursos de computación distribuida y analítica, almacenamiento, bases de datos y recursos dedicados para Internet de las cosas que ofrece AWS. Esto permitirá vitaminar el proyecto con ciertos automatismos, en forma de reglas de negocio para la persistencia de información emitida y la toma de decisiones en tiempo de celebración de evento, que es cuando verdaderamente se requieren. 4. AWS SAR: Reglas y funciones Serverless para completar la operabilidad en la solución IoT Cloud Recuperando el diagrama global de infraestructura IoT Cloud presentado en la primer parte de nuestro tutorial, vamos a establecer el flujo básico de publicación/suscripción entre AWS IoT y AWS Lambda. Con ello llevaremos a cabo la implementación de un Backend Serverless que permita enviar y recibir mensajes en el flujo de topics bajo protocolo MQTT, posibilitando una funcionalidad completa de doble sentido: Al emitir un mensaje desde M5Stack Fire como dispositivo emisor y originario del flujo de interacción, una regla de AWS IoT reenviará su contenido hacia una función Lambda ("TopicSubscriber") encargada de registrar su contenido en una tabla del servicio autogestionado de bases de datos NoSQL DynamoDB. Al emitir una petición de servicio con un mensaje determinado desde un endpoint REST POST habilitado en el servicio API Gateway, dicho recurso invocará a una función Lambda ("TopicPublisher") que reenviará el contenido hacia el topic al que está suscrito M5Stack Fire. Figura 1. Visión global con flujo de conexión de servicios Cloud y M5Stack Fire. De cara a simplificar la realización de este apartado, recurriremos al despliegue de una aplicación reutilizable ya existente y de dominio público disponible en Serverless Application Repository (AWS SAR). Utilizando la plantilla de definición de recursos necesarios AWS Serverless Application Model (SAM), dicha aplicación despliega los siguientes servicio de manera automática sobre nuestra cuenta de AWS: Las dos funciones Lambda de suscripción ("TopicSubscriber") y publicación ("TopicPublisher") anteriormente descritas. Una tabla en DynamoDB en la que registrar los mensajes emitidos por M5Stack Fire. Una regla AWS IoT que invoca a la función Lambda de suscripción con el contenido del mensaje enviado al topic m5stack/pub. Endpoint de APIGateway con recurso de invocación a la función Lambda de publicación de mensajería hacia el dispositivo local. Incorporar a nuestra propuesta el enorme potencial de recursos que ofrece AWS permitirá vitaminar el proyecto con ciertos automatismos, en forma de reglas de negocio para la persistencia de información emitida y la toma de decisiones en tiempo de celebración de evento, que es cuando verdaderamente se requieren. El procedimiento a seguir para dicha integración es el siguiente: Autenticarnos desde la consola de administración web en la cuenta de AWS sobre la que realizamos los primeros pasos de nuestro tutorial, situándonos en la misma región en la que dimos de alta el thing. En otra pestaña del navegador, hacer clic en el siguiente enlace web, el cual nos redirigirá a la aplicación Serverless reutilizable lambda-iot-rule, alojada en el repositorio AWS SAR; posteriormente, seleccionar la opción "Deploy": Figura 2. Despliegue de aplicación Serverless con Backend genérico de servicios IoT. En la configuración de la aplicación, habrá que introducir los valores de los topics de publicación y suscripción incluidos en la configuración de política asociada a nuestro dispositivo IoT (véase en caso de duda la sección de "1. AWS IoT Device Management: things y buenas prácticas" del anterior post); preservando el nombre de aplicación por defecto, introduciremos la cadena "m5stack/sub" en el campo del topic de publicación al que M5Stack se suscribe para la recepción de mensajes, y "m5stack/pub" en el campo del topic de suscripción como canal por el que el dispositivo pueda comportarse como emisor de mensajes. Importante en última instancia habilitar la casilla de consentimiento de creación de roles personalizados requeridos de permisos de interacción entre servicios en IAM: Figura 3. Configuración de parámetros de despliegue de aplicación Serverless lambda-iot-rule. En un corto plazo de tiempo se procede al aprovisionamiento de todos los servicios de AWS necesarios antes descritos, definidos en la plantilla de Serverless Application Model (SAM); finalmente, podrá verificarse la creación de la aplicación Serverless, incluyendo hasta 11 recursos distintos, aparte del endpoint o punto de enlace a API Gateway (: Figura 4. Listado de recursos desplegados en aplicación Serverless SAR. De modo opcional, podemos revisar que se han creado debidamente cada uno de los recursos mencionados, validando así que nuestra aplicación Serverless se encuentra plenamente operativa. Por otra parte, dicha validación se realizará con el ánimo de conocer más en profundidad el detalle de configuración de las instancias de servicios involucrados, la programación embebida en el tratamiento de eventos, y en la parametrización de identificadores necesarios para vincular unos recursos con otros. Para ello, y desde la consola de administración de AWS: Accedemos al servicio AWS Lambda y seleccionamos en la barra lateral la opción "Functions", mostrándosenos en el panel central de la vista las dos creadas tras el despliegue de la aplicación SAR: Figura 5. Recursos listos para atender a todo evento resultante en Backend Serverless. La función de subscripción al topic atiende a la gestión de eventos, preparando un nuevo "item" a insertar en DynamoDB como consecuencia de una invocación a la función con el contenido del mensaje incluido en el parámetro "event". Destacar también la referencia al identificador con el nombre de la tabla sobre la que persistir dicha información. Se trata de un valor generado dinámicamente en tiempo de despliegue (al igual que el resto de identificadores de los recursos disponibles) a través del uso de variables de entorno: Figura 6. Función de subscripción al topic en Node.js autogenerada en despliegue SAR. Realizando el mismo ejercicio con el segundo recurso funcional, para la publicación de mensajes al topic al que está subscrito M5Stack se requiere de la gestión del mensaje emitido desde el endpoint habilitado en API Gateway. La función Serverless es invocada por este punto de enlace, el cual publica en el topic cuyo valor se concretiza nuevamente dinámicamente: Figura 7. Función de publicación al topic en Node.js autogenerada en despliegue SAR. Accedemos ahora al servicio DynamoDB, y seleccionamos en la barra lateral la opción "Tables", figurando en el panel central una (de momento vacía) que lleva por nombre el mismo que el indicado en el paso de parámetros de la función Lambda de subscripción (figura 6): Figura 8. Tabla en DynamoDB generada para persistir los mensajes emitidos desde M5Stack. Queremos comprobar seguidamente si, en caso de emitirse un mensaje desde M5Stack al topic de publicación ("m5stack/pub"), se ha registrado alguna regla de actuación que invoque a la función Lambda de inserción del contenido en DynamoDB. Nos dirigimos al servicio IoT Core, hacemos clic en la opción "Act" y "Rules" sobre el menú lateral, y entramos al detalle del único registro listado. Debe de figurar activada la regla, la condición de consulta del disparador orientada al topic de publicación en cuestión, y la acción programada de invocación hacia la función Lambda correspondiente ("TopicSubscriber"): Figura 9. Configuración esperada de AWS IoT Rule para nuestro Backend Serverless. Únicamente nos queda dirigirnos a nuestra aplicación Lambda (en AWS Lambda", seleccionando la función de nombre serverlessrepo-lambda-iot-rule), y sobre la pestaña "Overview", guardarnos a buen recaudo el endpoint o punto de enlace de API Gateway. Haremos uso de él en nuestra gran demostración final: Figura 10. Llave de acceso a la publicación de mensajes en un topic de subscripción de things. Con esto daríamos por concluida la implementación de los componentes necesarios para contar con un flujo de trabajo básico en la comunicación entre un dispositivo inteligente local y servicios remotos Cloud. Inclusión de nueva regla AWS IoT adicional según tipo de asistente registrado Con el objetivo de mostrar la versatilidad de acciones que pueden adherirse a nuestro proyecto IoT Cloud, amoldable a las necesidades reales que pudieran requerirse en cualquier contexto y/o sector profesional, vamos a incorporar una funcionalidad nueva. Con ella, y retornando a nuestro ejemplo de aplicabilidad posible, en el supuesto del acceso al evento multitudinario de personas que acudan al mismo en calidad de ponente ("Speaker"), dicho registro de información, aparte de persistir en DynamoDB como soporte de almacenamiento de todos los asistentes, provocará: Almacenar el mensaje en un bucket de Amazon Simple Storage Service (S3) al que tendrá acceso únicamente el área de Marketing de la empresa organizadora del espacio, facilitando así la entrega de distinto material de merchandising como agradecimiento por la colaboración realizada. El envío de un mensaje personalizado gracias al servicio de notificaciones push Simple Notification Service (SNS), avisando al Chief Operations Officer (COO) de la llegada de cada conferenciante. Nos dirigiremos nuevamente por tanto al servicio AWS IoT en la consola de administración, seleccionando "Act" y "Rules" nuevamente del panel lateral, y haciendo clic en el otro extremo de la pantalla sobre botón "Create". Ya allí se sugiere el uso de valores para los siguientes parámetros: Name: speaker_detector Rule query statement: SELECT * AS speaker_details FROM 'm5stack/pub' WHERE type_attender = "Speaker" Add action: añadiremos dos acciones: 1) "Store a message in an Amazon S3 bucket", creando bucket de nombre "speaker-data" sobre el que depositar los mensajes con el detalle de los asistentes ponentes (más información aquí). 2) "Send a message as an SNS push notification", creando una subscripción de tipo email con la dirección de correo electrónico de la persona supervisora del control y gestión de los colaboradores (más información aquí). Tras crear la regla personalizada, la configuración debería de mostrarse similar a la que figura en la siguiente captura de pantalla: Figura 11. Características de regla AWS IoT adicional de detección de registro de speaker. 5. Validación final sin 'efecto demo' Llegó el gran día. Un evento sin precedentes. Nos encontramos ante la inauguración del encuentro tecnológico más esperado del año por todos: una nueva edición de IoT&Big Data Tech Event 2021. Inscripciones agotadas. Los mejores referentes mundiales charlando sin tapujos acerca de experiencias reales de proyectos reales haciendo uso de tecnologías asentadas y otras tantas disruptivas y en proceso de maduración. Comienzan los registros en puerta de asistentes regulares, sponsors y ponentes para la entrada al recinto. Para ello, se ha contado con una solución IoT Cloud desarrollada ad hoc para la presente edición, la cual parte de unos dispositivos inteligentes que van validando a cada paso la información del usuario (hora de acceso, tipología). Con una finalidad de control organizativo, de gestión del aforo y de apoyo a los colaboradores, dicha información se va registrando al momento, permitiendo llevar a cabo la toma de decisiones in-time (como la de restringir el acceso por superar el aforo establecido, por ejemplo). 9:00 horas: se abren las puertas, acudiendo paradójicamente (cuestiones del azar) únicamente personas en calidad de asistentes regulares y sponsors. 5 minutos después, se decide revisar uno de estos dispositivos IoT (el único a esas horas operativo), utilizado por un operario de la organización, así como el estado de la infraestructura aprovisionada en la nube de AWS para conocer si está funcionando correctamente la operabilidad . Revisando el thing en cuestión, se observa que se han producido hasta ahora 7 registros (3 de ellos con type_attender "Sponsor" - botón frontal izquierdo - y los otros 4 como "Regular attender" - botón frontal central -): Figura 12. Registro de las primera 7 altas en IoT&Big Data Tech Event 2021. Al acceder a la cuenta organizativa de AWS sobre la que se llevó a cabo la labor de implementación de nuestra solución IoT Cloud de servicios dedicados a la gestión de accesos al evento, encontramos que exactamente se habían registrado el mismo número de personas, y en el mismo orden temporal dentro del intervalo de los 5 minutos de registro: Figura 13. Items añadidos en tiempo de registro al evento en tabla de DynamoDB. Poniendo el foco en el cuerpo principal de cada registro (campo "payload"), observamos la información que a modo ilustrativo se emite desde el dispositivo origen, coincidente con la que se mostraba por la pantalla del dispositivo local: Figura 14. Volumen, tipo de inscritos e intervalos de tiempo alineados entre AWS y M5Stack. Justo a lo lejos, y obligado a madrugar por formar parte de la validación de esta nueva solución tecnológica, acude el primero de los ponentes al lugar de acreditación, registrándose debidamente al mismo. Acto seguido, se vuelve a requisar el dispositivo local para comprobar por pantalla si se ha emitido algún mensaje que corrobore dicha alta, indicando a todas luces que así fue: Figura 15. Primer speaker dado de alta en la solución IoT Cloud desde M5Stack. De manera análoga, validamos que se ha incluido un nuevo registro respecto a la anterior vez en el servicio autogestionado de bases de datos no relacionales DynamoDB, esta vez con el primer speaker dado de alta: Figura 16. Primer speaker dado de alta en la solución IoT Cloud desde M5Stack. Al tratarse de un colaborador, revisamos que el área de marketing disponga ya de la información relevante de su presencia para proveerle de un kit de bienvenida como gesto de gratitud por estar presente en estas jornadas: Figura 17. Detalle del ponente de acceso restringido al área de Marketing del evento. Y no menos importante, preguntamos al director de operaciones si ha recibido algún aviso relevante, y nos reenvía esta captura de pantalla de su dispositivo móvil: Figura 18. Notificación push avisando al COO del evento de la llegada del primer speaker. 13:00 horas: el aforo empieza a completarse. Éxito en la primera jornada, es probable que durante el día se tenga que impedir el paso a más visitantes para respetar las medidas de seguridad sanitaria en el recinto. 13:26 horas: tras contabilizar el número de personas dadas de alta, e identificar que ha llegado al máximo permitido, se emite una petición de servicio a todos los dispositivos inteligentes para dar por finalizada su labor de registro de nuevos usuarios: curl -d '{"STAFF":"AFORO COMPLETADO! IMPOSIBILIDAD DE NUEVAS ALTAS."}' -H "Content-Type: application/json" -X POST "https://xj91kamgla.execute-api.eu-west-1.amazonaws.com/Prod/publish" Figura 19. Mensaje emitido de organización a M5Stack avisando de una decisión en real-time ¡Sed más previsores en la jornada de mañana, que lo mismo volvéis a quedaros a las puertas de la cita obligada para todo "techie"! Aquí finaliza nuestro tutorial de diseño e implementación de una solución tecnológica que aúna la interconexión de componentes locales de sensorización y actuación local en combinación con capacidades Cloud. Espero con ello haber afianzado los conocimientos abordados a lo largo de esta serie de 3 publicaciones. Si has llegado hasta aquí, solo me queda felicitarte por tu esfuerzo. ¡Un nuevo mundo de posibilidades te espera! Todos los post de esta serie: Tu primer proyecto IoT Cloud (I): Tutorial para solución E2E con ESP32 y AWS IoT Tu primer proyecto IoT Cloud (II): Registro en AWS IoT y puesta a punto de M5Stack Tu primer proyecto IoT Cloud (III y fin): Procesamiento en streaming y validación final Para mantenerte al día con el área de Internet of Things de Telefónica visita nuestra página web o síguenos en Twitter, LinkedIn y YouTube

En el primer de los capítulos de esta serie planteamos un reto: tangibilizar las aproximaciones teóricas acerca del estado del arte del Internet de las Cosas y los servicios que la nube provee para aproximar disciplinas y unir capacidades. Definida la visión global de proyecto y los requisitos imprescindibles para su implementación (¡tiempo se ha concedido para equiparse!), no queda otra que ponernos en marcha. 1. AWS IoT Device Management: things y buenas prácticas Para poder establecer comunicación con un dispositivo ESP32, el primer requerimiento es el de dar de alta el mismo en la nube como representación virtual del objeto físico. Este procedimiento permite generar certificados únicos de seguridad, así como especificar sobre qué topics dispondrá de permisos de publicación o suscripción de mensajes. Para ello, es necesario recrear los siguientes pasos: Inicie sesión con sus credenciales de acceso en la consola de administración de AWS, navegue hasta el servicio AWS IoT Device Management. Ya allí, observará en el panel lateral izquierdo un listado de múltiples opciones, destacando el apartado "Manage" desplegado. Haga clic sobre "Things" (de normal seleccionada por defecto) y en "Register a thing" sobre la ventana principal, tal como se muestra en la siguiente imagen: Figura 2. Registro de nuestro dispositivo ESP32 M5Stack en AWS IoT Device Management En la siguiente ventana del asistente, haga clic en "Create a single thing". Es tiempo de añadir información identificativa de la cosa, necesaria para el registro de la entidad y su shadow en AWS IoT. Establezca por nombre m5stack-fire-01, manteniendo el resto de campos restantes con sus valores por defecto. Opcionalmente, es recomendable llevar a cabo una serie de buenas prácticas para adecuarse al dimensionamiento de proyecto real de Internet de las Cosas, en donde múltiples dispositivos de distinta naturaleza pudieran estar conviviendo cumpliendo distintas finalidades, a destacar: Aplicar un tipo ("thing type") para simplificar la administración de aquellos que sean de la misma familia, marca o recursos. Esta agrupación permite asociar características en común (atributos y tags), facilitando la identificación en masa para labores de mantenimiento, auditoría y/o inventariado de hardware. A modo de propuesta, crearemos un tipo de nombre event-recognition-unit, descripción "Registry counter units for technology current events." y tag clave-valor "device-type": "sender". Los grupos de cosas ("thing groups") facilitan la gestión remota IoT, sintetizando la ejecución de tareas: envío de ficheros, actualización de SO, aplicativos, etc.. Continuando con nuestro ejemplo, crearemos un nuevo grupo representativo del siguiente evento tecnológico del que el microcontrolador formará parte, de nombre "current-technology-event", conservando el resto de campos tal como figuran por defecto. Figura 3. Definición de nombre de dispositivo, tipo y grupo de cosas Escoge "One-Click certificate creation"; una vez generados, descargar únicamente el certificado del thing (el primero en la lista, de extensión .pem), la clave privada (.key) y la Amazon Root CA 1. Aparte, es fundamental hacer clic en el botón "Activate" para habilitarlo en el registro y posibilitar la conectividad. Tras ello, haga clic en "Attach a policy". Omitir agregar una política y seleccionando "Register Thing". Esto dará por concluido el asistente, regresando al panel principal de AWS IoT Device Management con el nuevo periférico dado de alta. En el menú lateral de la consola de AWS IoT, esta vez haga clic en "Secure", "Policies" y "Create". Establezca por nombre "M5StackPolicy", y seleccione la pestaña "Advanced mode" para añadir la siguiente plantilla de política genérica: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": [ "arn:aws:iot:REGION:ACCOUNT_ID:client/M5StackFire01" ], "Condition": { "ForAllValues:StringEquals": { "iot:ConnectAttributes": [ "PersistentConnect" ] }, "Bool": { "iot:Connection.Thing.IsAttached": [ "true" ] } } }, { "Effect": "Allow", "Action": "iot:Subscribe", "Resource": [ "arn:aws:iot:REGION:ACCOUNT_ID:topicfilter/m5stack/sub" ] }, { "Effect": "Allow", "Action": "iot:Receive", "Resource": [ "arn:aws:iot:REGION:ACCOUNT_ID:topic/m5stack/sub" ] }, { "Effect": "Allow", "Action": "iot:Publish", "Resource": [ "arn:aws:iot:REGION:ACCOUNT_ID:topic/m5stack/pub" ] } ] } Sobre la plantilla, reemplazar REGION y ACCOUNT_ID (este segundo, sin guiones medios) por los valores correspondientes definidos en su cuenta AWS. Pueden encontrarse encontrar en la esquina superior derecha de la ventana de la consola de administración de AWS. Figura 4. Definición de nombre de dispositivo, tipo y grupo de cosas Haga clic en "Create". Nuevamente en la consola de AWS IoT, elija "Secure",y sobre el menú desplegado en "Certificates". Seleccione el creado para su dispositivo y haga clic sobre "Actions" y "Attach policy". Elija M5StackPolicy sobre el listado de políticas de seguridad y seleccione "Attach". Llegados a este punto, el dispositivo IoT se encuentra registrado y con permisos de autenticación sobre el Hub de AWS IoT, pudiendo publicar en la cola de mensajes m5stack/pub y suscribirse sobre los topis emitidos en m5stack/sub. Por último, es conveniente obtener el endpoint MQTT de la cuenta AWS, punto de acceso único a compartir con todo thing con el que desee aprovisionar la solución (en este caso, únicamente uno). Esta información debe resguardarse junto a los certificados generados y descargados anteriormente para incorporar en siguientes pasos dentro de la lógica (código) del artefacto hardware. Figura 5. Endpoint MQTT necesario para la interconexión IoT Cloud 2. Arduino IDE: Puesta a punto Contando ya con el entorno de desarrollo instalado en su equipo, llevaremos a cabo una serie de ajustes previos de configuración indispensables. Con ellos, el IDE reconocerá al kit de desarrollo y prototipado M5Stack-Fire como módulo compatible para su programación, así como la instalación de librerías requeridas en tiempo de compilación. Abra Arduino IDE, y en el menú superior de opciones, seleccione "Archivo" y dentro, sobre la opción "Preferencias". Al final de la ventana emergente encontrará la opción "Gestor de URLs Adicionales de Tarjetas", agregar la siguiente url, presionando en última instancia el botón "OK": https://dl.espressif.com/dl/package_esp32_index.json Ahora diríjase sobre el menú principal a "Herramientas", "Placas" y "Gestor de tarjetas". En la barra de búsqueda, escriba esp32 e instale la última versión. Una vez se complete el proceso, haga clic en el botón "Cerrar". Cuando volvamos a abrir el gestor de tarjetas veremos que se han añadido en la parte inferior las tarjetas instaladas. Seleccionaremos la tarjeta que vamos a utilizar; en nuestro caso la tarjeta de la familia ESP32 Arduino M5Stack Fire: Figura 6. Elección de modelo de microcontrolador elegido para nuestra PoC desde Arduino IDE Únicamente resta para completar este setup inicial la instalación de dependencias de software para habilitar el protocolo de conectividad MQTT y el tratamiento de mensajes en JavaScript Object Notation (JSON). Por ello, sobre el menú superior, haga clic en esta ocasión sobre "Programa", luego en "Incluir Librería" y "Administrar Bibliotecas..."; sobre el cuadro de opciones en la ventana emergente, instala las últimas versiones de MQTT (de Joel Gaehwiler), ArduinoJson y Adafruit Neopixel sobre la barra de búsqueda. 3. "...Developers, Developers, Developers...!" Apartado enfocado en la codificación del desarrollo a incorporar en M5Stack, encargado de ordenar peticiones de servicio según tipología de asistente al evento tecnológico hacia la nube, así como procesar cualquier mensaje que se quiera transmitir en sentido inverso. Abra Arduino IDE en su equipo, haga clic en Archivo, Nuevo para crear un nuevo sketch o boceto (de extensión .ino). Es necesario agregar además una nueva pestaña, asignarle por nombre "secrets.h". Representa el fichero cabecera con todos los componentes requeridos; en este caso, hay que pegar la plantilla de código que figura a continuación, y sobre ella, rellenar la siguiente información: Nombre del thing registrado en AWS IoT Device Management (en constante de nombre "THINGNAME"): m5stack-fire-01 Parámetros de conectividad al punto de acceso disponible WiFi. (constantes "WIFI_SSID" y "WIFI_PASSWORD"). Endpoint MQTT único de nuestra cuenta AWS ("AWS_IOT_ENDPOINT"). Copy-paste de los 3 certificados descargados: Amazon Root CA 1 ("AWS_CERT_CA"), certificado ("AWS_CERT_CRT") y clave privada del dispositivo ("AWS_CERT_PRIVATE"). #include <pgmspace.h> #define SECRET #define THINGNAME "m5stack-fire-01" const char WIFI_SSID[] = "YOUR WIFI NETWORK NAME (SSID)"; const char WIFI_PASSWORD[] = "WIFI PASSWORD"; const char AWS_IOT_ENDPOINT[] = "xxxxx.amazonaws.com"; // Amazon Root CA 1 static const char AWS_CERT_CA[] PROGMEM = R"EOF( -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- )EOF"; // Device Certificate static const char AWS_CERT_CRT[] PROGMEM = R"KEY( -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- )KEY"; // Device Private Key static const char AWS_CERT_PRIVATE[] PROGMEM = R"KEY( -----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY----- )KEY"; Ahora seleccione la pestaña original con el fichero Sketch, copie el siguiente código y guarde los cambios, asignándole como nombre event-handler.ino. Posteriormente pasaremos a describir brevemente las secciones más relevantes: #include "secrets.h" #include "WiFi.h" #include <WiFiClientSecure.h> #include <MQTTClient.h> #include <ArduinoJson.h> #include <stdio.h> #include <stdlib.h> #include <ezTime.h> #include <time.h> #include <M5Stack.h> #include <Adafruit_NeoPixel.h> // How many times we should attempt to connect to WiFi #define WIFI_MAX_RECONNECT_TRIES 15 // The MQTT topics that this device should publish/subscribe #define AWS_IOT_PUBLISH_TOPIC "m5stack/pub" #define AWS_IOT_SUBSCRIBE_TOPIC "m5stack/sub" // How many times we should attempt to connect to AWS #define AWS_MAX_RECONNECT_TRIES 10 #define NOTE_D1 294 #define NOTE_DL1 147 #define NOTE_DH1 589 #define M5STACK_FIRE_NEO_NUM_LEDS 10 #define M5STACK_FIRE_NEO_DATA_PIN 15 Adafruit_NeoPixel pixels = Adafruit_NeoPixel(M5STACK_FIRE_NEO_NUM_LEDS, M5STACK_FIRE_NEO_DATA_PIN, NEO_GRB + NEO_KHZ800); WiFiClientSecure net = WiFiClientSecure(); MQTTClient client = MQTTClient(256); void connectToWiFi() { WiFi.mode(WIFI_STA); WiFi.begin(WIFI_SSID, WIFI_PASSWORD); M5.Lcd.print("Connecting to Wi-Fi"); // Only try 10 times to connect to the WiFi int retries = 0; while (WiFi.status() != WL_CONNECTED && retries < WIFI_MAX_RECONNECT_TRIES){ delay(500); Serial.print("."); retries++; } while (WiFi.status() != WL_CONNECTED){ M5.Lcd.print("."); esp_sleep_enable_timer_wakeup(1 * 60L * 1000000L); esp_deep_sleep_start(); } M5.Lcd.println(""); } void connectToAWSIoT() { // Condiv WiFiClientSecure to use the AWS IoT device credentials net.setCACert(AWS_CERT_CA); net.setCertificate(AWS_CERT_CRT); net.setPrivateKey(AWS_CERT_PRIVATE); // Connect to the MQTT broker on the AWS endpoint we defined earlier client.begin(AWS_IOT_ENDPOINT, 8883, net); // Create a message handler client.onMessage(messageHandler); M5.Lcd.print("Connecting to AWS IoT"); int attempts = 0; while (!client.connect(THINGNAME) && attempts < AWS_MAX_RECONNECT_TRIES) { delay(50); M5.Lcd.print("."); attempts++; } M5.Lcd.println(""); if(!client.connected()){ M5.Lcd.println("AWS IoT Timeout!"); return; } // Subscribe to a topic client.subscribe(AWS_IOT_SUBSCRIBE_TOPIC); M5.Lcd.println("AWS IoT Connected!"); initPixel(); M5.Lcd.println("ESP32&AWS: Tutorial from scratch solucion IoT Cloud"); M5.Lcd.println("https://empresas.blogthinkbig.com/esp32-y-aws-tutorial-from-scratch-de-solucion-iot-cloud"); M5.Lcd.println("Author: Ismael Rihawi Aragon"); M5.Lcd.println(""); M5.Lcd.println("========================================"); M5.Lcd.println("WELCOME TO IOT&BIG DATA TECH EVENT 2021!"); M5.Lcd.println("- What kind of assistant are you?"); M5.Lcd.println("A)Regular attender B)Sponsor C) Speaker"); M5.Lcd.println("========================================"); } void publishMessage(String attender) { StaticJsonDocument<200> doc; doc["type_attender"] = attender; doc["quantity"] = 1; doc["access_time"] = UTC.dateTime(); char jsonBuffer[512]; serializeJson(doc, jsonBuffer); client.publish(AWS_IOT_PUBLISH_TOPIC, jsonBuffer); } void messageHandler(String &topic, String &payload) { StaticJsonDocument<200> doc; deserializeJson(doc, payload); const char* message = doc["message"]; M5.Lcd.println(message); } void initPixel() { int i, j; for (i = 1; i < 2; ++i) { pixels.begin(); for (j = 1; j < 11; ++j) { pixels.setPixelColor(j, pixels.Color(255, 0, 0)); pixels.show(); delay(100); } pixels.clear(); pixels.show(); } } void setup() { M5.begin(); M5.Lcd.fillScreen(WHITE); M5.Lcd.setTextColor(BLUE); pixels.begin(); Serial.begin(9600); connectToWiFi(); connectToAWSIoT(); } void loop() { if(M5.BtnA.wasReleased()) { M5.Speaker.tone(NOTE_D1, 200); M5.Lcd.println("You pressed REGULAR ATTENDER!"); publishMessage("Regular attender"); delay(1000); } else if(M5.BtnB.wasReleased()) { M5.Speaker.tone(NOTE_DH1, 200); M5.Lcd.println("You pressed SPONSOR ATTENDER!"); publishMessage("Sponsor"); delay(1000); } else if(M5.BtnC.wasReleased()) { M5.Speaker.tone(NOTE_DL1, 200); M5.Lcd.println("You pressed SPEAKER ATTENDER!"); publishMessage("Speaker"); delay(1000); } // update button state M5.update(); client.loop(); } Sobre la plantilla propuesta, cabe resaltar: La definición de los topics MQTT en los que llevar a cabo la emisión de mensajes o la recepción por suscripción, asignación recogida en las constantes AWS_IOT_PUBLISH_TOPIC y AWS_IOT_SUBSCRIBE_TOPIC. Por otra parte, dicha información concuerda con lo establecido dentro de la política de seguridad adjunta al certificado del dispositivo IoT en AWS IoT Device Management. La función connectToWiFi() intenta establecer conexión con las credenciales de punto de conectividad proporcionados, entrando en modo de suspensión en caso no conseguirlo al cabo de un número de intentos n para eficientar el uso de la batería. La función connectToAWSIoT() contiene la creación de instancias de cifrado punto a punto en el paso de mensajes (clase WiFiClientSecure) y canal de comunicación MQTT (clase MQTTClient). Los certificados codificados y el endpoint de nuestra cuenta AWS entran en juego en la configuración de los objetos para el posterior intento de establecimiento de conexión. Este proceso se encuentra acotado a un número de intentos máximos para eficientar también los recursos energéticos del dispositivo IoT; en caso afirmativo, se procede a la suscripción del topic definido y a la renderización por pantalla LCD de textos de bienvenida y menú de opciones disponibles. La función publishMessage(String attender) tiene por objetivo construir un mensaje JSON a objeto de publicación por el topic correspondiente; recoge información simple para facilitar la comprensión, resaltando la inclusión del tipo de asistente al evento tecnológico seleccionado. Las librerías internas de M5Stack nos permiten capturar en todo momento si el usuario presiona el botón físico izquierdo del frontal (en cuyo caso, indica que se trata de un "Regular attender"), botón central ("Sponsor") o derecho ("Speaker"). Este evento acciona ipso facto la creación del objeto mensaje descrito, que acto seguido se emite hacia la nube para su consumo por parte de otros suscriptores y/o accionado de reglas de negocio en cadena. La función initPixel() únicamente tiene por misión iluminar con una transición de color rojo las 2 barras LED laterales que porta M5Stack cuando se conecta correctamente a AWS IoT, en claro homenaje a un icono generacional. Flasheado de módulo ESP32 Ya sólo resta alojar nuestro código en el propio thing para dar por completada la labor de programación del tutorial, y que posibilita en esencia la interoperabilidad completa entre componentes mínimos fundamentales en una solución IoT Cloud. Conecte M5Stack a un puerto USB del equipo en el que tenemos instalado y configurado (placa y librerías) la última versión de Arduino IDE. Abrir herramienta de desarrollo y sketch propuesto con la lógica incorporada (fichero principal de extensión .ino y cabecera .h). Cerciorarse de que se conserva la elección de la placa ESP 32 Ardunio M5Stack Fire (recordamos que se realiza en el menú superior, haciendo clic en "Herramientas", "Placas", "Gestor de tarjetas" y "ESP32 Arduino"). Seleccionar el botón "Subir" para iniciar las etapas de compilación y volcado del código. Un log similar al siguiente debiera mostrarse por la terminal de salida del IDE, evidenciando la finalización del proceso. Figura 7. Trazas de correcta escritura (flashing) de boceto en M5Stack Fire desde Arduino IDE Al instante veremos iluminarse la pantalla LCD del dispositivo, ejecutando la secuencia de acciones programadas: Figura 8. M5Stack conectado por WiFi a AWS IoT. ¡Todo preparado para el evento del año! Hasta aquí llega la segunda parte del tutorial. En el tercer post que completa la serie, definiremos ciertos automatismos sobre servicios Cloud de AWS recurrentes originados por los mensajes IoT emitidos. Cerraremos con una gran validación final, certificando el correcto funcionamiento de nuestro flujo de trabajo end-to-end. Stay tuned! Todos los post de esta serie: Tu primer proyecto IoT Cloud (I): Tutorial para solución E2E con ESP32 y AWS IoT Tu primer proyecto IoT Cloud (II): Registro en AWS IoT y puesta a punto de M5Stack Tu primer proyecto IoT Cloud (III y fin): Procesamiento en streaming y validación final Para mantenerte al día con el área de Internet of Things de Telefónica visita nuestra página web o síguenos en Twitter, LinkedIn y YouTube.

En un anterior post a comienzos de verano exploramos en profundidad el catálogo de servicios disponibles en Amazon Web Services para la implementación de soluciones profesionales que permitan unir recursos de dispositivos inteligentes con capacidades de múltiple propósito de la nube. Sentadas las bases teóricas, es turno de pasar a la acción: he aquí un tutorial paso a paso para la creación desde cero de un proyecto IoT basado en la conexión e interacción entre un microcontrolador ESP32 y el Hub de componentes asociados en la nube de AWS IoT. Con la intención de facilitar la comprensión didáctica, el proyecto tendrá por finalidad simbólica el registro estadístico de profesionales a un evento tecnológico de vanguardia, discerniendo si cada persona de a pie acude en calidad de asistente regular, patrocinador o ponente. Lo prometido es deuda, ¡manos a la obra! Visión global técnica de la solución La propuesta plantea abordar todos los pasos necesarios para una comunicación bidireccional entre componente IoT físico y AWS IoT: registro del thing, incluyendo gestión de certificados y políticas, programación de lógica de publicación y suscripción básica a topics para mensajería segura a través del protocolo MQTT. Posteriormente llevaremos a cabo el despliegue de una plantilla predefinida existente en AWS Serverless Application Repository (SAR), añadiendo dicha conexión e interacción entre entidad local e infraestructura Cloud. El flujo de trabajo completo que incorpora la aplicación SAR incluye: Configuración de AWS IoT Rule para el reenvío o suscripción de los mensajes emitidos por el microcontrolador a una función AWS Lambda que permita actualizar una tabla en el servicio autogestionado de bases de datos NoSQL Amazon DynamoDB. Endpoint REST que acepta peticiones de servicio POST mediante Amazon API Gateway, invocando una función AWS Lambda que publique mensajes personalizados en la propia pantalla del dispositivo. Figura 1. Herramientas y tecnologías implicadas en solución IoT Cloud ¿Qué se requiere para la Prueba de Concepto? De cara a la realización de la PoC, asegúrate de contar con lo siguiente: Cuenta de AWS, resultando más que suficiente para nuestras pretensiones de proyecto la capa de 12 meses de uso gratuito (Free Tier) de los servicios involucrados, no esperando sobrepasar las limitaciones de uso de los mismos. Puede hacer uso del siguiente enlace para proceder a un nuevo registro, así como entrar al detalle de las condiciones de uso de los servicios de la capa gratuita de AWS desde este otro link. Una conexión WiFi estable. Descarga e instalación de la versión más reciente del entorno de programación Arduino IDE, necesario para programar microcontroladores que nos permitan recoger datos de la sensórica integrada para su envío, persistencia y procesamiento en la nube. Disponer de un módulo de la familia ESP32 compatible con Arduino, atendiendo a este listado oficial de placas admitidas. ESP32 ESP32 es la denominación de familia de chips SoC ("System on Chip") que salió al mercado en 2016 de la mano de Espressif (de ahí su nombre) y TSMC. Evolución natural del SoC ESP8266, representan un diseño ideal para soluciones IoT al integrar un procesador de doble núcleo de 32 bits (ampliable a 240 MHz), conectividad WiFi y Bluetooth 4.0, encriptación por hardware, múltiples sensores ambientales, táctiles y posicionales, y una enorme comunidad a sus espaldas desarrollando firmwares, herramientas y documentación para popularizar su uso. En nuestro caso, recurriremos para la prueba de concepto al kit de desarrollo integrado M5Stack Fire, el cual incluye: SoC ESP32, pantalla LCD a color, botones frontales programables, altavoz integrado, zócalo para tarjetas micro SD y capacidad de expansión de múltiples módulos funcionales magnéticamente. https://www.youtube.com/watch?v=zzw_oGgEzSQ&feature=emb_logo Video 1. Spot promocional oficial del kit de desarrollo y prototipado ESP32 M5Stack Hitos para alcanzar la cima Con el fin de establecer una composición de lugar para orientarnos en caso de pérdida, nuestra solución comprenderá los siguientes objetivos: Registro de nuevo tipo de dispositivo virtual AWS IoT ("thing"), certificados y políticas de seguridad; definición de plantillas de cosas o thing types, thing groups y billing groups (opcional). Instalación y configuración de placa ESP32 y librerías de soporte de protocolo de comunidad M2M MQTT y serialización de mensajes en formato JSON en Arduino IDE. Inclusión de certificados, implementación y flashing de código en SoC ESP32 para registro de paridad y operabilidad sobre AWS IoT Core y resto de servicios Cloud. Despliegue personalizado de aplicación AWS SAR para creación de Backend Serverless de envío, recepción y procesamiento en streaming de topics. Validación de workflow de solución IoT Cloud. Este artículo es el primero de una serie de 3 capítulos, cuyo enfoque se centrará en completar los tres primeros pasos descritos anteriormente, reservando los dos últimos para la tercera parte de la función. La misión es clara: aportar un valor diferencial a partir de la captura de información del entorno que requiere de suplir carencias y aprovechar oportunidades gracias al Internet de las Cosas. ¿Te animas? Just do IoT! Todos los post de esta serie: Tu primer proyecto IoT Cloud (I): Tutorial para solución E2E con ESP32 y AWS IoT Tu primer proyecto IoT Cloud (II): Registro en AWS IoT y puesta a punto de M5Stack Tu primer proyecto IoT Cloud (III y fin): Procesamiento en streaming y validación final Para mantenerte al día con el área de Internet of Things de Telefónica visita nuestra página web o síguenos en Twitter, LinkedIn y YouTube.

Nos encontramos ante un nuevo tiempo donde el usuario final, hasta entonces principal responsable de aportar valor al negocio a través de sus datos, está cediendo el protagonismo en favor de las máquinas. En este contexto, se confirma la consolidación de una tendencia: la migración de infraestructuras tecnológicas propias (on-premise) hacia una nube de servicios multipropósito que se rigen por el modelo "Pay as You Go". ¿Qué tienen que decir los players destacados de Cloud Computing al respecto? El Internet de las cosas o IoT representa un universo de objetos inteligentes conectados con el fin de proporcionar datos relevantes acerca del entorno y quiénes conviven en el mismo. Su naturaleza es claramente habilitadora al promover el procesamiento en la nube y capacitar a nuevas soluciones a hacer frente a problemas reales en base a insights más precisos y personalizados. Conocedores de esta gran oportunidad, compañías e industrias están centrando sus esfuerzos en organizar su porfolio de productos profesionales alrededor de un ecosistema IoT propio. Al frente, una serie de desafíos a superar en el ámbito tecnológico para ver prosperar tal revolución: seguridad, conectividad, compatibilidad, estandarización y capacidad analítica. Aspectos a los que plataformas Cloud como Amazon Web Services (AWS) empiezan a dar respuesta, actualizando su catálogo de servicios dedicados a abordar todas las etapas del ciclo de vida de una solución IoT. En esencia, ayudando a empresas y particulares a simplificar las tareas de soporte de infraestructura deslocalizada, en aras de permitir que sus equipos técnicos puedan centrarse en el desarrollo de la lógica empresarial. A continuación, realizaremos un recorrido por los principales productos que ofrece este gigante tecnológico, describiendo funcionalidad, uso propuesto y configuración requerida con un amplio enfoque E2E (End-to-End). Visión global de AWS IoT Core Figura 1: Elementos core requeridos en el funcionamiento de AWS IoT AWS provee una infraestructura de funcionalidades core orientadas a incorporar dispositivos con conexión a Internet. Dicho anidamiento de "things" conforma una tipología en forma de red descentralizada de nodos físicos con recursos propios de captura, almacenamiento, inferencia y actuación frente a lo que sucede a su alrededor. Sobre ellos, habilita un canal unificado constituido por los siguientes componentes (Figura 1): Mecanismo seguro de publicación y/o suscripción de mensajes entre dispositivos registrados en AWS IoT y aplicaciones móviles, identificado como Message Broker. Requerido el uso de a) Kit de desarrollo de software oficial (AWS SDK) b) Protocolo de conectividad machine-to-machine MQTT sobre WebSocket o interfaz HTTP REST según especificación. Registro recurrente del estado de cada dispositivo con información identificativa que lo representa virtualmente en la nube. Dicha instantánea recibe el nombre de sombra ("shadow"), siendo el servicio Device Shadow el responsable de administrar el histórico de todas las capturas con las actualizaciones en el tiempo. Meta-contenido adicional asociado a las magnitudes físicas capturadas por elementos de sensorización, desencadenando acciones por el cumplimiento de condiciones en reglas definidas por la organización. Sobre el diagrama anterior, recibe el nombre de Rules Engine. Protección en comunicaciones a través de la generación y requerimiento de uso de certificados X.509 como credencial de identificación y acceso a cada uno de los componentes anteriormente descritos. Facilidad de integración con soluciones corporativas ya implantadas o de nueva creación desplegadas en la propia infraestructura Cloud, permitiendo flexibilidad máxima entre estos. Aparte, gracias a la conexión al proveedor, toda solución IoT hereda las características inherentes al mismo: alta disponibilidad de servicio, durabilidad de la información, seguridad y escalabilidad, garantizando un óptimo nivel de disponibilidad de servicio. Catálogo de servicios autogestionados en AWS IoT El conjunto de componentes anteriormente descrito recibe el nombre de AWS IoT Core, disponible públicamente desde finales de 2015, y constituye la vía de entrada sobre el que operar con nuevos servicios agregados con entidad propia (Figura 2). De más reciente incorporación, otorgan robustez y autonomía al modelo híbrido de Things & Cloud, a destacar los siguientes: Figura 2: Arquitectura de servicios principales de la plataforma AWS IoT AWS IoT Greengrass: Servicio que posibilita transferir competencias de comunicación, persistencia, replicación y analítica de datos al entorno local (concepto que conocemos como "edge computing"). Su inclusión dota a las soluciones IoT de respuesta a eventos near real-time, mantenimiento del servicio en ausencia de conectividad y reducción de costes operacionales, entre otras. AWS IoT Device Management: Motor de simplificación de las labores de inclusión de dispositivos en masa, facilitando de manera ágil su supervisión. La generación de certificados, políticas, agrupaciones de cosas, trabajos o canales seguros entre cosas, a golpe de clic. AWS IoT Device Defender: Panel de monitorización de métricas de seguridad de la flota de dispositivos, asegurando el correcto cumplimiento normativo y de procesos de auditaría. Figura 3: Ejemplo de arquitectura de mantenimiento predictivo industrial con integración de servicios tradicionales de computación distribuida y almacenamiento de alta durabilidad en AWS AWS IoT Analytics: Módulo que facilita el análisis proveniente de los datos recogidos por los dispositivos de Internet of Things. ¿Qué beneficios entraña respecto a los servicios de Big Data e Inteligencia Artificial ya existentes en AWS? Una capa de abstracción que aúna y optimiza las tareas desde su captura en tiempo real (en vez de Amazon Kinesis), almacenamiento (Amazon S3), transformación (AWS Glue) o consulta (Amazon Athena), entre otros. El ejemplo del diagrama anterior se vería reducido ostensiblemente con la incorporación de esta pieza de carácter cognitivo (Figura 4): Figura 4: Ejemplo de arquitectura de mantenimiento predictivo industrial simplificada gracias a AWS IoT Analytics En constante evolución, AWS IoT sigue incorporando nuevos servicios (véase AWS IoT SiteWise, AWS IoT Things Graph o FreeRTOS) y alimentando de nuevas funcionalidades a los ya existentes de largo recorrido. A pesar de todas las ventajas proporcionadas por los mismos, el mercado indica la existencia de cierto margen de crecimiento, especialmente en la mejora de la complejidad de uso y la experiencia de usuario. Amazon presenta un listado de casos prácticos ejecutados con éxito por parte de empresas de múltiples sectores pioneras en su productivización. En un siguiente post, ya a la vuelta del verano, nos pondremos manos a la obra, llevando a cabo paso a paso una prueba de concepto (MVP) al alcance de todos, y que se apoyará en algunos de estos servicios. El objetivo será el de arrojar luz acerca de como establecer un flujo de trabajo básico en la comunicación e interacción entre un microcontrolador y el hub de componentes asociados en la nube de AWS. ¡Estad listos para entonces! Para mantenerte al día con el área de Internet of Things de Telefónica visita nuestra página web o síguenos en Twitter, LinkedIn y YouTube.

Los bitcoins, la tecnología Blockchain, la minería o los smart contracts son conceptos que están cada vez más presentes en medios tecnológicos. Pero ¿de verdad alcanzamos a comprender lo que conlleva la tecnología y hacia dónde camina?. En el post de hoy vamos a plantear una serie de preguntas que nos van a ayudar a arrojar algo de luz sobre aspectos que nos preocupan a todos. El documento publicado por la enigmática figura de Satoshi Nakamoto a finales de 2008 presentaba Bitcoin como un sistema de pago electrónico Peer-To-Peer. Pero... 1. ¿Qué es un Bitcoin y cómo puede un usuario ejercer la posesión de sus Bitcoins? Respuesta: Bitcoin representa un activo digital en forma de moneda virtual, resultante de la combinación de redes de ordenadores, técnicas criptográficas y software avanzado para el intercambio de bienes y servicios al actuar éste como un medio de pago, transmitiendo valor electrónicamente de forma fácil, rápida y segura entre dos usuarios sin mediación de una entidad central que la emita y controle (de ahí el uso tan generalizado del concepto vinculado a Bitcoin de “descentralización”). El mecanismo empleado para ejercer posesión de criptomonedas y hacer uso de éstas es a través de los conocidos monederos o wallets, que no son más que aplicaciones móviles y/o de escritorio con una interfaz visual amigable y comprensible a ojos de cualquiera. La peculiaridad de esta clase de herramientas es que abstraen por completo al usuario final de la tecnología subyacente, poniendo a su disposición la capacidad de llevar a cabo operaciones básicas de control y gestión financiera de sus unidades monetarias. Gracias a las claves privadas (únicas para cada usuario), permiten la consulta del saldo global como compendio del histórico de importes vinculados a su dirección pública en todas las transacciones monetarias registradas en la cadena de bloques en las que éste se vio involucrado desde el origen de los tiempos. Del mismo modo, los monederos también permiten consultar el detalle de dichas transacciones firmadas digitalmente con nuestras claves privadas (fechas de emisión, direcciones origen y destino, comisión, número de confirmaciones, etc.), así como emitir otras nuevas, siendo la red la que valida previamente la autoría de la firma y la liquidez de sus fondos. 2. ¿Y si el usuario pierde el equipo o las claves? Respuesta: El grado de resolución varia ostensiblemente según sea uno u otro escenario. En caso de perder el dispositivo en el que teníamos alojada la cartera digital contenedora de las claves privadas, existe un sistema de recuperación conocido como “semilla determinística” o “seed”, que es un conjunto de palabras aleatorias (normalmente 12) sencillas de memorizar o anotar en papel con las que es posible regenerar siempre las mismas claves privadas, almacenándolas en una nueva instalación de monedero en otro equipo de sustitución. Si por el contrario accidentalmente se pierden las claves privadas y no se cuenta con un sistema de respaldo y recuperación al uso, entonces todos los importes de las transacciones registradas en la cadena de bloques firmadas digitalmente con esa “llave maestra” pasarían a quedar en la nada, inutilizables, fuera del suministro circulante y total. 3. ¿En qué consiste el concepto de cadena de bloques?¿ por qué se dice que aporta garantías de inmutabilidad? Respuesta: Es sin duda la base teórica y conceptual necesaria para comprender el funcionamiento de esta tecnología, y de la que emergen la mayor parte de sus bondades. Una cadena de bloques es una lista de bloques vinculados entre sí por orden cronológico de llegada y escritura, y que partieron de un bloque inicial (llamado “génesis”). ¿Qué información contienen? Cada bloque reúne un conjunto de transferencias de valor (bitcoins) entre una dirección origen y una dirección destino llamadas “transacciones”, las cuales son elegidas por los nodos mineros responsables de su escritura, así como un sello de tiempo que establece la fecha de tramitación y una huella digital del bloque anterior que aporta robustez a la infraestructura y fiabilidad a la información que atesora. La validación de las transacciones se establece a través del cálculo de un algoritmo matemático que transforma la cabecera de todo este bloque arbitrario de datos en una secuencia de caracteres con una longitud fija (lo que se conoce por “función criptográfica Hash”). Esto supone un esfuerzo computacional notorio por parte de uno de los tipos de participantes más activos y notorios en la red: los nodos mineros. Dicha prueba de trabajo realizada por ellos permite la escritura de nuevos bloques que se añaden a la cadena principal bajo el consenso de todos los nodos de la red. Y es precisamente ahí donde reside la garantía de inmutabilidad. En el cálculo del Hash de la cabecera de un bloque actual se encuentra el Hash del bloque anterior, por lo que si se produjese alguna modificación en el cuerpo o identidad de un nodo padre, esto repercutiría en una remota corrección de los nodos sucesores a éste al verse en cada uno de ellos modificado el valor del campo Hash de bloque anterior requerido para la confección del suyo propio, lo cual computacionalmente sería imposible de abordar en el tiempo. Se suele afirmar que muchos cibercriminales prefieren cobrar extorsiones en bitcoins porque es anónimo, pero esa afirmación parece chocar con el concepto público de la blockchain. 4. ¿Hasta qué punto es anónimo Bitcoin? Respuesta: En un mundo hiperconectado, en donde las barreras de seguridad y ofuscación de datos sensibles y/o de identificación del ser chocan con filtraciones de información y medidas preventivas de detección de usos maliciosos ante resquicios de vulnerabilidad en tecnologías disruptivas recién implantadas, no es posible garantizar el anonimato de los usuarios participantes en una Blockchain pública. ¿Cuáles son los principales argumentos de ello? La propia naturaleza intrínseca de una cadena de bloques, la cual permite sin restricciones contemplar la trazabilidad de cualquier operación entre pares de direcciones públicas, así como realizar un seguimiento pormenorizado de transacciones asociadas a una en concreto (gracias a la existencia de herramientas web de exploración de bloques como Blockchain.info o Blockchair.com, entre otras). A esto tenemos que añadir que, en el caso de Bitcoin, estamos hablando de una cadena de bloques pública y no "permisionada" (no requiere de solicitud previa para ingreso en la misma). Ahora bien, ¿poder rastrear direcciones debido a su carácter público puede derivar en conocer la identidad personal de los propietarios portadores de dichos monederos? Existen varios indicios o mecanismos que podrían arrojar pistas bastante concluyentes sobre ello. El hecho de utilizar una red P2P de nodos interconectados ejecutando un software de computación y almacenamiento de copias idénticas (el ya archiconocido “libro contable universal”), hace que todo mensaje que emita una transacción de valor digital entre direcciones Bitcoin lleve implícita una dirección IP de interconexión de ese nodo responsable fácilmente geolocalizable. Otros factores relevantes y susceptibles de debilitar enteramente la privacidad son a través de la compra-venta de criptomonedas en casas de intercambio, las cuales exigen de un registro previo nominativo de la persona a hacer uso del servicio (copia de documento nacional de identidad, pasaporte, datos bancarios inclusive), o con el uso de monederos ligeros o web (como los que suministran las propias casas de intercambio) delegando a ellos la gestión de tus claves privadas, y consistiendo el seguimiento exhaustivo de los metadatos derivados del acceso y navegación web/mobile a sus servicios. El mundo ha cambiado mucho desde el año 2008. Por aquel entonces los iPhone apenas llevaban unos años en el mercado y a Instagram aún le quedaba tiempo hasta despuntar en 2010. 5. ¿Cómo ha llevado el paso del tiempo la comunidad de Bitcoin? ¿Se ha producido algún cambio en el protocolo original que se pueda reseñar? Respuesta: Uno de los pilares básicos que ha propiciado el asentamiento, crecimiento y evolución de Bitcoin hasta nuestros días ha sido en buena parte debido al respaldo inicial y continuado de la comunidad de tecnólogos y entusiastas de los principios inherentes de esta revolución tecnológica, la cual propone en esencia la descentralización, transparencia, seguridad e inmediatez en el intercambio de valores digitales. Este apoyo ha trascendido a hechos consensuados por todos ellos, plasmados en la existencia de una metodología de revisiones constantes de la funcionalidad y características del protocolo de red de Bitcoin respecto a la especificación inicial planteada (en el documento “White paper”), permitiendo abordar errores o limitaciones detectadas a posteriori, así como ideas de mejora que enriquecen su operatividad. El nombre en clave del documento que plasma la propuesta es BIP o “Bitcoin Improvement Proposals”. ¿Cuáles destacaría a mi parecer? De los BIPS de tipo informacional, la que introdujo las carteras deterministas jerárquicas (BIP-0032) que permiten la generación de múltiples direcciones públicas derivadas unas (padres) de otras (hijas) en una estructura de árbol con profundidad infinita, partiendo de la misma secuencia de palabras clave (24) como semilla de respaldo, permitiendo mayor eficiencia y simplicidad en la gestión de wallets, mayor privacidad en la recepción de valor y subsanación de problemas en el uso de copias de seguridad. Por otra parte, de las propuestas de tipo standards track (estructural/funcional), sin duda el BIP-0141 o “Segregated Witness”, la cual lucha contra la maleabilidad o posibilidad de alteración de las firmas involucradas en una transacción, influyendo negativamente en la confianza de la red. La solución técnica, a grandes rasgos, pasa por desplazar las firmas y claves de los valores de condición de la lógica impuestos por el originador de la transacción en validación de la transacción (también conocido como “scriptSig”) a una zona reservada llamada Witnesses, con beneficios extras de ahorro en espacio en disco por aligerar los bloques, menor gasto en fees y ancho de banda, entre otros. 6. ¿Y cómo funciona el mecanismo de aceptación de estos cambios en el protocolo de Bitcoin? Respuesta: Siguiendo los cauces de proposición y consenso de las propuestas de mejora, que parten de la publicación del documento (borrador) en la lista de correo de desarrolladores “bitcoin-dev”, en donde se localizan y subsanan errores e introducen aspectos no considerados. Continuando, después, con una etapa de discusión acerca de la viabilidad y ganancia real de la propuesta que precede a la publicación en el repositorio de oficial de propuestas en GitHub. Las directrices que facilitan la aprobación pasan por respetar un formato estandarizado (MediaWiki), una estructura de contenido con secciones ya preestablecidas (Preámbulo, Abstract, Copyright, Especificación, etc.) y cuyo enfoque abarque y desee implantar una finalidad acotada pero precisa. Estas pautas determinan que un BIP tengas más opciones de iterar dentro de su ciclo de vida entre los estados de “borrador”, “propuesta” y “final/activo”, como culminación de su implantación en la red. Llevado a la práctica, la implantación parte del hecho de que los nodos participantes en la red lleguen al consenso de aceptación de uso de la especificación de cada nuevo BIP, y esto afecta principalmente a los nodos mineros, puesto que el voto se determina por poder computacional en función del porcentaje de bloques que se escriban hasta una determina fecha (o número de bloque) con una sección de datos “pactada” que representa su muestra de apoyo o no. Aunque su peso no sea tan relevante, también ha de recogerse la palabra de los nodos validadores y ligeros (solo emisores de transacciones), requeridos de igual modo para el correcto funcionamiento habitual de la red y del computo de las nuevas decisiones a tomar en adelante. En última instancia, y en caso de resultar favorable el desenlace de votación, es la comunidad de desarrollo del núcleo de Bitcoin (conocido como Bitcoin Core) quien ha de aplicar finalmente dichos cambios en el software, derivados de modificaciones en el protocolo, reglas de validación de transacciones y bloques, consenso o interoperabilidad, para entonces ponerlo a disposición en una actualización masiva que origine su activación. Entonces, en el caso de que los desarrolladores o una parte de la comunidad apostara por implementar un cambio y otra parte apostara por no hacerlo, 7. ¿Qué podría ocurrir? ¿Se ha dado algún caso que afecte a Bitcoin? Respuesta: Bajo el amparo de un consenso mayoritario de todos los participantes en una cadena de bloques, la ausencia de un criterio único deriva normalmente en bifurcaciones que, en el ámbito de la informática, y partiendo del hecho de ser Bitcoin un software de código abierto, constituyen la reimplementación de versiones del proyecto con modificaciones que difieren en un instante del tiempo de su planteamiento en la versión inicial. En función del grado de afección de los cambios y sus implicaciones asociadas, existen dos tipos de bifurcaciones. Las suaves (o “soft forks”), las cuales se consideran una mejora o actualización del software, no presentando incompatibilidades con aquellos nodos que decidan preservar versiones anteriores. ¿Cómo es posible esto? Es consecuencia de que incluyen cambios puntuales no estructurales (como cambios en el formato de transacciones) y/o nuevas funciones auxiliares que, en ningún caso, resultan obligatorias y determinantes de ver en todos los nodos de la red, preservando la unicidad de la cadena de bloques con la adopción de nuevas reglas de consenso y el respeto a las ya heredadas. Dicha convivencia resulta del hecho de la aceptación tanto de los nuevos como de los viejos bloques por parte de los nodos desactualizados, pero solo de los más recientes para los ya aprovisionados con la nueva versión. Por otra parte, en caso de cambios estructurales (bloques) o de funcionamiento (cálculo de Hash, reglas de dificultad, transacciones válidas, entre otros) en los que no se recibe un apoyo unánime de la comunidad de participantes, se produce una bifurcación dura (o “hard fork”) ante la incompatibilidad con versiones anteriores (los nodos actualizados consideran inválidos los bloques generados desde nodos con versiones anteriores y viceversa), obligando a los participantes a una actualización requerida si quieren formar parte de la nueva cadena de bloques que solo comparte el histórico hasta la fecha. En ocasiones, esta circunstancia deriva en nuevos proyectos que adoptan una propia filosofía, algoritmo de consenso, criptodivisa, comunidad, mineros y usuarios (las llamadas “bifurcaciones contenciosas”, a diferencia de las planificadas), como en el célebre caso de bifurcación en agosto de 2017 de Bitcoin Cash. Si se ha dado algún caso de cambio de las reglas del juego, que afecte a Bitcoin: 8. ¿Qué cambios fueron objeto de la polémica? Respuesta: La comunidad de Bitcoin debatió durante un largo periodo de tiempo acerca de los problemas latentes de escalabilidad acuciante, debido en buena parte a la popularidad de la criptomoneda y a un creciente uso de ésta (volúmenes de transacciones diarias cercano a las 300.000), provocando en consecuencia la pérdida de las características que la hicieron popular. Congestión en la red, retrasos en las confirmaciones de las transacciones, o el encarecimiento en las comisiones de envío resultaron suficientes motivos para apuntar a la limitación del tamaño de los bloques de transacciones (1MB) el principal responsable. Es por ello por lo que se presentaron diversas propuestas que aminoraban tales problemas, evitando a la vez la división de la red y criptomoneda en dos, siendo la propuesta de Segregated Witness la que recibió una mayor aceptación. ¿Cómo? A través de un soft fork que permitía aparte de las mejores antes citadas, un mayor aprovechamiento del espacio de bloque al redimensionar su estructura sin firmas ni claves por alojarse en la nueva zona reservada, alcanzando un tamaño máximo de 2 MB. El consenso al respecto era un hecho palpable ante el nuevo protocolo propuesto por parte de desarrollos de Bitcoin Core, materializando a ojos del mundo su aprobación durante la conferencia anual Consensus 2017, y comprometiéndose, por un lado, a su implantación en el 80% del poder computacional global de la red, y a un hard fork planificado que permitiese aumentar el tamaño de bloque hasta los 2 MB, añadiéndose a la propuesta de mejora incluida ya en Segwit, de nombre SegWit2x (en BIP91). Todo apuntaba a un desenlace optimista al respecto, hasta que en los días previos al 1 de agosto, la casa de cambio ViaBTC, poseedora de un 6% de la capacidad computacional total de la red, dio un paso al frente descartando dicha propuesta de mejora, para pasar a crear una nueva criptomoneda, como bifurcación de la red blockchain original Bitcoin, de nombre Bitcoin Cash (BCH). ¿Cuáles son sus rasgos identificativos en palabras de sus precursores? Ofrecer los mismos pilares que Bitcoin con aspectos reforzados, y aumentando el tamaño de bloque hasta los 8 MB para así poder contener mayor número de transacciones en cada uno de ellos para así combatir de frente los problemas de escalabilidad que originaron el desencuentro. 9. Y, más allá de Bitcoin, ¿existe algún otro ejemplo de fork relevante en otras criptodivisas como, por ejemplo, Ethereum? ¿Qué motivos esgrimieron ambas partes? Respuesta: Sí, en Ethereum tuvo también lugar un hard fork o bifurcación dura, pero en este caso el origen partió de un ataque al proyecto thedao.org, siglas de Organización Autónoma Descentralizada, cuyo objetivo era el de crear un fondo descentralizado de inversión para financiar proyectos de startups en el ecosistema de Ethereum, y que logró atraer más de 140 millones de dólares de inversión en Ether. El mecanismo era sencillo: los inversores decidían por votación que proyecto se apoyaba, y los que no aceptaban la decisión, podían aceptar la decisión conjunta, o independizarse del fondo y crear un nuevo DAO para tomar sus decisiones acorde a sus preferencias. Todo iba en la línea correcta hasta que estudiosos del lenguaje de programación Solidity advirtieron de agujeros de seguridad y malas prácticas de codificación en los Smart Contracts involucrados en el proyecto, y con la consiguiente sustracción a los días de 3.5 millones de Ether de TheDAO hacia un DAO hijo. ¿Qué sucedió? La comunidad decidió, tras un largo tira y afloja, llevar a cabo un hard fork y devolver el dinero desfalcado, decisión que generó muchas discrepancias y la dividió enormemente, puesto que implicó deshacer todas las transacciones posteriores a las que contenían las del robo y transferencia a la dirección del DAO hijo. ¿Qué implicaciones supuso esta decisión? Básicamente, incumplir uno de los pilares fundamentales de toda cadena de bloques: el principio de inmutabilidad de la información (eso en Ethereum “original”), mientras que en la nueva criptomoneda resultante (Ethereum Classic) no se revirtió el hurto ni compensó a los afectados, respetando el principio de que “el código es la ley”, y si figuraba en un Smart Contract, aunque fuese una vulnerabilidad o agujero de seguridad, ha de respetarse y cumplirse una vez publicado. Hablando de Ethereum, se está hablando mucho últimamente de los cambios que se están gestando dentro de la comunidad para implementar un mecanismo de consenso diferente y con una huella ambiental menor como Proof-of-Stake. 10. ¿Qué aportaría este mecanismo frente a Proof of Work? Respuesta: A diferencia de Proof of Work, en donde el algoritmo de consenso recompensa a aquel nodo minero que obtiene el hash válido del reto criptográfico con el que valida las transacciones contenidas en el nuevo bloque de la cadena, en la prueba de participación, los parámetros de poder se rigen de manera determinista sobre varios factores clave en la elección del nodo creador del nuevo bloqueo. ¿Cuáles? Dejando a un lado el poder computacional usado por PoW, en Proof of Stake la probabilidad de crear un nuevo bloque aumenta cuanto mayor sea la riqueza del nodo participante (número de tokens) y la antigüedad de la posesión de estas, así como mecanismos de reputación en la comunidad amparados por el seguimiento de nuestra participación en la cadena. Este cambio de paradigma en el algoritmo de consenso en Ethereum propondrá, previo hard fork, hacer frente a una de las grandes preocupaciones de los desarrolladores de Blockchains que se apoyan en Proof of Work para su funcionamiento, puesto que el gasto en energía cada vez es mayor y las previsiones a futuro no son alentadores en cuanto a impacto ambiental y dependencia de pago al cambio con moneda fiat.

Vivimos en una sociedad digital e hiperconectada, volcada en las redes sociales, acostumbrada a convivir entre sensores inteligentes y una nueva realidad con múltiples facetas (virtual, ampliada, mixta). En este contexto, apremia la inmediatez en el uso de los servicios, la improvisación y espontaneidad en la generación y consulta masiva informacional, la ausencia de miramientos en la exposición de contenido sensible en la red salvaguardados por la nueva ley de protección de datos. Por ello, cobran especial importancia roles como el data engineer o ingeniero de datos, cuyo papel no siempre está muy claramente definido en las organizaciones. El objetivo de este artículo es arrojar luz sobre esta cuestión. La realidad implícita en esta vorágine de sobreconsumo es la del incremento exponencial de nuevas plataformas de datos de cada vez mayor diversidad de naturaleza, fiel reflejo de la interacción de humanos, servicios y máquinas. En el ánimo de dar respuesta a las nuevas necesidades que el mercado demanda a cada instante, y que derivan en conocer al mayor nivel de detalle posible al usuario final y su entorno para así proveerle de la mejor experiencia de uso, es preciso preguntarse entonces qué rol profesional es capaz de cumplir con ese cometido. Esa figura es la del ingeniero de datos, pieza central de todo equipo multidisciplinar de soluciones de Big Data e Inteligencia Artificial dedicado a las labores de recolección, modelización y normalización de la información clave para describir el presente y predecir el futuro. Perfil todoterreno: experto técnico, especialista en negocio e impacto social Cada revolución tecnológica trae consigo nuevas destrezas a adquirir, renovados mecanismos de operabilidad a integrar sobre los ya existentes, profesiones emergentes que reúnen un abanico de responsabilidades de reciente incorporación. Desde aquel Big Bang que convergió en el universo Big Data, que unos remontan a cuando Google presentó su sistema de ficheros distribuido Google File System o GFS (2003), y otros a la publicación en 2004 del paper que enunciaba el paradigma de procesamiento en paralelo MapReduce (lo que posteriormente constituiría la primera plataforma open-source Hadoop), el collage y superposición de roles ha sido de aúpa. El ingeniero de datos, proveniente en sus inicios de funciones recurrentes de desarrollo backend y/o administración de bases de datos, se ha llevado la palma todo este tiempo, representando a un profesional con infinitas acepciones en la red, propiciando en muchas organizaciones un halo de misticismo ante el desconocimiento de no saber qué papel real encomendarle. Funciones del data engineer y conocimientos necesarios Con amplios conocimientos en ingeniería de software, estructuras de datos de la información y paradigmas de computación distribuida, entre otras habilidades técnicas, un data engineer es el encargado de la implementación de los procesos de captura masiva de información provenientes de múltiples orígenes, así como de las etapas de normalización, anonimización y limpieza de la misma. Automatización, operativización, minería de datos, exportación de insights e interfaces de aplicaciones (API) son términos de funciones que también nos acompañan en nuestro día a día. El objetivo primordial de este perfil es el de hacer uso de la infraestructura tecnológica desarrollada por la figura del arquitecto Big Data para aprovisionar las siguientes formas de explotación de los datos una vez procesados: Modelos analíticos para la identificación de patrones conductuales y la predicción de tendencias resultantes del histórico recogido desde el origen de los tiempos por parte de los científicos de datos. La puesta en valor de las conclusiones extraídas o insights, a través de múltiples vías de representación (siendo las más frecuentes el dashboarding y los chatbots) que permitan facilitar la toma de decisiones en base a escuchar lo que el dato siempre ha tratado de decirnos y hasta hace no mucho ni habíamos reparado. Por si aún no era suficiente, no solamente de tecnicismos vive un Data Engineer. Es preciso conocer el estado del arte de la información que manejan con propósito multisectorial, al ritmo de la célebre expresión “saber del negocio”, cuestión vital para modelar contenido desestructurado de distinta procedencia bajo unos criterios de estandarización coherentes y versátiles en el tiempo. Labores recurrentes de ingeniería en soluciones de Big Data e Inteligencia Artificial A continuación, se indican 4 pilares considero claves que agrupan distintas funciones a las que todo data engineer hace frente de manera cotidiana en todo ciclo de vida del dato. Para cada supuesto se aporta un listado de tecnologías, servicios y/o lenguajes asociados que sirven para ejemplificar la etapa que comprenden, entre un portfolio de alternativas innumerable, citando únicamente las implementaciones base en su versión Open Source, omitiendo para sintetizar su comprensión los servicios análogos de los principales proveedores de Cloud Computing. Por descontado, otras tareas adicionales pudieran verse añadidas a las siguientes expuestas, no viéndose excluidas por ello (como la implementación de API’s de consulta de las métricas obtenidas, como interfaz puente a la renderización en una capa de presentación al uso). Figura 1: Funciones del ciclo de vida del dato. Captura masiva de la información: extracción desde fuentes externas e internas al proyecto según casuística, persistencia de los datos en bruto en sistemas de almacenamiento distribuido on-premise (Hadoop Distributed File System o HDFS) o en la nube (véase S3 en Amazon Web Services o Azure Storage en la plataforma de Microsoft). Las tecnologías requeridas para dicha labor son de tres tipos: a partir de peticiones de servicios a métodos de consulta tipo API REST, mediante técnicas de extracción a través de arañas de rastreo de contenido web (scraping), o con servicios dedicados Big Data según el tipo de dato a capturar (eventos, logs, bases de datos relacionales) y su frecuencia de generación (Batch vs Near-Real Time vs Real Time). Transformación, limpieza, anonimización y consolidación: Procesos de refinamiento del contenido ingestado hacia la calidad del dato, antesala de las etapas analíticas y de visualización de las conclusiones extraídas. La utilización de frameworks de computación distribuida como Apache Spark, Apache Flink o Apache Storm resultan vitales para el aprovechamiento de los recursos de la infraestructura Big Data y su capacidad de reparto del trabajo entre múltiples nodos paralelamente. A destacar también servicios para la consulta, agregación y análisis de datos y metainformación como Apache Hive o Cloudera Impala, administrados bajo la interfaz de usuario web Apache Hue. Todo ello sustentado por lenguajes de programación (Java, Scala) y consulta (SQL) robustos, escalables, extensibles, orientados a su uso en entornos productivos, y bajo el amparo de una gran comunidad de desarrolladores comprometidos con su evolución y mantenimiento. Automatización de procesos de ingesta y normalización: Orquestación de trabajos de manera programática, acotando el esfuerzo computacional de los procesos según intervalos de vigencia del dato, facilitando en consecuencia la ejecución secuencial de tareas que aprovisionen con información un Data Lake, como antesala a los procesos de gobernanza de los mismos. Apache Oozie y Apache Airflow son dos grandes servicios que cumplen la misión de programación de workflows. Integración y despliegue continuo al servicio de la eficiencia operativa: Papel determinante en la evolución del software que se despliega en un entorno productivo partiendo de un estado inicial, cumpliendo debidamente a cada iteración con las etapas de revisión estática, pruebas funcionales (unitarias, aceptación, integración y regresión) y no funcionales (carga, estrés, escalabilidad, portabilidad) que acreditan su validez y minimizan el riesgo adherido. Todos los componentes indicados en esta sección forman parte de conglomerado de piezas que todo ciclo de operativización ha de contar, en cuyo diseño e implementación el data engineer ha de respaldar a la figura del DevOps en su consecución. Git como repositorio de control de versiones del software; Jenkins como servidor de integración continua, SonarQube como servidor de revisión de código estático; Junit y JMeter como librerías de soporte de pruebas unitarias y rendimiento (QA); Docker como proyecto de despliegue de contenedores efímeros (“sandboxes”) para la abstracción de dichas validaciones; Openshift como plataforma de despliegue de los mismos (Platform as a Service o PaaS); Nexus como servidor gestor de repositorios y artefactos finales de los aplicativos productivos. Queriendo fomentar que los equipos de transformación digital dedicados al tratamiento del dato cuenten con los integrantes precisos para no verse frenados en la consecución de sus propósitos de proyecto, si veis a alguien por la oficina presentar dudas al respecto, ¡hacedle saber quién pone orden en el caos de los datos!

Mucho se discute sobre el agujero existente entre dos campos muy presentes en el día a día de cualquier persona: la medicina y las tecnologías de la información. Ya surgen proyectos muy importantes resultado de la colaboración entre estos dos sectores, como la impresión de órganos en 3D o el desarrollo de algoritmos capaces de predecir enfermedades. Sin quitar la relevancia de esas iniciativas, la realidad es que los beneficios de tecnologías punteras como el Big Data y la Inteligencia Artificial todavía no han llegado a todos los estratos de la sociedad, influyendo en la mala percepción que la ciudadanía tiene acerca de todo trámite relativo a la gestión hospitalaria. Un claro ejemplo de ello transcurre en las consultas de los ambulatorios distribuidos por todo el territorio nacional, donde el desconocimiento completo del historial del paciente es patente en caso de no acudir a su centro asignado. También se nota en la concesión de citas de atención médica tardías y en la falta de agilidad en urgencias e intervenciones quirúrgicas por ausencia de procedimientos digitales que aceleren dichas demandas. Ni por asomo hablar de diagnósticos médicos basados en el análisis pormenorizado del histórico de datos, para así establecer tendencias de afecciones asociadas a perfiles comunes claramente identificados, todavía restringidos a dolencias más graves en centros muy especializados. Pero nuevos tiempos transcurren, y apuntan a esperanzadores. Una serie de indicios empuja a creer que finalmente se está dando el acercamiento entre el sector salud y la implantación de soluciones Data Driven para la aplicación de servicios cognitivos. Surgen nuevas generaciones de profesionales médicos familiarizados con herramientas digitales; hay más recursos y técnicas capaces de procesar ingentes cantidades de información; tienen lugar mayor número de eventos que logran asentar las bases del entendimiento y la promoción de dinámicas de equipo multidisciplinares; se observan avances notorios en líneas de investigación que refuerzan el discurso; y, finalmente, hay mayor concienciación por parte de la comunidad científica de que ya existen los medios para abordar las deficiencias descritas y obrar en la excelencia sanitaria. Ahora bien, es importante poner sobre la mesa ciertos retos a superar en el camino a la verdadera transformación digital en el ámbito médico. Por una parte, la fiabilidad y granularidad de los datos, requisitos necesarios para dotar de precisión y verdadero rigor su aplicabilidad, lo cual implica de una mejora en los procesos de recogida de la información en tiempo de consulta médica. Por otro lado, propiciar la implantación de una infraestructura global de almacenamiento de todos los historiales informatizado, recogidos estos de manera confiable, de cara a su tratamiento desde los principios de la ética y privacidad, con el único fin de devolver el valor del dato a la sociedad en aras de garantizar una óptima salud y bienestar. Esta nueva pieza constituirá una herramienta aliada de inmensa valía en tiempo de toma de decisiones por parte de los facultativos sanitarios, verdaderos protagonistas, aportandoles una información adicional jamás antes imaginada. La población quiere disponer de una sanidad a la altura de los tiempos que corren y el resto de prestaciones sociales que consume recurrentemente pero, ¿realmente estaría dispuesta a poner de su parte? Para ganar su apoyo, habría que poner el paciente en el centro de todos los esfuerzos. Implantar políticas públicas para concienciar que eso supondría un retorno diferencial en la calidad de la atención, diagnóstico y tratamiento. Asimismo, propiciar la adquisición del conocimiento y beneficios de su uso por parte de los médicos, sabiendo trasladarlo a los pacientes para generar la confiabilidad de que su información personal será tratada con el mejor de los fines, revirtiendo en una mejor experiencia. ¿Estamos preparados para afrontar los retos y darle el empujón necesario para que IA y Salud caminen de la mano? De los desafíos surgen nuevas oportunidades, el mercado ya demanda perfiles especializados, y una nueva y prometedora línea de trabajo emergerá para los apasionados de los datos y la analítica avanzada, ¡estad preparados para ser parte del cambio! Para mantenerte al día con LUCA, visita nuestra .