Lista de comprobación de la migración de archivos planos para desarrolladores de software Embarqué
Esta es la última entrega de la serie de entradas de blog que he escrito sobre el uso continuado de los archivos planos y por qué ya no son una opción viable para el futuro. La primera entrega se centró enlos archivos planos y en por qué los desarrolladores de aplicaciones de software integrado los adoptaron tan rápidamente. A continuación, en la segunda entrega, analicépor qué los desarrolladores de sistemas integrados se muestran reacios a utilizar bases de datos. La tercera entrega examinó por qué los desarrolladores siguen aferrándose a los sistemas de archivos planos.
Para esta última entrega, me di cuenta de que el argumento a favor de dejar de usar archivos planos probablemente deba plantearse de una manera más concreta. Por eso, junto con nuestro jefe de ingeniería, Desmond Tan, hemos elaborado una lista de razones que no se centran realmente en lo que estás utilizando actualmente ni en lo que deberías usar en teoría. En su lugar, se centra en cuáles serían los requisitos reales que justificarían el cambio desde los archivos planos. Esta lista se basa en cómo vemos que están evolucionando los casos de uso de la gestión de datos en el borde (Edge) integrada en los ámbitos de la telefonía móvil, el IoT y los equipos inteligentes complejos. También refleja lo que nos cuentan nuestros clientes en reuniones privadas sobre sus retos y sus requisitos empresariales y de producto.
A partir de esta información, estos son los ocho requisitos principales para la gestión moderna de datos en el borde:
1. La persistencia de datos locales y la evolución de su uso
Por lo general, los datos almacenados localmente en archivos planos se necesitaban como caché para realizar operaciones inmediatas con datos exclusivos del dispositivo en cuestión. Además, esos datos se evaluaban sin una referencia de referencia duradera, aunque continuamente actualizada. Sin embargo, la necesidad de combinar datos de múltiples dispositivos y fuentes de datos, así como el uso de datos históricos como referencia de patrones para todo, desde la simple relación señal-ruido hasta la inferencia de aprendizaje automático, implica que la necesidad de gestionar datos de operaciones complejas que alimentan el procesamiento y el análisis de datos locales supera la funcionalidad básica que ofrecen los sistemas de archivos.
2. Compatibilidad con múltiples entornos de sistemas operativos mediante un único formato de almacenamiento
En el ámbito del diseño de productos, las carteras de tecnología operativa y el soporte informático empresarial para las líneas de negocio, una amplia gama de sistemas, desde el perímetro hasta el interior de la empresa, deben compartir datos entre distintos sistemas operativos, desde Android e iOS hasta Windows y Linux, pasando por entornos virtualizados en la nube. Un formato de almacenamiento único reduciría considerablemente el tiempo y el coste de integración, además de mejorar la seguridad.
3. Apoyo en la gestión de datos para todos los perfiles implicados en el procesamiento y el análisis de datos
Los distintos perfiles tendrán que aprovechar el acceso a la plataforma de gestión de datos Edge, tanto de forma remota como local, en esta gama de plataformas subyacentes a través de diversos mecanismos de acceso, como la interfaz de línea de comandos (CLI), la programación y los lenguajes de scripting. Probablemente haya mucho que decir al respecto, por lo que merece la pena dedicarle una entrada de blog aparte.
4. Gestionar el big data en el perímetro
Prueba sorpresa: ¿cuáles son las cuatro «V» del Big Data? Sí, todos podéis nombrarlas aunque os despierten de un sueño profundo (para aquellos que os negáis a salir de ese maravilloso sueño: volumen, variedad, velocidad y valor). Al igual que Hadoop fue el primer paso a nivel empresarial para abordar la necesidad de un repositorio común para el Big Data, es necesario que haya un equivalente en el Edge. Y, al igual que ocurrió con el último requisito, se necesitaría un blog completo para analizar en profundidad la separación de los archivos planos. Por ahora, la conclusión clave y tangible es que es necesario poder admitir diversos tipos de datos, incluidos JSON, BLOB y datos estructurados tradicionales, en una única base de datos.
5. Compartir datos entre entornos de tecnología operativa (OT), la nube y entornos tradicionales de TI
El intercambio de datos debe poder gestionar escenarios de dispositivo a dispositivo y de dispositivo a pasarela en entornos de tecnología operativa (OT), así como de perímetro a nube y de nube a centro de datos para entornos remotos y de sucursales en la interfaz entre el perímetro y la nube. En otras palabras, se necesita una única plataforma para arquitecturas de cliente, punto a punto, cliente-servidor e Internet/Intranet.
6. Funcionar de forma autónoma durante los periodos de desconexión
Aunque el «Edge» pueda estar avanzando en general hacia un estado de hiperconectividad, esto no debe interpretarse erróneamente como que elimina o reduce la necesidad de poder procesar y analizar datos a nivel local. En muchas aplicaciones de tecnología operativa, un enfoque exclusivamente web es inviable. Por ejemplo, en el caso de los vehículos autónomos, el procesamiento y la toma de decisiones basadas en señales de vídeo y lidar para determinar hacia dónde dirigir el coche, a qué velocidad y con qué aceleración —o desaceleración— no pueden gestionarse desde la nube; la latencia por sí sola provocaría accidentes. En otros casos, la comodidad o la facilidad de uso pueden ser la razón por la que se opte por gestionar las operaciones de forma local. Imaginemos que tienes miles de álbumes en tu colección de iTunes y quieres buscar una canción por su letra durante tu vuelo de catorce horas de San Francisco a Nueva Delhi.
7. Gestionar la recopilación de datos multicanal a alta velocidad
Muchas de las señales fundamentales que se recopilan no cambiarán a medida que avancemos hacia un estado más conectado y automatizado; la presión, el volumen y la temperatura son tres ejemplos claros de ello. Sin embargo, como se ha mencionado anteriormente, las transmisiones de vídeo —desde el reconocimiento facial hasta la visión artificial— son cada vez más habituales y presentan resoluciones y frecuencias de fotogramas mucho más altas; pensemos, por ejemplo, en 4K UHD a 120 Hz. También se han mencionado anteriormente las señales LIDAR. En su día, fui ingeniero y construí sistemas de radar láser. Incluso en aquellos tiempos, podía recopilar fácilmente 400 MB de datos al día, tomando decisiones en milisegundos sobre cada conjunto de señales lidar recopiladas. Podría seguir con un ejemplo tras otro. La cuestión es que, con el procesamiento y análisis de datos en el borde moderno, llegar a los múltiples terabytes al día, donde los datos se procesan inmediatamente pero también se recuperan en parte o en su totalidad para un procesamiento adicional en un momento posterior, todos estos escenarios serán habituales.
8. Aprovechamiento de componentes complementarios ya disponibles del ecosistema
No hace falta decir que quienes utilizan archivos planos probablemente sean de los que prefieren hacer las cosas por su cuenta también en otros aspectos de sus soluciones. Abandonar los archivos planos optimizará la productividad, ya que les permitirá aprovechar opciones «plug-and-play» para herramientas y plataformas avanzadas de análisis, generación de informes y visualización.
En resumen, si te encuentras con uno o varios de estos requisitos, deberías plantearte seriamente migrar de los archivos planos a una arquitectura única, escalable y segura, capaz de gestionar el desarrollo y la implementación multiplataforma, y que te ofrezca la potencia necesaria para dar respuesta a una gran variedad de casos de uso avanzados de procesamiento y análisis de datos. Los archivos planos ya no son suficientes, amigo mío.
Manténgase conectado
Información detallada sobre los datos a su disposición.
(por ej., ventas@..., asistencia@...)
