The Twelve-Factor App: Metodologia para construção de aplicações robustas

Conhecendo a metodologia - Apresentação

Bem-vindos de volta, e vamos falar sobre mais um fator, um fator chamado processos, que na minha opinião deveria ser renomeado, mas tudo bem, vamos entender o que fala esse fator. A ideia é executarmos nossa aplicação como um ou mais processos sem estado.

Foca nessa palavra, sem estado, do inglês stateless. O que isso quer dizer? Imagine uma aplicação web normal onde temos a autenticação, temos o formulário de login. O usuário manda o login e senha para nós, vamos verificar se existe esse login, se a senha está correta, e vamos armazenar essa informação no servidor dizendo “esse usuário vai ter um id 1234”, e devolve nessa resposta dizendo “eu te identifiquei como 1234 no servidor”.

Isso é o que é chamado de sessão http. Quando temos esse conceito de sessão, existem diversos problemas, e o The Twelve-Factor App não curte essa ideia. Mas não sessões especificamente, mas sim armazenar essa sessão no servidor da aplicação, porque de novo, a sua aplicação deve ser um processo sem estado.

Qual o problema disso? Inclusive existe um vídeo na Alura+ onde falamos sobre JWT que explica com muito mais detalhes o problema sobre isso, mas vou dar uma passada bem rápida.

O que acontece? Imagine que você tem um load balancer, ou seja, sua aplicação está rodando como mais de um processo. Tem vários servidores e tem o load balancer que vai distribuir a sobrecarga para esses vários servidores. Na primeira requisição, na hora de fazer o login, foi o primeiro servidor que respondeu, verificou que está tudo certo, armazenou a sessão e enviou a resposta para o usuário.

O usuário vai fazer a próxima requisição tentando acessar a lista de alguma coisa, por exemplo. Ele vai dizer “eu sou o usuário 1234”, mas o load balancer manda ele para o segundo servidor. Ou seja, esse segundo servidor não tem os detalhes da sessão, ele não sabe quem é esse usuário, vai redirecionar ele para fazer login de novo.

Isso não é interessante. E não só por isso. Como ele diz, ele dá alguns exemplos, se você fizer o deploy da aplicação e sua aplicação reiniciar você vai perder os dados, mesmo que você tenha um só. Se você modificar alguma configuração, se a execução do ambiente realocar algum processo, se algo acontecer e você perder aqueles dados, sua aplicação vai ser impactada.

Por isso não deveríamos armazenar estados. “Ok, Vinicius, e qual é a solução?”. Repare que ele diz que sticky session, que é esse conceito que expliquei, não é interessante. Então qual a solução? Armazenar tudo que você armazenaria como estado do seu processo em serviços de apoio.

Por exemplo, eu preciso processar uma imagem e enviar essa imagem minificada. Você não vai salvar essa imagem no seu servidor como se fosse parte da sua aplicação. Ou você vai armazenar em um espaço específico para assets, que não vai fazer parte da base de código, ou você vai armazenar em um servidor específico de arquivos, ou você vai armazenar até no banco de dados. Enfim.

Você vai usar um serviço externo para isso. E para a sessão isso não muda. Você pode salvar o id da sessão. Ao invés de salvar na própria aplicação, salvar no servidor externo, como um banco de dados, um redis, um memcached, em algum desses lugares, como inclusive a documentação, essa página sugere.

Então, a lógica por trás desse fator é dizer que seus processos, sua aplicação deve ser com um processo sem estado, e por que digo que esse nome deveria ser outro? Por que isso deveria ser renomeado? Eu entendo que esse nome vem do conceito de processos do sistema operacional. Um processo, a execução de um processo não depende de execução anterior.

Por exemplo, deixa eu ver se ainda tenho o terminal aberto. Se executo ‘ls’ e executo ‘ls’ de novo, essa execução não depende em nada da outra. Essa é a ideia de ser um processo sem estado, que vem dos processos do sistema operacional. Só que como nem todas as pessoas que desenvolvem tem tanto conhecimento de sistema operacional, talvez um nome melhor seria stateless, sem estado, ou algo do tipo.

Mas basicamente essa é a ideia desse fator, inclusive se você der uma olhada no meu canal, Dias de Dev, fazendo um jabá aqui, tem exatamente sobre isso também. E nessa parte de autenticação por token, de forma semelhante ao que fizemos aqui na Alura+ tem uma explicação do processo envolvendo armazenar dados em sessão e como evitar isso.

Aqui mostro uma tecnologia mais específica. Dê uma olhada no vídeo da Alura+ sobre JWT, se te interessar ver com mais detalhes dê uma olhada também lá no meu canal, mas a ideia por trás desse fator é que você não deve armazenar estado na sua aplicação em si, qualquer estado que você precise armazenar deve ser em algum serviço de apoio. Banco de dados, sistema de cache como redis, memcached. Em algum lugar à parte.

