Pontos a se considerar ao utilizar self-hosted

 estilo de vida

Classificaria este post como infra ou devops, mas com algumas mudanças ele pode se encaixar na vida das pessoas, de diversas formas… Como por exemplo, comprar ou não determinado modelo de carro, máquina de lavar. Por isso classifiquei como estilo de vida.

Alguns pontos abordados abaixo são uma visão sobre a utilização de self-hosted e é baseado nas minhas experiências com esse tipo de assunto. Em experiências com muitos softwares e versões diferentes. Por isso minha opinião não é sobre um único sistema, mas no geral, pode ser que não encontre nenhuma dificuldade, como pode ser que seja pior que a minha. Enfim, leia, tire suas conclusões baseado no que você precisa e não encare a minha opinião como absoluta, apenas como um ponto de vista para formar a sua.

Dito isto, vamos começar explicando que alguns projetos tem versões open source e uma enterprise. Pois bem:

  • Hosted: se trata da versão enterprise, que a empresa que desenvolve ou uma especializada oferece a plataforma em forma de serviço. Assim os clientes podem utilizar o software sem precisar se preocupar com manutenção.
  • Self-hosted: é versão open source, onde a empresa que deseja utilizar o software baixa, faz a instalação, configuração e cuida da manutenção por conta própria.

A primeira vista parece somente ponto positivo com muita coisa boa vindo junto, mas com o passar do tempo, se nota pontos que não são interessantes e isto só é possível, depois que boa parte das suas informações estão no software.

E tempo, não se compra, não se vende, apenas se aproveita da melhor forma possível. Sua importância é tanta, que ganhou um parágrafo apenas para ele.

Nota: uma coisa que levo comigo, é que as informações são minha e eu faço o que eu quiser. Partindo disso, procure soluções que possuam API’s ou modos de retirar toda sua informação dela através de código e migrar para outra importando através de código. Acredite, isso faz diferença e torna sua vida mais simples e migrável. A torna prática de certa forma.

Sem mais considerações, vamos aos pontos que encontrei e que gostaria de compartilhar.

Manutenção que vai ser gerada

Pode parecer que não, mas isso gera uma manutenção e se não observado o change log do projeto que está querendo usar, pode ser mais complexo do que imagina.

Acredite, se eles não manterem uma compatibilidade ou uma coerência nas atualizações, toda atualização pode ser que se tenha que executar um SQL de conversão de banco de dados ou uma migration, pode parecer mágico, mas migrations num cenário de atualização, existe muita chance de dar problema. Não é um cenário apocalíptico, é um cenário vivenciado.

Nota: Caso vá por esse caminho, clone a máquina que está o sistema e instale na cópia ou crie um snapshot, tenha uma cópia disso funcionando, por segurança.

Fora que se for parar pra pensar, o sistema também pode apresentar uma falha, outra e mais uma. Como medida corretiva você teria que instalar o sistema novamente ou atualizar.

Tem o ponto de checar as dependências, por que acredite ou não, projetos nascem, ficam inativos, ressurgem da inatividade ou simplesmente morrem, já que outros aparecem e fazem o que ele faz de forma mais eficiente.

Pessoas para cuidarem do sistema

Chegamos ao fator humano, vamos aos pontos:

Nota: minha opinião sobre isso, é que empresas que usam self-hosted, podem contribuir com o projeto, não só com código, mas oferecendo sua experiência de uso dele como contribuição, como artigos, vídeos, tutoriais etc. Isto ajuda a não só compartilhar, mas fazer uma fonte mais atualizada e confiável sobre o assunto.

  • Documentação do projeto;
  • Outras pessoas utilizando o projeto, isso é importante, visto que quanto maior a comunidade e mais unida ela for, vai fornecer uma ajuda e um feedback do que você está fazendo (existem comunidades que não são assim e é cada um por si);
  • Locais de busca (tags no StackOverflow, grupos no Telegram/WhatsApp, listas de email)

Os pontos acima são essenciais para que a pessoa responsável pela implantação desse software consiga de forma mais simples.

Nota: em certos pontos de implantação de alguns softwares, minha experiência em TI de forma geral, me ajudou nisso.

Hardware ou um lugar para executar o sistema

Quando digo hardware não é só a máquina que você vai deixar em produção o sistema, mas outra igual para sandbox, não teste coisas em produção.

Também deve ser levado em consideração um backup consistente que cubra o sistema como um todo, armazenado localmente e em nuvem. Versione seus scripts de backup rode algum tipo de checagem nele, garanta integridade dos scripts e backups. Crie uma terceira máquina igual e restaure o backup. Isso não é adicional, é essencial. Testar somente quando se precisa é algo arriscado, visto que não sabe se de fato o backup funciona.

Nota: caso não disponha tanto recurso, apenas crie um snapshot da máquina de produção e execute localmente para o teste de coisas novas no sistema.

Se for virtualizado, procure hypervisors mais estáveis e com menos overhead. De preferência não utilize interface gráfica no sistema host, nem nos guests, isso economiza recurso.

Custo

Sim, custo

A princípio pode parecer barato, mas você terá de pagar pra manter online ou deslocar recurso da sua virtualização local para manter isso ou máquina física para isso, logo isso consome recurso de outra coisa.

Se for sistema com SLA alto, entenda maior que 98%, veja se é elegível a classificação TIER de redundância utilizada em datacenters. Leia sobre nos links abaixo:

Nota: já que vai fazer, faz direito. Se isso não for viável, usa nuvem.

Nota: essa parte acima cabe em hardware e neste tópico sobre custo, mas como gera um custo elevado devido a ter duplicidade em serviços, neste tópico seria mais adequado (ao meu ver)

Voltando ao primeiro item da lista, a manutenção, aqui dependendo da soma das horas que foram alocadas para o funcionário, se isso não seria o preço pago pelo serviço hosted que não geraria manutenção e que seu funcionário ficaria com o tempo pra outra atividade que de fato rende algo.

Leve em conta o tipo de sistema que quer utilizar, senão houver problemas com internacionalização é mais simples, mas se houver internacionalização referente a moeda, fuso horário e formatos locais do país ou de sua região… deve ser analisado se existe suporte contínuo e sobre a maturidade deste suporte.

Outro ponto é se for comercial, algumas coisas de sistema fiscal apenas existem no Brasil (nota fiscal, nota fiscal eletrônica, nota fiscal paulista entre outras), então análise o custo de fazer o módulo ou confiar em módulos que podem não dar suporte e você assumir essa manutenção para o seu sistema funcionar.

Referências

Dessa vez as referências são diferentes das encontradas em outros posts. Minha experiência se baseia em:

Sempre insiro links em termos chaves nos meus posts para que o leitor sempre possa ter conteúdo adicional para ler ou que seja completar ao assunto abordado.


comments powered by Disqus