Copia de articulo publicado en LinkedIn
Para las organizaciones de TI los desarrollos en el mundo DATA tienen un impacto abrumador. De repente se ven confrontados con solicitudes y requisitos para tecnologías que desconocen. En vez de estar ellos en la vanguardia tecnológica, ahora se ven confrontados con usuarios que aprendieron a programar! Esto require de una transición mental difícil. Pero es un cambio que tienen que enfrentar, por ejemplo antes de poder escribir términos y condiciones que están abiertos a soluciones DATA.
Veo tres temas principales. Primero entender que una solución DATA es algo diferente a una aplicación tradicional. Ya no es la interfaz lo que es lo más importante, pero la habilidad del proveedor de dar respuesta a los problemas puntuales de metodología, capacidad de cómputo y almacenaje. Segundo, no todas las base de datos son iguales. Hay un preconcepto de que MS SQL Server es lo más, más. Y es muy bueno para soluciones con tablas relacionales, pero no para todos los tipos de datos. Y como último hay que caer en cuenta que ni siquiera Microsoft usa .Net para todos los problemas Big Data. Una solución DATA es algo diferente a una aplicación
Me ha pasado regularmente que al exponer sobre nuestra aproximación a un problema DATA complejo damos al clavo para dar una solución. Pero cuando nos llegan los términos y condiciones, estas presentan muchas páginas sobre la interfaz y el requisito de aplicar en alguna tecnología web conocida. De alguna forma la complejidad del problema DATA se convirtió en algo menor a la interfaz.
Pero en el mundo DATA la interfaz para humanos es quizás lo menos interesante. Hay muchas soluciones y proveedores costo efectivos para crearlos. Lo que añade valor no es la interfaz, si no el proceso de la ingestión de datos y el procesamiento rápido y correcto para dar el producto de datos deseado, ya sea el resultado de un cálculo complejo, un diagnostico, o una predicción. No todas las bases de datos son iguales
Microsoft SQL Server apareció en 1989 y tiene 28 años de desarrollo. A muchos niveles es el mejor producto que Microsoft ha desarrollado en su historia. Es una de las mejores plataformas para trabajar con datos que caben en tablas relacionadas. Pero los problemas que ocurren con DATA hoy en día muchas veces no tienen esas características.
Imagina por ejemplo un proceso del cual sale un registro cada 10 segundos. Puede ser una fila con el estado de un GPS, o de una máquina en una fábrica, o la actividad de usuarios en la página web. este tipo de datos consisten de una sola tabla, sin relaciones con otras, y pueden contener cientos de miles, hasta millones de registros por día. Poner eso en MS SQL Server sin duda va a llevar a problemas. Por eso gigantes como Google y consorcios como la Fundación Apache han desarrollado bases de datos especializados en ese tipo de datos: las bases de datos columnares.
El mismo Microsoft no se queda atrás, y ofrece ahora en SQL Server 2016 mejor soporte para JSON, y la posibilidad de trabajar con una tabla completa desde memoria. Es más, con CosmosDB tratan de entrar al mercado con su propio solución NoSQL distribuida, para ofrecer la alternativa a SQL Server necesaria para Big Data. Ni siguiera Microsoft usa .Net para Big Data
Cuando entré a la sala de expositores de Strata y Hadoop hace un par de años, me llamó la atención un stand grande de Microsoft con un banner Microsoft ♡ Linux. La razón era que presentaban sus soluciones DATA, que incluyen (hasta el momento!) Hadoop sobre Linux. Es más, los lenguajes oficiales de microsoft para interactuar con datos en Azure y hasta dentro de SQL Server son Python y R. Además Scala y Java vienen de ñapa con el framework Hadoop.
Por eso cada vez que veo términos y condiciones para un proyecto DATA donde exigen PHP, o .Net, o de hecho, donde exigen un solo lenguaje, ya sabemos que el enfoque no está en una solución para sus problemas DATA. El enfoque está en otro sistema más, que quizás se va a ver muy bonito, y va a tener todos los botones. Pero desafortunadamente no les va a dar la solución que necesitan, ni los va preparar para el futuro que viene. Porque cualquier problema con volumen de datos, capacidad de cómputo y análisis que tienen ahora, va ser mucho, mucho más grande en solo un par de años. Entonces cómo hacemos?
Los siguientes serían mis sugerencias.
Si buscan una solución innovadora, no pre-determinen y cierren las lista de los lenguajes de cómputo que se puedan usar. Aún cuando el objetivo es mantener el sistema con un equipo interno después de recibirlo, vale la pena ver por donde dice el mercado que esta la mejor solución.
Si buscan que el proveedor les mantenga la solución en servidores externos, como un servicio SaaS a medida, no tiene sentido imponer que tipo de servidores o sistemas operativos se han de usar. Hay por lo menos tres grandes en en infraestructura como servicio (Amazon, Google e IBM) que excluyes de la oferta al obligar a usar alguna variante de Windows.
En ixpantia vemos un futuro políglota e interoperable. Ya tenemos proyectos donde somos responsable por uno de los servicios dentro de uno conjunto de servicios que diferentes equipos mantienen. La agilidad con la que podemos operar en este tipo de entornos es asombrosa.
Para una organización existente no es de una noche a la mañana que se va a llegar a allí. Pero es un riesgo seguir enfocando en las tecnologías de Microsoft de mas de 10 años atrás, y ni siquiera considerar la innovación que Microsoft mismo ha hecho desde entonces. Si quieres una tecnología a prueba del futuro, tienes que lograr que tu equipo dé cara al futuro y aprenda a darle la espalda a los pre-conceptos que tienen.