Agora que já entendemos isso, vamos continuar avançando juntos nos nossos princípios, nos nossos fatores dessa metodologia, mas no próximo vídeo.

Conhecendo a metodologia - O que é o 12 Factor App?

Bem-vindos de volta. Vamos falar de forma bem rápida e resumida o que é esse tal de The Twelve-Factor App. Primeiro vamos trazer uma tradução. Uma das traduções possíveis é metodologia de aplicações 12 fatores. Então só com essa tradução já chegamos em uma das possíveis respostas para o que é essa The Twelve-Factor App.

The Twelve-Factor App é uma metodologia de desenvolvimento, de trabalho de software e traz algumas vantagens para nós que devem ser aplicadas em determinados cenários.

E como o próprio nome diz, The Twelve-Factor App, essa metodologia traz para nós 12 regras, 12 princípios, 12 fatores, você pode chamar como quiser, mas traz esses 12 fatores para que sigamos e seguindo atinjamos alguns objetivos. Como por exemplo com esses fatores mantemos o formato declarativo da nossa automação de setup, vamos dizer assim.

Ou seja, o que precisamos para a nossa aplicação funcionar está declarado, está utilizando um formato declarativo, está escrito de forma explícita em algum lugar. Preciso de uma dependência que envie e-mail, por exemplo, preciso de um sistema com 8gb de RAM, isso vai estar escrito em algum lugar, isso vai estar em um formato declarativo.

Além disso, com esses fatores criamos aplicações que têm um formato muito claro e muito limpo com o que vamos depender. Por exemplo, com o sistema operacional em si definimos um contrato e não dependemos diretamente. Para quem já conhece programação, dependemos de certas abstrações e essa é uma recomendação não só dessa metodologia, mas do desenvolvimento em geral.

Dependências além do sistema operacional, outros pedaços de código, sempre devemos utilizar também contratos muito claros para utilizar essas dependências. E com isso facilitamos a portabilidade. Mudar nosso sistema, por exemplo, de um servidor para outro, trocar uma dependência para outra.

Isso é bastante pregado por essa metodologia. Além disso, com essa metodologia temos uma certa facilidade para fazer deploy em plataformas de cloud, como Google cloud, AWS, etc.

Seguindo essas metodologias, nossa aplicação teoricamente já vai estar pronta para esses ambientes. Isso é bastante interessante. Outra vantagem de seguir essa metodologia é que vamos tender a ter menos divergências, ou seja, o mínimo de divergências possíveis, entre nosso ambiente de desenvolvimento e o ambiente de produção.

O que isso quer dizer? A máquina onde escrevo o código, normalmente meu computador pessoal, e o servidor de produção vão ter configurações muito parecidas. O mesmo servidor web na mesma versão, com o mesmo servidor de aplicação e esse tipo de coisa.

Com essa divergência diminuída, mitigamos, tentamos resolver aquele famoso problema de na minha máquina funciona. Essa metodologia também ajuda nesse cenário. E por fim, mais um detalhe que é muito importante, seguindo essa metodologia, seguindo esses fatores nós criamos aplicações que escalam, que têm a possibilidade de escalar sem necessidade de alteração na arquitetura, em código em si.

Então ela está pronta para funcionar pequeno e funcionar muito grande. Essa é a ideia por trás da metodologia de aplicação de 12 fatores. E um detalhe muito importante é que essa metodologia pode ser aplicada em aplicações em qualquer linguagem de programação, que utilize qualquer combinação de serviço de suporte.

O que é um serviço de suporte? Vamos explicar com muito mais detalhes mais para a frente, mas basicamente qualquer sistema terceiro. Um sistema de cash, mensageria, banco de dados, servidor de e-mail, etc. Com isso, qualquer linguagem de programação com qualquer conjunto de serviços de suporte vão poder implementar essa metodologia.

Vinicius, eu programo em Go, vai fazer, eu programo em Java, você vai conseguir, eu uso MYSQL, vai dar para aplicar, eu uso Redis, show de bola. Essas coisas são detalhes para essa metodologia, detalhes que conseguimos mudar, trocar de um para outro, e por isso tudo que falarmos aqui vai funcionar em qualquer um desses ambientes.

Agora que entendemos o que é, vamos bater um papo um pouco mais rápido do que esse, sobre como utilizar, quando utilizar, se faz sentido utilizar todos os 12 fatores, enfim. Vamos bater esse papo no próximo vídeo.

Conhecendo a metodologia - Quando e como usar

