recap oraex

# 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 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)

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.