DEV Community: TeixeiraJr

Os 12 fatores para um projeto web de excelência

TeixeiraJr — Sat, 11 Jun 2022 02:41:51 +0000

O que são os 12 fatores para um projeto web de excelência

Em projetos web, é comum um desenvolvedor novato (ou até mesmo experiente) acabe tendo dúvidas a respeito de como planejar a arquitetura de um software, muitas vezes por não conhecer todos os processos disponíveis como também por vícios de aprendizado que o acompanham na sua experiência profissional. Os 12 fatores trata dos requisitos mínimos necessários para que uma aplicação web seja compatível com escalonamento horizontal. Isto é, caso um sistema cumpra tais fatores, ele está minimamente compatível com um escalonamento eficiente, e caso não esteja, dificilmente será compativel com tal atividade de maneira funcional. Os 12 fatores foi proposto por Adam Wiggins, cofundador do Heroku e seu artigo a respeito dos 12 fatores (referência direta para a criação deste artigo) necessários em aplicações web é bem difundido e serve muito bem como referência e base de estudos para os interessados no processo.

Vantagens da metodologia

Tal metodologia pode ser aplicada para qualquer sistema web, em qualquer linguagem e utilizando qualquer framework. Os principais motivos para se aplicar os 12 fatores em uma aplicação web são:

Automatizar a configuração inicial do projeto, facilitando o ingresso de novos desenvolvedores nos projetos;
Garantir a portabilidade do software em diversos sistemas operacionais, isto é, gerenciar todas as dependências de forma que não dependa diretamente de nenhum SO;
Minimizar o esforço de implementação e manutenção de sistemas hospedados em serviços em nuvem, reduzindo o custo de administração dos sistemas;
Promover o deploy contínuo da aplicação, evitando o acumulo de modificações e a necessidade de atualizações fora de expediente. Todo o processo de deploy ocorre de tal maneira que pode ser executado continuamente e sem prejudicar o ambiente de produção;
Garantir a escalabilidade eficiente do sistema, sem perda de dados, e sem necessitar de modificações na arquitetura do sistema.

Os doze fatores

Base de código

Todo o código fonte de uma aplicação DEVE estar em uma ferramenta de versionamento de código, o que na prática nos tempos modernos convergem para a tecnologia mais eficiente, o GIT. Seja no github, ou gitlab, azure devops ou qualquer outra ferramenta que utilize o git, o sistema deve estar disponível sempre em um repo externo. Seja em um único repositório com todo o sistema ou em vários (neste caso, um sistema distribuído), o importante é que todos os desenvolvedores tenham uma cópia dessa aplicação e que façam deploy frequentemente na mesma, de modo que os outros desenvolvedores tenham acesso a aquilo que foi feito. Também não se deve ter 2 aplicações utilizando a mesma base de código, nesse caso, deve-se disponibilizar libs para que ambos os sistemas possam utilizá-la por meio de gerenciamento de dependências.

Dependências

Uma aplicação não deve confiar na existência implícita de pacotes no sistema, isto é, toda e qualquer dependência do sistema deve estar no seu manifesto de dependências. Um bom exemplo de tal arquivo seria o package.json do Nodejs, onde o mesmo deve conter todas as dependências do sistema, de forma que quando um novo desenvolvedor deve ser capaz de configurar todo o sistema apenas com o arquivo de manifesto com um npm install no diretório do mesmo. Isso garante também que o sistema poderá ser executado nos mais diversos sistemas operacionais.

Configuração

Na configuração, é comum (e esperado) que os mais diversos ambientes (desenvolvimento, homologação, produção, entre outros) tenham diferentes configurações, como nomes de host, credenciais de acesso, configurações dos bancos de dados, etc. Deve-se garantir a separação de código e configuração. Um bom exemplo de tal prática são os arquivos .env, que armazenam as variáveis de ambientes e permitem a correta conexão dos ambientes de dev, homolog e pro, além das credenciais do banco de dados, sem que nada esteja diretamente escrito no código. Uma boa prova de fogo de tal conceito é validar se o código poderia ser exposto ao público sem comprometer nenhuma variável sensível. Os arquivos que armazenam env vars devem ser ignorados pelo versionamento do git.

Serviço de apoio

Todos os serviços de apoio da aplicação (bancos de dados como MYSQL ou MONGODB), serviços de mensageria como RabbitMQ, entre outros, devem ser consumidos como se fossem aplicações externas, acessados por meio de URLs ou outra forma de localização e credenciamento. Deve-se ser possível trocar de um banco de dados próprio por um serviço de terceiros (como o RDS da amazon) sem que qualquer alteração de código seja feita, apenas trocando as credenciais de acesso dos mesmos. Um bom método para identificar o cumprimento desse passo é transformar todos os elementos da aplicação em containers, já que os mesmos devem se comunicar como serviços externos.

