Considerações e Padrões de Hospedagem em Nuvem
Para Fornecedores de Software Independentes (ISVs)
Os Fornecedores de Software Independentes (ISVs) precisam de uma plataforma e de serviços de infraestrutura seguros, escaláveis e confiáveis para hospedar seus aplicativos. Mais do que organizações de tecnologia da informação (TI) que executam um sistema de back-office na nuvem, os ISVs precisam enfrentar operações 24 horas por dia, 7 dias por semana, implementações geograficamente diversas e padrões dinâmicos de tráfego de clientes que podem exigir dimensionamento elástico, bem como os desafios de segurança decorrentes da exposição de seus aplicativos na Internet pública.
Um ISV que está migrando para um ou mais provedores de nuvem em hiperescala, ou operando em um deles, tem uma série de escolhas e padrões importantes a considerar. Você deve efetuar a migração lift and shift do aplicativo no estado em que se encontra ou utilizar a migração para a nuvem como uma oportunidade de adotar uma postura nativa da nuvem e possivelmente começar a usar os serviços gerenciados de PaaS de um provedor? Uma implementação na nuvem pode transformar sua postura de alta disponibilidade (HA) e recuperação de desastres (DR) ao permitir o uso de domínios de falha no data center, domínios de disponibilidade na região ou interconexões entre regiões? Quais ferramentas o provedor de nuvem oferece para proteger seus dados, sua rede interna, seus hosts/contêineres de computação, bem como suas interações com clientes? Por fim, você está implementando seu aplicativo como um SaaS multitenant ou em uma configuração de tenant único para cada um de seus clientes?
A Oracle migrou centenas de aplicativos para a OCI. Além disso, nossa equipe de Engenharia de Nuvem ajudou dezenas de ISVs a planejar e, posteriormente, migrar para a OCI. Este microsite fornecerá orientação e apresentará padrões de hospedagem distintos para ISVs.
Exploramos vários tópicos pelas lentes de diferentes abordagens para a adoção da Oracle Cloud.
Este microsite não deve ser lido de forma linear. O diagrama abaixo representa visualmente o fluxo que você pode seguir no site com base em seu próprio perfil. Depois de concluir esta introdução, leia a seção Nosso Processo e, dependendo do seu modelo de hospedagem atual, leia a seção Nascido na Nuvem ou On-premises/Hospedagem Compartilhada. Em seguida, leia a seção SaaS Multitenant ou SaaS de Tenant Único, dependendo do modelo de entrega do seu aplicativo. Por fim, leia as seções de Características Transversais comuns e a seção de Resumo.
Nosso Processo
- Nascido na Nuvem
- On-premises/Hospedagem Compartilhada
- Modelo de Entrega de Aplicativos Multitenant
- Modelo de Entrega de Aplicativos de Tenant Único
Muitos provedores de SaaS de ISV "nasceram na nuvem", o que soa como "nativos da nuvem", mas nem sempre é o caso. Nascido na nuvem normalmente significa um desejo de não ser mais acoplado a sistemas legados e ser construído de acordo com os princípios de design de aplicativos modernos. Design de Aplicativo Moderno é a orientação arquitetural que incorpora os princípios descritos como um Twelve Factor App. Isso também não é o mesmo que a arquitetura Nativa da Nuvem, mas está intimamente relacionado a ela. Para aqueles que procuram um tratamento mais aprofundado de nativo da nuvem a partir de uma perspectiva da Oracle, vale a pena analisar os Padrões Nativos da Nuvem, um ebook com foco no design nativo da nuvem.
Independentemente de o aplicativo SaaS ser criado seguindo o design de aplicativo moderno ou os princípios nativos da nuvem, existem alguns fatores determinantes que são comuns:
- Desejo de seguir princípios modernos de desenvolvimento de aplicativo
- Desejo de focar no aplicativo, e não na infraestrutura
- Tempo reduzido de obtenção do valor para os recursos
- Implementações contínuas, confiáveis e que se repetem
- Distanciamento do que é visto como sistemas "legados" ou de fornecedor único
- Desejo de criar, operar e suportar uma arquitetura moderna
- Desejo de operar da maneira flexível que a computação em nuvem permite
Os ISVs que começaram com esses objetivos normalmente têm uma arquitetura de serviço mais desacoplada. Os componentes do aplicativo na carga de trabalho podem ser implementados de forma independente, geralmente como contêineres, e a arquitetura do aplicativo é construída para permitir a continuidade do aplicativo em caso de falhas de componentes. Os aplicativos precisam lidar com a consistência dos dados e com a disponibilidade do aplicativo.
Dependendo da arquitetura de tempo de execução escolhida, o ISV provavelmente terá monitoramento integrado e notificações no controle de sua infraestrutura. A OCI fornece serviços para suportar o seguinte:
- CNCF Cloud Events com nosso Serviço de Eventos na Nuvem
- CNCF OpenTracing como parte da nossa Cloud Observabilty and Management Platform, que fornece interoperação completa com as Funções em Nuvem (sem servidor) e o Serviço de Notificações, o que, além de simplificar o gerenciamento do ciclo de vida da sua frota de servidores, facilita as tarefas de governança.
A comunicação entre componentes normalmente implementa um padrão assíncrono por meio do qual os componentes produzem e respondem a eventos, em vez de instruções diretas. A OCI oferece o Serviço de Streaming, um serviço de streaming sem servidor compatível com Kafka que é comumente usado para processar essa comunicação. A vantagem dessa abordagem é a proteção dos componentes durante as falhas, em que o raio de alcance é reduzido pela utilização de enfileiramento ou roteamento inteligente.
O desacoplamento adicional é obtido separando os aplicativos da infraestrutura. A flexibilidade geralmente é obtida por meio do uso dos mecanismos de dimensionamento automático fornecidos pelo provedor de serviço de nuvem (CSP). O dimensionamento automático pode ser no nível do contêiner, utilizando o Oracle Kubernetes Engine (OKE), no nível do grupo de instâncias ou no nível do grupo de servidores.
Com o tempo, alguns aplicativos SaaS começam a divergir da arquitetura baseada em padrões originalmente planejada, à medida que as equipes começam a aproveitar as vantagens dos serviços PaaS nativos fornecidos por um único CSP. Exemplos disso incluem o uso de um serviço de gerenciamento de dados exclusivo para uma única nuvem, incorporação de uma chamada de API direta para uma plataforma NoSQL de fornecedor sem camadas adequadas de abstração na implementação para substituição futura e utilização de IDEs que geram códigos específicos do fornecedor. Para manter a portabilidade da nuvem, os ISVs devem ter o cuidado de equilibrar a conveniência de um serviço de plataforma com a ameaça de dependência do fornecedor, o que poderá ocorrer se o serviço estiver totalmente atrelado ao fornecedor. Muitos ISVs iniciaram uma jornada de remodernização de seus aplicativos com o objetivo de ter uma verdadeira cobertura multinuvem. Para isso, eles estão reavaliando os pontos de dependência extrema de um único fornecedor ou de tecnologias de uso único.
Com o tempo, pode ocorrer uma alteração na configuração da infraestrutura. Muitos ISVs adotam uma abordagem de Infraestrutura como Código (IaC). No entanto, a OCI oferece suporte às ferramentas padrão do setor, mas vai um passo além: o Gerenciador de Recursos da OCI, um serviço Terraform gerenciado, pode ser usado para monitorar, rastrear e reparar desvios na infraestrutura.
A implementação Lift and Shift consiste em migrar para a Oracle Cloud Infrastructure (OCI) suas cargas de trabalho de produção que estão em execução on-premises ou em uma instalação de hospedagem compartilhada. Em alguns casos, pode ser que você queira aproveitar as vantagens dos serviços de nuvem nativos oferecidos na OCI para aprimorar seus aplicativos. Essa atividade de "migração e melhoria" é outra razão convincente de migração para a OCI. As seções a seguir abordarão o processo Lift and Shift e as considerações sobre a migração Migrar e Melhorar, quando necessário.
Esse cenário é ideal para ISVs que querem reduzir suas despesas de capital e delegar algumas complexidades operacionais relacionadas à disponibilidade, à segurança e ao desempenho para um Provedor de Serviço de Nuvem (CSP) como a Oracle. O ISV geralmente implementa uma das seguintes estratégias:
- Lift and Shift: Migrar os aplicativos on-premises ou em instalações de hospedagem compartilhada para a OCI
- Migrar e Melhorar: Migrar os aplicativos on-premises ou em instalações de hospedagem compartilhada para a OCI e aprimorá-los por meio do uso dos serviços nativos da nuvem ou da migração dos bancos de dados para ofertas baseadas na nuvem.
Também é possível misturar e combinar essas estratégias: você pode migrar algumas cargas de trabalho no estado em que se encontram e modificar outras para aproveitar os serviços gerenciados da OCI (PaaS).
Lift and Shift
A estratégia Lift and Shift de migração para a nuvem consiste em migrar o aplicativo on-premises para a OCI sem fazer muitas alterações em relação à implementação local. A primeira etapa deste processo é identificar as cargas de trabalho e os aplicativos que permitirão a você aproveitar os recursos da OCI e atingir seus objetivos estratégicos. Oferecemos diversas opções de hospedagem para você escolher de acordo com seus requisitos de conectividade, latência e residência de dados. Independentemente do tipo de hospedagem escolhido, você terá acesso ao portfólio completo da OCI.
| Tipo de Hospedagem | Descrição |
|---|---|
| Nuvem Pública | Ampla plataforma de serviços de IaaS, PaaS e SaaS |
| Nuvem do Setor Governamental (domínios restritos) | Ampla plataforma de serviços de IaaS, PaaS e SaaS implementados em um domínio restrito para entidades do setor público |
| Região Cloud@Customer Dedicada | Ampla plataforma de serviços de IaaS, PaaS e SaaS implementados no seu data center |
| Roving Edge Infrastructure | Ampla plataforma de serviços de IaaS, PaaS e SaaS implementados em dispositivos robustos do Oracle Roving Edge (Oracle REDs) que fornecem computação em nuvem e serviços de armazenamento na borda das redes e em locais desconectados |
| Oracle Cloud VMWare | Migre as cargas de trabalho baseadas em VMware para a nuvem ou expanda seu VCenter on-premises a fim de incluir a nuvem sem rearquitetar aplicativos ou reorganizar operações. |
Ao projetar sua arquitetura de nuvem, saiba que a Oracle oferece suporte para diversas opções de conectividade de rede que permitem arquitetar uma solução de nuvem híbrida, que combina os recursos da OCI com os componentes em execução no seu data center, ou uma solução multinuvem, que interconecta sua presença na OCI com a presença em outro provedor de serviço de nuvem. As duas abordagens são muito comuns e podem facilitar a migração de dependências de carga de trabalho para aplicativos em execução on-premises ou em ambientes de outros fornecedores de serviço de nuvem a fim de cumprir os requisitos de residência de dados, os SLAs de TI ou outros requisitos.
A OCI permite essa comunicação pela internet pública, por meio de uma VPN IPSec ou usando conectividade dedicada (FastConnect). A tabela a seguir descreve algumas características de cada uma dessas abordagens:
| Método | Latência | Custo | Confiabilidade | Segurança |
|---|---|---|---|---|
| Internet Pública | Variável | Variável | Variável | Menos Segura |
| VPN IPSec | Variável | Variável | Variável | O tráfego é criptografado, mas o túnel é por meio da internet pública |
| OCI FastConnect | Baixa e previsível | Previsível | Mais confiável | Mais seguro; o tráfego usa uma conexão privada |
Além disso, embora seja possível fazer a interconexão nuvem-nuvem entre a OCI e qualquer outra nuvem usando as tecnologias acima, a Oracle tem uma parceria com o Microsoft Azure para fornecer um produto de interconectividade de baixa latência entre duas nuvens em diversas regiões no mundo todo.
A Oracle tem vários parceiros especializados em automatizar a migração para a OCI a partir de várias origens, incluindo nuvens públicas de outros fornecedores e ambientes on-premises virtualizados/não virtualizados. A lista completa de fornecedores de migração pode ser encontrada em nosso Marketplace, com destaque para a Rackware e a ZConverter.
Se estiver considerando a migração do Oracle Database de outras nuvens ou de ambientes on-premises, a Oracle oferece várias ferramentas que facilitam a migração off-line ou com tempo de inatividade zero/em tempo real. Essas diversas ferramentas incluem o Zero Downtime Migration (ZDM), o OCI Database Migration (DMS), o GoldenGate, o DataPump e o RMAN, entre outras. A ferramenta recomendada depende das características dos bancos de dados de origem e destino e do ambiente operacional. Consulte mais informações na Página Inicial de Migração da Nuvem de Banco de dados da OCI.
Migrar e Melhorar
A estratégia Migrar e Melhorar de migração para a nuvem consiste em aprimorar ou substituir um serviço existente por uma oferta de nuvem. Conforme sua equipe avança na identificação dos candidatos adequados a serem migrados para a nuvem, você deve priorizar as oportunidades de aprimorar ou substituir serviços. Por exemplo, você pode aprimorar seus aplicativos on-premises migrando o banco de dados on-premises que oferece suporte a um aplicativo de missão crítica para o nosso Database Cloud Service gerenciado, o nosso serviço totalmente automatizado Autonomous Database ou o Exadata Cloud Service, a plataforma mais rápida para executar Oracle Databases na nuvem.
Além disso, a adoção da Oracle Cloud Infrastructure fornece acesso a um portfólio completo de serviços que inclui:
- Data Science Cloud, que inclui tecnologias como Aprendizado de Máquina, IA, Serviço de Big Data
- Software de Tecnologias Aplicadas, que inclui tecnologias como Assistentes Digitais e Cadeia de blocos
- Desenvolvimento de Aplicativos, que inclui tecnologias como Container Engine for Kubernetes, APEX (Low Code), Visual Builder Studio (CI/CD) e Mobile Hub
- Serviços de Segurança, que incluem tecnologias como WAF, Gerenciamento de Identidades e Acesso, Cloud Guard e Serviço de Segurança de Acesso
- Analytics Cloud
O modelo de entrega multitenant para fornecedores de SaaS usa um software executado em uma infraestrutura compartilhada a fim de oferecer suporte aos clientes finais individuais do ISV (tenants).
Os dados do cliente geralmente são armazenados em um conjunto de tabelas compartilhadas, e todas as camadas do aplicativo reconhecem o identificador exclusivo de um cliente. O aplicativo é projetado para ser compatível com vários clientes. Em geral, o próprio aplicativo também é responsável por gerenciar as assinaturas de usuários. Além disso, a infraestrutura precisa ser categorizada em grupos de servidores com base no número de clientes, transações e regulamentos que precisam ser suportados.
Por que Escolher este Modelo
O modelo multitenant apresenta vantagens para o ISV (Fornecedor de Software Independente). O uso das economias de escala fornecidas no modelo multitenant fornece muitos ganhos de eficiência. Como a composição do grupo de servidores é bem conhecida, há ganhos de eficiência no gerenciamento e no monitoramento da infraestrutura. O lançamento de uma nova área de serviço é tão simples quanto executar o código de automação da infraestrutura e implementar o aplicativo. O conjunto comum de infraestrutura também fornece um painel centralizado de monitoramento.
A hospedagem dos clientes em serviços comuns de computação, armazenamento e banco de dados simplifica a estratégia de implementação de aplicativos. Os ISVs que usam esse modelo normalmente têm uma única base de código, o que facilita a implementação de atualizações em toda a base de clientes. Muitos ISVs que utilizam esse modelo permitem que os clientes aceitem recursos novos por meio do uso de sinalizadores de recursos.
Naturalmente, todos esses benefícios também podem apresentar desvantagens. O suporte a clientes que têm requisitos específicos de residência de dados exige uma estratégia de implementação regional, e podem existir cenários nos quais os requisitos de negócios dos clientes impeçam a hospedagem nos mesmos servidores de um concorrente. Dependendo da arquitetura do aplicativo, os clientes podem estar sujeitos ao cenário do "vizinho barulhento". Quando um grupo de servidores fica saturado, o ISV precisa optar por migrar o cliente para um grupo de servidores menos utilizado ou expandir a capacidade do grupo existente.
Uma das consequências indesejadas do suporte adequado ao modelo de SaaS multitenant é que a arquitetura do aplicativo precisa ser bem pensada e planejada em um nível mais alto do que em uma arquitetura de tenant único. Os controles de acesso adequados e os modelos de segregação de dados precisam ser arquitetados desde o início na estrutura do aplicativo, e os ISVs precisam garantir que tenham as habilidades de engenharia internas para realizar tudo isso.
A Oracle pode ajudar a preencher a lacuna envolvendo nossos arquitetos de nuvem. Eles podem orientar você sobre como modernizar o aplicativo e ajustá-lo para o sucesso na nuvem. Nossos arquitetos trabalham com outros ISVs em todo o espectro e podem trazer experiências de trabalho com problemas semelhantes e melhores práticas para a transformação da sua nuvem.
Isolamento de Grupo de Servidores
A principal característica do modelo multitenant é o uso de um ambiente compartilhado para os tenants hospedados. Como ISV, você precisa garantir que o aplicativo de SaaS tenha sido arquitetado para separar e proteger adequadamente os dados do cliente durante o tempo de execução. Você também precisa ser capaz de gerenciar, monitorar e manter adequadamente as operações nos vários grupos de servidores que hospedam o aplicativo.
Você pode ter requisitos específicos para manter clientes de regiões específicas separados dos clientes de outras regiões (ou sub-regiões). Você pode fazer esse tipo de separação implementando suas cargas de trabalho na combinação de regiões e compartimentos da OCI. Um exemplo disso seria um fornecedor de SaaS nos EUA que vende serviços para o mercado de assistência médica e de manufatura geral. Esse fornecedor pode usar construtos regionais e de compartimento a fim de separar essas cargas de trabalho e fornecer recursos diferenciados (como conformidade com HIPPA/HITRUST para as cargas de trabalho de assistência médica).
Uma evolução natural para ISVs que começaram com um modelo multitenant é expandir a oferta a fim de fornecer melhor isolamento dos dados do cliente. Normalmente, essa expansão acontece primeiro no nível dos dados, e o Oracle Database é compatível com um modelo multitenant que permite a incorporação de bancos de dados independentes e conectáveis em um único banco de dados contêiner.
O modelo de entrega de tenant único usa um software executado em uma infraestrutura dedicada para oferecer suporte aos clientes finais individuais do ISV. Ao contrário do modelo multitenant, no qual vários clientes compartilham os mesmos ciclos de computação e misturam dados dentro de tabelas de banco de dados comuns, o modelo de tenant único usa VMs de computação distintas, bancos de dados distintos e infraestrutura de suporte distinta (balanceadores de carga, filas de mensagens etc.) para cada cliente.
Por que Escolher este Modelo
O modelo de tenant único apresenta muitas vantagens para o ISV (Fornecedor de Software Independente). A hospedagem de cada cliente/tenant em recursos separados de computação, armazenamento e banco de dados apresenta um caso mais claro para a separação de questões do ponto de vista de segurança e desempenho; o cliente "A" não pode afetar o cliente "B" por meio de ações maliciosas ou do consumo não intencional de uma cota superior de recursos. Além disso, o raio de alcance de uma falha catastrófica é menor. A falha de um único componente (como banco de dados ou fila de mensagens) pode impactar um único cliente, em vez de todo o aplicativo de SaaS. Cada tenant tem seu próprio ambiente personalizado com recursos e patches exclusivos, criando um modelo de entrega altamente centrado no cliente.
Naturalmente, todos esses benefícios também podem apresentar desvantagens. Por exemplo, todos os benefícios obtidos com o fornecimento de ambientes centrados no cliente podem apresentar uma sobrecarga adicional de gerenciamento de configuração e exigir mais monitoramento e manutenção. Muitos outros benefícios dessa abordagem são obtidos em um modelo multitenant, embora por meio de um design e implementação mais rigorosos do aplicativo de SaaS do ISV.
No final das contas, o ISV precisa decidir se deseja investir em um modelo multitenant para habilitar o seu aplicativo de SaaS. Para isso, ele deve analisar se tem as habilidades internas de engenharia de software para implementar o modelo. Caso contrário, ele pode recorrer aos recursos de compartimentação inerentes fornecidos por sua plataforma de software e/ou pelo provedor de nuvem em hiperescala. Cada ISV deve fazer essa escolha com base em sua situação única.
A Oracle pode ajudar você a analisar essas opções envolvendo nossos arquitetos de nuvem. Eles podem orientar você sobre como modernizar o aplicativo e ajustá-lo para o sucesso na nuvem. Nossos arquitetos trabalham com outros ISVs em todo o espectro e podem trazer experiências de trabalho com problemas semelhantes e melhores práticas para a transformação da sua nuvem.
Isolamento de Tenant
A principal característica do modelo de tenant único é o uso de um ambiente isolado para cada tenant. Como ISV, você deseja fornecer recursos dedicados de computação, rede, armazenamento, mensagens e banco de dados para cada um de seus clientes. Você deseja fazer isso separando esses recursos uns dos outros, tanto da perspectiva de tempo de execução quanto da perspectiva de gerenciamento.
A OCI fornece um recurso exclusivo chamado compartimentos, que permite uma forte separação lógica dos recursos da OCI. Você pode colocar um ambiente de cliente inteiro (incluindo rede, computação etc.) dentro de um compartimento e criar as políticas da OCI que controlam o acesso a esses recursos. Por meio do uso desses dois recursos centrais da OCI, você pode separar efetivamente o cliente "A" do cliente "B" e evitar qualquer contaminação cruzada de recursos, gerenciamento ou informações. Os compartimentos são hierárquicos, então você pode aninhar compartimentos e modelar configurações complexas do cliente usando essa abordagem. Por exemplo, imagine um cliente real com várias divisões que deseja separar alguns recursos por unidade de negócios e manter alguns recursos corporativos comuns.
Embora o modelo de compartimento forneça uma garantia maior para a separação, existem algumas abordagens intermediárias que podem ser usadas em determinadas camadas do aplicativo a fim de melhorar a utilização de recursos sem deixar de recorrer a um método não personalizado para separar os tenants. Por exemplo, em vez de criar um sistema de banco de dados separado para cada tenant, você pode aproveitar os recursos multitenant do Oracle Database a fim de implementar um único banco de dados contêiner com vários esquemas conectáveis. Essa abordagem reduz a sobrecarga de criar vários clusters de banco de dados e permite que o banco de dados imponha a separação, em vez de forçar a recriação do esquema do aplicativo. O Database as a Service de máquina virtual e bare metal da Oracle suporta o modelo multitenancy pronto para uso, assim como o Banco de Dados Autônomo Dedicado, que pode ser usado para suas cargas de trabalho mais exigentes.
O uso dessa abordagem intermediária só não é permitido na camada de dados. Quando seu aplicativo estiver em contêineres, você poderá usar o Container Engine for Kubernetes (OKE) da Oracle para implementar vários contêineres de cliente em uma única infraestrutura. Em seguida, use os primitivos nativos do Kubernetes, como namespaces, controle de acesso baseado em função (RBAC), segredos e cotas de recursos, para manter a separação do tenant. Assim como ocorre com o banco de dados, em vez de recriar seu aplicativo para reconhecer o tenant, você pode simplesmente aproveitar os recursos dos serviços de nuvem subjacentes.
Veja por que os ISVs estão escolhendo a Oracle Cloud
ISVs agregam mais valor aos clientes com a ampla gama de serviços e suporte da OCI.
Características Transversais
Talvez você seja um ISV "Nascido na Nuvem" que esteja criando uma infraestrutura de SaaS de tenant único aproveitando seus recursos inatos de hiperescala. Talvez você tenha iniciado on-premises e esteja migrando seu aplicativo de SaaS multitenant para hospedá-lo exclusivamente na nuvem. Ou talvez sua empresa use alguma variação dessas abordagens. Independentemente do caminho que você tenha seguido, todo ISV com operações na nuvem deve ficar atento às características transversais importantes, como segurança, capacidade de observação, continuidade dos negócios e automação. Nas seções a seguir, veremos como a Oracle está posicionada para superar esses desafios funcionais e se diferenciar da concorrência.
Segurança, Governança e Conformidade
De acordo com a abordagem da Oracle, a segurança deve estar sempre "ativada" por padrão e deve ser simples e prescritiva. Além disso, acreditamos que os clientes não deveriam ter de escolher entre custo e segurança e nos esforçamos para fornecer todos os serviços relacionados à segurança, sem custo ou com baixo custo, com parceiros que fornecem alternativas em nosso mercado. Acreditamos que as violações de clientes acontecem não devido à falta de ferramentas para prevenir vulnerabilidades, e sim porque essas ferramentas são muito caras ou muito difíceis de operar para a maioria das organizações.
A Oracle acredita que tanto o provedor de nuvem quanto o ISV são responsáveis pela segurança. Fornecemos alguns recursos básicos, como virtualização de rede isolada e raiz de confiança de hardware, e os aprimoramos com ferramentas e serviços que o ISV pode usar para personalizar sua postura de segurança. Os ISVs interessados em obter uma visão geral de nossas ofertas de segurança devem começar analisando nossa página de destino de segurança e arquitetura de segurança na nuvem.
A segurança central começa com nossa implementação avançada de gerenciamento de identidades e acesso (IAM), que unifica os controles de acesso baseados em funções com nossa estrutura de política intuitiva. Esse recurso abrange diversos tópicos, incluindo usuários, grupos, federação de identidade e autorização principal de instância/recurso. Embora não seja abordado pelo IAM, outro conceito central de segurança está relacionado à rede definida pelo usuário por meio do uso de grupos, listas e regras de segurança de rede.
Conforme você começa a desenvolver uma arquitetura técnica segura na Oracle Cloud Infrastructure (OCI), um bom ponto de partida é o Center for Internet Security (CIS), uma organização independente de fornecedores que cataloga melhores práticas de segurança. O CIS desenvolveu um benchmark seguro para aplicativos da OCI, e a Oracle desenvolveu uma automação que ajuda os ISVs a implementar as recomendações do CIS por meio do Terraform.
A OCI fornece uma série de outros serviços básicos de segurança que incluem:
- Gerenciamento de chaves de criptografia e segredos
- Varredura de vulnerabilidade de host, contêiner e rede
- Gerenciamento de API e recursos de segurança, como proteção contra DDoS, controle de acesso por API e integração de identidade
- Recursos de Firewall de Aplicativo Web (WAF) que suportam inteligência contra ameaças, políticas de conformidade de segurança e gerenciamento adaptativo de bots.
- Um serviço de bastion que permite aos clientes fornecer acesso restrito e por tempo limitado a recursos privados
- Um serviço de certificado que permite armazenar e gerenciar certificados de criptografia de chave pública (PKCS).
Mais acima na pilha, as Zonas de Segurança Máxima são um recurso exclusivo da OCI que automaticamente configuram e impõem as políticas de segurança na OCI. Isso permite que a segurança declarativa seja imposta usando as melhores práticas de segurança e fornece uma abordagem proativa, em vez de reativa, para a segurança dos recursos mais críticos.
Por fim, nenhuma história de segurança está completa sem o gerenciamento da postura de segurança fornecido pelo Cloud Guard, para toda a sua estrutura na OCI, e pelo Data Safe, para as suas cargas de trabalho de banco de dados. Os dois serviços são fornecidos gratuitamente para clientes da OCI e garantem que recursos mal configurados e atividades inseguras sejam rapidamente detectados e corrigidos de forma automatizada, sem receitas de segurança prontas para o uso ou envio de dados para sistemas SIEM/SOC.
Capacidade de Observação
Todas as organizações precisam ser capazes de reunir insights sobre o desempenho da sua nuvem para oferecer suporte às operações e planejar o futuro da TI. Os ISVs, em particular, precisam de recursos mais avançados, porque normalmente executam aplicativos personalizados que muitas vezes exigem uma instrumentação mais detalhada de desempenho dos aplicativos. Além disso, os ISVs podem executar suas cargas de trabalho em escala de nuvem de forma ininterrupta com uma base de consumidores externos, o que exige níveis mais altos de tempo de atividade em comparação com um sistema de back-office típico.
No nível básico, a OCI fornece nosso serviço de Monitoramento, que apresenta insights em tempo real sobre o desempenho das suas cargas de trabalho na OCI e oferece métricas de integridade e desempenho prontas para uso. Os usuários podem configurar alarmes para detectar e responder a anomalias. Esse serviço está correlacionado ao nosso serviço de Log, que mostra os logs da OCI e os logs gerados por suas cargas de trabalho. As condições ou os problemas identificados por qualquer um dos serviços mencionados acima podem ser tratados por nosso serviço de Notificações, que fornece um sistema de publicação/assinatura de baixa latência e alta disponibilidade o qual envia alertas a funções sem servidor (para correção automática), e-mails ou parceiros de entrega de mensagens, como SMS, Slack e PagerDuty.
Mais acima na pilha, a Oracle oferece vários serviços baseados em aprendizado de máquina (ML). Esses serviços fornecem análises mais detalhadas nas áreas de log, desempenho de aplicativos, desempenho de banco de dados e operações. O Logging Analytics permite monitorar, agregar, indexar e analisar todos os dados de log e usar ML para detectar clusters com problemas e anomalias de maneira visual. O Application Performance Monitoring é um serviço compatível com os padrões (OpenTracing e OpenMetrics) que permite o monitoramento sintético, o rastreamento distribuído e a análise de execução de transações de aplicativos personalizados, incluindo suporte nativo para a telemetria de microsserviços derivada de ambientes Kubernetes/docker que muitos ISVs oferecem. O Gerenciamento de Banco de Dados fornece recursos de monitoramento para frotas Oracle Database e Insights de Operações, que permitem aos administradores identificar problemas de desempenho, prever o consumo e planejar a capacidade usando análises de ML. As organizações podem usar esses recursos a fim de tomar decisões baseadas em dados para otimizar o uso de recursos, evitar interrupções de maneira proativa e melhorar o desempenho.
Todos esses recursos de observação são fornecidos como serviços integrados na OCI e possuem "camadas gratuitas" generosas, o que permite ao ISV usar os serviços em cenários limitados e expandir para um uso maior com base nos sucessos iniciais.
Continuidade dos Negócios
Os requisitos de continuidade de negócios de um ISV geralmente são mais rigorosos do que os de uma organização ISV tradicional. Embora o tempo de inatividade de um sistema de back-office tradicional, como um sistema de gerenciamento de capital humano (HCM) ou de planejamento de recursos empresariais (ERP), possa ser problemático, a maioria dos ISVs não pode tolerar nem mesmo interrupções temporárias em seus sistemas voltados para o cliente, que são a força vital de seus negócios. Por isso, conceitos como alta disponibilidade (HA) e recuperação de desastres (DR) são extremamente importantes, e os ISVs precisam aproveitar ao máximo os recursos que a OCI fornece nessas áreas.
Alta Disponibilidade
Região da OCI é uma área geográfica localizada composta por um ou mais domínios de disponibilidade, cada um composto por três domínios de falha. A alta disponibilidade é garantida por uma redundância de domínios de falha dentro dos domínios de disponibilidade.
O domínio de disponibilidade é um ou mais data centers localizados em uma região. Os domínios de disponibilidade são isolados uns dos outros, são tolerantes a falhas e é pouco provável que falhem simultaneamente. Como os domínios de disponibilidade não compartilham a infraestrutura física, como energia ou resfriamento, ou a rede de domínio de disponibilidade interna, é improvável que a falha em um domínio de disponibilidade afete a disponibilidade de outros domínios.
O domínio de falha é um agrupamento de hardware e infraestrutura em um domínio de disponibilidade. Cada domínio de disponibilidade contém três domínios de falha. Os domínios de falha permitem distribuir suas instâncias de forma que não fiquem no mesmo hardware físico em um único domínio de disponibilidade. Como resultado, uma falha inesperada de hardware ou uma manutenção de hardware de computação que afeta um domínio de falha não afeta as instâncias em outros domínios de falha.
Todos os domínios de disponibilidade em uma região são conectados uns aos outros por uma rede de baixa latência e alta largura de banda. Essa interconexão previsível e criptografada entre domínios de disponibilidade fornece os elementos básicos para a alta disponibilidade e a recuperação de desastres.
Você pode projetar soluções em várias regiões, vários domínios de disponibilidade ou vários domínios de falha, dependendo da classe de falhas da qual deseja se proteger.
A OCI oferece diversos recursos e você pode fazer diversas escolhas para proteger seus recursos de rede, sistemas de armazenamento e recursos de banco de dados contra falhas localizadas. O Manual de Soluções de Alta Disponibilidade do OCI Architecture Center é um excelente ponto de partida. Consulte-o para fazer escolhas de acordo com o seu modelo operacional.
Recuperação de Desastres
Desastre pode ser qualquer evento que coloque seus aplicativos em risco, desde interrupções na rede a falhas em equipamentos e desastres naturais. Um plano de recuperação de desastres (DR) bem arquitetado permite que você se recupere rapidamente de desastres e continue a fornecer serviços aos usuários. Os recursos de DR da OCI se baseiam nos recursos abrangentes de HA discutidos na seção anterior.
Ao planejar sua estratégia de DR, você deve primeiro considerar seu RTO (Recovery Time Objective) e seu RPO (Recovery Point Objective). O RTO é o tempo limite para a restauração de um aplicativo após um desastre. Geralmente, quanto mais crítico o aplicativo, menor o RTO. O RPO é o período após um desastre no qual um aplicativo pode tolerar a perda de dados antes que o desastre comece a afetar os negócios.
Em seguida, você deve determinar o tipo de cenário de desastre do seu projeto. Você está tentando se proteger contra falhas de aplicativo, falha de rede, falha de data center, interrupções regionais ou todas essas opções? A resposta a esta pergunta, combinada com suas resoluções de RTO/RPO, direcionará sua estratégia de DR.
A OCI fornece orientação para a criação de arquiteturas tolerantes a desastres nos níveis de computação, rede, armazenamento, aplicativo e banco de dados. Você pode usar essas ferramentas a fim de criar uma arquitetura ativa-ativa em seus aplicativos funcionem simultaneamente em duas regiões e uma falha na região "a" possa ser tratada pela região "b", um cenário de backup a quente em que uma região secundária seja preparada e esteja pronta para assumir o tráfego em caso de falha da região primária, um cenário de backup a frio em que uma combinação de etapas manuais e/ou automatizadas possa ser necessária para restaurar as operações de negócios ou alguma combinação dessas opções.
O Manual de Soluções de Recuperação de Desastres do OCI Architecture Center é um excelente ponto de partida. Consulte-o para fazer escolhas de acordo com o seu modelo operacional.
Orçamentos e Cotas
Como um ISV que executa um aplicativo de SaaS que usa os compartimentos da OCI para isolamento, você pode considerar alguns primitivos relacionados a fim de ajudar você - e seus clientes - a gerenciar melhor os recursos. Cada tenancy da OCI normalmente vem pré-configurado com determinado limite anual em dólares. Embora o consumo excedente não gere penalidades, a maioria dos ISVs gosta de manter um rigoroso controle da utilização dos recursos.
Os ISVs devem começar analisando as cotas de compartimento como uma ferramenta para dividir os recursos de todo o tenancy em vários compartimentos dele. Usando esse primitivo, recursos comuns, como CPUs e blocos de armazenamento, ou recursos mais especializados, como GPUs e Exadatas, podem ser alocados em compartimentos para garantir que nenhum tenant receba uma alocação de recursos exagerada e que determinados recursos especializados sejam alocados nos lugares certos.
As cotas operam em recursos de nuvem. Ao controlar as alocações de dólares, os ISVs devem analisar os orçamentos da OCI. Esse recurso permite definir orçamentos de uso em cada compartimento e receber alertas quando um orçamento está se aproximando de um limite flexível ou excedeu um limite máximo. O uso desse recurso pode ajudar os ISVs a gerenciar seus gastos com vários clientes e ajudar a prever a necessidade de crescimento futuro de recursos.
Cobrança Retroativa
Embora cada ISV defina o preço de seu serviço de SaaS de forma diferente, uma entrada comum em muitos modelos de preços é o conceito de custo das mercadorias vendidas (COGS). Sem saber quanto você gasta para criar e entregar um produto, é difícil saber como definir um preço justo e como variar esse preço entre diferentes consumidores.
O serviço de SaaS tem muitos custos associados, incluindo custos de engenharia e de marketing, mas o custo de hospedagem na nuvem é um componente-chave. Nessa questão, a Análise de Custo da OCI pode ajudar fornecendo visualizações dinâmicas de uso em seus tenants de clientes segmentadas por compartimentos e/ou tags de rastreamento de custos. O uso dessas ferramentas pode ajudar a entender quanto você está gastando para hospedar cada um de seus clientes e orientar quanto à necessidade de ajustar o preço cobrado deles.
Se você precisar de dados mais granulares do que os apresentados pelas visualizações, poderá exportar os dados de uso totalmente granulares em um formato legível por máquina para análise posterior usando a ferramenta que desejar. Ao operar em um ambiente de nuvem híbrida, você terá liberdade para usar uma ferramenta multinuvem de terceiros, como a CloudHealth, a fim de fazer uma análise unificada.
Automação da Infraestrutura
Pouquíssimas organizações criam seus ambientes manualmente. Os ISVs, em especial, reconheceram o valor da orquestração de infraestrutura e do gerenciamento da configuração por meio do uso de ferramentas de Infraestrutura como Código (IaC), como Terraform, Ansible, Puppet etc. Embora a IaC seja ideal, independentemente do tamanho, da cobertura técnica ou da abordagem de implementação da sua organização, ela é particularmente crítica para ISVs em desenvolvimento que estão constantemente expandindo sua presença regional e sua base instalada. Sem automação, sua sobrecarga de manutenção aumenta exponencialmente e se torna difícil de gerenciar.
A OCI fornece suporte para uma série de ferramentas de automação padrão do setor que permitem implementar uma estratégia de automação neutra em nuvem. Isso inclui suporte via produto para HashiCorp Terraform, Ansible e Chef. Como a OCI expõe todas as suas funcionalidades por meio de SDKs e de CLI, a integração com outras ferramentas, como o Puppet, é muito fácil.
Além disso, a OCI se baseia nos recursos do Terraform oferecendo um serviço gerenciado chamado Gerenciador de Recursos. Esse serviço, oferecido gratuitamente aos clientes da OCI, permite que o Terraform seja executado dentro dos limites do modelo de segurança baseado em políticas da OCI e fornece gerenciamento de estado, modelos, descoberta de recursos e integração GitHub/GitLab prontos para uso.
Automação do Ciclo de Vida do Software
Os ISVs usam ferramentas automatizadas de criação e implementação para mover o código pelo ciclo de vida de desenvolvimento de software. Ao considerar um modelo de entrega de tenant único, a automação avançada se torna ainda mais importante, porque uma única implementação pode ser entregue a centenas de instâncias de tenant. Além disso, essas implementações geralmente devem ser realizadas de forma contínua para eliminar o tempo de inatividade e devem ser flexíveis o suficiente a fim de permitir personalizações baseadas em filiais específicas para clientes individuais.
A OCI é compatível com a maior parte das principais ferramentas de CI/CD disponíveis no mercado. Esteja você usando Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI ou outras ferramentas, há alguém no ecossistema de software que provavelmente está usando sua ferramenta preferida com a OCI.
Além disso, a OCI oferece um Serviço DevOps, uma plataforma completa e fácil de usar de integração contínua e entrega contínua (CI/CD) para desenvolvedores. Os ISVs podem usar esse serviço para criar, testar e implementar software de forma fácil na OCI, bem como gerenciar o código de origem com repositórios Git privados e hospedados.
Conclusão
A Oracle reconhece que cada ISV traz consigo uma história de origem, um ambiente de origem, uma arquitetura técnica, um modelo de implementação, bem como requisitos técnicos e de negócios únicos. Não existe uma abordagem genérica de migração para a Oracle Cloud Infrastructure (OCI) que considere todos esses fatores exclusivos e tenha eles em mente ao aproveitar os recursos da OCI.
Um componente-chave da nossa abordagem de alto nível para a migração de ISVs é a combinação do nosso processo de interação, que reúne arquitetos, consultores de negócios e engenheiros especializados com o objetivo de ajudar a projetar sua solução de nuvem, e o uso de Cloud Lift Services, para trabalhar lado a lado com você com o objetivo de trazer sua carga de trabalho para a OCI.
O diferencial da Oracle para os ISVs é nossa disposição e nosso desejo de interagir individualmente com os clientes nas camadas estratégica, de entrada no mercado (GTM), arquitetônica e de implementação, bem como a interação de nossos especialistas com os seus para o cumprimento conjunto dos seus requisitos na nuvem.