Identificar la arquitectura o solución más adecuada

Considere la serie de factores de evaluación (o factores de estrés) para identificar la arquitectura de referencia (RA) o la solución que mejor se adapte a sus necesidades. Las siguientes secciones le proporcionan información sobre los factores que debe considerar.

Para cada factor, le proporcionamos una indicación de si una arquitectura o solución soporta el factor o no. Si es necesario, puede hacerlo más matizado otorgando a cada factor una puntuación numérica. Utilice la información y la matriz de decisiones mediante estas recomendaciones.

Realice un seguimiento de qué columnas coinciden con su respuesta preferida.
Compare la RA o la solución que mejor se adapte a sus necesidades con cada factor de evaluación mediante la matriz de decisiones.
Agregue un peso a los factores que son más importantes para usted que para otros.

Considerar los diversos factores de evaluación

Considere cada factor de evaluación y, a continuación, compárelos con cada arquitectura y solución para determinar cuál se adapta mejor a sus necesidades.

Contenedor, máquina virtual (VM) o especialista

Puede ampliar los recursos de forma eficiente para los procesos que requieren más potencia informática mediante el despliegue de procesos en contenedores dentro de un entorno de orquestación de contenedores como Kubernetes. Las tareas como las pruebas de unidad y el análisis de código estático pueden beneficiarse de esto. La desventaja del uso de contenedores es la mayor complejidad en la configuración de extremo a extremo. Su equipo necesitará saber cómo utilizar las herramientas de orquestación de contenedores como Kubernetes. El uso de contenedores también garantiza que, cuando se destruyen, eviten que se detecten por accidente dependencias transitorias o datos de estado anteriores.

Utilizar una máquina virtual es más sencillo, ya que puede crear una única máquina virtual para manejar todos los pasos de un pipeline. Un recipiente es de naturaleza monolítica. Un enfoque de VM también alivia problemas como permitir el alojamiento de desarrolladores y evita problemas de uso de hosts de Windows frente a Linux.

Algunos escenarios especializados solo soportarán productos PaaS o SaaS en los que el proceso de creación prepara y despliega artefactos para el servicio. Puede orquestar esto mediante una herramienta de uso general. En algunos casos, el uso de una herramienta específica del requisito puede ser más beneficioso. Por ejemplo, Oracle Visual Builder Studio está diseñado para soluciones relacionadas con Visual Builder.

Orquestación de pipelines con OCI Native con productos de terceros/de código abierto

El uso de herramientas específicas del dominio o muy personalizables, incluidas herramientas de código abierto como Jenkins, puede ofrecer una mayor libertad en el proceso de creación durante la ejecución en comparación con el uso de las soluciones nativas de OCI. Aunque herramientas como OCI DevOps lanzan nuevas funciones con regularidad. Pero esta flexibilidad tiene el costo de gestionar más etapas de proceso, como el despliegue, la aplicación de parches y la supervisión, incluso cuando se ejecutan pipelines típicos.

Repositorios de despliegue estandarizados o repositorios de productos especiales

Los servicios nativos admitirán sus requisitos cuando gestione configuraciones mediante servicios estándar del sector como OCI Git, GitLab o GitHub, y herramientas similares. Los procesos de integración y despliegue continuos se pueden restringir con repositorios heredados parcialmente integrados. Puede que tenga que realizar cambios significativos en el pipeline para poder utilizar procesos de integración y despliegue continuos con repositorios heredados.

Herramientas heredadas o gestión de configuración estándar del sector

Al utilizar servicios proporcionados en la nube, es normal que el servicio solo soporte soluciones estándar del sector mediante sistemas de gestión de configuración (CM), como Git y SVN. Estos proveedores de servicios también pueden admitir cualquier mecanismo de gestión de configuración especializado que los propios productos del proveedor necesiten. Si debe utilizar un sistema de CM antiguo o nicho, puede que sea necesario considerar soluciones de terceros que admite el proveedor del sistema de CM. Por ejemplo, el soporte para CVS como una solución heredada puede necesitar que los usuarios utilicen herramientas de terceros para gestionar la configuración.

Despliegue en una sola nube o multinube

Desplegar la misma solución central en varias nubes puede agregar complejidades que debes tener en cuenta. Por ejemplo, si el proceso de despliegue se incorpora a un servicio Terraform, cada proveedor en la nube tendrá que tener procesos de despliegue que tengan en cuenta las diferencias de los distintos proveedores de Terraform. Es posible que se necesiten consideraciones más sutiles, como un juego de chips de destino para imágenes de Docker, ya que será necesario crear diferentes imágenes.

Para garantizar una mayor seguridad, puede elegir no exponer sus destinos de despliegue para una solución de despliegue externa. Por ejemplo, si está desplegando en Oracle Container Engine for Kubernetes (OKE) y Azure Kubernetes (AKE), puede utilizar GitHub para contener el código común y GitHub Actions para orquestar la creación del contenedor. Sin embargo, puede optar por no exponer AKS y OKE directamente a las acciones GitHub. En su lugar, considere una solución de varias etapas con Azure y OCI para proporcionar orquestación de despliegue y utilice GitHub para los procesos de creación continua o el código principal.