Build, release, run

Um deploy em uma aplicação se dá em 3 estágios:

Build, que é onde o repositório é convertido em uma imagem (semelhante ao que o Docker faz ao criar imagens), onde o mesmo obtêm todas as dependências do projeto;
Release, que é onde o build é enviado a um servidor e é obtido todas as configurações necessárias para a execução;
Run, que é a inicialização de todos os processos para a disponibilização dos serviços para os usuários.

A metodologia de 12 fatores dita que tais estágios devem ser totalmente separados, impedindo a alteração de códigos em produção, já que seria impossível propagar tais mudanças aos estágios anteriores de build e release. Toda alteração deve ser feita inicialmente no repositório para por fim ter seu processo de build, release e run. A maioria das ferramentas de deploy oferecem mecanismos para gestão de lançamentos, bem como para retorno a builds anteriores estáveis em caso de problemas em produção

Processos

A aplicação web deve obrigatoriamente ser stateless, isto é, sem estado. A mesma não deve armazenar nenhum dado que precise ser persistente na aplicação. Na prática, todo dado que trafega na mesma deve ser tratado como um cache temporário. Um bom exeplo disto seria uma aplicação rodando em um container Docker que armazena seus uploads em uma pasta dentro do próprio sistema chamada uplodas, onde basta o container ter qualquer problema e ser desativado que todos os uploads feitos na aplicação serão perdidos. Tais dados deveriam estar armazenadosem algum serviço de cloud de armazenamento de arquivos (AWS S3, Google Cloud Storage) ou até mesmo em um volume persistente, desde que fora do container, ou no caso de dados em algum banco de dados (MYSQL, MONGODB, entre outros), O container acessa qualquer destes serviços sem armazená-lo em sua build, garantindo que o mesmo será read only.

Vínculo de portas

Como regra, toda aplicação web deve exportar o HTTP como um serviço através de uma porta, e escutar as requisições que chegam na mesma. Tal aplicação terá poder de servir outro app ou receber requisições por meio dessas portas sem a necessidade de um serviço como o NGINX ou o Apache, apesar da utilização dos mesmos nos sistemas para a configuração de virtual hosts.

Concorrência

A aplicação deve ser compatível com escalonamento horizontal. Como consequência dos fatores anteriores, a aplicação web deve ser independente de qualquer estado do sistema operacional e é organizado como builds, é possível escalar o sistema de forma que mais de uma aplicação em paralelo possa receber processos e dividir o trabalho executado, geralmente por meio de um load balancer.

Descartabilidade

Para facilitar o escalonamento, aumentar a velocidade de deploy e mudanças nas configurações e dar maior solidez no sistema, aplicações web devem ser descartáveis, isto é, possa ser parada ou reiniciada a qualquer momento sem qualquer perda de dados ou problema com dependências. Isso garante que o processo de deploy de uma nova release, rollback para imagens anteriores, ou a criação de novos container em caso de escalabilidade horizontal seja feita de maneira simples e prática, sem a necessidade de intervenções manuais.

Paridade entre desenvolvimento e produção

Sistemas ineficientes geralmente detém de diferenças consideráveis entre seus ambientes, como por exemplo:

Demoras semanais para o código do desenvolvedor chegar a produção;
Desenvolvedores commitam o código e gerentes de projeto fazem o deploy dele;
Diferença entre bancos de dados, sistemas operacionais entre outros fatores do ambiente de desenvolvimento para o de homologação e produção.

Em tese, deve-se manter os ambientes de desenvolvimento, homologação e produção o mais similares possível, garantindo a rapidez e eficiência e permitindo a utilização de continuos deployment, diminuindo muito a lacuna entre os ambientes.

Utilizando continuos deployment, evita-se de ter a espera muitas vezes mensal ou semanal para fechar-se releases, para aí sim enviar para homologação ou produção. Tal metodologia permite que, ao ser enviado um commit ao repositório, o ambiente automaticamente realize uma série de testes automáticos (caso implementado), garantindo a solidez do sistema, e permitindo a configuração automática do envio de tais alterações para ambientes de homologação, que podem ser validados ou não de forma manual para serem enviados à produção.

Logs

