Consejos y experiencias reales en ingeniería de software, IA aplicada y desarrollo de soluciones digitales que marcan la diferencia.

Bienvenido a una explicación clara y práctica sobre mutabilidad e inmutabilidad en Python, un tema esencial para escribir código predecible y eficiente. En Python las variables son nombres que apuntan a objetos y la propiedad de mutabilidad depende del tipo de objeto: algunos objetos no pueden cambiarse después de su creación, y otros sí pueden modificarse en el lugar.

Tipos inmutables: int, float, str, tuple, frozenset, bool. Estos objetos no cambian; cualquier operación que parezca modificarlos crea en realidad un nuevo objeto. Tipos mutables: list, dict, set, bytearray. Estos pueden alterarse en el mismo objeto, afectando a todas las referencias que apuntan a él.

Un ejemplo práctico para entender la diferencia es el operador +=. Para un entero la operación crea un nuevo objeto: x = 5 luego x += 1 resulta en un nuevo objeto con otro identificador. Para una lista la misma sintaxis modifica la lista en el lugar: mi_lista = [1, 2, 3] luego mi_lista += [4] actualiza la misma lista sin crear un nuevo objeto. Esa diferencia explica por qué a veces parece que una variable cambia y otras veces no.

La distinción tiene efectos prácticos importantes. Un problema clásico es el uso de argumentos por defecto mutables en funciones. Por ejemplo la definición def add_task(new_task, tasks = []) crea la lista por defecto una sola vez cuando se carga la función, y todas las llamadas que usen el valor por defecto reutilizarán la misma lista, acumulando tareas sin querer. La solución recomendada es usar None como valor por defecto y crear la lista dentro de la función: def add_task(new_task, tasks = None): if tasks is None: tasks = [].

Otro punto clave es la copia de objetos. Asignar una variable a otra crea un nuevo nombre para el mismo objeto, no una copia. Para listas y estructuras anidadas hay que distinguir entre copia superficial y copia profunda. Una copia superficial comparte objetos internos mutables, por lo que cambiar un elemento anidado en el original afectará a la copia. Para clonar completamente estructuras anidadas es necesario usar deepcopy del módulo copy.

También existe la sutileza de contener objetos mutables dentro de contenedores inmutables. Un tuple es inmutable: no se pueden añadir ni reemplazar sus elementos, pero si uno de sus elementos es una lista mutable, ese elemento interno puede modificarse. Por ejemplo mi_tupla = (1, 2, [3, 4]) no permite reasignar mi_tupla[0], pero sí permite modificar la lista anidada con una llamada a append.

En este artículo explicamos cómo crear un sistema completamente automatizado y orientado por eventos para el procesamiento de archivos en Microsoft Azure utilizando únicamente el Portal de Azure, sin necesidad de herramientas de línea de comandos ni programación compleja. El flujo resultante permite que al subir un archivo se dispare automáticamente su procesamiento, archivado y limpieza, todo gestionado con servicios gestionados.

Arquitectura esencial: Archivo subido -> Blob Storage -> Event Grid -> Logic App -> App Service -> Automation Account. Este diseño escala automáticamente, incluye supervisión integrada y solo cobra por lo que se consume.

Qué necesitarás antes de empezar: una suscripción activa de Azure, permisos de colaborador para crear recursos, un navegador moderno y un archivo de prueba cualquiera. También es recomendable contar con buenas prácticas de seguridad como identidades administradas y asignaciones de rol mínimas.

Pasos básicos de implementación: 1 Crear un Resource Group para agrupar recursos. 2 Crear una Storage Account en el que activarás transferencia segura y crearás un contenedor privado llamado input-files. 3 Preparar un App Service Plan en Linux y una Web App para alojar la lógica de procesamiento, por ejemplo con runtime Node.js 18. 4 Desplegar la lógica de procesamiento en la Web App instalando express y @azure/storage-blob y configurando una App Setting con la cadena de conexión de almacenamiento.

Orquestación con Logic Apps: crea una Logic App Consumption con el disparador When an HTTP request is received. Logic App recibirá el payload de Event Grid, parseará el JSON, extraerá metadatos del blob y llamará a la API de tu App Service mediante una acción HTTP. Añade condicionales para comprobar si el procesamiento fue correcto y en casos de éxito invoca el proceso de archivado.

