E aí, pessoal!

O artigo de hoje será um pouco diferente. Queremos trazer para vocês como a Umbler desenvolveu sua plataforma de NodeJS utilizando Docker. Sim, falaremos sobre o que deu certo e, claro, o que deu errado nesse caminho. O intuito é mostrar mais um case de sucesso e tudo que foi preciso para isso.

A Umbler  já utiliza Docker há alguns anos (obviamente para aplicações/serviços internos) e isso ajudou no desenvolvimento de sua plataforma NodeJs. Mas até chegar à experiência ideal, levou tempo, pesquisa, testes, prototipação e muita paciência.

Abaixo, compartilhamos com vocês uma apresentação que foi realizada durante o Meetup de NodeJS em Porto Alegre no dia 11/07, onde mostramos aos participantes os detalhes dessa jornada:

Vamos detalhar o que foi apresentado:

Quem mesmo?

A Umbler é uma startup gaúcha de cloud hosting sob demanda. Seu objetivo é facilitar, cada vez mais, a vida de quem cria a web; ou seja, as agências e desenvolvedores. Atualmente, possui cerca de quarenta mil clientes e conta com setenta funcionários distribuídos pelo mundo.

O caminho até aqui

Como sempre, não existe uma solução mágica para todos os problemas, ou uma única solução infalível. Às vezes, temos que nos aventurar com o máximo de alternativas possíveis para ter certeza de que aquilo não nos atenderá ou, pelo menos, não nos atenderá naquele momento.

Foi assim que, depois de muitos meses de testes e prototipação, foi possível observar algumas coisas e descobrir o porquê de algumas soluções não atenderem a demanda que a Umbler queria resolver. Entre as soluções testadas, é possível destacar:

OpenShift

Plataforma pronta para criação de containers, baseada em Kubernetes. É uma plataforma que funciona muito bem, tem instalação relativamente fácil, possui gerenciamento centralizado e conta com integração com diversas outras ferramentas/soluções. Esta é uma ferramenta com muitos pontos positivos, pois atende aos mais variados problemas, mas que não se encaixou, até então, no que a Umbler precisava. Dos pontos negativos que se destacam são:

• Curva de aprendizagem: Openshift possui, além de kubernetes, uma série de outras soluções para que seja possível a criação e gerenciamento dos containers nela hospedado. Seu uso é simples e intuitivo, mas, eventualmente, algo daria manutenção. E aí estava um dos empecilhos. Além de saber tudo sobre Docker, Kubernetes, OpenVswitch, era obrigatório entender cada um dos demais componentes da plataforma, justamente para se antecipar a algum problema.
• Restrições: Apesar de todas as facilidades, o OpenShift possui algumas restrições que, para as necessidades mapeadas, impossibilitaram o seu uso ou, pelo menos, gerariam mais demanda para adaptar a plataforma. O objetivo da Umbler é criar uma plataforma completa e fácil, com a menor quantidade de amarras possíveis, garantindo a melhor experiência dos usuários. Infelizmente, o Openshift tornaria isso mais complexo de ser realizado.
• Inovação: Obviamente, inovar é preciso. No mercado de tecnologia, isso além de bom, é obrigatório. Com as restrições que foram encontradas, inovar utilizando o Openshift dependeria muito do que a plataforma teria a oferecer. Ou seja, a inovação do produto estaria presa a inovação da plataforma, restando pouco (ou quase nada) de margem para adaptação.
• Custo: Existem basicamente duas versões do Openshift. A Origin é opensource e você pode utilizar para resolver seus desafios sozinho, além de contar com o apoio da comunidade. ]A versão enterprise, garante suporte comercial à plataforma e atualizações dos softwares que a compõem. Independente da versão, o custo/benefício não compensava, pois, mesmo com a versão opensource, o tempo de resposta ou atualização para algo crítico era muito grande, tornando a versão “gratuita” não tão gratuita assim.

Kubernetes

O Kubernetes é um orquestrador para containers totalmente opensource, e mantido por uma comunidade gigantesca. Tendo em vista o histórico de testes/prototipação com o Openshift, a segunda abordagem naturalmente seria algo mais voltado ao que já foi visto. Como a base do Openshift é Kubernetes, a ideia era utilizar o Kubernetes e adaptar o que fosse necessário para a plataforma. Simples, não? Sim e não. Vamos ver algumas restrições dele:

• Curva de aprendizagem: Realmente, utilizando apenas o Kubernetes a quantidade de tecnologias que deveriam ser dominadas foi reduzida a apenas duas: Docker e Kubernetes. Mesmo assim, o tempo para aprender tudo e saber resolver tudo dessas tecnologias era elevado. Menor do que com Openshift, mas ainda assim algo que faria a plataforma levar mais tempo a ser finalizada.
• Restrições: Depois de muita leitura, estudo e testes, foram encontradas algumas restrições. A mais clássica delas é o Kubernetes não suportar as últimas versões do Docker, ou seja, sempre haveria um gap entre as novidades da engine do Docker e o que realmente está sendo utilizado.
• Inovação: Como no caso da Openshift, o uso do Kubernetes resolveria diversos pontos da plataforma, mas ainda assim seria algo que poderia travar a inovação e adaptação da plataforma.