Logs são, em essência, um formato de texto com um evento por linha (alguns podem ocupar mais que isso), onde temos um fluxo de eventos sendo apresentados continuamente durante a execução de uma aplicação. Os 12 fatores dita que todos os logs de uma aplicação devem ser enviados para o stdout, onde os mesmos podem ser capturados e apresentados utilizando ferramentas externas via tail. Um bom exemplo de tal fenômeno seria uma aplicação rodando em Docker cujo qual seja possível acessar os logs do mesmo via algum serviço como o Papertrail e ser visualizado sem a necessidade de consumí-los diretamente do container.

Processos Administrativos

Em aplicações web, é comum a necessidade da execução de algumas tarefas administrativas, como por exemplo rodar uma migration de um banco de dados, rodar scripts para execuções de tarefas rotineiras, entre outros. Em uma aplicação 12 fatores, deve-se criar um ambiente idêntico ao da aplicação, onde ao rodar os comandos necessários, as devidas alterações sejam executadas sem a necessidade das mesmas concorrerem com as requisições dos usuários comum. Tal procedimento pode ser automatizado, já que existem ferramentas para quase todos os tipos de tarefas administrativas. Um bom exemplo seria uma aplicação rodando em docker onde fosse necessáŕia alguma intervenção. Neste caso, criamos outro container docker idêntico ao original (onde o mesmo não recebe requisições, ou seja, fora do load balancer), executamos as devidas tarefas e após isso excluimos o mesmo, não comprometendo o funcionamento do outro Docker em produção. Eventualmente se necessário, criamos outra imagem docker com as alterações e excluimos a antiga, garantindo a continuidade do deploy e do funcionamento da aplicação.

Por fim, conclui-se que uma aplicação que atenda os 12 fatores terá uma excelente qualidade de construção, facilidade para escalar horizontalmente e simplicidade para se executar deploys. Associado a testes automatizados bem escritos, integração contínua associada a uma ferramenta baseada em git que permita builds automatizados e a execução de tais testes, com certeza tem-se um software com ótima qualidade de escrita.

Principais tipos de arquitetura de software - Monólitos, serviços e microsserviços

TeixeiraJr — Thu, 09 Jun 2022 02:24:23 +0000

Arquitetura de software

Quando iniciamos em qualquer carreira na área de tecnologia, principalmente como desenvolvedor web, é comum se deparar com diversos sistemas construídos de maneiras distintas que pode confundir quem está iniciando. Por ser uma área em que a todo momentos novas tecnologias e métodos são desenvolvidos e aprimorados, é importante conhecer ao menos as principais arquiteturas que dão origem a maior parte dos softwares em funcionamento.

Dentre as principais metodologias utilizadas, 3 delas se destacam, que seriam os sistemas monolíticos, sistemas em camadas ou MVC e sistemas em microsserviços.

Sistemas monolíticos

Geralmente utilizado em tecnologias mais antigas, os sistemas monolíticos trazem todas as suas funcionalidades centralizadas em uma grande aplicação (perceba que o termo 'monolítico' se refere a um elemento construído em um só bloco), isto é, todas as camadas da solução se encontram em apenas um código fonte em que o mesmo detém de uma alta dependência interna. Geralmente o mesmo é responsável por a parte visual na tela do usuário (frontend), na manipulação, lógica e processamento das informações (backend) e inserção e leitura dos dados na base de dados.

Dentre as principais vantagens de se utilizar sistemas monolíticos, estão:

Facilidade inicial no desenvolvimento do sistema, enquanto o nível de complexidade do sistema for baixo;
Facilidade de entender o código, já que o mesmo se encontra todo em um só lugar;
Eficiente para validação inicial de idéias, onde não se está bem definidos como o software vai funcionar, evitando integrações complexas em fase experimental;
Baixa integração, onde não será necessário integrar módulos distintos, já que tudo se integra internamente.

Dentre as principais desvantagens de tal arquitetura, temos:

Ao aumentar a complexidade do sistema, torna-se bem mais complexo a manutenção do mesmo, onde ao mexer em uma parte do sistema, pode-se instabilizar todo o sistema;
Difícil escalabilidade, onde caso seja necessário o incremento de recursos (processamento, memória, etc), é necessário disponibilizar máquina para todo o sistema elevando desnecessariamente o custo, onde quase sempre o gargalo de performance ocorre apenas em alguns trechos de código;
Emprego de uma única linguagem, pois ao ser definido a linguagem inicial, torna-se necessário o emprego da mesma em todo o sistema, inclusive em trechos cujo qual a mesma não tem performance adequadas;

