dgmorales · February 8, 2022 19:35 · Feb 8, 2022 · Feb 8, 2022
diff --git a/recap oraex b/recap oraex
@@ -30,7 +30,7 @@ Observações:
 
 # Fase 0: Levantamento de opções
 
-Após a avaliação de alguma opções, a proposta de solução da Oraex foi a de uma solução
+Após a avaliação de algumas opções, a proposta de solução da Oraex foi a de uma solução
 customizada, envolvendo a criação de um ou mais operators.
 
 # Fase 1: Validação (POC da POC)

diff --git a/recap oraex b/recap oraex
@@ -0,0 +1,111 @@
+# Objetivo geral do projeto
+
+## Nosso objetivo, genericamente:
+
+Disponibilizar um database as service para nossos desenvolvedores, integrado ao nosso projeto de plataforma interna.
+
+A solução precisará suportar ao menos:
+- PostgreSQL
+- MongoDB
+- MS SQLServer
+
+... em configurações de alta disponibilidade, incluindo cenários on-prem (VMware) e Cloud
+(Azure/GCP).
+
+E de preferência ser expansível para outros bancos populares (Oracle, MySQL) e eventualmente/futuramente  outros mais
+específicos (ScyllaDB, Cassandra, e qualquer outro).
+
+## Nosso objetivo, contextualizado:
+
+Dado que nossa plataforma se baseia numa extensão da API do Kubernetes, queremos então:
+
+Disponibilizar a criação e operação de Databases (PgSQL inicialmente) a partir de manifestos Kubernetes YAML aplicados a um cluster Kubernetes.
+
+Observações:
+
+- O que interessa ao usuário é ter um database. Se será um cluster ou single instance, on-prem ou na nuvem, isso são detalhes de implementação dirigidos por inputs do usuário (algo como tier/sku/flavor).
+- Se tivermos a solução de uma API DBaaS genérica que suporta os bancos requisitados, o próprio time Stone pode absorver 100% do trabalho
+  de encapsular isso como um operator. Também poderia dividir ou delegar esse trabalho para a Oraex.
+
+
+# Fase 0: Levantamento de opções
+
+Após a avaliação de alguma opções, a proposta de solução da Oraex foi a de uma solução
+customizada, envolvendo a criação de um ou mais operators.
+
+# Fase 1: Validação (POC da POC)
+
+Apenas descobrir e validar o "como" chegar no objetivo com uma solução customizada como a
+proposta, sem se prender a detalhes de config do database, cluster, vms, etc.
+
+
+## Passo 1: Ansible (config OS) rodando de dentro de um operator 
+
+Colocar o código Ansible que vocês produziram (config de OS) para rodar a partir de um operator.
+
+Observações:
+
+- Ignorar a parte de criação da VM neste momento, apontar para uma VM fixa pré-criada
+- Sugiro não tentar envolver o Crossplane na solução neste momento, pois me parece que vai mais atrapalhar que ajudar
+- Dito isso, no entanto existe este issue no projeto Crossplane
+  https://github.com/crossplane/crossplane/issues/2703. Ele tem de certa forma um review de opções disponíveis, e me parece a partir dele que o Ansible Operator (projeto da Red Hat) talvez não seja uma alternativa pronta para esta implementação aqui.
+
+## Passo 2: Criação de VM + config a partir do operator
+
+Acrescentar a parte de criação de VM, rodando também a partir de um operator.
+
+Observações:
+
+- Não precisa ser o mesmo operator fazendo as duas tarefas (criação e config da VM). O Crossplane é capaz de juntar as duas coisas em um componente único, e deixar para ele essa tarefa é a alternativa que me parece mais simples.
+- Nesta fase de validação, pode ser utilizada uma API de Cloud (Azure, GCP. etc.) para criar a VM. No entanto seria já mais interessante usar a API da VMware, e existem soluções para validar isso dentro de uma cloud, como o https://azure.microsoft.com/en-us/services/azure-vmware (avaliar se o custo não é um absurdo)
+- É possível usar o Ansible também para a criação de VMs (e é assim que criamos VMs no VMware na Stone, inclusive). Isso provavelmente simplificaria a criação dos operators, já que não seria necessário dar outra solução para executar o terraform a partir de um operator.
+- Caso se mantenha o caminho do Terraform, checar com a Stone soluções para execução do Terraform por um operator. o Crossplane já provê alternativas para isso.
+
+
+## Passo 3: Criação + config de um cluster PgSQL, e não só um single instance
+
+Expandir para o cenário de cluster, para confirmarmos que ele não traz impeditivos adicionais.
+
+## Passo 4: O dia 2 -- validação de alguma tarefa operacional no Database
+
+Entender como iremos expressar e implementar operações_ad-hoc_/_one-off_ no database, tais
+como:
+
+- Execução de backup e restore pontuais
+- Failover para réplicas secundárias/slaves
+- Upgrade de sizing do banco
+
+
+Realizar uma implementação (poc) de ao menos 1 das tasks acima. Mas é preciso alcançar
+confiança de que as outras poderão ser expressas de alguma forma.
+
+## Passo 4: Avaliação
+
+Avaliar a solução que alcançamos. Pontos importantes de avaliação:
+
+- Como adicionaremos suporte ao SQLServer usando essa solução
+- Como faremos a integração com a plataforma/Crossplane
+- Robustez e qualidade **alcançável** (e não a atual) adotando esse caminho
+- Esforço de implementação da versão "real" adotando esse caminho
+
+## Passos 5, 6?
+
+Dependende da avaliação. Podemos por exemplo concluir que é melhor já testar a integração com
+Crossplane ou algo sobre o suporte a SQL Server, antes de passar para a implementação final.
+
+
+# Fase 2:
+
+Com base na experiência adquirida na fase 1, seguimos com a implementação real, ainda que
+inicial, da solução (para bancos PgSQL). Não vou quebrar em passos aqui, isso seria desdobrado
+após a avaliação da fase 1. Mas incluirá:
+
+- Definição do modelo de input do usuário
+- Refinamento e implementação das nossas best practices de banco
+- Refinar/refatorar código produzido até então
+- Adicionar configuração de monitoramento
+- Adicionar configuração de backup periódico
+- Integração na solução de plataforma da Stone.
+
+
+
No results found