En esta función de invitado especial, Mike Waas, CEO de Datometry, echa un vistazo a los errores que las empresas deben evitar cuando se alejan de Teradata. Datometry es una plataforma de virtualización de bases de datos SaaS que permite que las aplicaciones existentes se ejecuten de forma nativa en sistemas modernos de gestión de datos en la nube sin tener que volver a escribir. Mike ha ocupado puestos de ingeniería senior en Microsoft, Amazon, EMC y Pivotal y es el arquitecto del optimizador de consultas ORCA de Greenplum. Es autor de más de 40 publicaciones científicas revisadas por pares en diversas áreas de investigación de bases de datos y posee más de 50 patentes.
Existe un movimiento de rápido crecimiento de empresas que se alejan de Teradata. Están cansados de que les digan cómo la TI solo gestiona el negocio, pero no los ayuda a hacer crecer, y no pueden permitirse perder la oportunidad de generar nuevos ingresos aprovechando la amplia gama de instalaciones de procesamiento de datos en la nube pública.
Sin embargo, la reestructuración infunde miedo incluso en el líder de TI más empedernido. Para tener una perspectiva, considere esta cotización que una importante empresa recibió recientemente para una migración basada en reescritura: $ 26 millones para un proyecto que se suponía que tomaría 36 meses. Tenga en cuenta que prácticamente todas las migraciones se retrasan y superan el presupuesto. Ahora, está viendo fácilmente entre $ 40 millones y $ 50 millones, probablemente durante 5 años.
Los líderes de TI que asumen que pueden reescribir su salida de Teradata en un par de meses se enfrentarán a un rudo despertar, junto con un paso en falso que podría poner fin a su carrera. ¿Cuáles son algunos otros errores comunes que las empresas deben evitar al cambiar la plataforma desde Teradata?
Suponiendo que los 3 existentesrd las aplicaciones de fiesta simplemente se pueden reasignar
La mayoría de los proveedores de BI / ETL admiten almacenes de datos en la nube (CDW) en las últimas versiones de su software (el énfasis está en la última versión). Las empresas que tienen un ecosistema de aplicaciones bien establecido probablemente estén ejecutando versiones anteriores de estos sistemas, por lo que no pueden simplemente reorientarlos.
Para que funcionen con nuevos almacenes de datos de destino, las empresas primero deben actualizar. Este esfuerzo depende del tamaño y la estructura del sistema existente, pero la actualización es una operación que generalmente abarca varios trimestres y cuesta rápidamente millones de dólares.
Sin embargo, incluso una actualización costosa no funciona todavía. Todas las herramientas comerciales de BI / ETL admiten la inyección de SQL personalizado en informes y canalizaciones de datos. Como resultado, hay Teradata SQL integrado prácticamente en todos los procesos diarios. En una reescritura convencional, toda esa lógica debe extraerse, reescribirse, reinsertarse, volver a probarse y volver a implementarse.
Si bien es tentador creer que el ecosistema es portátil, en la práctica requiere un esfuerzo significativo que requiere mucha mano de obra.
Reescritura de ETL al pasar a la nube
Esto puede parecer absurdo considerando cuánto esfuerzo requiere la reimplementación de ETL. Sin embargo, a menudo se produce después de lo anterior. (consulte «Suponiendo que los 3rd las aplicaciones del partido simplemente se pueden reasignar ”). Si la reubicación de un sistema existente no es una opción debido a todas las reescrituras necesarias, uno podría simplemente morder la bala y reescribir las canalizaciones de datos por completo. O eso dice la lógica. Pero eso es tremendamente defectuoso.
Este es un gran ejemplo de por qué las migraciones basadas en reescritura fallan con regularidad. Las empresas que pasen de ajustar ETL a un rediseño completo deshacerán años de inversión y lo más probable es que terminen rediseñando y reinventando exactamente la misma lógica empresarial del sistema existente de todos modos.
Si bien reescribir y evolucionar ETL puede ser un proyecto de diseño importante para una empresa, hay un momento y un lugar para todo. Cuando una empresa necesita cambiar a la nube lo más rápido posible, no es el momento ni el lugar para tales diseños experimentales.
Esperando migrar de Teradata a un CDW moderno en un par de meses
La verdad es que las empresas pueden cambiar de Teradata a un CDW solo si lo hacen no volver a escribir. El aprovisionamiento, el redireccionamiento de aplicaciones y las pruebas por sí solos llevarán varios meses. Considere esto para comparar: la simple actualización de Teradata lleva meses para planificar y ejecutar. No requiere la reescritura de una sola aplicación, ajustar ningún SQL incorporado o reemplazar cargadores y utilidades.
Si la migración de Teradata a un CDW moderno requiere una reescritura, todas las apuestas están canceladas. Si las empresas deben reescribir, “un par de meses” pueden convertirse en años. Las pruebas por sí solas son un gran problema: las empresas deben reescribir todas las pruebas, revalidarlas y volver a implementarlas. La validación es compleja debido a que ahora operan dos entornos de prueba claramente diferentes. Luego vienen las pruebas de aceptación del usuario que son aún más onerosas debido a las diferencias de los sistemas.
En resumen, un par de meses es el mínimo indispensable para cualquier operación. Si las empresas deben reescribir las aplicaciones, rápidamente están observando un gran múltiplo de esa línea de base.
Suponiendo que las reescrituras conducen a un mejor rendimiento
Todos los CDW modernos se enorgullecen de ser almacenes de datos de uso general. Los potentes optimizadores de consultas integrados en estos sistemas garantizan la mejor ejecución posible de cualquier consulta, sin importar la consulta. Son capaces de procesar casi cualquier cosa que se les arroje.
Sin embargo, todavía existe la idea errónea de que las consultas de Teradata deben reescribirse de ciertas formas no especificadas. Supuestamente eso los hace funcionar mejor en CDW. Esto era cierto hace unos años cuando la nube aún estaba en su infancia, pero afortunadamente, esos días ya pasaron.
Las empresas no solo no necesitan estas personalizaciones, sino que también deberían mantenerse alejadas de ellas. Cualquier optimización de este tipo, no importa cuán bien intencionada sea, agrega complejidad y rápidamente se convierte en deuda técnica.
Es de interés principal de los proveedores de la nube eliminar la necesidad de personalización o formulación especial de consultas. Lo que hoy podría parecer una optimización inteligente no será más que un obstáculo mañana. En resumen, las «optimizaciones» requieren un esfuerzo considerable, pero casi siempre son una pérdida de tiempo.
Resolviendo solo el 80% del problema
La mayoría de las migraciones fallan porque los líderes de TI subestiman el esfuerzo. Las migraciones de bases de datos son un problema 80-20: el primer 80% del viaje requiere solo el 20% del esfuerzo. Es fácil hacer un buen progreso con una reescritura y casi toda la migración parece sorprendentemente fácil. Sin embargo, es el 20% restante el que saca a relucir todos los problemas, lleva años y años y acaba con los proyectos de migración.
Recientemente ha surgido una gran cantidad de herramientas de migración. Intentan convertir el código SQL de Teradata en SQL equivalente en el CDW. Ahora considere que la mayoría de estas conversiones de código automáticas reclaman una tasa de éxito del 50-70% y podemos ver rápidamente por qué no son una solución a este problema. Básicamente, resuelven la mayoría de los problemas fáciles que no eran el problema para empezar. En el mejor de los casos, los convertidores de código automáticos reducen el esfuerzo total en un 10-15%. Pero en el gran esquema de las cosas, eso es solo ruido.
Replataformar desde Teradata no es tan simple como se les hace creer a muchas empresas. Al contrario de lo que se les dice a los líderes de TI, la reestructuración requiere mucho más que una reescritura. Es importante que las empresas estén al tanto de estos conceptos erróneos comunes sobre el cambio de plataforma, para evitar cometer errores costosos y garantizar el éxito al migrar desde Teradata.
Suscríbase al boletín gratuito insideBIGDATA.
Únase a nosotros en Twitter: @ InsideBigData1 – https://twitter.com/InsideBigData1