Portanto, a arquitetura monolítica se mostra vantajosa em sistemas de baixa complexidade e sem perspectivas de implementações de features complexas no futuro, ou até mesmo como forma de validar como um sistema irá funcionar sem a necessidade de no momento inicial de validação da idéia seja necessário a implementação de arquiteturas complexas.

Sistemas MVC

Sistemas utilizando a arquitetura MVC tem por principal vantagem separar o software em camadas, onde cada uma destas se torna responsável por executar tarefas específicas relativas a um sistema. Na arquitetura MVC, temos a camada model, responsável por toda a lógica interna do sistema cujo qual resolve os problemas propostos pela aplicação e controla o comportamento dos dados por meio de funções. a camada view é responsável por apresentar toda a interface do lado do cliente, renderizando botões, quadros, tabelas, gráficos, imagens e qualquer recurso em que seja necessário que o usuário interaja, ou seja, é o responsável por renderizar a página. Por fim, temos a controller, cujo qual tem o papel de mediar as requisições feitas na view, entregá-las à model e devolver a resposta ao usuário, padronizando tal comunicação de maneira eficiente para que ambos os serviços funcionem corretamente.

Dentre as principais vantagens do padrão MVC, temos:

Separação do sistema em parte lógica e visual, onde é possível que mais de um desenvolvedor trabalhe de forma independente em cada uma das áreas (backend e frontend), sem que um frontend precise lidar com o backend e vice e versa;
Permite uma melhor apresentação dos dados, já que um valor que vem do backend pode ser apresentado de diversas formas no frontend, sem comprometer o dado em si;
Código mais organizado, onde cada camada faz sua função de maneira independente, tornando bem mais fácil entender como o software foi construído e testá-lo de maneira mais eficaz;
Aumento da segurança do sistema, já que a camada controller trata todos os dados antes dos mesmos chegarem na model, diminuindo muito a possibilidade de problemas por conta de dados incorretos ou ausentes, podendo até mesmo utilizar-se de middlewares para tais validações.

já entre as principais desvantagens, temos:

Demanda um tempo relativamente maior para o desenvolvimento, em relação a um sistema monolítico;
Necessita de profissionais de frontend e backend para seu correto funcionamento, aumentando a demanda por desenvolvedores especializados;
Necessita de uma infraestrutura maior em relação a sistemas monolíticos, tratando-se de aplicações simples

É muito fácil ignorar as desvantagens de tal arquitetura em relação as outras disponíveis, já que existem frameworks que facilitam muito o desenvolvimento web, tornando muito vantajoso a utilização de tal modelo na grande maioria dos casos.

Microsserviços

Sistemas distribuídos em microsserviços são em essência, várias aplicações rodando de forma independentes (*inclusive sem compartilhamento de memória), muitas vezes até mesmo rodando em hosts distintos, em que, ao serem integrados por meio de comunicações externas, geram funcionalidades completas. Vários módulos são separados em processos distintos, cada um executando uma parte específica de um todo, onde não há mais possibilidade de um módulo acesse qualquer recurso interno de outro módulo, sendo possível apenas a comunicação através das portas expostas dos demais. Nesse modelo, pode-se imaginar pequenas aplicações rodando em paralelo, onde uma pode requisitar outra a qualquer momento, e desde que a requisição esteja correta, tais aplicações se comunicam entre si enviando e recebendo requisições de forma a resolver o problema que o software se propõe solucionar.

Dentre as principais vantagens da arquitetura em microsserviços, temos:

Como os microsserviços são independentes, a manutenção do sistema se torna mais eficiente, já que ao modificar um dos serviços, não ocorre efeitos colaterais nos demais;
A possibilidade de utilização de várias tecnologias em um único sistema, pois como os microsserviços são independentes e se comunicam atráves de interfaces expostas, desde que as requisições sejam feitas corretamente, nada impede um microsserviço de login em nodeJS se comunicar com um sistema que manipula muitos dados em Python, que se comunica com um sistema de transações de alta performance em Golang. Utilizando microsserviços, pode-se extrair o melhor de cada tecnologia maximizando a performance do sistema;
A diminuição da possibilidade de falhas do sistema, pois se um dos microsserviços cair, apenas as funcionalidades que dependam do mesmo serão afetadas, não comprometendo o restante do sistema. Além da possibilidade de se executar mais de um microsserviço em paralelo (escalonamento horizontal) por meio de pods, onde os mesmos nem precisam estar no mesmo ambiente, garantindo que ao menos um deles estará online para suprir a demanda de solicitações.
Simplicidade dos microsserviços, já que cada um deles irá resolver problemas específicos, tornando o código simples e relativamente fácil de se manter;
A possibilidade de escalonamento de maneira eficiente, já que torna-se possível replicar microsserviços específicos quantas vezes forem necessárias para suprir demandas específicas por um tipo de serviço (por meio de pods em Kubernetes), sem a necessidade de escalar de maneira igualitária os outros microsserviços menos requisitados.

