Um único design, usado para todos os clientes. As diferenças específicas da nuvem — o produto de conectividade, o serviço principal, o mecanismo de banco de dados — são escolhas de configuração, não reformulações. É isso que torna um ambiente construível a partir de código em cinco dias úteis.
Lendo a imagem de cima para baixo.
- Usuários e integrações chegam a um único endereço, erp.<domínio do cliente>, e acessam um balanceador de carga com WAF via HTTPS, TLS 1.2 ou superior. Essa é a única forma pública de acesso.
- Pelo menos três nós de trabalho, um por zona de disponibilidade, executam a web e a API, o mecanismo de publicação, o operador ASK e os processos e tarefas. A perda de um nó ou de uma zona inteira deixa a capacidade ociosa, impedindo o atendimento aos usuários.
- O banco de dados gerenciado — com mecanismo e tamanho escolhidos pelo cliente — possui um servidor de espera síncrono em outra zona. Uma falha de zona não causa perda alguma: RPO ≈ 0.
- Os documentos e anexos ficam armazenados em um sistema de armazenamento de objetos versionado, e não no banco de dados.
- O tráfego de saída passa pelo NAT e é direcionado para uma lista de permissões: bancos, serviços fiscais e de faturamento eletrônico, folha de pagamento, e-mail e o mecanismo de IA. Nada mais.
- Os backups são enviados em uma única direção para um cofre isolado da internet em uma conta separada.
O endpoint privado e o balanceador de carga interno são representados por linhas tracejadas porque existem apenas quando o acesso privado é utilizado. Com acesso somente HTTPS, eles não são representados.
Cinco botões, e nada mais.
Tamanho do nó; número de nós, no mínimo três; mecanismo e tamanho do banco de dados; região de recuperação de Live DR; número de ambientes. Todo o resto é a arquitetura de referência.
Configure, integre e só então programe.
Um requisito que vai além do padrão é atendido por meio de configuração, se possível — atualizando-se com a plataforma. Caso contrário, é feita por meio de uma integração através das APIs da TRANXACT executadas fora do cluster. Somente então, após uma análise de segurança e engenharia, é considerado o uso de código ou um agente dentro do cluster; se aprovado, é tolerado e suportado pelo cliente; se rejeitado, é executado externamente.
Não há acesso direto ao banco de dados para o cliente — está marcado como não oferecido (DB_3.1.09). A geração de relatórios e a integração são feitas por meio de APIs e extrações da TRANXACT, e é por isso que uma ferramenta de BI se conecta por API ou extração agendada, nunca por login no banco de dados.
A equipe de BI da Calderwood solicitou um usuário de banco de dados com permissão somente leitura para seu data warehouse. A resposta foi uma extração agendada por meio de um link privado — a linha de BI na lista de interfaces deles está configurada como "manter, extração agendada, link privado".
Experimente Um nó de trabalho na zona 2 apresenta falha durante o fechamento mensal da Calderwood. O que acontece com os usuários e isso afeta o SLA?
Seus pods são reprogramados para os nós nas zonas 1 e 3, que foram dimensionados para suportar a carga; o banco de dados não é afetado, a menos que a zona 2 contenha o servidor primário, caso em que ocorre o failover para o servidor de espera síncrono com RPO ≈ 0. Ele só é contabilizado no SLA se a disponibilidade do mês não atingir a meta estabelecida.