El futuro está en la nube, la ciencia de datos y la resiliencia

Computación en nube: SAP ERP se une a Google BigQuery con el aprendizaje automático

El final de SAP R/3 y ER/ECC 6.0 está claramente en el horizonte. Sin embargo, fijar una fecha exacta parece todo un reto para SAP. Lo que está claro, sin embargo, es que el soporte para los anteriores sistemas centrales de SAP se interrumpirá dentro de unos años. La falta de una fecha concreta de finalización del R/3 lleva a las empresas a aparcar el tema una y otra vez. Tiene sentido abordar el cambio a tiempo, porque es la única forma de aprovechar las oportunidades de una reorientación preparada para el futuro.

Si bien parece que en el futuro sólo habrá una plataforma objetivo para el funcionamiento de los sistemas, a saber, la nube, los modelos on-prem siguen dominando entre las empresas usuarias, aunque con una tendencia continuamente decreciente. El alojamiento en un centro de datos externo está igual de extendido. Pero, ¿cuáles son las ventajas de cambiar el modelo de implantación a la nube? ¿Y qué nube tiene sentido para el caso de uso individual?

Nube pública SAP

La nube pública de SAP se adapta a escenarios definidos y desempeña un papel secundario para la mayoría de las empresas. La propia SAP está impulsando el cambio a productos y servicios basados en la nube con Rise with SAP, el último intento de la empresa de Walldorf de llevar a los clientes a la nube. Además de la presión de marketing generada por SAP, los hiperescaladores también están interesados, por supuesto, en asumir las cargas de trabajo de SAP. En la actualidad, siete hiperescaladores ofrecen plataformas IaaS certificadas para OLAP y OLTP. Para el mercado de habla alemana, Amazon Web Services (AWS), Google Cloud Platform (GCP) y Microsoft Azure son los proveedores relevantes.

A menudo surgen sorpresas en el proceso de toma de decisiones a la hora de elegir el modelo operativo. Las supuestas desventajas y ventajas se relativizan al examinar más de cerca el cambio a la nube. Especialmente cuando se trata del tema de la seguridad, en la práctica se encuentran más ventajas que objeciones. Los servicios de los tres hiperescaladores mencionados, por ejemplo, cumplen el Catálogo de Controles de Cumplimiento de la Computación en la Nube (C5) de la Oficina Federal Alemana de Seguridad de la Información (BSI). El C5 ayuda a las empresas a asegurar sus operaciones contra los ciberataques más comunes cuando utilizan servicios en la nube.

Un aspecto que apenas se examina al inicio de un proyecto -y tampoco en los procesos de solicitud de propuestas (RfP) de las empresas usuarias en su conjunto- es cómo afecta una operación SAP realineada a la fuerza innovadora y la competitividad de la empresa usuaria. Resulta sorprendente que muchas empresas alineen un sistema central de creación de valor corporativo con el catálogo de preguntas del pasado, especialmente en una época de dramáticos cambios. La agilidad, la proximidad al mercado y la sostenibilidad son los paradigmas del futuro.

Asimismo, los nuevos modelos de negocio, como los conceptos de venta directa al consumidor (DTC) y los servicios de suscripción, son cada vez más populares. Aunque la cuota del comercio electrónico en las ventas totales sigue siendo pequeña en la actualidad, su crecimiento se está acelerando de forma significativa. La inteligencia artificial (IA) y el aprendizaje automático, el Internet de las cosas (IoT) y el blockchain prometen cambiar fundamentalmente el éxito empresarial. Los líderes del sector ya están utilizando estas nuevas tecnologías para responder a las tendencias de los consumidores y hacer que sus operaciones sean más eficientes.

Plataforma tecnológica empresarial

El sistema de planificación de recursos empresariales sigue siendo la unidad central de gestión de datos (fuente de autoridad). Además, los hiperescaladores proporcionan sistemas de bases de datos y tecnologías que permiten a las empresas reaccionar con mayor eficacia y rapidez a las exigencias del mercado (fuente de agilidad). El puente hacia la transición es la plataforma SAP Business Technology Platform (BTP).

En los tres hiperescaladores mencionados, BTP es una plataforma establecida para combinar aplicaciones empresariales inteligentes con funciones de gestión, análisis, integración y ampliación de bases de datos y datos. En el proceso, los clientes deben tener libertad para elegir la combinación adecuada de soluciones en la nube según sus necesidades individuales, y poder introducir nuevas funciones rápidamente si es necesario.

Fuente de agilidad

