Os bancos de dados são a base de aplicativos e software. Eles também são um tanto invisíveis; como diz a língua franca do software, eles são o back-end, a implicação é que estão situados atrás ou debaixo de todo o resto.
Isso significa que, quando se trata de atualização, é fácil cair em uma de duas armadilhas: esquecer que eles estão lá ou sentir uma ansiedade intensa por estar mexendo em algo que não deveria tocar.
Este é um ponto levantado por David Stokes, evangelista de tecnologia da Percona, uma organização que fornece suporte e serviços para bancos de dados de código aberto.
“Parte da questão é que se está funcionando e (as equipes) não têm certeza sobre o que o banco de dados realmente faz ou como funciona, elas não querem mexer nele”, disse ele ao The New Stack.
Da mesma forma, ele acrescentou: “Quem retiraria algo da produção para atualizá-lo?” Se não voltar a tempo, quais serão as repercussões?”
A atitude, sugeriu ele, é tipicamente: “Está funcionando agora… por que tocá-lo?” Espere até que ele quebre.”
A questão da atualização dos bancos de dados é particularmente significativa no contexto de certas versões de bancos de dados de código aberto que atingem o fim de sua vida útil (EOL).
Em 2023, por exemplo, chegou o fim do MySQL 5.7, uma versão extremamente popular que já existia há quase uma década (foi lançada em 2015), PostgreSQL 11, Apache Cassandra 3 e MongoDB 6.3. Claro, quando um software está sendo ‘aposentado’ (por falta de um termo melhor), normalmente há novas versões nas quais um fornecedor ou comunidade decidiu investir sua energia – MongoDB 7.0 foi lançado em agosto de 2023, PostgreSQL 16 em setembro de 2023 e Apache Cassandra 5 em novembro de 2023.
Para muitas equipes, o EOL representa um precipício. Isso significa que o software não será mais corrigido e atualizado, abrindo um risco ainda maior de problemas de segurança e, potencialmente, também de desempenho.
É claro que a documentação não será mantida e qualquer suporte (se houver alguma coisa) desaparecerá completamente. Em alguns casos, pode ser um problema de conformidade – no mundo dos pagamentos, por exemplo, as organizações certificadas pelo PCI-DSS – aquelas que precisam cumprir os padrões de segurança de dados da indústria de cartões de pagamento – devem implantar quaisquer patches críticos no máximo um mês. depois de serem libertados.
Jan Wieremjewicz, gerente sênior de produtos da Percona, relembra a violação de segurança do Log4J. “Imagine rodar em software em fim de vida que não é corrigido para excluir possíveis explorações de Zero Day”, disse ele ao The New Stack. “Fico arrepiado no momento em que penso nisso!”
Os riscos de não atualizar as bases de dados são substanciais. Em essência, o que deveriam ser as bases robustas dos vossos sistemas mais amplos tornam-se um passivo, uma bomba-relógio que pode inviabilizar o que parece funcional e estável a qualquer momento.
Mas também é importante notar que o lançamento de novas versões — especialmente lançamentos importantes — pode representar oportunidades para equipes de engenharia. Considere os novos recursos e a experiência aprimorada que são habituais quando qualquer software é lançado. Embora parte disso possa ser descartado como campanha publicitária de marketing, é importante reconhecer que não atualizar pode significar que você está perdendo uma maneira melhor de fazer as coisas.
Dados estes riscos substanciais, vale a pena aprofundar o sentimento de evitação (se não mesmo de medo) que caracteriza certas organizações. Um dos motivos destacados por Wieremjewicz é a mudança na composição das equipes de engenharia de software.
Os arquitetos de banco de dados “são uma raça em extinção”, disse ele – e estão sendo substituídos por engenheiros de confiabilidade de sites. “Há cada vez menos DBAs e cada vez mais SREs, que muitas vezes não são tão especialistas em problemas de banco de dados quanto os DBAs.”
Isto é em parte, sugeriu ele, um sintoma da ascensão do banco de dados como serviço (DBaaS) baseado em nuvem. Embora, por um lado, tenha simplificado muitos aspectos da configuração e do gerenciamento de bancos de dados, por sua vez, permitiu que a complexidade se espalhasse para outros lugares, enquanto as habilidades e as estruturas organizacionais evoluem de maneiras que não estão necessariamente equipadas para lidar com essa complexidade.
“Há alguns anos, passamos de um punhado de bancos de dados para milhares, se não mais, de bancos de dados”, diz Stokes. “Você ainda precisa de alguém para verificar as consultas e fazer o trabalho básico de higiene, certificando-se de que as contas estão corretas, as senhas, o software está atualizado, se está replicando corretamente, se as coisas estão sendo salvas. .”
Isso não é tangencial à questão das atualizações de banco de dados: destaca a essência do problema. Numa altura em que as bases de dados são tratadas como blocos de construção leves e não como âncoras pesadas e aparentemente inamovíveis, no preciso momento em que somos lembrados de que as bases de dados são coisas complicadas que requerem atenção e cuidado constantes, queremos fingir que simplesmente não podem ser tocadas, ou que eles são o problema de amanhã.
Poder-se-ia argumentar que a actualização de uma base de dados simplesmente não tem o apelo sexual (ou, mais especificamente, o valor comercial óbvio) que outros projectos têm. É muito “trabalho de higiene”, para usar a expressão de Stokes.
Ele explicou de outra maneira: “Um vice-presidente sênior chega e diz: ‘Ei, tenho uma ótima ideia para essa coisa nova que vamos fazer. Este é meu projeto favorito. Eu quero que você cuide disso. Você diz ‘Sim, mas o antigo sistema que gerencia o processo de inventário precisa de algumas atualizações’. ‘Sim, mas este é meu projeto favorito, eu realmente precisava disso.'”
Só há uma maneira de isso acontecer, argumentou Stokes – e não é a favor das atualizações.
“Atualizações de banco de dados são sempre complicadas”, disse ele, “porque são apenas mudanças sutis, mesmo nos melhores momentos. é preciso ler muito as notas de lançamento e, com sorte, fazer um ou dois testes, para ter certeza de que tudo funciona bem.”
Os bancos de dados de código aberto são particularmente desafiadores quando se trata de atualização. Você está quase sozinho, provavelmente dependente da comunidade contribuinte para obter documentação relevante e até mesmo suporte.
Nessas situações, a flexibilidade que um banco de dados de código aberto pode oferecer às equipes de engenharia torna-se um fardo. As equipes são prejudicadas por algo que não conseguem gerenciar facilmente por conta própria – mesmo os projetos de código aberto mais ativos não conseguem fazer muito quando se trata de apoiar as equipes em sua implementação específica.
É aqui que entra a Percona. Tudo começou há algum tempo, com Wieremjewicz contando a história de como o fundador Peter Zaitsev deixou o MySQL depois de trabalhar lá como desenvolvedor com a ambição de fornecer maior suporte aos usuários.
Embora o MySQL seja uma parte fundamental da história de origem da empresa, seu escopo abrange bancos de dados de código aberto de forma mais ampla. É provável que a equipe forneça suporte a empresas que usam PostgreSQL ou MongoDB, assim como MySQL.
Este agnosticismo de plataforma ou ferramenta pode ser vantajoso, por uma série de razões.
“Somos capazes de aconselhar sobre soluções – até mesmo sobre a mudança de um banco de dados para outro, de uma forma muito verdadeira e honesta, porque não estamos ganhando dinheiro, empurrando alguns softwares que criamos”, disse Wieremjewicz. “É literalmente para o benefício do usuário.”
No contexto específico da atualização de bancos de dados, o agnosticismo do fornecedor pode presumivelmente permitir que as organizações tenham a mente mais aberta ou até mesmo criativas na forma como abordam um problema de banco de dados. Claro, atualizar do MongoDB para o MongoDB pode fazer sentido, mas e se explorar um novo banco de dados fosse mais relevante para o seu contexto técnico específico?
É muito difícil tomar essas decisões sozinho, mesmo com a equipe mais experiente e aberta – aconselhamento externo e agnóstico pode ser imensamente valioso para fornecer o suporte necessário e impulsionar a mudança.
Não há como fugir do fato de que atualizar bancos de dados pode ser um desafio. O que é crucial é planejar e estar um passo à frente.
“Você tem que planejar com bastante antecedência, você não pode esperar que o fim da vida aconteça, você deve antecipar muito mais cedo”, disse Wieremjewicz.
Não fazer isso pode gerar problemas técnicos – e talvez comerciais – significativos que serão muito mais difíceis de corrigir no futuro.
Stokes não acredita que exista uma maneira correta de atualizar um banco de dados. A forma como isso será abordado dependerá, em última análise, da maturidade e da confiança da organização que realmente o executa.
“Esta é uma daquelas coisas que gostamos de aprender a andar de bicicleta”, disse ele. “Algumas pessoas saltam e fazem isso sozinhas – outras precisam de alguém para acomodar e firmar o assento enquanto você aprende como empurrar as pernas para cima e para baixo e como dirigir.”
Ele está convencido de que enquanto houver pessoas que precisem aprender sobre bancos de dados, a Percona continuará sendo valiosa para esses clientes: “Já estamos no mercado há tempo suficiente para saber onde contornar os buracos e evitar subir as colinas”.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