Automatización posterior: crea un Automation Account y un Runbook en PowerShell que se ejecute con identidad administrada. El Runbook debe crear un contenedor processed-files si no existe y copiar el blob procesado con un nombre con marca temporal por ejemplo 20250911_213000_miarchivo.txt. De esta manera se conserva un histórico y se puede limpiar el contenedor de entrada si es necesario.

Permisos y seguridad: habilita identidades administradas en la Logic App y en el Automation Account. Asigna roles concretos: a la Logic App como Storage Blob Data Reader, al Automation Account como Storage Blob Data Contributor y otorga a la Logic App permisos de Automation Contributor para invocar runbooks. Tras cualquier asignación de rol espera unos minutos para la propagación.

Integración con Event Grid: crea una suscripción de eventos sobre el contenedor input-files usando el evento Blob Created y establece como endpoint la URL HTTP POST de la Logic App. Event Grid se encargará de entregar el evento que desencadena la orquestación.

Prueba del flujo: sube un archivo de prueba al contenedor input-files y observa cómo Event Grid invoca la Logic App, la Logic App llama al App Service que procesa el archivo y finalmente el Automation Account archiva la copia procesada en processed-files. Revisa el Log Stream de App Service y el historial de ejecución de la Logic App y del Runbook para depuración.

Consejos de resolución de problemas: si la Logic App no se dispara revisa el estado de la suscripción de Event Grid; si la Web App falla consulta el Log Stream y verifica la cadena de conexión; si el Runbook devuelve error confirma las asignaciones de rol y que la identidad administrada tiene acceso; recuerda esperar unos minutos tras cambios de permisos.

Ventajas de este enfoque: no requiere código extensivo, es completamente automatizado, escalable y seguro al usar identidades administradas. Es una solución coste efectiva basada en pago por uso y ofrece monitorización completa desde el Portal de Azure.

Consideraciones de coste estimadas para bajo volumen: Logic Apps 5 a 15 USD mensuales, App Service Plan B1 alrededor de 13 USD, Storage entre 2 y 10 USD, Automation cuenta con minutos gratuitos y Event Grid incluye un nivel gratuito. Durante desarrollo puede usarse el tier gratuito de App Service.

Siguientes pasos recomendados: cuando domines el Portal explora IaC con Azure CLI, ARM o Bicep y Terraform para automatizar despliegues y añade pipelines CI CD para desplegar código de forma segura y repetible.

Vivimos en una era de innovación constante donde la automatización y los agentes IA han pasado de ser herramientas de nicho a componentes esenciales para empresas y profesionales que buscan mantenerse competitivos.

La automatización es más que una moda: es la vía para ganar eficiencia. En esencia, automatizar significa ejecutar tareas de forma repetible sin intervención manual, desde sincronizar datos entre hojas de cálculo hasta gestionar respuestas de correo. Automatizar procesos rutinarios reduce errores y libera tiempo para tareas de alto valor como la estrategia y la relación con clientes.

Los flujos de trabajo son el latido de la automatización. Mientras que la automatización ejecuta tareas aisladas, los workflows conectan esas tareas en procesos coherentes: capturar datos de un formulario, validar la información y registrar un nuevo cliente en un CRM. Herramientas visuales y no code facilitan diseñar estos pipelines y permiten a equipos sin perfil técnico controlar cómo fluye la información entre plataformas.

La verdadera evolución llega con los agentes IA. A diferencia de la automatización basada en reglas, los agentes IA pueden interpretar lenguaje, tomar decisiones y aprender con el tiempo. Un agente IA puede gestionar consultas de clientes, analizar pedidos y reponer stock automáticamente, o incluso priorizar incidencias según gravedad, mejorando la experiencia del cliente y la eficiencia operativa.

Sí, lo leíste bien — diseñé e implementé en un día un framework moderno full stack en JavaScript y sin servidor. No es clickbait ni una demostración de egos; era una necesidad para un proyecto real: una base de datos de recuperación con enfoque AI, pensada para ejecutarse serverless y aprovechar la red edge de Cloudflare para latencias mínimas y coste reducido a escala.