¿Qué hace la fuente de agilidad? Esto se ilustra con un ejemplo: Google BigQuery es un almacén de datos multi-nube sin servidor para las innovaciones impulsadas por datos en las empresas, que está conectado al ERP de SAP a través de la ruta descrita y es el "sistema de agilidad" aquí. Como sistema central, soporta la transformación de datos. Los datos propios de SAP se enriquecen con conjuntos de datos externos y datos de streaming en tiempo real. BigQuery se convierte así en la solución central para los analistas y científicos de datos, con la que pueden consultar todos los tipos de datos: estructurados, semiestructurados y no estructurados. 

Con Dataplex, un tejido de datos inteligente, las organizaciones pueden acceder a datos fiables y análisis útiles a escala. A continuación, pueden capturarlos, gestionarlos, supervisarlos y entregarlos a través de lagos de datos, almacenes de datos y marts de datos con controles unificados. El siguiente paso es utilizar el resultado para el aprendizaje automático (ML) integrado en BigQuery. BigQuery ML permite a las organizaciones crear y ejecutar modelos de aprendizaje automático en BigQuery mediante consultas SQL estándar. 

Ciencia de datos con BigQuery

El aprendizaje automático con grandes conjuntos de datos requiere amplios conocimientos de programación y de marcos de ML. Estos requisitos limitan el desarrollo de soluciones en la mayoría de las empresas a un grupo muy reducido de personas. Los analistas de datos no son uno de ellos porque, aunque suelen comprender los datos, sus conocimientos de programación y de aprendizaje automático son limitados. En cambio, con BigQuery ML no necesitan adquirir nuevos conocimientos y pueden utilizar las herramientas SQL existentes para utilizar el aprendizaje automático. Con BigQuery ML, los modelos ML pueden crearse y evaluarse en BigQuery. De este modo, el equipo de operaciones de SAP puede ocuparse de sus tareas y las unidades orientadas al cliente pueden acceder a datos en tiempo real muy condensados y visualizados para tomar las decisiones correctas.

Marco Google Cloud Cortex

Con el marco Google Cloud Cortex, Google ofrece una colección de herramientas y servicios de Google Cloud específicos para la seguridad y el cumplimiento de las aplicaciones e infraestructuras basadas en la nube. El marco forma parte de la plataforma de seguridad de Google Cloud y apoya a los equipos de seguridad y cumplimiento normativo con servicios como:

Centro de Mando de Seguridad, Un panel de control centralizado que proporciona información exhaustiva sobre la seguridad y el cumplimiento de Google Cloud, incluida la gestión de vulnerabilidades, el análisis de riesgos y las evaluaciones de cumplimiento.

Detección de amenazas por eventos, un servicio que supervisa automáticamente los registros de Google Cloud e identifica anomalías, amenazas y posibles incidentes de seguridad.

Autorización binaria, un servicio que controla la ejecución de aplicaciones en la nube y garantiza que sólo se ejecute software aprobado y de confianza.

Seguridad Forseti, una herramienta de código abierto que se ejecuta en Google Cloud y supervisa y automatiza la seguridad y el cumplimiento de las infraestructuras en la nube.

Como parte de la plataforma más amplia Google Cloud Platform, el marco Google Cloud Cortex ayuda a las organizaciones a mejorar la estrategia de seguridad en la nube de los clientes SAP existentes en Google Cloud y a cumplir los requisitos de conformidad.

Google Apigee

Google Apigee es una plataforma de gestión de API que ayuda a las organizaciones a diseñar, desplegar, supervisar y escalar API (interfaces de programación de aplicaciones). Las API son interfaces que permiten a las aplicaciones comunicarse entre sí e intercambiar datos. Entre las principales características de Apigee se incluyen:

Diseño de API: Apigee ayuda a las empresas a diseñar API con los estándares del sector y las mejores prácticas para garantizar una experiencia coherente a los desarrolladores y una integración más sencilla. Esto conduce a una comercialización más rápida de las nuevas aplicaciones y hace que las empresas sean más ágiles.

Gestión de API: Apigee permite a las empresas gestionar eficazmente sus API, incluyendo el acceso, la seguridad y la supervisión. Esto significa que las empresas pueden controlar el acceso a sus API, garantizando que funcionen de forma estable.

Análisis API: Apigee proporciona una supervisión y un análisis exhaustivos de las API para detectar patrones de comportamiento e identificar tendencias. Esto permite a las organizaciones responder rápidamente a los problemas y mejorar el rendimiento de sus API.