Porém, como desvantagem desta arquitetura, temos:

A necessidade de integração em funcionalidades simples, já que ao criar um novo microsserviço o mesmo precisa ter toda uma interface de integração para se comunicar com os demais;
Uma maior demanda técnica, pois é necessário um amplo conhecimento em frontend, backend e devops, sem contar a complexidade da comunicação entre os microsserviços;
Alta complexidade da arquitetura, tornando-se inviável em aplicações simples e com pouca demanda, já que o gerenciamento de tal arquitetura é altamente complexo para tais situações. Geralmente se utiliza tal arquitetura quando um sistema se torna complexo a ponto de dificultar sua manutenção, ou quando se espera uma demanda muito alta em uma nova aplicação e necessita-se utilizar de escalonamento horizontal para otimizar os custos com infraestrutura.

Como criar um banco de dados mariaDb com docker

TeixeiraJr — Thu, 02 Jun 2022 01:02:20 +0000

Em quais situações utiliza-se Docker para banco de dados ?

Neste post, iremos demonstrar passo a passo como criar um banco de dados mariaDb utilizando docker.
Na grande maioria dos casos, não é recomendado a conteinerização de bancos de dados, por diversos motivos, como:

Não é necessário um escalonamento automático da grande maioria dos bancos de dados,
Apesar das recentes evoluções do Docker, o mesmo ainda não lida bem com as cargas de trabalho oriundas das consultas e inserções dos bancos de dados,
Caso não seja configurado um volume em host (isto é, fora do container) e o mesmo for excluído, os dados armazenados no mesmo serão destruídos,
Existem serviços específicos que lidam de uma forma muito melhor com banco de dados, como o RDS da AWS, diminuindo a complexidade do gerenciamento dos bancos que muitos devs sentem dificuldade.

Então, por qual motivo a criação de bancos de dados em docker seria interessante? Simples, a prática é muito boa para ambientes de desenvolvimento. Criando um container em docker, é removida a complexidade de gerenciamento da mesma facilitando muito o processo de desenvolvimento local.

Como criar um banco de dados em container

Inicialmente, é necessário que tenhamos o docker e o docker compose instalados, caso não tenha, siga o passo a passo da documentação de acordo com o seu sistema operacional.

Com o Docker instalado, iremos criar um arquivo chamado docker-compose.yml para parametrizarmos a criação do Docker do banco facilitando a criação da imagem e do container. Segue um exemplo do arquivo yml utilizando uma imagem mariaDb:

version: '3.4'

services:
  mariadb:
    image: mariadb:10.2
    environment:
      MYSQL_ROOT_PASSWORD: 'mypassword'
      MYSQL_DATABASE: 'mydatabasename'
      MYSQL_USER: 'mydatabaseuser'
      MYSQL_PASSWORD: 'mydatabasepassword'
    ports:
      - 3306:3306

Com isto, temos um arquivo yml que irá criar uma instância Mariadb, utilizando a imagem 10.2, com as credenciais configuradas no enviroment acessado pela porta 3306.

Após a criação do arquivo, acesse através do terminal o diretório do mesmo e rode o comando:

docker-compose up

Na primeira criação de imagem do Docker, o mesmo fará o download da imagem utilizada.

Utilizando outro terminal (o container ficará rodando neste terminal), utilize o seguinte comando para verificar se o container está ativo:

docker ps

O retorno esperado é algo similar a isso, que traz diversas informaçoes a respeito do seu container:

Acessando a sua base de dados

Agora que o container está ativo, utilizaremos alguma ferramenta de banco de dados para acessá-lo. Recomendo pessoalmente a utilização do Dbeaver mas fique a vontade para utilizar qualquer outro.

Entrando no Dbeaver, vamos em nova conexão (canto esquerdo superior), e selecionamos MariaDb

Nas credenciais, preenchemos o host como 'localhost' e port como '3306'. Em Database, Username e Password, preenchemos conforme o arquivo docker-compose.yml de configuração da base:

Ao clicar em Test connection, espera-se:

Por fim, agora clicamos em Finish e nosso banco de dados está configurado e conectado em uma ferramenta para visualização e manipulação de dados. Caso deseje conectar em alguma aplicação, utilize as credencias do arquivo compose.