La pila elegida combina herramientas actuales y robustas: Hono como backend ligero y extensible, React en el frontend para velocidad de desarrollo y experiencia de usuario, Vite como sistema de build ultrarrápido, Node.js para desarrollo local y Cloudflare Workers en producción, y NPM como ecosistema de paquetes. El resultado es una arquitectura comparable a stacks modernos como Next.js pero sin vendor lock in y con funciones edge listas para producción.

Arquitectura y flujo de trabajo: monorepo con carpetas packages y types para compartir tipados, configuración central en package.json y tsconfig para enlazar cliente y servidor, y wrangler para desplegar Workers y servir assets desde Cloudflare Pages. El backend expone APIs con Hono, sirve los assets estáticos y realiza server side rendering importando dinámicamente la entrada del servidor compilada por Vite. El cliente usa react-router para routing, react query para gestión de estado y renderizado isomórfico con hidratación en el browser.

Beneficios prácticos: funciones edge distribuidas, alto rendimiento y escalabilidad automática, experiencia de desarrollo fluida con hot reload y tipado TypeScript compartido cliente-servidor. Ideal para aplicaciones que demandan baja latencia, despliegues globales y coste eficiente.

Día 3 en mi viaje con Go y sigo con mi registro diario para consolidar aprendizajes y ayudar a quienes comienzan con este lenguaje. Hoy cubrí conceptos clave como Concepto, Sintaxis, Implementación, Ejemplos y Casos de uso, además de temas prácticos que todo desarrollador debe dominar.

Empecé revisando el manejo de Errores y Errores personalizados para construir sistemas robustos y con mensajes claros. La gestión de errores en Go es fundamental para aplicaciones a medida y para crear soluciones seguras y mantenibles en producción.

Trabajé con Funciones de cadenas y Formateo de texto, esenciales para preparar salidas legibles, construir logs y normalizar datos. También profundicé en Plantillas de texto para separar lógica de presentación en APIs y aplicaciones web.

Regular expressions Regex fue otra pieza del día para validaciones y extracción de patrones en entradas de usuario y logs. La manipulación de Fechas y Tiempo, parsing y formateo de epoch time es clave en sistemas distribuidos y procesamiento de eventos.

Generación de Números aleatorios y el Parseo de números para validaciones y simulaciones completaron la jornada. Estos temas aparecen con frecuencia en proyectos de machine learning, simuladores y agentes IA para tareas específicas.

Para la implementación práctica repasé ejemplos y casos de uso como microservicios, APIs REST, herramientas de línea de comandos y pipelines de datos. Go destaca por su rendimiento y concurrencia, lo que lo hace ideal para backend de aplicaciones a medida y soluciones enterprise.

Mirae es una plataforma interactiva de cuentos infantiles que genera historias personalizadas y escritas por profesionales para niñas y niños de 6 a 12 años. Cada niño se convierte en el protagonista de su propia aventura única, con ilustraciones personalizadas, funciones interactivas de vocabulario y contenido educativo. La interfaz combina tecnología avanzada de generación de historias con un diseño glass morphism y optimización para móvil usando React Native. Actualmente la compra de Tokens para generar historias en el sitio estará disponible una vez que la app iOS pendiente sea aprobada.

La idea de Mirae nació al observar cómo los libros tradicionales, aunque hermosos, son estáticos y ofrecen la misma experiencia a todos. Queríamos aprovechar las posibilidades de la tecnología para crear narrativas que se adapten a los intereses, nivel de lectura y personalidad de cada niño. Los padres pueden subir fotos que se integran en las ilustraciones, elegir estilos de escritura inspirados en autores infantiles, y seleccionar estilos de arte, escenarios y personajes que coincidan con las preferencias del niño. Cada palabra de la historia puede ser interactiva, ofreciendo definiciones y audio para mejorar la comprensión lectora.

