Construir ou comprar monitoramento de bancos de dados

Construir ou comprar monitoramento de bancos de dados

Existem muitas decisões na vida em que nos perguntamos se devemos "construir ou comprar". Uma casa nova, por exemplo. Uma empresa. Um aplicativo. Independentemente do assunto da discussão, a resposta a algumas perguntas iniciais pode ajudar a orientá-lo rumo à solução certa.

Dada a crescente importância, complexidade e amplitude dos sistemas de bancos de dados, é fundamental responder à pergunta "o que devo fazer: construir ou comprar monitoramento de banco de dados?". Agora, como profissional de software, preciso esclarecer que não estou defendendo uma opção em detrimento da outra. Em vez disso, quero deixar claro que existem bons casos de uso para ambas as abordagens e oferecer uma estrutura que ajude a determinar qual abordagem é certa para você.

Comece se fazendo estas quatro importantes perguntas:

  • Quais são os requisitos? Quais são os elementos "essenciais" e os elementos "desejáveis"?
  • Existe alguma solução comercial que atenda a pelo menos os requisitos mínimos?
  • Há alguma vantagem tangível específica a ser obtida com a construção em comparação com o que está disponível comercialmente?
  • Qual é o custo total de propriedade (TCO) das opções de construir e de comprar?

Vamos nos aprofundar um pouco mais em cada uma dessas áreas.

Requisitos

O primeiro passo é obter informações de todos os grupos de interesse que utilizarão os dados do monitoramento ou que precisarão agir com relação aos alertas. Isso inclui, no mínimo, DBAs, desenvolvedores e responsáveis por aplicativos, mas também pode estender-se a outras funções, como administradores de sistemas, armazenamento ou virtualização.

Sua meta é entender quais dados são necessários a cada um, como esses dados serão usados e como o monitoramento de dados permitirá que as decisões certas sejam tomadas. Ao definir esses requisitos, seja o mais cuidadoso e detalhista possível. Seja realista em relação aos itens "essenciais" e tente não incluir itens que não sejam indispensáveis. E não deixe de levar em conta as práticas recomendadas.

A solução já existe?

Depois de definir os requisitos, é hora de começar a jornada. Uma pesquisa rápida no Google® provavelmente resultará em várias alternativas a serem levadas em consideração. Considere o seguinte:

  • Recursos que correspondam aos requisitos
  • Testemunhos e avaliações de clientes
  • Satisfação com o produto e o suporte
  • Pontos fortes e fracos específicos da solução de monitoramento

Além da pesquisa acima, avaliações podem ser uma boa opção. Todos os principais itens devem estar presentes, mas um "test drive" das diferentes soluções possíveis pode ajudar muito na determinação da melhor opção. É provável que essa fase envolva a implantação do produto em seu ambiente, que é uma grande oportunidade para, observando o produto em cenários do mundo real, obter informações adicionais que possam ter passado despercebidas durante sua pesquisa. Restringir a avaliação a dois a quatro candidatos pode economizar tempo e poupar esforços.

Vantagem competitiva

Determinar se haverá alguma vantagem competitiva na construção de um software de monitoramento pode ser um pouco nebuloso. Em geral, as ferramentas de monitoramento de bancos de dados dos principais fornecedores de RDBMS são bastante conhecidas. É provável que somente os bancos de dados sem uma base de instalação significativa não tenham disponível uma solução de monitoramento comercial pronta para uso. Ainda assim, se não encontrar uma solução que atenda aos seus critérios mínimos, talvez você precise passar para o cenário da construção. Na verdade, muitas empresas startup resultaram de necessidades não atendidas por produtos comerciais prontos para uso.

Custo total de propriedade (TCO)

Na minha experiência, comprar licenças perpétuas de produtos comerciais costuma ser bastante simples. Os custos a serem levados em conta são o preço de tabela, o preço inicial de compra/negociado (geralmente um percentual do que está na tabela) e o custo de manutenção (normalmente algo em torno de 20% do preço de tabela ao ano).

O custo total de propriedade (TCO) da construção de uma solução é um pouco mais ambíguo, mas ainda pode ser estimado. Os custos a serem levados em conta incluem desenvolvimento do produto, integração potencial com outras tecnologias, segurança, administração, custo de oportunidade durante o desenvolvimento (associado ao não monitoramento) e manutenção do produto quando novos drivers/versões forem lançados para os RDBMSs visados. Como o desenvolvimento de software é relativamente imprevisível, um fator de contingência de pelo menos 20% deve ser incorporado ao custo de retrabalho, correção de bugs, ajustes de curso etc. Caso você tenha sorte durante o desenvolvimento, a redução no custo poderá fluir diretamente para o resultado financeiro.

Conclusão

A decisão entre construir e comprar é fundamental. Usar esta estrutura ajudará você a tomar a decisão certa para o seu ambiente de banco de dados. Independentemente da decisão tomada, o mais importante é não ignorar a necessidade de entender melhor seu banco de dados e otimizá-lo, não apenas de acordo com as necessidades atuais da empresa, mas também de acordo com as necessidades futuras.

 

[author] [author_image timthumb='on']https://docmanagement.com.br/wp-content/uploads/2017/06/gerardo-dada-thumbnail.jpg[/author_image] [author_info]Gerardo Dada

Vice-presidente de marketing de produtos da SolarWinds[/author_info] [/author]

Share This Post

Post Comment