Bem-vindos de volta. Já falamos o que é a metodologia de 12 fatores, já vimos as vantagens que ela traz, mas algo que é muito pouco discutido, pelo menos ao meu ver, é se posso aplicar esses 12 fatores em qualquer projeto. Se eu fizer um CRUD, um sistema de cadastro só, posso aplicar essas metodologias?

A resposta é sim e não. Você vai poder aplicar muitos dos fatores, com certeza. Só que alguns desses 12 fatores que vamos discutir no decorrer do curso vão acabar te trazendo uma complexidade desnecessária para sistemas muito simples. Então o ideal é que você conheça os 12 fatores, entenda os prós e contras dessas recomendações e decida por si só se isso vale a pena implementar no seu projeto ou não.

Mas toda metodologia tem um propósito, um público alvo, algo desse tipo. E o alvo da metodologia 12 fatores é, como conseguimos ver na página oficial, a aplicação de 12 fatores é uma metodologia para construir softwares como serviço. Os famosos SAS, softwares as services.

O que isso quer dizer? O que é um software com um serviço? Basicamente, é um programa de computador, um sistema que você não vende como produto, você vende como se fosse um serviço, algo recorrente. Por exemplo, e isso inclusive pode ser algo pago nesse formato de assinatura recorrente, ou pode ser algo gratuito, um serviço que você fornece sem custo nenhum, colocando somente propagandas ou algo do tipo.

Por exemplo, o Gmail é um software as a service, ou o Outlook, sistemas de e-mail em geral. Eles são sistemas que você utiliza como serviço. Você não chega lá, pega o Gmail e compra para você. Você utiliza o serviço.

E dando o exemplo de formatos de assinatura, temos Netflix, por exemplo. Saindo um pouco do formato de assinatura e voltando para serviços, Dropbox, ou Google Drive, One Drive, Google Docs, o Microsoft Office Online. Esse é um tipo de aplicação que chamamos de software como serviço.

Você entrega um serviço de software, e não um produto que você compra, paga uma vez e instala na sua máquina, por exemplo. Softwares como serviços são armazenados no servidor do fornecedor do serviço, ele gerencia o serviço em si, ele gerencia os servidores, o código mantém.

Já o produto, você entregaria, por exemplo, o sistema para o cliente que está comprando, e ele vai instalar na máquina dele, nos servidores dele, ele vai cuidar de manter esses servidores, etc. Existe essa diferença.

O alvo dessa metodologia é para criação desse tipo de aplicação, ou seja, aplicação de software como serviço, que depende de uma infraestrutura mais robusta para conseguir fornecer o acesso a vários clientes, que esteja em servidores de alta disponibilidade, etc.

Mas tendo entendido o alvo da metodologia, preciso aplicar todas as 12 regras, preciso seguir todos esses fatores a ferro e fogo sem flexibilidade? E que de novo é algo que pouca gente comenta, mas basicamente, você não é obrigado a nada. Você vai implementar o que fizer sentido para o seu sistema.

Só que aplicando esses 12 fatores seu sistema vai estar muito provavelmente mais pronto para ser implementado, para ser entregue como um serviço, para ser entregue como um SAS. Um software as a service.

“Mas Vinicius, eu estou criando aqui um CRUD, um cadastro, e queria seguir a regra 2 e 3, por exemplo. Tem problema?”. Obviamente que não tem problema nenhum.

Então a minha recomendação pessoal, isso não é algo que vem da metodologia em si, é que você conheça todos os fatores, entenda o que eles querem dizer e o que te entregam de vantagens e desvantagens, e a partir disso você, que é arquiteto, desenvolvedor, desenvolvedora, pessoa que está tomando decisões pelo produto, vai decidir se vale a pena implementar ou não cada um dos fatores.

Porque como eu disse no vídeo anterior alguns desses fatores trazem complexidade, e às vezes nosso sistema não precisa dessa complexidade, ele não vai crescer, ele nunca vai sair de um servidor, de uma hospedagem compartilhada, por exemplo. É um sistema pessoal.

Nesse caso, muitos desses fatores não valem a pena serem aplicados. Mas alguns outros vale considerar. Então, conforme formos passando pelo treinamento e conhecendo esses 12 fatores, você vai ser a pessoa responsável por decidir se você vai implementar todos eles ou alguns deles no seu sistema, mas lembrando que ao aplicar esses 12 fatores você muito provavelmente já vai estar com uma aplicação mais pronta para ser distribuída como serviço.

Sobre o curso The Twelve-Factor App: Metodologia para construção de aplicações robustas

O curso The Twelve-Factor App: Metodologia para construção de aplicações robustas possui 92 minutos de vídeos, em um total de 41 atividades. Gostou? Conheça nossos outros cursos de Builds em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conhecendo a metodologia
• Isolando o código
• Isolando a aplicação
• Gerenciando ambientes
• Cuidando do sistema