Detrás del proyecto hay una historia personal y técnica. Al principio pensé en usar un tema oscuro y minimalista, habitual en aplicaciones de productividad, pero pronto comprendí que un cuento infantil exige algo brillante, lúdico y atractivo. Encontré en el hackathon Kiro la inspiración para implementar glass morphism correctamente, combinando estética y accesibilidad sin sacrificar el rendimiento.

El plan de trabajo generado con Kiro produjo documentos de implementación muy detallados que guiaron la construcción del sistema: desde componentes visuales como GlassCard, GlassButton y GlassInput hasta estrategias de optimización y accesibilidad para React Native. Esos planes anticiparon problemas críticos como la gestión de memoria de historias largas y características offline para lectura sin conexión.

La base visual de Mirae se construyó con componentes pensados para un público infantil: efectos de desenfoque y translucidez combinados con animaciones suaves y retroalimentación táctil clara. Diseñar para niños implica considerar interacciones distintas, como pulsaciones más largas o gestos exploratorios, y asegurar que los estados de foco y las áreas táctiles sean accesibles.

El motor de generación de historias, llamado HighSpeedGeneration, orquesta agentes creativos que validan y ensamblan narrativas completas. Soporta múltiples estilos de escritura: desde relatos repetitivos y educativos estilo Eric Carle hasta historias rítmicas y rimadas al estilo Dr. Seuss. Para lectores de 6 a 8 años las historias suelen ser de 30 a 40 páginas con vocabulario controlado, mientras que para edades de 9 a 12 años pueden alcanzar 80 páginas o más con tramas y arcos de personajes complejos, e incluso formatos interactivos tipo elige tu propia aventura.

Pasar de web a móvil implicó repensar la experiencia: gestos táctiles, limitación de espacio en pantalla, variabilidad de dispositivos y conexiones intermitentes. Implementamos carga progresiva de contenidos para que las portadas y primeras páginas estén disponibles de inmediato, mientras el resto se descarga en segundo plano y se cachea para lectura offline. Además ajustamos la calidad de imágenes según las capacidades del dispositivo para ahorrar batería y datos.

La accesibilidad fue un requisito desde el inicio. Todos los elementos interactivos cumplen con tamaños mínimos de toque, contraste de color adecuado y soportan aumento de texto. El sistema de vocabulario ofrece definiciones visuales y audio, beneficiando a lectores con distintas necesidades, incluyendo dislexia o dificultades motoras mediante opciones de pulsación larga y gestos alternativos.

Para asegurar buen rendimiento en una amplia gama de dispositivos creamos múltiples rutas de renderizado: efectos completos en equipos de gama alta, versiones simplificadas para móviles medios y diseños estáticos en dispositivos antiguos. La gestión de memoria carga imágenes bajo demanda, mantiene una caché pequeña y libera recursos de páginas que ya no son visibles.

La personalización va más allá de cambiar nombres. El sistema analiza edad, intereses, fotos subidas y nivel lector para adaptar trama, tono y relaciones entre personajes. La integración de fotos utiliza visión por computadora para representar al niño en las ilustraciones manteniendo coherencia artística. Además el motor aprende de patrones de lectura y del feedback para mejorar recomendaciones con el tiempo.

Probar con usuarios reales fue esencial. Los niños son directos y exploradores; esperan respuestas inmediatas y se frustran con esperas largas. Cambiamos definiciones emergentes por explicaciones inline y afinamos las animaciones de carga para mantener la atención. También ajustamos el contraste y la intensidad de los efectos glass para que la legibilidad no se vea afectada en exteriores.

Mirae nació como producto, pero su arquitectura modular permite escalar y evolucionar: nuevos estilos de escritura, técnicas de arte y marcos educativos pueden integrarse sin romper la base. La comunidad de familias ha aportado ideas valiosas que han mejorado la lectura compartida y el uso educativo del vocabulario interactivo.

Desde el punto de vista técnico aprendimos que herramientas de planificación automatizada aceleran el desarrollo cuando se usan bien, que React Native permite experiencias móviles ricas si se optimiza cuidadosamente, y que glass morphism aporta atractivo visual si se balancea con accesibilidad y rendimiento.

