[ETP] Impactos nos sistemas com a migração de dados para o Postgres

1. Introdução

Este estudo tem por objetivo a análise de impacto de migração para o banco de dados Postgres nos sistemas: PPE, SISCAB, AGENDAMENTO PPE, PENTAGONO, SISNE e GDOP. Será abordado qual o esforço para migrar os sistemas do banco de dados SQL Server para Postgres, quanto tempo levaria para a migração ser realizada e se há algum impedimento para que a migração não seja viável.

2. Desenvolvimento

Os sistemas: PPE, SISCAB, AGENDAMENTO PPE, PENTAGONO, SISNE e GDOP atualmente utilizam banco de dados SQL SERVER e como linguagem de programação o C#. Para um melhor entendimento do cenário atual é necessário se abordar os custos das licenças atuais para manter o SQL Server atualizado. No site (https://www.microsoft.com/pt-br/sql-server/sql-server-2019-pricing) é possível observar os impactos financeiros para se possuir uma versão atualizada do produto da microsoft:

Edições	Preço Open No Level (US$)	Modelo de licenciamento	Disponibilidade do canal
Enterprise	$13, 748[1]	Pacote de 2 núcleos	Licenciamento por volume, hospedagem
Standard - por núcleo	$3,586[1]	Pacote de 2 núcleos	Licenciamento por volume, hospedagem
Standard - servidor	$899[1]	Server[2]	Licenciamento por volume, hospedagem
Standard - CAL	$209	CAL	Licenciamento por volume, hospedagem
Desenvolvedor	Gratuito	Por usuário	Download gratuito
Web	Consulte seu parceiro de hospedagem para saber o preço	Não aplicável	Somente hospedagem
Express	Gratuito	Não aplicável	Download gratuito

Fonte: Microsoft

Considerando que o presente Estudo Técnico Preliminar (ETP) foi desenvolvido pelo time de desenvolvimento CAVEIRAS, o qual não possui acesso a ferramentas como Banco de Preços para realização de estimativa de economia, compreendemos que não seja possível chegar aos valores exatos dos custos das licenças atuais para se abordar o cenário atual. No entanto, após vislumbrar os custos de venda no site da microsoft das licenças atualizadas, fica observável o quanto manter as licenças do SQL Server pode trazer gastos que podem ser potencialmente economizados, visto que no erário público o ideal é sempre se prezar por atingir a eficácia, eficiência, efetividade e economicidade no âmbito do poder executivo estadual.

Desde sua criação a SETIC busca, conforme encontra-se definido em sua missão, “Promover, em benefício do cidadão, o desenvolvimento de soluções inovadoras em TIC aos poderes públicos e à sociedade do Estado de Rondônia”. O lema definido para a visão estratégica não deixa dúvidas do que se almeja: “Tornar o Estado de Rondônia uma referência em Tecnologia da Informação e Comunicação – TIC na Região Norte”.

Como órgão executor das Políticas de Tecnologia da Informação e Comunicação do Governo de Rondônia, é a responsável também por manter os diversos Sistemas e Bancos de Dados que se encontram sob sua responsabilidade.

Como resultados pretendidos, segue uma lista com alguns sites hospedados nos servidores da SETIC e uma lista com órgãos que armazenam ou trafegam dados através da estrutura da SETIC.

Inicialmente é importante ressaltar a necessidade de verificar as compatibilidades tecnológicas decorrentes da mudança de banco de dados, pois há uma diversidade de tecnologias trabalhadas na SETIC. Este estudo terá por escopo somente as aplicações desenvolvidas em C# utilizando o framework Asp.net Core para desenvolvimento web.