Escalabilidad: Apigee permite a las empresas escalar sus API a escala global y distribuir el tráfico entre diferentes servidores y ubicaciones. Esto permite a las empresas ampliar su base de clientes y mejorar la disponibilidad de sus aplicaciones.

Integración: Apigee ofrece una integración perfecta con otros servicios de Google Cloud como Kubernetes, Cloud Functions, Cloud Pub/Sub y Cloud Storage. Esto facilita a las empresas el desarrollo y despliegue de aplicaciones en Google Cloud Platform.

En general, Apigee añade así valor a las empresas ayudándolas a diseñar, gestionar, supervisar, escalar e integrar API de forma más eficaz, lo que puede conducir a una mayor agilidad, eficiencia y satisfacción del cliente.

Reduzca el tiempo de inactividad de las aplicaciones

¿Cuántas veces han cerrado los usuarios una aplicación al encontrarse con la "rueda giratoria de la muerte"? Hay que reconocerlo: ¡una forma bastante melodramática de decir que una aplicación tarda demasiado en cargarse! Pero en la economía digital actual, en la que las aplicaciones son la principal fuente de ingresos para muchas empresas, esta rueda de la muerte giratoria (o un rendimiento deficiente de la aplicación) puede suponer una pérdida de usuarios o de ingresos. Y casi todas las aplicaciones modernas dependen de las API como sistema nervioso entre los sistemas distribuidos, los servicios de terceros y las arquitecturas de microservicios. Además, al tiempo que se cumplen los requisitos de ciclos de lanzamiento rápidos y actualizaciones frecuentes de las API, también es esencial que los equipos de TI garanticen que se cumplen los requisitos de rendimiento y los SLO de las API y que se mitigan los problemas de forma proactiva. 

Sin embargo, cuando miles o incluso millones de usuarios realizan múltiples solicitudes a una API, basarse únicamente en herramientas de monitorización sintética no suele ser suficiente para realizar diagnósticos precisos o análisis forenses útiles. Esto se debe a que, en la mayoría de los casos, sólo se basan en muestras o en información limitada sobre la disponibilidad de la API.

Al mismo tiempo, supervisar cada uno de los aspectos sólo aumenta el esfuerzo y el tiempo medio de diagnóstico. La supervisión de las API es absolutamente crítica como "arte y ciencia" para los equipos de operaciones. Es la única forma que tienen de asegurarse de que todas las API se ejecutan y funcionan según lo previsto.

Cualquier técnico puede informar de los gastos generales que ocasionan las alertas mal priorizadas. Imagine una aplicación distribuida con 20 API: Incluso si existen monitores de alertas básicos para la latencia, los errores y el tráfico de estas API, acabará teniendo unas 60 definiciones de alertas que supervisar y gestionar: una gran sobrecarga. Por lo tanto, para equilibrar la evitación de puntos muertos de supervisión con la fatiga de alertas, los equipos de operaciones deben desarrollar una comprensión clara de todos los eventos y priorizar la configuración de alertas para los eventos que soportan tráfico crítico.

Cualquier condición de alerta creada debe incluir también información que requiera la participación activa de un usuario, en lugar de una mera respuesta robótica. La supervisión de API de Apigee permite crear condiciones de alerta basadas en métricas o registros, al tiempo que proporciona información procesable (por ejemplo, el estado
código, tasa, etc.) y los libros de jugadas están listos para el diagnóstico.

En los sistemas multicapa, el síntoma de un equipo ("¿Qué se ha roto?") es la causa de otro sistema descendente ("¿Por qué?"). Aunque algunos eventos no se presten a alertas procesables, un fallo debe desencadenar una transferencia de información a un sistema descendente para mitigar el impacto de la dependencia ascendente. En estos casos, el equipo de SAP Basis debe invertir en alertas automatizadas, agrupación de incidentes múltiples en canales de notificación y seguimiento de incidentes. Con Apigee, por ejemplo, TI puede integrar y agrupar alertas en canales como Slack, Pagerduty y Webhooks.

Los sistemas de producción modernos evolucionan constantemente, por lo que una alerta actualmente infrecuente puede convertirse en frecuente y automatizable. De forma análoga a la limpieza de la acumulación de tickets, las políticas de alerta deben revisarse periódicamente para garantizar que se identifican nuevas condiciones y que las alertas existentes se perfeccionan con nuevos umbrales, priorización y correlaciones. Controles como Advanced API Ops utilizan IA y ML para detectar el tráfico anómalo, distinguido de las fluctuaciones aleatorias, para establecer definiciones de alerta precisas.