Mirae es una plataforma interactiva de cuentos infantiles que genera historias personalizadas y profesionalmente redactadas para niños de 6 a 12 años. Cada niño se convierte en el protagonista de su propia aventura única, con ilustraciones personalizadas, funciones interactivas de vocabulario y contenido educativo. La plataforma combina tecnología avanzada de generación de historias con un diseño glass morphism moderno y optimizaciones para móviles con React Native.

La idea nació de la frustración frente a libros estáticos donde todos leen la misma historia. Queríamos algo que aprovechara la personalización y la interactividad que permite la tecnología actual. Mirae no es solo reemplazar nombres: adapta el tono, la complejidad narrativa, el estilo artístico y las mecánicas interactivas según la edad, los intereses y el nivel lector del niño. Los padres pueden subir fotos que se integran en las ilustraciones y elegir estilos de autor inspirados en referentes infantiles, así como paletas de arte, escenarios y compañeros que reflejen las preferencias del niño.

El motor de generación, llamado HighSpeedGeneration, orquesta agentes creativos que actúan como escritores y artistas colaborando para producir narrativas coherentes, con desarrollo de personajes, arcos argumentales y contenidos adecuados por edad. Para lectores de 6 a 8 años las historias suelen ser de 30 a 40 páginas con vocabulario controlado y soporte interactivo para palabras. Para edades 9 a 12 las tramas son más complejas, pueden superar las 80 páginas y dar lugar a formatos interactivos como aventuras de escoger camino.

En diseño enfrentamos el dilema del tema oscuro habitual en herramientas de productividad. Para una experiencia infantil necesitábamos algo brillante, lúdico y accesible. La solución fue adoptar un enfoque glass morphism que aporta profundidad y tacto visual sin sacrificar legibilidad. Componentes como GlassCard, GlassButton y GlassInput fueron diseñados con cuidados especiales de rendimiento para móviles, técnicas de desenfoque, sombras y retroalimentación táctil pensada para las manos de los niños.

La planificación fue clave. Herramientas de planificación automatizada ayudaron a generar documentos de implementación detallados que cubrieron desde arquitectura de componentes hasta gestión de memoria y estrategias offline. Gracias a esos planes pudimos anticipar retos como el manejo de archivos de historias pesadas, la compatibilidad con lectores de pantalla y la necesidad de cargas progresivas para no bloquear la experiencia. Esto permitió pasar del agotamiento inicial al avance sostenido del proyecto.

Las limitaciones de móvil obligaron a repensar interacciones: gestos táctiles, orientación vertical y horizontal, estrategias de caché y carga progresiva. Solo las primeras páginas y las portadas se cargan de inmediato mientras el resto se descarga en segundo plano para mantener el flujo de lectura. Las imágenes se adaptan según las capacidades del dispositivo para controlar uso de memoria, ancho de banda y batería.

La accesibilidad fue un requisito desde el inicio. Tamaños de toque adecuados, contrastes de color suficientes, compatibilidad con lector de pantalla, escalado de texto y soporte multimodal para vocabulario con definiciones visuales y audio de pronunciación. También se consideraron variantes de interacción para niños con diferencias motoras, con toques largos y deslizados ajustables.

La personalización integra visión por computadora para analizar fotos subidas por los padres y representar al niño de forma consistente en las ilustraciones, cuidando coherencia artística y evitando simples recortes. Las historias se adaptan al temperamento del niño: temas de confianza para los más tímidos, retos colaborativos para los aventureros, etc. El sistema aprende de patrones de lectura y retroalimentación para mejorar recomendaciones.

El proceso de prueba con usuarios reales fue revelador. Los niños demandan respuestas inmediatas y detestan interrupciones. Cambiamos popups por definiciones inline y creamos animaciones de carga entretenidas. Ajustamos efectos de vidrio para mantener legibilidad bajo luz solar y optimizamos feedback táctil para que todas las interacciones sean claras y gratificantes.

En cuanto a escalabilidad, implementamos múltiples rutas de renderizado para soportar desde terminales antiguos hasta tablets de última generación. Los dispositivos de gama alta reciben efectos completos; los de gama media experimentan versiones simplificadas y los más antiguos usan alternativas estáticas que conservan la funcionalidad. La gestión de memoria prioriza carga bajo demanda y liberación agresiva de recursos no visibles.