O time de desenvolvimento CAVEIRAS atualmente trabalha com o Entity Framework Core que pode ser definido como um mapeador de banco de dados. No site oficial da microsoft (https://docs.microsoft.com/pt-br/ef/core/) é possível ter acesso para uma definição mais acertiva do que seria o Entity Framework:

O EF (Entity Framework) Core é uma versão leve, extensível, de software livre e multiplataforma da popular tecnologia de acesso a dados do Entity Framework.

EF Core pode servir como um mapeador relacional de objeto (O/RM), que:

• Permite que os desenvolvedores do .NET trabalhem com um banco de dados usando objetos .NET.
• Elimina a necessidade de maior parte do código de acesso a dados que normalmente precisa ser gravado.

O EF Core é compatível com vários mecanismos de banco de dados, consulte detalhes em Provedores de Banco de Dados.

Fonte: Microsoft

Conceituado os termos acima descritos, o problema inicial a ser verificado é a compatibilidade dos provedores de banco de dados com o Entity Framework e validar se o Postgres está listado e habilitado para uso. No site oficial da  microsoft (https://docs.microsoft.com/pt-br/ef/core/providers/?tabs=dotnet-core-cli) fica disponível a lista de todos os provedores compatíveis:

Provedores atuais

 Importante

Os provedores do EF Core são criados por uma variedade de origens. Nem todos os provedores são mantidos como parte do Projeto do Entity Framework Core. Ao considerar um provedor, avalie a qualidade, o licenciamento, o suporte etc. para garantir que ele cumpra os seus requisitos. Examine também a documentação de cada provedor para obter informações detalhadas de compatibilidade de versão.

 Importante

Os provedores do EF Core normalmente funcionam em versões secundárias, mas não em versões principais. Por exemplo, um provedor lançado para o EF Core 2.1 deve funcionar com o EF Core 2.2, mas não funcionará com o EF Core 3.0.

PROVEDORES ATUAIS

Pacote NuGet	Mecanismos de banco de dados com suporte	Mantenedor / fornecedor	Notas / requisitos	Criado para a versão	Links úteis
Microsoft.EntityFrameworkCore.SqlServer	SQL Server 2012 em diante	Projeto EF Core (Microsoft)		5.0	docs
Microsoft.EntityFrameworkCore.Sqlite	SQLite 3.7 em diante	Projeto EF Core (Microsoft)		5.0	docs
Microsoft.EntityFrameworkCore.InMemory	Banco de dados em memória do EF Core	Projeto EF Core (Microsoft)	Limitações	5.0	docs
Microsoft.EntityFrameworkCore.Cosmos	API do SQL do Azure Cosmos DB	Projeto EF Core (Microsoft)		5.0	docs
Npgsql.EntityFrameworkCore.PostgreSQL	PostgreSQL	Equipe de desenvolvimento do Npgsql		5.0	docs
Pomelo.EntityFrameworkCore.MySql	MySQL, MariaDB	Pomelo Foundation Project		5.0	Leiame
MySql.EntityFrameworkCore	MySQL	Projeto MySQL (Oracle)		5.0	docs
Oracle.EntityFrameworkCore	Oracle Database 11.2 em diante	Oracle		5.0	site
Devart.Data.MySql.EFCore	MySQL 5 em diante	DevArt	Pago	5.0	docs
Devart.Data.Oracle.EFCore	Oracle Database 9.2.0.4 em diante	DevArt	Pago	5.0	docs
Devart.Data.PostgreSql.EFCore	PostgreSQL 8.0 em diante	DevArt	Pago	5.0	docs
Devart.Data.SQLite.EFCore	SQLite 3 em diante	DevArt	Pago	5.0	docs
FirebirdSql.EntityFrameworkCore.Firebird	Firebird 3.0 em diante	Jiří Činčura		5.0	docs
EntityFrameworkCore.Jet	Arquivos do Microsoft Access	Bubi		3.1	Leiame
IBM.EntityFrameworkCore	Db2, Informix	IBM	Pago, Windows	3.1	site do cliente
IBM.EntityFrameworkCore-lnx	Db2, Informix	IBM	Pago, Linux	3.1	site do cliente
IBM.EntityFrameworkCore-osx	Db2, Informix	IBM	Pago, macOS	3.1	site do cliente
Teradata.EntityFrameworkCore	Banco de dados Teradata 16.10 em diante	Teradata		3.1	site
FileContextCore	Armazena dados em arquivos	Morris Janatzek	Para fins de desenvolvimento	3.0	Leiame
EntityFrameworkCore.SqlServerCompact35	SQL Server Compact 3,5	Erik Ejlskov Jensen	.NET Framework	2.2	wiki
EntityFrameworkCore.SqlServerCompact40	SQL Server Compact 4.0	Erik Ejlskov Jensen	.NET Framework	2.2	wiki
EntityFrameworkCore.OpenEdge	Progress OpenEdge	Alex Wiese		2.1	Leiame

Fonte: Microsoft

Visto que dentre os provedores está disponível o Postgres (Npgsql), então seguindo o que se orienta no site oficial (https://www.npgsql.org/efcore/index.html), fica possível realizar a conversão da aplicação em .NET para uma base de dados Postgres.

Após a conclusão do procedimento de converter o banco de dados de uma aplicação desenvolvida em C#, vem agora o procedimento de migração manual de dados, que pode ser um processo dispendioso para a equipe como um todo, pois o número de sistemas a serem migrados e o tamanho de suas bases de dados é grande.

Uma ferramenta de migração de banco de dados deve solicitar que o usuário selecione os objetos a serem migrados, como tabelas, índices, restrições de chave primária e estrangeira. Existem ferramentas que podem automatizar o trabalho manual, serão apresentados dois exemplos:

1. pgloader  é  uma ferramenta de código aberto bem conhecida que importa dados do SQL Server para o Postgres usando o comando COPY, carrega dados, índices e chaves estrangeiras e converte dados para Postgres conforme pretendido.

1. pgloader carrega dados de várias fontes como MS SQL, SQLite, MySQL, CSV em PostgreSQL.

2. Ele é licenciado sob a licença PostgreSQL e de uso gratuito.

3. pgloader é um software multiplataforma.

4. A imagem do Docker está disponível.

2. Sqlserver2pgsql  é escrito em Perl. Esta é outra ferramenta de migração de código aberto para automatizar a conversão do banco de dados Microsoft SQL Server para o banco de dados Postgres.

1. Ele converte um esquema SQL Server em um esquema Postgres

2. Se desejar, pode criar um console Pentaho Data Integrator (Kettle) para migrar todos os dados do SQL Server para Postgres.

Para estimativa de tempo de migração é necessário considerar e diferenciar os processos, são eles os principais: Avaliação, planejamento da migração dos sistemas, migração de teste, testes, migração final e transferências. A imagem a seguir ilustra este processo em ordem de execução:

Fonte: SETIC/GOV-RO

Após análise técnica do time de desenvolvimento CAVEIRAS, foi possível chegar aos dados quantitativos estimados com relação ao tempo envolvido em cada processo logo abaixo:

Fonte: SETIC/GOV-RO

Portanto, com base nas estimativas levantadas conclui-se a respeito do tempo de migração que para o melhor cenário será o total de 19 dias de trabalho e 42 dias de trabalho para o pior cenário, reforça-se que esse tempo inclui o fator de planejamento e execução técnica.

A maioria dos impedimentos de migração de dados pode ser atribuída à confusão em torno do plano de migração (se houver um em vigor) e à falha em se preparar adequadamente para a mudança. A mudança de banco de dados e migração de dados entre o SQL Server e Postgres pode ser extremamente complexa a depender da estrutura a ser migrada. Quando os técnicos responsáveis ​​por fazer essas mudanças não conseguem inventariar sistemas e dados, subestima o tempo e esforços necessários e não identifica quais recursos serão necessários no ambiente de destino, o procedimento pode se tornar um problema.

O desenvolvimento de um plano abrangente de migração de dados deve ser sempre a primeira etapa em qualquer transferência de tecnologia. Isso não só estabelece o escopo e os objetivos, mas também desenvolve o cronograma de sua execução e identifica as pessoas que serão responsáveis ​​pelo procedimento. O plano destaca áreas com problemas potenciais com antecedência para que os riscos possam ser mitigados de forma eficaz antes que inviabilizem o projeto e atrase a implementação.

Quando tantos dados estão sendo transferidos de um local para outro, sempre há a possibilidade de alguns desses dados serem perdidos. Alguma quantidade de perda de dados pode não ser consequente, especialmente se for “desnecessário” ou outros dados “não essenciais” que não serão perdidos. Da mesma forma, alguns dados perdidos podem ser facilmente restaurados de arquivos de backup. Mas alguns tipos de perda de dados são muito mais problemáticas.

Mesmo ignorando o desastre potencial de perda de informações confidenciais ou privadas que precisam ser protegidas, a perda de dados pode criar um efeito cascata que encerra partes do processo de migração. Se a perda de dados escapar da atenção da equipe técnica, ninguém perceberá que dados essenciais estão faltando até que um aplicativo trave devido à falta de dados.

Então a solução viável é: Nenhum dado essencial deve ser retirado de seu ambiente atual sem fazer backup em algum lugar. Isso permite a equipe técnica reverta elementos da migração no caso de ocorrer um problema. Em alguns casos, isso pode ser feito facilmente com imagens de backup armazenadas em um sistema existente ou externo. Para dados críticos que precisam permanecer disponíveis durante a migração, os ambientes swing e paralelo podem ser configurados para garantir a continuidade dos serviços. 

Transferir dados e aplicativos de um ambiente para outro é teoricamente um processo simples, mas, na prática, pode ser mais complexo. Isso pode criar alguns problemas de compatibilidade no futuro devido à má otimização. Alterar os bancos de dados dos sistemas desenvolvidos na SETIC pode tornar alguns arquivos inacessíveis porque eles não estão mais em um formato legível. Os controles de acesso podem não fazer uma transição suave do ambiente de origem para o sistema de destino, deixando os técnicos incapazes de acessar os principais aplicativos quando precisam. Em um cenário de pior caso absoluto, todo o sistema pode travar assim que for removido de seu ambiente legado.

Qualquer plano completo de migração de dados deve incluir uma avaliação detalhada dos requisitos operacionais do sistema atual e como eles devem ser adaptados ao novo ambiente. Migrar tudo primeiro e esperar para lidar com quaisquer problemas de compatibilidade que surjam depois não é apenas uma falha no planejamento, está planejando falhar. Todos os requisitos do sistema devem ser documentados com antecedência e monitorados de perto ao longo do processo. Somente após a execução de testes completos no novo sistema para validar seu desempenho, o sistema antigo deve ser encerrado. 

Os problemas de compatibilidade de software são complicados o suficiente, mas às vezes o ambiente de destino simplesmente não é capaz de lidar com a quantidade de dados e aplicativos que estão sendo migrados. Embora superestimar a capacidade possa levar ao desperdício desnecessário (e caro). Sempre há o cenário de pesadelo de um servidor ser danificado durante a transferência para um novo local.

Finalizando o contexto, qualquer software de banco de dados legado que está sendo migrado deve ser verificado exaustivamente após a instalação. Em muitos casos, este software pode ter problemas de otimização de desempenho em alguns pontos do sistema ou simplesmente acabar evidenciando um problema de compatibilidade.

3. Conclusão

O presente ESTUDO TÉCNICO PRELIMINAR, elaborado pelos integrantes TÉCNICOS do time CAVEIRAS, considerando a análise dos desafios técnicos envolvidos e citados, conclui pela VIABILIDADE DA MIGRAÇÃO DE DADOS PARA O POSTGRES DE MODO CRITERIOSO, uma vez que foram considerados os potenciais benefícios em termos de eficiência, economicidade e também os riscos envolvidos. Em complemento, os riscos identificados são administráveis, pelo que RECOMENDAMOS o prosseguimento da migração. Ressalva-se que  a RECOMENDAÇÃO é de cunho unitário, ou seja, o processo deve ser feito em apenas um sistema por vez, pois os riscos já foram levantados e é necessário de considerar que caso ocorra uma falha no procedimento, poderá resultar em tempo de inatividade para aplicativos críticos de atividades essenciais garantidas pela SETIC, o que pode causar impactos reais. Qualificar e/ou treinar a equipe técnica e elaborar um plano de migração é a maneira ideal de superar esses obstáculos e aumentar as chances de sucesso.