Identificar a Arquitetura ou Solução mais Adequada

Considere a série de fatores de avaliação (ou estressores) para identificar a arquitetura de referência (RA) ou a solução que melhor atende às suas necessidades. As seções a seguir fornecem informações sobre os fatores que você deve considerar.

Para cada fator, fornecemos uma indicação de se uma arquitetura ou solução suporta ou não o fator. Se necessário, você pode torná-lo mais matizado, atribuindo a cada fator uma pontuação numérica. Use as informações e a matriz de decisão usando essas recomendações.

  • Controle quais colunas correspondem à sua resposta preferida.
  • Compare o RA ou a solução que melhor atende às suas necessidades em relação a cada fator de avaliação usando a matriz de decisão.
  • Adicione uma ponderação aos fatores que são mais importantes para você do que outros.

Considere os Vários Fatores de Avaliação

Considere cada fator de avaliação e compare-os com cada arquitetura e solução para determinar o que melhor se adapta às suas necessidades.

Contêiner, Máquina Virtual (VM) ou Especialista

Você pode dimensionar recursos com eficiência para processos que exigem mais poder de computação, implantando processos em contêineres dentro de um ambiente de orquestração de contêineres como o Kubernetes. Tarefas como testes de unidade e análise de código estático podem se beneficiar disso. A desvantagem de usar contêineres é o aumento da complexidade na configuração de ponta a ponta. Sua equipe precisará saber como usar ferramentas de orquestração de contêineres como o Kubernetes. O uso de contêineres também garante que, quando eles forem destruídos, eles impeçam de selecionar acidentalmente dependências transitórias ou dados de estado anteriores.

O uso de uma VM é mais simples, pois você pode criar uma única VM para tratar todas as etapas de um pipeline. Um recipiente é monolítico na natureza. Uma abordagem de VM também alivia problemas como permitir hospedagem de desenvolvedor e evita problemas ao usar hosts Windows versus Linux.

Alguns cenários especializados só suportarão produtos PaaS ou SaaS nos quais o processo de criação prepara e implanta artefatos para o serviço. Você pode orquestrar isso usando uma ferramenta de finalidades gerais. Em alguns casos, usar uma ferramenta específica ao requisito pode ser mais benéfico. Por exemplo, o Oracle Visual Builder Studio foi projetado para soluções que envolvem o Visual Builder.

Orquestração de Pipeline com OCI Nativo com Produtos de Código Aberto/Terceiros

O uso de ferramentas específicas ou muito personalizáveis de domínio, incluindo ferramentas de código aberto, como Jenkins, pode oferecer maior liberdade no processo de construção durante a execução em comparação com o uso de soluções Nativas do OCI. Embora ferramentas como OCI DevOps liberem novos recursos regularmente. Mas essa flexibilidade se resume ao custo de gerenciar mais estágios de processo, como implantação, aplicação de patches e monitoramento, mesmo ao executar pipelines típicos.

Repositórios de Implantação Padronizados ou Repositórios de Produto Especial

Os serviços nativos darão suporte aos seus requisitos quando você gerenciar configurações usando serviços padrão do setor, como OCI Git, GitLab ou GitHub, e ferramentas semelhantes. Os processos CI/CD podem ser restritos a repositórios legados parcialmente integrados. Talvez você precise fazer alterações significativas no pipeline para poder usar processos de CI/CD com repositórios legados.

Gerenciamento de Configuração Padrão do Setor ou Ferramentas Legadas

Ao usar serviços fornecidos pela nuvem, normalmente o serviço suporta apenas soluções de padrão industrial usando sistemas de Gerenciamento de Configuração (CM), como Git e SVN. Esses provedores de serviços também podem oferecer suporte a quaisquer mecanismos de gerenciamento de configuração especializados necessários aos próprios produtos do fornecedor. Se você precisar usar um sistema CM legado ou de nicho, poderá ser necessário considerar soluções de terceiros que o provedor de sistema CM suporta. Por exemplo, o suporte ao CVS como uma solução legada pode precisar que os usuários usem ferramentas de terceiros para gerenciar a configuração.

Implantação multicloud ou em nuvem única