Ingeniería de fiabilidad del emplazamiento

El libro de Google Site Reliability Engineering presenta argumentos para realizar diagnósticos eficaces mediante la construcción de cuadros de mando que respondan a preguntas básicas sobre cada servicio, incluyendo normalmente alguna forma de las cuatro señales de oro: latencia, tráfico, errores y saturación.

Incluso si sólo se recogen estas métricas de oro, la cantidad de información puede acumularse rápidamente. Como todos los sistemas de software, la supervisión se convierte entonces en un complejo agujero sin fin, complicado de personalizar y tedioso de mantener. Por ello, el libro recomienda recopilar y agregar métricas básicas, junto con alertas y cuadros de mando, para obtener los sistemas más eficaces y viables.

Siempre que el cliente del inventario SAP ejecute un programa completo de API con un equipo de base dedicado a supervisar las API, se pueden utilizar los paneles de supervisión listos para usar de la solución de gestión de API (como la supervisión de API de Apigee) para obtener información en tiempo real sobre las API. Como alternativa, también se pueden utilizar soluciones como la supervisión de la nube. Esto proporciona una visión general de toda la pila de aplicaciones: las métricas individuales, los eventos y los metadatos pueden visualizarse allí en un lenguaje de consulta enriquecido para un análisis rápido. La conclusión es que el uso de un único sistema para la pila de aplicaciones ofrece la posibilidad de supervisarla en su contexto y agiliza la navegación entre sistemas.

Incluso después de recopilar y agregar las métricas, es importante disponer de visualizaciones de datos significativas para comprender rápidamente el problema e identificar las correlaciones durante el diagnóstico. Sin embargo, quienes se centran en demasiados cuadros de mando para las visualizaciones de datos suelen tener una curva de aprendizaje pronunciada y aumentan el tiempo medio de cada diagnóstico. Por eso, Apigee API Monitoring, por ejemplo, ofrece por defecto unas cuantas visualizaciones predefinidas que son a la vez sencillas y eficaces.

Supervisión de extremo a extremo

El desarrollo moderno de aplicaciones ha acelerado la adopción de prácticas como la nube, los contenedores, las API, las arquitecturas de microservicios, DevOps y SRE. Si bien esto aumenta la velocidad de lanzamiento, también hace que una pila de aplicaciones sea más compleja y propensa a errores. Por ejemplo, una respuesta lenta a una solicitud de un cliente se extiende entonces por múltiples microservicios que organizan y gestionan diferentes equipos y pueden no identificar los problemas de rendimiento individuales.  

En estos casos, el rastreo distribuido es la mejor forma de que DevOps, Operaciones y SRE obtengan respuestas a preguntas como el estado del servicio, la causa raíz de los errores o los cuellos de botella de rendimiento en un sistema distribuido. Para ello, los clientes de SAP legacy deberían invertir en instrumentar sus aplicaciones distribuidas con estándares de código abierto como OpenCensus y Zipkin. El uso de herramientas como Cloud Trace, con un amplio soporte de plataformas, idiomas y entornos, ayuda a ingerir fácilmente datos de cualquier fuente.

Aunque el rastreo distribuido ayuda a reducir el problema a un servicio específico, en algunos casos se puede necesitar más contexto para identificar la causa raíz. Un ejemplo de ello: incluso si el origen de un problema de rendimiento se aísla en un proxy de API, sigue siendo un proceso tedioso identificar el cuello de botella correcto entre las múltiples políticas que se están ejecutando. Con herramientas como Apigee Debug, el equipo de SAP Basis puede hacer zoom en un flujo de proxy de API y examinar los detalles de cada paso para ver detalles internos como ejecuciones de políticas, problemas de rendimiento y enrutamiento, etc. 

Las capacidades de monitorización de API de Apigee (basadas en métricas expuestas por los internos del sistema) trabajan por tanto con la infraestructura de monitorización existente para reducir el tiempo medio de diagnóstico y hacer que la aplicación sea más resistente. El uso de la supervisión de API de Apigee ayuda a mantener una alta capacidad de recuperación con controles exhaustivos para reducir el tiempo medio de diagnóstico y resolución. Los equipos de operaciones en particular pueden beneficiarse.

La elección del modelo operativo:

Hay una serie de criterios de decisión para la elección del modelo operativo, entre ellos:

• Aspectos de seguridad
• requisitos reglamentarios
• Controlabilidad en funcionamiento
• Requisitos técnicos (latencia, ancho de banda, etc.)
• niveles de servicio específicos