Docker Swarm

O Swarm é o método nativo de cluster na engine do Docker. A partir da versão 1.12 do Docker é possível utilizar esse recurso sem a necessidade de uma ferramenta ou solução de terceiros. Assim como no Kubernetes, com o Swarm é possível criar e gerenciar todos os serviços/containers do cluster. Com o Swarm, foi possível resolver algumas das pendências das demais soluções, como por exemplo:

• Curva de aprendizagem: Como já mencionado, a Umbler utiliza Docker há algum tempo, então, já havia em casa mesmo o conhecimento prévio, bastando apenas a adaptação para o modo de cluster.
• Custo: Existe a versão opensource e a versão enterprise do Docker. A grande diferença entre depender da comunidade Docker e comunidade Openshift é a velocidade na resolução de alguma issue ou até mesmo melhoria para a engine. Isso facilita na tomada de decisão, sem contar no tamanho das comunidades.
• Inovação: Ainda há uma amarra quanto a tecnologia, no entanto, com o Swarm é possível criar/modificar a plataforma na mesma velocidade da engine de containers.

Existe algo que o Swarm não atendeu? Sim, obviamente. E isso é natural, visto que não existe solução mágica para tudo. No entanto, foi possível adaptar algumas outras soluções para que fosse possível mitigar ou até mesmo sanar esses casos.

Sim, foi um processo longo, às vezes demorado, mas que rendeu bons frutos, seja de nível técnico (com o incremento de conhecimento para a equipe), ou de negócio, pois foi necessário o entendimento de todos quanto a necessidade real dos usuários. E, claro, a moldagem das ideias para atender essas necessidades. Desafios que foram sendo resolvidos durante a caminhada, é possível destacar:

• Isolamento: Sim, containers são isolados. Mas para isolar o tráfego entre os serviços, como faz? Esse foi um dos pontos onde se investiu algum tempo para encontrar a melhor resposta.
• Inovar de forma responsável: A cada três meses é lançada uma nova versão do Docker, atualiza-se o ambiente a cada três meses? Usa-se as features novas já de cara? Este também foi motivo para algumas horas de conversa.
• Complexidade: Não é porque foi utilizada uma tecnologia base que o ambiente não seria complexo. Quanto mais features para a plataforma, maior a complexidade para se atender essa demanda.
• Simplificar: Como simplificar, então? Como deixar tudo fácil de ser entendido, e, principalmente, replicável?
• Deploy: De que forma o usuário vai utilizar a plataforma? Como deve ser o melhor fluxo para colocar uma aplicação no ar com Docker? Às vezes, a resposta certa não é a óbvia.
• Cobrança: Como quantificar o gasto de cada cliente? Existe isso na “caixa”? Quanto cobrar, e mais importante, vamos cobrar?

Além de desafios, ficaram também diversos aprendizados, que não custa nada compartilhar, certo?!

• Pesquisa e Prototipação são fundamentais. Mesmo que você saiba tudo na teoria, às vezes, um comportamento só é validado na prática, tentando fazer dar erro.
• Perseverança é muito importante. Às vezes, a solução mais fácil parece ser a melhor, o que pode não se confirmar. Por isso, é preciso cuidado, pois você estará fazendo algo não para você, e nem para seu colega, mas, sim para dezenas, centenas, milhares de pessoas. É nelas que você deve pensar.
• Ouvir todos os interessados é fundamental. Seja seu cliente (aquele que já paga pelo serviço), seja seu usuário (aquele que apenas usa, mas não gasta), seja seu colega, seu chefe, e principalmente a comunidade. Apenas ouça, processe, e aí sim pense em algo que faça sentido para todos.
• Outro ponto interessante é separar o “que” precisa ser feito do “como” deve ser feito. Em alguns casos (muitos, por sinal), quando recebemos um problema para resolver, já saímos com a solução pronta, montada em nossa cabeça. Mas será que o problema é realmente o apresentado? Será que essa solução se encaixa realmente na resolução? Lembre-se: O que eu preciso fazer define como eu vou fazer, e não o contrário.
• Admita, você não terá todas as respostas em uma única solução. Isso é improvável. Mas você precisará estar aberto a isso, e, principalmente, você precisará saber lidar com isso.
• Última, mas não menos importante dica: entenda exatamente o que você está fazendo. Não apenas aceite e saia executando. Entenda! Isso fará o seu trabalho ter mais valor e você terá outra visão daquilo que está criando.

Esperamos que isso ajude vocês durante suas próprias jornadas. Para nós, foi uma experiência bem divertida, além de enriquecedora. E é uma honra compartilhar com vocês.