Consideraciones y patrones de alojamiento en la nube
Para proveedores de software independientes (ISV)
Los proveedores de software independientes (ISV) necesitan una plataforma y unos servicios de infraestructura seguros, ampliables y fiables para alojar sus aplicaciones. Incluso más que las organizaciones de tecnologías de la información (TI) con un sistema interno en la nube, los ISV deben lidiar con operaciones ininterrumpidas, despliegues en distintas ubicaciones geográficas, patrones dinámicos de tráfico de clientes que pueden requerir una capacidad de ampliación flexible y desafíos de seguridad relacionados con la exposición de su aplicación a la Internet pública.
Un ISV que se traslada o que trabaja en uno o más proveedores de servicios en la nube a hiperescala tiene que tener en cuenta una serie de opciones y patrones importantes. ¿Debería migrar a la nube su aplicación tal como está o, por el contrario, aprovechar la migración a la nube para modificar la arquitectura con un enfoque más nativo en la nube y poder comenzar a utilizar servicios PaaS gestionados por un proveedor? ¿Puede un despliegue en la nube transformar su estrategia de alta disponibilidad (HA) y recuperación ante desastres (DR) al introducir la capacidad de utilizar dominios de errores en el centro de datos, dominios de disponibilidad en la región o interconexiones entre regiones? ¿Qué herramientas le ofrece su proveedor de servicios en la nube para proteger sus datos, red interna, contenedores o hosts de recursos informáticos e interacciones con sus clientes? Por último, ¿está desplegando su aplicación como SaaS multiinquilino o en una configuración de inquilino único para cada uno de sus clientes?
Además de los cientos de aplicaciones que Oracle ha trasladado a OCI, nuestro equipo de ingeniería en la nube ha ayudado a docenas de ISV a planificar la migración a OCI y, posteriormente, a llevarla a cabo. En este micrositio se proporciona orientación y se presentan diferentes patrones de alojamiento para ISV.
Analizamos varios temas en el marco de diferentes enfoques para adoptar Oracle Cloud.
Este micrositio no se debe leer de forma lineal. En el siguiente diagrama se representa visualmente el flujo que puede seguir en este sitio según su propio perfil. Después de completar esta introducción, lea la sección Nuestro proceso y, a continuación, según su modelo de alojamiento actual, elija la sección Nacido en la nube o Nivel local/Colocación. A continuación, lea la sección SaaS multiinquilino o SaaS de inquilino único según el modelo de entrega de la aplicación. Por último, todos los lectores deben leer las secciones Cuestiones transversales y Resumen.
Nuestro proceso
- Nacido en la nube
- Nivel local/Colocación
- Modelo de entrega de aplicaciones multiinquilino
- Modelo de entrega de aplicaciones de inquilino único
Muchos ISV y proveedores de SaaS "nacen en la nube", lo que suena a "nativo en la nube", pero no siempre es así. Por lo general, nacido en la nube implica el deseo de desvincularse de los sistemas antiguos para dar paso a la creación según los principios de diseño moderno de aplicaciones. El diseño moderno de aplicaciones es la guía arquitectónica que plasma los principios descritos en la metodología de aplicación de doce factores. Esto tampoco es lo mismo que la arquitectura nativa en la nube, aunque está estrechamente relacionado con ella. Si desea más información sobre la computación nativa en la nube desde la perspectiva de Oracle, vale la pena consultar Cloud Native Patterns, un eBook en que se explica el diseño nativo en la nube.
Con independencia de que la aplicación SaaS se cree según los principios de diseño moderno de aplicaciones o de desarrollo nativo en la nube, hay algunos factores clave comunes:
- Deseo de seguir los principios de desarrollo moderno de aplicaciones.
- Deseo de centrarse en la aplicación y no en la infraestructura.
- Reducción del plazo de obtención de resultados de las funciones.
- Despliegues continuos, fiables y repetibles.
- Desvinculación de los sistemas que se consideran "antiguos" o de un solo proveedor.
- Deseo de crear, utilizar y respaldar una arquitectura moderna.
- Deseo de trabajar con la flexibilidad que brinda la informática en la nube.
Los ISV que han comenzado a trabajar en estos objetivos suelen tener una arquitectura de servicio más diferenciada. Los componentes de la aplicación en la carga de trabajo se pueden desplegar de forma independiente, a menudo como contenedores, y la arquitectura de la aplicación está diseñada para asegurar su continuidad en caso de fallo de los componentes. Las aplicaciones no solo deben garantizar la coherencia de los datos, sino también la disponibilidad de la aplicación.
Según la arquitectura de tiempo de ejecución elegida, el ISV probablemente tendrá la supervisión y las notificaciones integradas en el control de su infraestructura. OCI brinda servicios para soportar lo siguiente:
- CNCF Cloud Events con nuestro servicio de eventos en la nube
- CNCF OpenTracing como parte de nuestra plataforma de observación y gestión en la nube proporciona una interoperabilidad completa con las funciones en la nube (sin servidor) y el servicio de notificaciones, que simplifica la gestión del ciclo de vida del conjunto de servidores y facilita las tareas de gobernanza.
La comunicación entre componentes se suele implantar como un patrón asíncrono mediante el cual los componentes producen y responden a eventos en lugar de instrucciones directas. OCI ofrece el servicio de transmisión, un servicio sin servidor compatible con Kafka que a menudo se utiliza para gestionar esta comunicación. La ventaja de este enfoque es la protección de los componentes en caso de fallo, al reducir el radio de influencia mediante el uso de rutas y colas inteligentes.
La separación de las aplicaciones de la infraestructura es un paso más en la desvinculación. Con frecuencia, la flexibilidad se logra mediante mecanismos de escala automática proporcionados por el proveedor de servicios en la nube (CSP). La escala automática podría tener lugar en el nivel de contenedor con Oracle Kubernetes Engine (OKE), en el nivel de agrupación de instancias o en el nivel del grupo de servidores.
Con el tiempo, algunas aplicaciones SaaS comienzan a separarse de la arquitectura basada en estándares originalmente planificada, a medida que los equipos comienzan a utilizar los servicios PaaS nativos que proporciona un solo CSP. Algunos ejemplos son: usar un servicio de gestión de datos exclusivo de una sola nube, incorporar una llamada de API directa a una plataforma NoSQL concreta de un proveedor sin las capas adecuadas de abstracción en la implantación para una sustitución futura, o usar IDE que generan código específico del proveedor. Para mantener la portabilidad de la nube, los ISV deben atender al equilibro entre la comodidad de un servicio de plataforma y el riesgo de dependencia que puede surgir si el servicio no es independiente del proveedor. Muchos ISV han comenzado a modernizar sus aplicaciones, con el objetivo de tener una verdadera presencia multinube. Para ello, están volviendo a examinar los puntos de vinculación estrecha con tecnologías de un solo proveedor o de un solo uso.
Con el tiempo, podría producirse un cambio en la configuración de la infraestructura. La mayoría de los ISV adoptan un enfoque de infraestructura como código (IaC), y OCI soporta herramientas estándar del sector, pero va un paso más allá: OCI Resource Manager, un servicio gestionado de Terraform, se puede utilizar para controlar, realizar un seguimiento y reparar cambios en la infraestructura.
Una implantación de migración a la nube consiste en migrar las cargas de trabajo de producción que se ejecutan de forma local o en instalaciones de colocación a Oracle Cloud Infrastructure (OCI). En algunos casos, puede que desee aprovechar los servicios nativos en la nube que se ofrecen en OCI para optimizar sus aplicaciones. Esta acción de "trasladar y mejorar" es otro motivo importante para migrar a OCI. En las siguientes secciones se describirá el proceso de migración a la nube y se abordarán las consideraciones del enfoque "trasladar y mejorar" cuando sea necesario.
Este escenario está pensado para los ISV que buscan beneficiarse de la reducción de los gastos de capital y delegar algunas de las complejidades operativas relativas a la disponibilidad, la seguridad y el rendimiento a un proveedor de servicios en la nube (CSP) como Oracle. Normalmente, un ISV implantará una de las siguientes estrategias:
- Migración a la nube: migrar sus aplicaciones locales o en la misma ubicación a OCI.
- Trasladar y mejorar: migrar aplicaciones locales o en la misma ubicación a OCI y, después, optimizarlas con servicios nativos en la nube o con la migración de las bases de datos a ofertas basadas en la nube.
No hay nada que impida combinar estas estrategias, en las que algunas cargas de trabajo se mueven tal cual y otras se modifican para utilizar los servicios gestionados de OCI (PaaS).
Migración a la nube
La estrategia de migración a la nube consiste en trasladar su aplicación local a OCI de manera que el despliegue resultante sea similar al despliegue local. El primer paso de este proceso consiste en identificar las cargas de trabajo o aplicaciones que le permitirán utilizar las capacidades de OCI y lograr sus objetivos estratégicos. Tenemos muchas modalidades de alojamiento según los requisitos de residencia, latencia y conectividad de los datos. Tendrá acceso a la cartera completa de OCI, independientemente de cuál de los siguientes tipos de alojamiento elija.
| Tipo de alojamiento | Descripción |
|---|---|
| Nube pública | Amplia plataforma de servicios IaaS, PaaS y SaaS |
| Nube del gobierno (dominios restringidos) | Amplia plataforma de servicios IaaS, PaaS y SaaS desplegados en un dominio restringido para entidades del sector público. |
| Región dedicada en Cloud@Customer | Amplia plataforma de servicios IaaS, PaaS y SaaS implantados en su centro de datos. |
| Roving Edge Infrastructure | Amplia plataforma de servicios IaaS, PaaS y SaaS implantados en Oracle Roving Edge Devices (Oracle RED) reforzados, que brindan servicios de almacenamiento e informática en la nube en el borde de las redes y en ubicaciones desconectadas. |
| Oracle Cloud VMWare | Mueva las cargas de trabajo basadas en VMware a la nube o amplíe el VCenter local para incluir la nube sin tener que volver a diseñar las aplicaciones ni las operaciones. |
A medida que diseña su arquitectura en la nube, debe saber que Oracle soporta una variedad de opciones de conectividad de red que permitirán diseñar una solución de nube híbrida que combine recursos de OCI con componentes que se ejecuten en su centro de datos, o una solución multinube que interconecte los beneficios de OCI con los de otro proveedor de servicios en la nube. Ambos enfoques son muy comunes y pueden ayudar a facilitar la migración de las dependencias de la carga de trabajo para las aplicaciones existentes que se ejecutan de forma local o en otros entornos de proveedores de nube, con objeto de cumplir con los requisitos de residencia de datos, SLA de TI u otros requisitos.
OCI permite esta comunicación mediante la red pública de Internet, una VPN IPSec o conectividad dedicada (FastConnect). En la siguiente tabla se describen algunas de las características de cada uno de estos enfoques:
| Método | Latencia | Costo | Fiabilidad | Seguridad |
|---|---|---|---|---|
| Red pública de Internet | Variable | Variable | Variable | El menos seguro |
| VPN IPSec | Variable | Variable | Variable | El tráfico está cifrado, pero el túnel está en la red pública de Internet. |
| OCI FastConnect | Baja y predecible | Predecible | El más fiable | El más seguro; el tráfico atraviesa una conexión privada. |
Además, si bien la interconexión de nube a nube es posible entre OCI y cualquier otra nube que utilice las tecnologías anteriores, Oracle colabora con Microsoft Azure para proporcionar interconectividad productiva de baja latencia entre ambas nubes en muchas regiones del mundo.
Oracle cuenta con varios partners especializados en automatizar la migración a OCI desde cualquier número de orígenes, incluidas las nubes públicas de la competencia y los entornos locales virtualizados o no virtualizados. Puede encontrar la lista completa de proveedores de migración en nuestro Marketplace, con ejemplos destacados como Rackware y ZConverter.
A la hora de plantearse la migración a Oracle Database desde otras nubes o entornos locales, Oracle proporciona varias herramientas que facilitan la migración fuera de línea o sin tiempo de inactividad/en directo. Estas herramientas diversas incluyen la migración de datos sin tiempo de inactividad (ZDM), OCI Database Migration (DMS), GoldenGate, DataPump y RMAN, entre otras. La herramienta elegida depende de las características de la base de datos de origen y destino y de su entorno operativo. Puede encontrar más detalles si consulta la página de llegada de migración de bases de datos a OCI.
Traslado y mejora
La estrategia de migración a la nube de traslado y mejora consiste en optimizar o sustituir un servicio existente con una oferta en la nube. A medida que su equipo avanza en el proceso de identificación de los candidatos adecuados para migrar a la nube, debe tener en cuenta las oportunidades para optimizar o sustituir los servicios. Por ejemplo, puede mejorar las aplicaciones locales existentes al migrar la base de datos local que soporta una aplicación esencial al servicio gestionado Database Cloud Service, a la principal solución de autogestión Autonomous Database o a Exadata Cloud Service, que es la plataforma más rápida para ejecutar instancias de Oracle Database en la nube.
Además, la adopción de Oracle Cloud Infrastructure brinda acceso a una cartera completa de servicios que van desde:
- Ciencia de datos en la nube, que incluye tecnologías como Machine Learning, IA o Big Data Service.
- Software de tecnologías aplicadas, que incluye tecnologías como Digital Assistant y Blockchain.
- Desarrollo de aplicaciones, que incluye tecnologías como Container Engine for Kubernetes, APEX (con poco código), Visual Builder Studio (integración y despliegue continuos) y Mobile Hub.
- Servicios de seguridad, que incluyen tecnologías como WAF, Identity & Access Management, Cloud Guard y Access Security Broker.
- Análisis en la nube
Un modelo de entrega multiinquilino para proveedores de SaaS utiliza software que se ejecuta en una infraestructura compartida para respaldar a los distintos clientes finales (inquilinos) ISV.
Los datos del cliente se suelen almacenar en un conjunto de tablas compartidas, y todas las capas de la aplicación conocen el identificador único de un cliente. La aplicación en sí está diseñada para ser compatible con múltiples clientes. Por lo general, la propia aplicación también es responsable de la gestión de las suscripciones de los usuarios. Además, la infraestructura también se debe clasificar en grupos de servidores según el número de clientes, transacciones y normativas que se deben soportar.
Por qué elegir este modelo
Un modelo multiinquilino aporta ventajas al ISV (proveedor de software independiente). Son muchas los beneficios que se obtienen al utilizar las economías de escala proporcionadas en un modelo multiinquilino. Dado que la composición del grupo de servidores es bien conocida, se obtienen beneficios en la gestión y el control de la infraestructura. Lanzar una nueva área de servicio es tan simple como ejecutar el código de automatización de su infraestructura y, a continuación, desplegar la aplicación. El conjunto común de infraestructura también proporciona una vista unificada para el control.
El alojamiento de clientes en recursos informáticos, de base de datos y de almacenamiento comunes simplifica la estrategia de despliegue de aplicaciones. Los ISV que utilizan este modelo suelen tener una única base de código que facilita el despliegue de actualizaciones en toda la base de clientes. Muchos ISV que utilizan este modelo permiten a los clientes optar por nuevas funciones con la utilización de indicadores de funciones.
Por supuesto, todos estos beneficios también pueden presentar inconvenientes. Respaldar a los clientes que tienen requisitos específicos de residencia de datos implica una estrategia de despliegue regional, y puede haber escenarios en los que los clientes tengan requisitos comerciales de no estar alojados en los mismos servidores que un competidor. Según la arquitectura de la aplicación, los clientes pueden estar sujetos a un entorno con vecinos ruidosos. Cuando un grupo de servidores se satura, el ISV debe decidir si migrar el cliente a un grupo de servidores nuevo y menos utilizado, o bien ampliar la capacidad del grupo existente.
Una de las consecuencias no deseadas que implica el soporte adecuado del modelo SaaS multiinquilino es que la arquitectura de la aplicación debe estar bien pensada y mejor planificada que en una arquitectura de inquilino único. Los controles de acceso adecuados y los modelos de separación de datos se deben diseñar en el marco de la aplicación desde el principio, y los ISV se deben asegurar de tener las aptitudes internas de ingeniería necesarias para lograr todo esto.
Oracle puede ayudar a salvar la brecha al involucrar a nuestros arquitectos de soluciones en la nube para que lo ayuden con la modernización y optimización de su aplicación para que tenga éxito en la nube. Nuestros arquitectos trabajan con otros ISV de todo el espectro y pueden aportar experiencia al trabajar con problemas similares, así como mejores prácticas para su transformación en la nube.
Aislamiento del grupo de servidores
Una construcción clave del modelo multiinquilino es un entorno compartido para usuarios alojados. Como ISV, se debe asegurar de que la aplicación SaaS esté diseñada para separar y proteger adecuadamente los datos del cliente durante el tiempo de ejecución. También necesita poder gestionar, controlar y mantener adecuadamente lo que sucede en los distintos grupos de servidores que alojan su aplicación.
Es posible que tenga requisitos específicos para mantener a los clientes de regiones específicas lejos de los clientes de otras regiones (o subregiones). Este tipo de separación se puede lograr mediante el despliegue de sus cargas de trabajo en una combinación de regiones y compartimentos de OCI. Un ejemplo sería un proveedor de SaaS en EE. UU. que vende servicios para el mercado de la asistencia sanitaria y para el mercado de fabricación en general. El proveedor podría usar construcciones regionales y compartimentos para separar esas cargas de trabajo y proporcionar capacidades diferenciadas (como la conformidad con HIPPA/HITRUST para las cargas de trabajo relacionadas con la asistencia sanitaria).
Un paso natural para los ISV que comenzaron con un modelo multiinquilino es desarrollar la oferta para brindar un mejor aislamiento de los datos de los clientes. Este desarrollo se suele producir primero en el nivel de datos, y Oracle Database soporta un modelo multiinquilino, que permite incorporar bases de datos independientes y conectables en una única base de datos de contenedores.
Un modelo de entrega de inquilino único utiliza software que se ejecuta en una infraestructura dedicada para respaldar a los clientes finales de los ISV. A diferencia de un modelo multiinquilino, en el que varios clientes comparten los mismos ciclos de recursos informáticos y combinan datos en tablas de bases de datos comunes, un modelo de inquilino único se basa en máquinas virtuales diferentes, bases de datos distintas y una infraestructura de soporte diferenciada (equilibradores de carga, colas de mensajes, etc.) para cada cliente.
Por qué elegir este modelo
Un modelo de inquilino único aporta numerosas ventajas al ISV (proveedor de software independiente). Cada cliente/inquilino alojado en un recurso informático, de almacenamiento y de base de datos diferente deja clara la separación de intereses desde la perspectiva de la seguridad y el rendimiento. El cliente A no puede afectar al cliente B mediante una acción maliciosa o con el consumo involuntario de más recursos de los que le corresponden. Además, el radio de influencia para fallos catastróficos es menor; el fallo de un solo componente (es decir, una base de datos o una cola de mensajes) podría afectar a un solo cliente en lugar de a toda la aplicación SaaS. Cada inquilino tiene su propio entorno personalizado con funciones y parches únicos que lo convierten en un modelo de entrega muy centrado en el cliente.
Por supuesto, todos estos beneficios también pueden presentar inconvenientes. Todos los beneficios derivados, por ejemplo, de proporcionar entornos centrados en el cliente se pueden ver contrarrestadas por la carga adicional de la gestión de la configuración y el aumento del control y el mantenimiento. Muchas otras ventajas de este enfoque se obtienen en un modelo multiinquilino, aunque con un diseño e implantación más rigurosos de la aplicación SaaS del ISV.
En definitiva, la decisión se reduce a si un ISV desea invertir en un enfoque multiinquilino para su aplicación SaaS, lo que depende en gran medida de si cuenta con las aptitudes internas de ingeniería de software para hacerlo. De lo contrario, pueden optar por confiar en las capacidades de compartimentación inherentes proporcionadas por su plataforma de software o proveedor de servicios en la nube a hiperescala. Cada ISV debe tomar esta decisión en función de su situación particular.
Oracle puede ayudarlo a analizar estas opciones al involucrar a nuestros arquitectos de soluciones en la nube para que lo asesoren a la hora de modernizar y optimizar su aplicación para que tenga éxito en la nube. Nuestros arquitectos trabajan con otros ISV de todo el espectro y pueden aportar experiencia al trabajar con problemas similares, así como mejores prácticas para su transformación en la nube.
Aislamiento de inquilinos
Una construcción clave del modelo de inquilino único es un entorno aislado para cada inquilino. Como ISV, desea aprovisionar recursos informáticos y de red, almacenamiento, mensajería y base de datos exclusivos para cada uno de sus clientes. Quiere hacerlo de tal manera que estos recursos estén separados entre sí desde el punto de vista del tiempo de ejecución y la gestión.
OCI ofrece una función única denominada compartimentos, que proporcionan una sólida separación lógica entre cualquier recurso de OCI. Puede colocar un entorno de cliente completo, incluida la red, los recursos informáticos, etc. dentro de un compartimento y escribir políticas de OCI que controlen el acceso a estos recursos. Estas dos funciones principales de OCI le permiten separar eficazmente el cliente A del cliente B, así como evitar toda contaminación relacionada con los recursos, la gestión o la información. Los compartimentos son jerárquicos, por lo que tiene la capacidad de anidar compartimentos y de modelar configuraciones complejas de clientes utilizando este enfoque; por ejemplo, imagine un cliente real con varias divisiones que desea cierta separación entre las unidades de negocio y, al mismo tiempo, mantener algunos recursos corporativos comunes.
Aunque el modelo de compartimento ofrece las garantías más sólidas para la separación, existen algunos enfoques intermedios que se pueden utilizar en determinados niveles de la aplicación para mejorar la utilización de los recursos y, al mismo tiempo, confiar en un método no personalizado para separar a los inquilinos. Por ejemplo, en vez de crear un sistema de base de datos independiente para cada inquilino, puede aprovechar las capacidades multiinquilino de la base de datos Oracle para implantar una única base de datos de contenedores con varios esquemas conectables. Este enfoque reduce la sobrecarga que supone mantener varios clústeres de bases de datos y, al mismo tiempo, permite que la base de datos aplique la separación en lugar de aplicar una reescritura del esquema de la aplicación. La máquina virtual y la base de datos como servicio con hardware dedicado de Oracle soportan capacidades multiinquilino listas para usar, al igual que la base de datos dedicada autónoma, que se puede utilizar para las cargas de trabajo más exigentes.
Este enfoque intermedio no está soportado solo en el nivel de datos. Si su aplicación está distribuida en contenedores, puede utilizar Container Engine for Kubernetes (OKE) de Oracle para desplegar varios contenedores de clientes en una única infraestructura. Después, puede utilizar primitivos nativos de Kubernetes, como espacios de nombres, control de acceso basado en roles (RBAC), secretos y cuotas de recursos para mantener la separación de inquilinos. Al igual que ocurre con la base de datos, en lugar de volver a escribir su aplicación para que sea compatible con inquilinos, solo tiene que aprovechar las capacidades de los servicios en la nube subyacentes.
Descubra por qué los ISV eligen Oracle Cloud
Los ISV ofrecen un valor añadido a sus clientes con la amplia gama de servicios y soporte de OCI.
Cuestiones transversales
Quizás sea un ISV "nacido en la nube" que está creando una infraestructura SaaS de inquilino único y que aprovecha las capacidades innatas de su hiperescalador. Tal vez comenzó en el nivel local y está migrando su aplicación SaaS multiinquilino exclusivamente a la nube. O, quizás, su negocio sea una combinación de estos enfoques. Independientemente del camino que haya seguido, todos los ISV que trabajan en la nube deben abordar cuestiones transversales clave como la seguridad, la capacidad de observación, la continuidad del negocio y la automatización. En las siguientes secciones, revisamos cómo se posiciona Oracle para hacer frente a estos desafíos funcionales y diferenciarse de la competencia.
Seguridad, gobernanza y conformidad
El enfoque de Oracle es que la seguridad siempre debe estar "activada" por defecto y debe ser simple y prescriptiva. Estamos convencidos de que los clientes no deberían tener que elegir entre costo y seguridad, y nos esforzamos por brindar todos los servicios relacionados con la seguridad, ya sea sin costo o de bajo costo, con partners que ofrecen alternativas en nuestro Marketplace. Asimismo, creemos que los clientes sufren infracciones y filtraciones no porque no existan herramientas para prevenir vulnerabilidades, sino porque esas herramientas son demasiado costosas o complejas para la mayoría de las organizaciones.
Para Oracle, la seguridad es una responsabilidad compartida entre el proveedor de servicios en la nube y el ISV. Proporcionamos algunas capacidades básicas, como virtualización de red aislada y raíz de confianza de hardware, y las ampliamos con herramientas y servicios que el ISV puede usar para personalizar su estrategia de seguridad. Los ISV interesados en obtener una visión general de nuestras ofertas de seguridad pueden visitar la página de llegada de seguridad y la arquitectura de seguridad en la nube.
La seguridad básica comienza con nuestra sólida implantación de gestión de identidad y acceso (IAM), que unifica los controles de acceso basados en roles con nuestro marco de políticas intuitivo. Esta capacidad abarca diversos temas, como usuarios, grupos, federación de identidades y autorización principal de instancia/recurso. Si bien no se incluye en IAM, otro concepto de seguridad básica tiene que ver con las redes definidas por el usuario mediante el uso de listas, grupos y reglas de seguridad de red.
A medida que comienza a desarrollar una arquitectura técnica segura en Oracle Cloud Infrastructure (OCI), un buen punto de partida es Center for Internet Security (CIS), una organización no específica de ningún proveedor que cataloga las mejores prácticas de seguridad. El CIS ha desarrollado una referencia de seguridad para aplicaciones de OCI, mientras que Oracle ha desarrollado una automatización que ayuda a los ISV a implantar las recomendaciones del CIS mediante Terraform.
OCI proporciona otros servicios básicos de seguridad que incluyen:
- Gestión de secretos y claves de cifrado.
- Análisis de vulnerabilidades de host, contenedor y red.
- Capacidades de seguridad y gestión de API , como protección DDoS, control de acceso a API e integración de identidad.
- Capacidades de firewall de aplicaciones web (WAF), compatibles con inteligencia de amenazas, políticas de conformidad y seguridad, y gestión de bots adaptable.
- Un servicio de bastión que permite a los clientes proporcionar acceso restringido y por tiempo limitado a recursos privados.
- Un servicio de certificado que permite el almacenamiento y la gestión de certificados de criptografía de clave pública (PKCS).
Si subimos de nivel, una capacidad única de OCI son las zonas de máxima seguridad, que configuran y aplican automáticamente las políticas de seguridad en OCI. Esto permite que la seguridad declarativa se aplique mediante el uso de las mejores prácticas de seguridad y proporciona un enfoque de seguridad proactivo en lugar de reactivo para los recursos esenciales.
Por último, la seguridad no está completa sin la gestión de la estrategia de seguridad que ofrecen Cloud Guard para los activos de OCI y Data Safe para las cargas de trabajo de base de datos. Ambos servicios se ofrecen sin costo alguno para los clientes de OCI y aseguran que los recursos mal configurados y la actividad poco segura se detecten y solucionen rápidamente de manera automatizada con recetas de seguridad listas para usar o mediante el envío de datos a sistemas SIEM/SOC.
Capacidad de observación
Todas las organizaciones requieren la capacidad de recopilar estadísticas del rendimiento de sus activos en la nube tanto para respaldar las operaciones como para la planificación de TI futura. En concreto, los ISV necesitan capacidades más avanzadas, ya que suelen utilizar aplicaciones personalizadas que a menudo requieren una instrumentación de rendimiento de aplicaciones más profunda. Además, puede que los ISV ejecuten sus cargas de trabajo a escala de nube con una base de consumidores externos ininterrumpida, que necesita niveles más altos de tiempo de actividad que un sistema interno típico.
En un nivel básico, OCI ofrece nuestro servicio de supervisión, que brinda estadísticas en tiempo real del rendimiento de las cargas de trabajo en OCI y proporciona métricas listas para usar respecto del estado y el rendimiento. Los usuarios pueden configurar alarmas para detectar y responder a anomalías. Este servicio se combina con el servicio básico de registro, que muestra los logs de OCI además de los logs que generan sus cargas de trabajo. Nuestro servicio de notificaciones puede manejar las condiciones o los problemas identificados mediante cualquiera de los servicios antes mencionados, proporcionando un sistema de publicación-suscripción de baja latencia y alta disponibilidad que envía alertas a funciones sin servidor (para su reparación automática), correo electrónico o partners de entrega de mensajes, como SMS, Slack y PagerDuty.
Si subimos un poco más, Oracle proporciona una serie de servicios impulsados por Machine Learning (AA), que brindan análisis más detallados en las áreas de registro, rendimiento de aplicaciones, rendimiento de bases de datos y operaciones. Logging Analytics le permite controlar, agregar, indexar y analizar todos los datos de log, así como utilizar el aprendizaje automático para detectar clusters de problemas y anomalías de forma visual. Application Performance Monitoring es un servicio que cumple con los estándares (OpenTracing y OpenMetrics) y que permite la supervisión sintética, el rastreo distribuido y el análisis de ejecución de transacciones de aplicaciones personalizadas, incluido el soporte nativo para la telemetría de microservicios derivados de los entornos de Kubernetes/Docker que ofrecen muchos ISV. Gestión de base de datos proporciona capacidades de control para conjuntos de Oracle Database y Estadísticas de operaciones, con el fin de que los administradores puedan detectar problemas de rendimiento, prever el consumo y planificar la capacidad con análisis de AA. Las organizaciones pueden utilizar estas capacidades para tomar decisiones basadas en datos para optimizar el uso de recursos, evitar interrupciones de manera proactiva y mejorar el rendimiento.
Todas estas capacidades de observación se incluyen como servicios integrados en OCI y cuentan con "niveles gratuitos" que permiten al ISV usar servicios en escenarios limitados y, luego, ampliar el uso en base a los éxitos iniciales.
Continuidad del negocio
Con frecuencia, los requisitos de continuidad del negocio de un ISV pueden ser más rigurosos que los de una organización de ISV tradicional. Si bien el tiempo de inactividad de un sistema interno tradicional (como un sistema de administración de capital humano [HCM] o un sistema de planificación de recursos empresariales [ERP]) puede presentar problemas, la mayoría de los ISV no pueden tolerar ni siquiera interrupciones temporales de sus sistemas del cliente, que son el elemento vital de su negocio. Con este fin, conceptos como alta disponibilidad (HA) y recuperación ante desastres (DR) son extremadamente importantes, y los ISV deben aprovechar las capacidades que OCI proporciona en estos campos en la mayor medida posible.
Alta disponibilidad
Una región OCI es un área geográfica localizada compuesta por uno o más dominios de disponibilidad, cada uno de ellos formado por tres dominios de errores. La alta disponibilidad está asegurada por la redundancia de los dominios de errores en los dominios de disponibilidad.
Un dominio de disponibilidad consiste en uno o más centros de datos ubicados en una región. Los dominios de disponibilidad están aislados entre sí, son tolerantes a errores y es poco probable que fallen de forma simultánea. Debido a que los dominios de disponibilidad no comparten la infraestructura física, como la energía, la refrigeración o la red interna de dominios de disponibilidad, es poco probable que un fallo que afecte a un dominio de disponibilidad afecte la disponibilidad de los demás.
Un dominio de errores es una agrupación de hardware e infraestructura en un dominio de disponibilidad. Cada dominio de disponibilidad contiene tres dominios de errores. Los dominios de errores le permiten distribuir las instancias para que no estén en el mismo hardware físico de un único dominio de disponibilidad. Como resultado, un fallo de hardware inesperado o el mantenimiento del hardware de recursos informáticos que afecte a un dominio de errores no influye en las instancias de otros dominios de errores.
Todos los dominios de disponibilidad de una región están conectados entre sí mediante una red de baja latencia y gran ancho de banda. Esta interconexión cifrada y predecible entre dominios de disponibilidad proporciona los componentes básicos para la alta disponibilidad y la recuperación ante desastres.
Puede diseñar soluciones en varias regiones, distintos dominios de disponibilidad o diversos dominios de errores, según la clase de fallos contra los que se desee proteger.
También hay numerosas capacidades que ofrece OCI y opciones que puede implantar para proteger sus recursos de red, sistemas de almacenamiento y recursos de base de datos contra fallos localizados. Un buen punto de partida consiste en leer el playbook de la solución de alta disponibilidad del centro de arquitectura de OCI y tomar las decisiones adecuadas para su modelo operativo.
Recuperación ante desastres
Un desastre puede ser cualquier evento que ponga en riesgo sus aplicaciones, desde cortes de red hasta fallos en los equipos y desastres naturales. Un plan de recuperación ante desastres (DR) bien diseñado le permite recuperarse rápidamente de los desastres y continuar brindando servicios a sus usuarios. Las capacidades de recuperación ante desastres de OCI se basan en las amplias capacidades de alta disponibilidad analizadas en la sección anterior.
Al plantearse su estrategia de recuperación ante desastres, primero debe pensar en su objetivo de tiempo de recuperación (RTO) y su objetivo de punto de recuperación (RPO). El RTO es el tiempo objetivo dentro del cual se debe restaurar una aplicación determinada después de que ocurra un desastre. Normalmente, cuanto más esenciales son las aplicaciones, menor es el RTO. El RPO es el período posterior a un desastre durante el cual la aplicación puede tolerar la pérdida de datos antes de que el desastre comience a afectar a la empresa.
A continuación, debe determinar a qué tipo de escenario de desastre está orientado el diseño. ¿Está tratando de protegerse contra fallos en las aplicaciones, fallos en la red, fallos en el centro de datos, interrupciones regionales o todo lo anterior? La respuesta a esta pregunta, junto con sus determinaciones de RTO/RPO, impulsará su estrategia de recuperación ante desastres.
OCI proporciona orientación para crear arquitecturas tolerantes a desastres en los niveles de recursos informáticos, red, almacenamiento, aplicaciones y bases de datos. Puede usar estas herramientas para crear una arquitectura activa-activa en la que sus aplicaciones funcionen simultáneamente en dos regiones y un fallo en la región "a" pueda ser manejado por la región "b", un escenario de copia de seguridad semiactiva en el que una región secundaria esté preparada y lista para asumir el tráfico en caso de fallo de la región principal, un escenario de copia de seguridad inactiva en el que se puede requerir una combinación de pasos manuales o automatizados para restaurar las operaciones de negocio, o alguna combinación de las anteriores.
Un buen punto de partida consiste en leer el playbook de la solución de recuperación ante desastres del centro de arquitectura de OCI y tomar las decisiones adecuadas para su modelo operativo.
Presupuestos y cuotas
Como ISV que ejecuta una aplicación SaaS que aprovecha los compartimentos de OCI para el aislamiento, puede que desee plantearse el uso de algunos primitivos relacionados que le ayudarán tanto a usted como a sus clientes a gestionar mejor sus recursos. Cada arrendamiento de OCI suele estar preconfigurado con un cierto límite anual en dólares y, si bien los excedentes no incurren en ninguna penalización, a la mayoría de los ISV les gusta mantener un control estricto sobre la utilización de recursos.
Los ISV deberían empezar por mirar las cuotas de compartimentos como una herramienta para dividir los recursos de todo el arrendamiento en varios compartimentos en el arrendamiento. Con el uso de este primitivo, recursos comunes como CPU y bloques de almacenamiento, o recursos más especializados, como GPU e instancias de Exadata, se pueden asignar entre compartimentos para asegurarse de que ningún inquilino obtenga una asignación de recursos excesiva y que determinados recursos especializados se asignen en los lugares correctos.
Las cuotas se usan en los recursos en la nube. Al controlar las asignaciones en dólares, los ISV deberían analizar los presupuestos de OCI. Esta capacidad le permite definir presupuestos de uso en cada compartimento y recibir alertas cuando un presupuesto se acerque al límite flexible o cuando supere un límite obligatorio. El uso de esta función puede ayudar a los ISV a gestionar el gasto en varios clientes y ayudar a predecir la necesidad de un crecimiento futuro de los recursos.
Costos
Si bien cada ISV fija el precio de su servicio SaaS de manera diferente, un elemento común en muchos modelos de precios es el concepto de costo de bienes vendidos (COGS). Si no sabe cuánto gasta para crear y entregar un producto, es difícil saber cómo fijar un precio justo y cómo variar ese precio entre los diferentes consumidores.
Un servicio SaaS tiene muchas entradas de precios, incluidos los costos de ingeniería y marketing, pero un componente clave es el costo del alojamiento en la nube. Esta es un área donde el análisis de costos de OCI puede ayudar mediante las visualizaciones dinámicas del uso que hacen los inquilinos clientes, segmentados por compartimentos o etiquetas de seguimiento de costos. El uso de estas herramientas puede ayudarlo a comprender cuánto está gastando para alojar a cada uno de sus clientes y orientarlo sobre si es posible que deba ajustar el precio que les presenta.
Si necesita datos más detallados de los que se proporcionan en nuestras visualizaciones, puede exportar datos de uso detallados en un formato legible por máquina para analizarlos con la herramienta de su elección. Además, si trabaja en un entorno de nube híbrida, puede usar una herramienta de terceros multinube, como CloudHealth, para hacer un análisis unificado.
Automatización de infraestructura
Muy pocas organizaciones construyen sus entornos manualmente. Los ISV han reconocido especialmente el valor de la orquestación de la infraestructura y la gestión de la configuración mediante el uso de herramientas de infraestructura como código (IaC), como Terraform, Ansible, Puppet, etc. Si bien se recomienda la IaC independientemente del tamaño de la organización, la huella técnica o el enfoque del despliegue, es esencial para los ISV en fase de crecimiento que están expandiendo constantemente su presencia regional y la base instalada. Sin automatización, los gastos generales de mantenimiento aumentarán exponencialmente y serán difíciles de gestionar.
OCI brinda soporte para diferentes herramientas de automatización estándar del sector que le permitirán implantar una estrategia de automatización no específica de ninguna nube. Estas incluyen soporte productivo para HashiCorp Terraform, Ansible y Chef. Puesto que OCI expone toda su funcionalidad mediante SDK y una CLI, se puede integrar fácilmente con otras herramientas, como Puppet.
Además, OCI se basa en las capacidades de Terraform y ofrece un servicio gestionado denominado Gestor de recursos. Este servicio, que se ofrece sin costo a los clientes de OCI, permite que Terraform se ejecute desde dentro de los límites del modelo de seguridad basado en políticas de OCI y proporciona gestión de estado, creación de plantillas, detección de recursos e integración con GitHub/GitLab listos para usar.
Automatización del ciclo de vida del software
Los ISV utilizan herramientas de creación y despliegue automatizadas para que el código vaya avanzando por el ciclo de vida de desarrollo del software. Al plantearse un modelo de entrega de inquilino único, una automatización sólida cobra aún más importancia, ya que un solo despliegue puede servir a cientos de instancias de inquilino. Además, estos despliegues a menudo se deben realizar de forma dinámica para eliminar el tiempo de inactividad y deben ser suficientemente flexibles para manejar personalizaciones específicas basadas en sucursales para clientes individuales.
OCI soporta la gran mayoría de herramientas de integración y despliegue continuos líderes en el mercado. Si utiliza tanto Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI como otras herramientas, probablemente haya alguien en el ecosistema del software que esté usando su herramienta elegida con OCI.
Además, OCI proporciona un servicio de DevOps fácil de usar, que consiste en una plataforma de integración y despliegue continuos (CI/CD) completa para desarrolladores. Los ISV pueden utilizar este servicio para crear, probar y desplegar fácilmente software en OCI, así como para gestionar el código fuente con repositorios Git privados y alojados.
Conclusión
Oracle reconoce que cada ISV trae consigo una historia, un entorno de origen, una arquitectura técnica, un modelo de despliegue y requisitos técnicos y de negocio únicos. No hay un enfoque único para migrar a Oracle Cloud Infrastructure (OCI) que considere todos estos factores únicos y que los tome en cuenta a la hora de aprovechar las capacidades de OCI.
Un componente clave de nuestro enfoque diferenciado para la migración de ISV es la combinación de nuestro proceso de compromiso, que reúne a arquitectos, asesores de negocio e ingenieros especializados para ayudar a diseñar su solución en la nube, con el uso de Cloud Lift Services para trabajar hombro a hombro con usted para migrar su carga de trabajo a OCI.
Lo que hace que Oracle sea único en el ámbito de los ISV es nuestra voluntad y deseo de involucrarnos personalmente con los clientes en las etapas de implementación, arquitectura, estrategia y lanzamiento al mercado, así como coordinar nuestros expertos con los suyos para satisfacer de forma conjunta sus requisitos en la nube.