Considere una solución de varias etapas cuando la infraestructura como código (IaC) forma parte del proceso de despliegue. Esto permite que cada entorno tenga una configuración IaC diferente para el aprovisionamiento de servicios informáticos, de almacenamiento y gestionados. El uso de Kubernetes permite limitar o eliminar dichos problemas.

Personalización de procesos o procesos a medida

Si necesita procesos especiales o de nicho, las herramientas para soportar el pipeline de compilación deben permitir extensiones para la configuración personalizada. Crear sus propios procesos a medida requiere más esfuerzo. Debe tener en cuenta y evaluar el riesgo de cómo futuros cambios pueden impedir que la personalización funcione.

Potencial de escala

Las cargas de trabajo de desarrollo pueden fluctuar debido a factores como las tendencias comunes durante un día laborable. Por ejemplo, los compromisos para finalizar actividades de fin de día que activan procesos de integración y despliegue continuos generan un aumento de la carga de trabajo al final de la jornada laboral. A medida que los proyectos avanzan a lo largo de su ciclo de vida de creación, lanzamiento y despliegue, la infraestructura de creación ve un aumento en la demanda. Existe un patrón de aumento en las solicitudes de cambios pequeños, ya que los problemas menores se abordan al final de los ciclos de lanzamiento/sprint.

Revisión de la matriz de decisiones

Las arquitecturas y soluciones se agrupan en un número común, como 1a, 1b y 1c en función de dónde tengan variaciones sutiles. Por ejemplo, un único nodo para la solución de integración y despliegue continuos o la misma solución con una configuración de herramientas diferente indica que la solución puede funcionar a una escala mayor. Cada agrupación es una cabecera de columna en la matriz de decisión y cada factor es una cabecera de fila. Las llamadas dentro de la tabla, como ¹, proporcionan información adicional.

Agrupaciones de Soluciones y Arquitectura

Orquestación de Jenkins (con dos variantes)
1. Configurar un pipeline de integración y despliegue continuos para despliegues en la nube con Jenkins: enfoque de despliegue mínimo sin escalabilidad ni resiliencia
2. Desplegar Jenkins en modo maestro/agente: despliegue escalable y resistente
3. Cree un pipeline de despliegue e integración continuos con el servicio DevOps de Oracle.
GitLab (Fin de creación)
1. Despliegue GitLab para activar los pipelines de integración y despliegue continuos en OCI
2. Despliegue programas de ejecución GitLab en Oracle Container Engine for Kubernetes con escala automática de cluster
OCI DevOps: variantes para contenedores y sin servidor
1. Cree un pipeline CICD con el servicio Oracle Cloud Infrastructure DevOps y OCI Functions
2. Cree un pipeline de despliegue e integración continuos con el servicio DevOps de Oracle.
GitHub Acciones: cree un pipeline de integración y despliegue continuos para despliegues en la nube con GitHub Acciones y el servicio Oracle Cloud Infrastructure DevOps
Estrategia de aplicaciones moderna: planificación de estrategias de despliegue de aplicaciones modernas con Oracle Cloud Infrastructure Devops
Hub móvil: creación de un pipeline de integración y despliegue continuos para aplicaciones móviles
Bots: Creación de un pipeline de integración y despliegue continuos para componentes personalizados de bots

La siguiente matriz de decisiones representa las variaciones entre las arquitecturas y las soluciones para permitirle identificar la adecuada para sus necesidades de negocio.

Factor	1. Orquestación de Jenkins	2. GitLab (Fin de creación)	3. OCI DevOps	4. Acciones de GitHub	5. Estrategia de aplicación moderna	6. Hub móvil	7. Bots
Contenedor, máquina virtual (VM) o especialista	VM y contenedor (Aunque se han proporcionado máquinas virtuales de destinos de solución)	VM o contenedor	VM y contenedor	VM y contenedor	VM y contenedor	Especialista	Especialista
Orquestación de pipeline con OCI nativo o no gestionado con productos de código abierto/terceros	Si	Si	No	Si	No	No (Oracle Dev Cloud)	No
Repositorios de despliegue estandarizados	Sí^1,3	Sí ¹	No	No (en implementación de RA, pero posible)	Sí ¹	No	No
Repositorios de gestión de configuración soportados	GIT, SVN y otros	GIT DE	GIT DE	GIT DE	GIT DE	GIT DE	GIT DE
Despliegue multinube o en una única nube	Único^2,3	Única o multinube	Único²	Única o multinube	Único²	Único	No
Personalización de procesos o procesos a medida	Si	Si	Si	Si	Si	No	Limitado
Potencial de escala	1a - No 1b - Sí	Si	Si	Si	Si	No	No

Notas al pie de la tabla

Nota:

¹ OCIR es compatible con los estándares.
² Utiliza OCI para impulsar procesos en otros entornos. Pero también plantea el desafío de la exposición indeseable a los servicios en otros entornos.
³ Utiliza OCI DevOps en la fase de despliegue para la opción 1a, por lo que limita esa fase a una única nube.