Metodologia 12 fatores

3 de outubro de 2016
Compartilhe

Rita de Cássia Rodrigues – coordenadora dos cursos superiores de tecnologia em Análise e Desenvolvimento de Sistemas e Banco de Dados da FIAP – responde sobre a Metodologia 12 fatores.O que é a metodologia 12 fatores?É uma metodologia que aborda 12 fatores a serem seguidos, para a criação de um projeto SaaS com sucesso.O que é SaaS?SaaS, é uma sigla que significa “Software as Service”  (Software como serviço).Podemos afirmar, que este modelo de negócio de TI, é um modelo maduro e o mais conhecido pelo usuário final, e o que mais cresce no mercado de cloud computing.Neste modelo, não é necessário instalação ou atualização de software e nem licenças para uso.Ele funciona via internet, portanto, é acessível por qualquer dispositivo conectado.São exemplos de serviços disponibilizados como SaaS: Office Web Apps, Google Docs, sistemas de e-mail como Gmail e Hotmail e redes sociais como Facebook e Twitter.Como surgiu?A partir da necessidade de práticas ideais para o desenvolvimento de aplicações escritas em qualquer linguagem de programação e que utilizem qualquer combinação de serviços de suportes.Em virtude da experiência obtida pela plataforma Heroku, durante a criação e suporte de aplicativos SaaS, bem  como a observação de problemas sistemicos vistos durante o desenvolvimento destas aplicações e o oferecimento de soluções conceituais para os problemas observados, foi criado o 12factor.O que é Heroku?É uma plataforma de serviço em nuvem (PaaS), que roda sobre o Amazon EC2, que suporta várias linguagens de programação como: Ruby, Java, Node.js, Scala, Clojure, Python e PHP.Foi umas das primeiras plataformas em nuvem, em desenvolvimento desde 2007.A 12factor é uma metodologia para construir softwares que:

  • Usam formatos declarativos para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto;
  • Tem um contrato claro com o sistema operacional que o suporta, oferecendo portabilidade máxima entre ambientes que o executem;
  • São adequados para implantação em modernas plataformas em nuvem, evitando a necessidade por servidores e administração do sistema;
  • Minimizam a divergência entre desenvolvimento e produção, permitindo a implantação contínua para máxima agilidade;
  • E podem escalar sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento.

Os 12factors e sua aplicação

  1. Codebase

Gerenciar todos os códigos, através de um sistema de controle de versões (Git ou Subversion).Gerar vários deploys (Versão de código sendo executada em máquinas de desenvolvimento, testes ou produção).

  1. Dependencies

Declarar e isolar do código, qualquer dependência.Caso exista dependência de alguma ferramenta externa, banco de dados ou uma biblioteca de processamento de imagem, por exemplo, inserir uma versão desta biblioteca, em um diretório do projeto, garantindo que o deploy possa ser feito em qualquer servidor, e ainda, que não haverá a falta de alguma dependência.

  1. Config

Configurações podem variar entre ambientes diferentes, a ideia é armazenar as configurações no ambiente (não colocar configurações no código-fonte).Por exemplo, o código de comunicação com o banco de dados é sempre o mesmo, mas a localização do banco de dados será diferente para a máquina do desenvolvedor e do servidor de produção.Portanto todos os dados de configuração, devem ser armazenados separadamente do código, através de variáveis de ambiente, configuradas em cada servidor e lidas no momento da execução.

  1. Baking Services

Tratar serviços de apoio, como recursos ligados.São serviços consumidos, normalmente através da rede e que são partes necessárias para a operação da aplicação. São exemplos: bancos de dados, servidores de cache, serviços de e-mail e repositórios de arquivos.Esses serviços podem ser executados na mesma máquina, ou em hosts diferentes, data centers diferentes, isto não importa, seu código não precisa saber desta diferença.Isto traz flexibilidade, caso ocorra mudanças, não será necessário alterar o código.

  1. Build, realease, run

O codebase é transformado em um deploy por três estágios:Buid: Transformar em uma versão especifica do repositório com suas dependências e transformá-la em uma versão executável .Release: Enviar um build para um servidor e executar todas as configurações necessárias para o terceiro estágio.Execução: Inicializar todos os processos necessários para que os usuários possam utilizar.

  1. Processes