Mirae fue desarrollado teniendo en mente integraciones futuras: nuevos estilos de escritura, técnicas artísticas adicionales y marcos educativos. También planeamos explorar formas emergentes de experiencia como realidad aumentada y asistentes de voz para ampliar la inmersión sin perder la esencia literaria.

Tu vendedor se queda congelado en medio de la frase. En una llamada de 50K. Aparece el nombre de un competidor y pum la confianza se evapora. Si has estado cerca de llamadas comerciales en vivo, seguro has visto un trato morir en tiempo real porque el representante fue sorprendido por un rival para el que no estaba preparado. Titubea, gana tiempo con excusas y promete volver con una respuesta. Y así se pierde el impulso.

La mayoría asume que es un problema del vendedor. No lo es. Es un problema de battlecards o tarjetas de venta.

Por qué la mayoría de las battlecards no funcionan

1. Las crean quienes no venden Muchas battlecards las elaboran equipos de marketing o enablement que no están en las llamadas. El resultado parece profesional en papel pero se desmorona bajo presión porque nadie validó los argumentos en campo.

2. El tiempo no coincide Los reps no esperan semanas para prepararse contra un competidor. Necesitan apoyo ahora. Si la organización tarda 2 o 3 semanas en publicar una tarjeta, el negocio ya puede estar perdido.

3. Documentos estáticos que envejecen Precios, funcionalidades y posicionamientos cambian constantemente. Una battlecard congelada en el tiempo pierde credibilidad y, cuando muere la confianza, dejan de usarla.

Qué convierte una battlecard en una herramienta que realmente cierra negocios

Olvida la teoría. Estas cuatro piezas juntas marcan la diferencia:

1. Inteligencia en tiempo real, no PDFs obsoletos Las mejores tarjetas se actualizan con lo que sucede en llamadas reales: grabaciones, notas de win/loss y frases que usan los reps que funcionan en la práctica. Las organizaciones que integran datos del campo y los procesan rápido mantienen a su equipo preparado.

2. Creación en minutos, no en meses Si detectas un nuevo competidor en un trato esta semana, necesitas una tarjeta útil para el viernes. Usa plantillas enfocadas y, si dispones de herramientas con IA, genera borradores iniciales que los reps puedan retocar al instante.

3. Scripts prácticos, no listas de características No basta con decir que tenemos la funcionalidad X. Las battlecards ganadoras dan el discurso exacto: preguntas de descubrimiento para exponer debilidades, reframes cuando el competidor es fuerte en algo y guiones de valor que cambien la narrativa. Las palabras importan tanto como los datos.

4. Accesible durante la llamada, sin romper el flujo Si la tarjeta no está al alcance del vendedor en vivo, es como si no existiera. Centraliza la información y facilita el acceso para que buscar no sea una excusa en medio de una negociación.

Cómo construir battlecards que tu equipo realmente use

No necesitas un documento de 12 páginas ni un diseño espectacular. Necesitas claridad, rapidez y relevancia.

Paso 1: Recoge inteligencia del frente Revisa grabaciones de llamadas, análisis de victorias y pérdidas y entrevista a los reps que cierran. Esa es la materia prima.

Paso 2: Estructura para vender Mantén cada tarjeta corta y accionable. Formato recomendado: resumen del competidor con sus fortalezas y cómo neutralizarlas; guiones concretos para la conversación; respuestas a objeciones comunes; pruebas y métricas que respalden la afirmación. Incluye siempre ejemplos de cómo decirlo, no solo qué decir.

Paso 3: Bucle de retroalimentación Las battlecards nunca están acabadas. Establece revisiones ligeras cada 2 a 4 semanas: qué ha cambiado, qué escuchan los reps, qué guiones funcionan. Haz del aprendizaje competitivo un hábito del equipo.

Paso 4: Consigue adopción verdadera Empieza con tus reps estrella para crear campeones internos; entrena con roleplays; celebra los cierres donde la tarjeta fue decisiva; y mide uso e impacto con métricas como tasa de cierre, tiempo al cierre y confianza del vendedor. No las hagas obligatorias: hazlas tan útiles que quieran usarlas.

