Em busca de agilidade, muitos buscam distanciar infraestrutura de banco de dados. Esta não é uma boa ideia
A maioria das equipes de desenvolvimento e implantação agora funciona melhor do que antes da computação em nuvem. A ascensão de agile e devops/devsecops definiu a estrutura para equipes de ops e dev trabalharem mais próximas. Dev agora funciona bem com ops e vice-versa.
No entanto, estou percebendo algumas falhas no sistema. Ou seja, os designers de banco de dados em nuvem que trabalham com bancos de dados nativos e não nativos na nuvem não parecem estar sincronizados com os designers/arquitetos de infraestrutura que fornecem recursos importantes para um banco de dados em nuvem, incluindo armazenamento e computação.
Isso resulta em alguns resultados ruins.
Primeiro, os bancos de dados ficam sem recursos enquanto executam o processamento do negócio principal. Em muitos casos, ele é corrigido depois que uma mensagem de aviso aparece no console de alguém, mas ainda desliga os bancos de dados por um tempo, e essas transações de negócios importantes vão embora.
Em segundo lugar, é uma interrupção total. O banco de dados fica sem recursos durante o processamento e simplesmente para de funcionar sem aviso. Isso pode até corromper o banco de dados, o que significa que você é tão bom quanto o último backup.
O problema é que todos os bancos de dados hospedados em nuvem não são iguais, mas os engenheiros de infraestrutura em nuvem pensam que sim. Alguns bancos de dados podem alocar automaticamente seus próprios recursos e exigir apenas que alguém pague a conta no final do mês (sem servidor). A maioria exige que os responsáveis pela infraestrutura tenham algum conhecimento do banco de dados, incluindo o número, a quantidade e o tipo de armazenamento necessário; crescimento do banco de dados; uso de um cache de dados; requisitos de tamanho e tipo de CPU; etc.
Se você acha que isso se parece muito com a configuração e o dimensionamento de servidores para bancos de dados locais, você está certo. Muitos desses bancos de dados populares e tradicionais ainda não sabem se são executados no local ou na nuvem pública. O processo de dimensionamento de sistemas para bancos de dados específicos e suposições de uso são praticamente os mesmos.
Nós sabemos como resolver este problema. O problema surge quando é hora de realmente fazer isso. As comunicações geralmente são interrompidas entre aqueles que projetam, configuram e implantam um banco de dados baseado em nuvem e aqueles com as chaves para os recursos que o banco de dados requer. As interrupções evitáveis do banco de dados acontecem mais do que deveriam e isso impacta negativamente os negócios.
A correção é fácil. Inclua uma etapa no processo de desenvolvimento e operações em que as pessoas que selecionarão e implantarão um determinado banco de dados comunicam os requisitos detalhados às pessoas que alocarão, dimensionarão e configurarão quaisquer recursos de que o banco de dados específico possa precisar. Este também é o momento de tratar da segurança, governança e gerenciamento do banco de dados, e isso requer conversar com outro grupo dentro da empresa.
Aqui está minha solução (desculpe, pessoal do banco de dados): Os administradores de banco de dados e administradores de infraestrutura acreditam que a comunicação deva ser simbiótica entre as duas partes. No entanto, os responsáveis pela implementação do banco de dados precisam prestar mais atenção à infraestrutura e ser mais proativos.
Os dias de excesso de capacidade de processamento e armazenamento em um data center acabaram. É um ato de equilíbrio trazer apenas os recursos de que você precisa e fazer isso sem nunca ficar sem recursos. Isso cai nas mãos do pessoal de banco de dados, com o apoio do pessoal de infraestrutura em nuvem.
O pessoal de banco de dados precisa se tornar muito mais informado sobre o funcionamento interno de seus hosts de nuvem pública. A nuvem pública e os bancos de dados locais não se misturaram quando o banco de dados local ficou no corredor. Agora precisamos misturá-los.