A implantação da mesma solução básica em várias nuvens pode adicionar complexidades que você deve considerar. Por exemplo, se o processo de implantação for incorporado a um serviço Terraform, cada provedor de nuvem precisará ter processos de implantação que levem em consideração as diferenças de vários provedores Terraform. Considerações mais sutis, como um chipset de destino para imagens do Docker, podem ser necessárias, pois serão necessárias diferentes imagens.

Para garantir uma melhor segurança, você pode optar por não expor seus destinos de implantação para uma solução de implantação externa. Por exemplo, se você estiver implantando no Oracle Container Engine for Kubernetes (OKE) e no Azure Kubernetes (AKE), poderá usar GitHub para armazenar o código comum e GitHub Actions para orquestrar o build do contêiner. Mas você pode optar por não expor o AKS e o OKE diretamente às Ações GitHub. Em vez disso, considere uma solução de vários estágios com Azure e OCI para fornecer orquestração de implantação e usar GitHub para os processos de criação contínuos ou o código central.

Considere uma solução de vários estágios quando a Infraestrutura como Código (IaC) fizer parte do processo de implantação. Isso permite que cada ambiente tenha uma configuração IaC diferente para provisionar serviços de computação, armazenamento e gerenciados. O uso do Kubernetes permite limitar ou remover esses problemas.

Personalização de Processo ou Processos Bespoke

Se você precisar de processos especiais ou de nicho, as ferramentas para suportar o pipeline de build deverão permitir extensões para configuração personalizada. Criar seus próprios processos sob medida requer mais esforço. Você deve levar em consideração e avaliar o risco de como alterações futuras podem impedir que a personalização funcione.

Potencial de Dimensionamento

As cargas de trabalho de desenvolvimento podem flutuar devido a fatores como tendências comuns durante um dia de trabalho. Por exemplo, confirmações para finalizar atividades de fim de dia que acionam processos de CI/CD resultam em um aumento na carga de trabalho no final do dia de trabalho. À medida que os projetos progridem em seu ciclo de vida de construção, liberação e implantação, a infraestrutura de construção vê um aumento na demanda. Há um padrão de aumento nas solicitações de pequenas alterações, pois problemas menores são abordados no final dos ciclos de liberação/impressão.

Analisar a Matriz de Decisão

As arquiteturas e soluções são agrupadas sob um número comum, como 1a, 1b e 1c, com base no local em que têm variações sutis. Por exemplo, um único nó para a solução CI/CD ou a mesma solução com uma configuração de ferramentas diferente indica que a solução pode operar em uma escala maior. Cada agrupamento é um cabeçalho de coluna na matriz de decisão e cada fator é um cabeçalho de linha. Chamadas dentro da tabela, como 1, fornecem informações adicionais.

A matriz de decisão a seguir representa as variações entre as arquiteturas e soluções para permitir que você identifique a adequada às suas necessidades de negócios.

Fator 1. Orquestração do Jenkins 2. GitLab 3. OCI DevOps 4. GitHub Ações 5. Estratégia Moderna de Aplicativos 6. Hub Móvel 7. Bots
Contêiner, máquina virtual (VM) ou especialista

VM e Container

(Embora a solução fornecida vise VMs)

VM ou Container VM e contêiner VM e Container VM e Container Especialista Especialista
Orquestração de pipeline com produtos nativos da OCI ou não gerenciados com código aberto/de terceiros Sim Sim Não Sim Não Não (Oracle Dev Cloud) Não
Repositórios de implantação padronizados Sim1,3 Sim 1 Não Não (na implementação da RA - mas possível) Sim 1 Não Não
Repositórios de gerenciamento de configuração suportados GIT, SVN e outros GIT GIT GIT GIT GIT GIT
Implementação de nuvem única ou multinuvem Solteiro2,3 Única ou Multicloud Solteiro2 Única ou Multicloud Solteiro2 Único Não
Personalização de processos ou processos sob medida Sim Sim Sim Sim Sim Não Limitado
Potencial de dimensionamento

1a - Não

1b - Sim

Sim Sim Sim Sim Não Não

Notas de Rodapé da Tabela

Observação:

  • 1 OCIR é compatível com padrões.
  • 2 Usa o OCI para orientar processos em outros ambientes. Mas também levanta o desafio da exposição indesejável a serviços em outros ambientes.
  • 3 Usa o OCI DevOps na fase de implantação para a opção 1a; portanto, limita essa fase a uma única nuvem.