Consejo práctico Crea una tarjeta piloto para un solo competidor, pruébala en llamadas reales, ajusta y repite. Ser un 10% más preparado frente a la competencia suele marcar la diferencia.

Cómo puede ayudar Q2BSTUDIO

En este artículo describimos paso a paso cómo aprovisionar de forma sencilla un Oracle Autonomous Database en Google Cloud mediante la oferta pública Oracle Database@Google Cloud, integrando servicios de Oracle Cloud Infrastructure y Google Cloud Platform para ejecutar bases de datos Oracle dentro del entorno de Google.

1. Tener una cuenta de Google Cloud Sea editor del proyecto GCP y disponga de permisos de facturación. Es imprescindible contar con los permisos necesarios para crear recursos y vincular servicios entre GCP y OCI.

2. Suscribirse a la oferta Oracle Database@Google Cloud en GCP Marketplace En Marketplace busque Oracle Database@Google Cloud, seleccione la opción Pay as You Go y suscríbase. La suscripción en sí no suele generar coste inmediato, pero Oracle debe aprobar manualmente la orden, por lo que el proceso puede tardar.

3. Crear una cuenta OCI nueva a través de la oferta Tras procesarse la oferta, en la página del recurso Oracle Database@Google Cloud aparecerá la opción para vincular el proyecto GCP a una tenancy de OCI. En el caso de ofertas públicas solo es posible crear y enlazar una cuenta OCI nueva, no una ya existente.

4. Crear la red ODB La red ODB en GCP es una red virtual que conecta los recursos Oracle Database@Google Cloud en el sitio hijo de OCI dentro del datacenter de GCP con su VPC de Google Cloud. Permite que la Oracle Virtual Cloud Network que aloja las bases de datos se mapee hacia la VPC de Google. Esta red no aparece listada entre las VPCs comunes de GCP, y debe crearse desde la página del recurso Oracle Database@Google Cloud seleccionando ODB network.

5. Crear subredes cliente y de backup para la ODB Después de crear la ODB cree las subredes client y backup necesarias. Un Autonomous Database requiere como mínimo un bloque CIDR /27. En entornos de prueba puede utilizar por ejemplo 10.0.1.0/24 para cliente y 10.0.2.0/24 para backup, teniendo en cuenta la planificación del espacio de direcciones IP.

6. Crear el Autonomous Database Vaya al menú Autonomous Database y seleccione Crear. Complete los datos requiridos, escoja una región soportada y si va a probar conectividad pública incluya su IP para permitir acceso desde su ubicación. También puede habilitar mutual TLS para mayor seguridad.

7. Verificar la conexión a la base de datos Una vez creado el ADB utilice el botón Manage in OCI para acceder al panel de la nueva cuenta OCI y descargue el wallet de conexión. Para conectar públicamente pruebe con Oracle SQL Developer: seleccione Cloud Wallet como tipo de conexión, indique la contraseña admin configurada al crear la base, cargue el archivo wallet y elija uno de los endpoints públicos en lugar del endpoint privado alto. Pulse Test y Connect y ejecute consultas SQL para verificar el funcionamiento.

Recomendaciones finales Este tutorial ofrece una visión práctica y de alto nivel para desplegar un ADB mediante la oferta pública. Revise la documentación oficial para detalles avanzados y buenas prácticas. Detenga o apague su Autonomous Database cuando no lo utilice para evitar costes innecesarios.

Sobre Q2BSTUDIO Q2BSTUDIO es una empresa de desarrollo de software y aplicaciones a medida especializada en soluciones tecnológicas integrales. Ofrecemos servicios de software a medida, aplicaciones a medida y consultoría en inteligencia artificial pensada para empresas. También prestamos servicios de ciberseguridad y pentesting para proteger sus activos digitales, así como servicios cloud para AWS y Azure y proyectos de inteligencia de negocio y Power BI. Si busca apoyo para migrar o administrar bases de datos en la nube o integrar capacidades de IA en sus procesos, podemos ayudarle con diseño, implementación y soporte.