Trabalhar com arquitetura de software exige uma capacidade de abstração muito grande, é preciso ter imaginação. Trabalhar sozinho, projetando o futuro de uma empresa com muitos projetos é ainda mais desafiador porque é difícil documentar e comunicar a evolução. Este post tem essa intenção, contar um pouco da história das arquiteturas “perdidas” no passado da F5 Sites.
Passado
Arquitetura de 2003-2009 – Hospedagem grátis
Uma boa história merece ser contada desde o começo, basicamente no começo, de 2003 até 2009 usava serviços gratuitos, depois passei a pagar para ter hospedagem e domínio, assim neste tempo a arquitetura era terceirizada. Passei por domínios como .kitnet, .h1000, usando a ferramenta Microsoft Frontpage para editar simples páginas html, com links, que subia por FTP. Em alguns casos tinha uma minúscula cota de banco de dados.
Arquitetura de 2009-2013 – Hospedagem compartilhada
A partir de 2009 migrei para um grande site de hospedagem, assinava uma opção compartilhada (e econômica) com o domínio gerenciado pela empresa, com a gestão feita pelo cpanel. Uma dica de um cliente, que utilizava o serviço, assim neste ano lancei a primeira versão e o embrião da F5 Sites, com o domínio já internacional que mantenho até hoje www.f5sites.com. A cada novo domínio um novo pacote de hospedagem compartilhada.
Arquitetura de 2013-2017 – Plano de revenda de hospedagem
A partir de 2013 já tinha bastante experiência com cpanel e nesta mesma empresa de hospedagem decidi migrar para um plano de revenda, com um alto custo. Facilitava a minha vida como gestor de projetos da minha própria empresa, conseguia seprarar cada pequeno projeto em um plano de hospedagem próprio, mas como meu crescimento comercial foi fraco, não terminei nenhum projeto valioso, não consegui nem iniciar a revenda de planos. Tive a sensação que trabalhar revendendo planos de outra empresa seria trabalhar para outra empresa, não a minha própria, as grande empresas gerenciam sua infra, Google e Facebook não contratam terceiros para sua hospedagem, infra é o núcleo (core business) de uma empresa de TI que quer ser respeitada.
Arquitetura de 2017-2020 – Micro cloud self managed
Dizem que os maiores hackers se tornam grandes devido as dificuldades que enfrentam, assim com uma limitação enorme de orçamento, precisei de meses para migrar de uma estrutura de custo alto (vários projetos e vários domínios num plano de revenda de hospedagem) para a solução mais econômica possível.
Passei então a um plano compartilhado de cinco dólares por mês (já que no Brasil, naquela época, não encontrei nenhuma empresa que oferecesse micro-nuvem baratas com auto-gestão por SSH), possíveis de serem pago com boleto bancário (já que eu também não tinha cartão de crédito, sequer internacional). Passei a administrar os meus domínios e fazer a gestão do DNS (precisei aprender sobre como fazer tudo isso no processo), todos apontando para uma econômica máquina virtual compartilhada.
Assim estava sentindo que entrava no caminho certo para crescer de forma escalonada, uma injeção de recursos facilitaria a expansão do serviço pela agregação de mais nós a custos controlados, sem cobranças abusivas. Tinha a sensação de estar indo no rumo certo de grandes empresas com respeitada arquitetura e soluções de infra.
O espaço em disco também era um problema, todos os meus sites eram WordPress e para caber no menor plano possível a única solução foi compartilhar uma instalação de WordPress para todos os projetos (cada backup de um projeto cPanel tem em médio 1gb). Isso foi um desafio enorme para a arquitetura de solução, hoje é fácil perceber que foi uma solução executada de uma forma ruim, mas possível.
Assim que terminei a migração enfrentei outra enorme dificuldade que foi a obtenção de certificados SSL (eu nem sabia o que era isso). Com todos os domínios e projetos no servidor mais econômico possível, como obter um certificado para cada domínio gratuitamente? Descobrir um caminho para gerar um certificado compartilhado para os domínios (poupando dezenas de dólares) e então finalmente tinha independência da minha arquitetura com o Lets Encrypt para apache.
Arquitetura de 2020-2022 – Início do docker
No final de 2019 e início de 2020 era impossível ignorar o surgimento e predominância da tecnologia docker. Na empresa que eu trabalhava e em muitos projetos que participei era unânime sua adoção, assim decidi também adotadas a tecnologia para F5 sites.
Já que nenhum projeto meu estava acabado a minha infraestrutura era precária estaria arriscando pouco para colher bons frutos. Em 2020 adotei de forma integral o docker derrubando tudo que eu tinha feito de 2017 até então e unificando os serviços, padronizando tudo pelo docker (também de uma forma meio grotesca e primitiva, um único docker apache e mysql para vários projetos WordPress, numa única instalação: simples mas meio inútil pois quebra a regra de independência de serviços).
De fato a infraestrutura evoluiu com a adoção do docker, permitiu a automação do deploy de novos servidores, mas continuou compacta e muito parecida com anterior ao docker, já que eu tinha uma única instância de servidor e a migração para o docker não alterou isso, permaneci com uma instância do servidor, porém dockerizada em vez dos serviços como Apache e Mysql instalados diretamente na máquina. Ainda era preciso entrar no docker para obter o certificado do SSL, pois não consegui superar o desafio de gerar uma instância docker para obtenção de certificados, de forma independente (um belo samba).
Arquitetura a partir de 2023 – Docker como micro-serviço
Finalmente estamos em 2022, já no final do ano, e a arquitetura de infra começa a se tornar verdadeiramente robusta. Com um pouco mais de recurso, mais máquinas e um esforço enorme para estudar novos conceitos de devOps, cloud e docker, consegui finalizar a última etapa do desafio.
Fazendo uma referência ao início desse post, lembramos do poder da imaginação. Uma grande dificuldade em separar os projetos de forma independente em instâncias de docker eram a utilização da mesma porta. Dois domínios com servidores apaches utilizando a mesma porta virar um conflitos, assim para desenvolver projetos sempre derrubava um docker para iniciar outro.
Com a agenda muito apertada entre viagens (conheça meu instagram de viagem @vamoslonge), produção de conteúdo, atendimento de clientes e desenvolvimento de projetos precisei dedicar um esforço mental muito grande, no período onde tive um tempo de algumas semanas (pois fui desligado do meu único cliente). Nesse ínterim estudei como rodar infinitas distâncias de docker na mesma máquina sem ter problemas com porta.
Superei mais um desafio tecnológico e entendi como utilizar o enigma x com proxy reverso e o docker gem para ficar sempre escutando a inicialização é derrubada distâncias docker utilizando o conceito de encaminhamento de porta. Complexo para entender e complexo para explicar e resumo uma imagem de docker e a sua instância fazem a comunicação com o cliente e direcionam o domínio para o seu docker que pode ser na mesma máquina. Uma analogia simples é como colocar um porteiro num prédio e sempre que alguém vai visitar ele indica o andar o apartamento da pessoa.
Assim hoje (data que escrevo este post) superei o último desafio, com essa infraestrutura montada ter um docker atacado para obtenção de certificações SSL para cada domínio do projeto. Para tanto criei uma segunda máquina compartilhada na nuvem e migrei meu primeiro domínio (www.f5sites.com), com uma máquina zerada e muito estudo, atenção aos detalhes, consultas extensas em sites de buscas e documentação de projetos, encontrei finalmente o caminho e conseguir migrar o meu primeiro domínio para essa estrutura, com seu docker próprio.
Então o resumo da missa é que no passado, devido a restrições financeiras, migrei uma estrutura terceirizada para uma máquina muito pequena na nuvem auto gerenciada. O futuro no curto prazo é uma infraestrutura muito mais confiável sólida e econômica, e o presente é a migração dos outros domínios após o sucesso do primeiro.
Futuro no longo prazo
Ainda sonho com a criação do meu MaaS (Metal as a Service), minha própria estrutura física compartilhada com projetos de outras empresas. Onde pretendo reciclar máquinas velhas e criar um datacenter sustentável com amplas áreas ventiladas, utilização de água resfriada ecológica e um poderoso sistema de node balance para distribuir o calor gerado pelas máquinas numa arquitetura predial moderna, atendendo todas as normas de segurança.