Diminuir o acoplamento entre os componentes do projeto para facilitar a escala.

  1. Port binding

Exportar serviços, através de portas.A princípio, como em todos os serviços de apoio consumidos, o aplicativo também faz interface com o mundo através de uma URL simples.Pode-se criar uma URL separada para o API que o website poderá utilizar, não passando por níveis de segurança (firewall e autenticação), fazendo que o tempo de execução seja otimizado.

  1. Concurrency

A ideia é dimensionar por um modelo de processo.Quando um código é executado, vários processos são executados atendendo necessidades especificas. Podemos ter por exemplo: processamento das solicitações web, chamadas de API´s, processamento de e-mails, envio de tweets, compartilhamento em serviços de mídia social.Cada um desses processos trabalha de forma independente, se forem executados como processos separados, teremos um melhor dimensionamento, sendo capaz de executar mais coisas ao mesmo tempo.

  1. Disposability

Maximizar a robustez com inicialização e desligamento rápidos.Ao implantar um novo código, é desejado que a nova versão seja iniciada imediatamente e que comece a responder ao tráfego.Se uma aplicação gastar 20 segundos para se preparar para atender ao tráfego, esta aplicação demorará mais tempo para ficar disponível, prejudicando o início/termino de processos independentes.Os processos precisam ser iniciados ou parados a qualquer momento.É esperada a robustez da aplicação, caso pare de funcionar, por alguma falha, a aplicação deve ser capaz de iniciar novamente, sem perda de dados ou qualquer outro possível problema.

  1. Dev/prod parity

Mantenha o desenvolvimento, teste, produção o mais semelhante possível.É importante ter um ciclo mais rápido entre o desenvolvimento de uma alteração e a implantação da mudança no ambiente de produção.Para que tenhamos um ciclo mais rápido, é desejável manter o ambiente local, de um desenvolvedor, o mais semelhante possível ao ambiente de produção.Isso significa usar os mesmos serviços de apoio, as mesmas técnicas de gerenciamento de configuração, as mesmas versões de bibliotecas de software, e assim por diante.

  1. Logs

Trate logs como fluxo de eventos.Os logs são importantes ferramentas, que nos permitem entender o comportamento de uma aplicação.Os logs permitem identificar erros, pontos de melhoria, ou seja, podemos controlar desde da inicialização do aplicativo com sucesso, até situações críticas como, informações de erros enviadas aos usuários.Em uma máquina de desenvolvimento, podemos ter um arquivo com tais informações, e em um servidor de produção, onde podemos consolidar os dados capturados e realizar a mineração de dados através do Hadoop.

  1. Admin Process

Executar tarefas de administração/gerenciamento, como processos pontuais.Devemos automatizar tarefas administrativas, uma vez que a aplicação pode rodar em diversos servidores, contemplando diversos processos. Tarefas como limpar cache, carregar dados, atualizar bases de dados, precisam ser facilitadas.Fontes:https://12factor.net/pt_br/http://gizmodo.uol.com.br/entenda-o-que-significa-saas-paas-e-iaas/http://imasters.com.br/box/ferramenta/heroku/http://www.cloudmarket.com.br/blog/cloud-computing/iaas-paas-e-saas-descubra-agora-tudo-sobre-os-3-modelos-de-nuvem/http://imasters.com.br/infra/cloud/os-12-fatores-uma-metodologia-para-criacao-de-projetos-saas/?trace=1519021197&source=singlehttp://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/Rita de Cássia Rodrigues – Coordenadora dos cursos superiores de tecnologia em Análise e Desenvolvimento de Sistemas e Banco de Dados da FIAP. Mestranda em Engenharia de Software pela University of Liverpool-UK. Possui MBA em Gestão de Projetos (PMI) e Especialização em Engenharia de Software. Experiência de mais de 20 anos na área de análise e desenvolvimento de sistemas e em gestão de projetos, tendo atuado em grandes empresas como Bovespa, G&P, GPTI, Banco Itaú.         

Nosso site armazena cookies para coletar informações e melhorar sua experiência. Gerencie seus cookies ou consulte nossa política.

Prosseguir