1.
Boas práticas na construção de serviços
1

2.
Grazi Bonizi
Coordeno a trilha de Arquitetura .Net no The Developers Conference,
compartilho código no GitHub, escrevo no Medium e no Blog da Lambda3, e
participo de Meetups e PodCasts normalmente sobre DevOps, Azure, .Net,
Docker e DDD
Consultora DevOps na Lambda3
Este é um exemplo de
subtítulo.
https://twitter.com/GraziBonizi
https://github.com/grazibonizi
https://www.linkedin.com/in/graziella-bonizi-b14835a0/
https://www.lambda3.com.br/L3/graziella-bonizi/
2

3.
Conteúdo
1 Origem, princípios e fatores
2 Fatores de Design
3 Fatores de Build & Release
4 Fatores de Gerenciamento
5 Próximos passos
Quais são nossas principais preocupações ao construir uma
aplicação? Que decisões valem a pena ser tomadas no início do
projeto para que a aplicação esteja "production-ready" desde as
primeiras features?
Ao longo da palestra vamos entender como os princípios da 12 Factor
Apps podem implementados para que a aplicação seja escalável,
íntegra e gerenciada adequadamente.
Porque 12 factor app?
12 Fator App é uma metodologia bem didática que reúne boas práticas para
construção de serviços, muito relacionado a desenvolvimento moderno,
containers, DevOps e plataforma em nuvem.
O objetivo hoje é mostrar como o 12 Factor App pode guiar a construção de
serviços prontos para serem publicados desde as primeiras versões.
Os fatores foram agrupados em três assuntos:
• Fatores de Design, que estão relacionados ao desenvolvimento e arquitetura da
aplicação em si,
• Fatores de Build & Release, que observam as práticas de integração e entrega
contínuas
• e Fatores de Gerenciamento, relacionados à administração e ao
monitoramento da aplicação em execução.
Para encerrar, vou outros dois fatores que talvez fizessem parte da metodologia
se ela fosse elaborada hoje, e vou demonstrar uma aplicação em .NET que
cumpre os 12 fatores.
3

4.
12 Factor App:
Origem, Princípios e
Fatores
4

5.
Origem
a lenta deterioração do software ao longo
do tempo que acabará por torná-lo
inutilizável. O software não decai, mas sofre
com a falta de atualização em relação à
mudança ambiente em que reside”
“Erosão de software
é
• Metodologia criada pelos colaboradores da
plataforma Heroku, em particular o co-fundador
Adam Wiggins;
• Heroku é uma plataforma PAAS poliglota;
• O time criou a metodologia com base na sua
experiência no que contribuiu para o sucesso e
resistência à erosão do Heroku.
• É destinada à construção de serviços, independente
de linguagem e plataforma
Em 2006, Adam Wiggins, fundador dos 12 fatores, criou uma aplicação web
simples e a compartilhou com alguns amigos. Ele deixou de utilizá-la, mas seus
amigos continuaram. Dois anos depois ele foi notificado que o site estava fora do
ar.
Logando no servidor com ssh, ele descobriu que:
• O processo da aplicação tinha quebrado e não reiniciou;
• A utilização do disco tinha atingido 100% por causa dos arquivos de log e
dados de sessão;
• O kernel, ssh, openssl e apache precisavam de atualizações de segurança
críticas;
• A distribuição do linux tinha sido descontinuada, e não possuía as atualizações
de segurança necessárias. Ele tentou migrar a aplicação para outra VM com
um Sistema Operacional atualizado, mas a aplicação quebrou por uma série de
motivos, como apontamentos locais que eram diferentes neste Sistema
Operacional, e mudanças em dependências externas.
Em resumo, a aplicação atingiu um estado não funcional, sem nenhuma alteração
no código que estava funcionando.
Ele tinha acabado de vivenciar um caso impactante de Erosão de Software.
5

6.
• 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 ambientes, como 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.
É uma metodologia para construir softwares-
como-serviço que:
6

7.
Os fatores
1 Codebase
2 Dependencies
3 Config
4 Backing services
5 Build, release, run
6 Processes
7 Port binding
8 Concurrency
9 Disposability
10 Dev/prod parity
11 Logs
12 Admin processes
7

8.
Fatores de Design
8

9.
Port Binding
• Self-Hosted Apps: a aplicação deve ser capaz de
inicializar e ouvir e responder a uma porta
• O HTTP Server deixa de ser um elemento externo e
passa a ser uma dependência da aplicação
Exporte os serviços via
port binding
Tradicionalmente as aplicações eram compiladas e publicadas em WebServers
externos, como IIS e Apache.
Com o desenvolvimento moderno, os webservers deixam de ser um elemento
externo e passam a fazer parte da aplicação como dependência.
O efeito é a aplicação ser auto-contida, isto é, capaz de se “hospedar” sozinha e
ser executada como um processo web vinculado a uma porta.
No ambiente de desenvolvimento, o programador acessa a URL local, como
http://localhost:5000, e no ambiente de deploy, uma URL pública é vinculada à
URL local, como http://www.12factor.net .
9

10.
Processes and concurrency
• Não dependa de sessões ou dados armazenados no
ambiente
• Informações de sessão devem ser armazenadas numa
Store externa
• Mais de um serviço deve poder ser instanciado sem
impacto no funcionamento da aplicação
Execute a aplicação
como um ou mais
serviços sem estado
Ainda muito relacionado ao fator Port-Binding, os fatores Processes e
Concurrency permitem que a aplicação seja escalada verticalmente (várias
instâncias na mesma máquina) e horizontalmente (várias instâncias em
máquinas diferentes).
A aplicação é executada como um processo que não compartilha estado,
portanto, pode ser gerenciada isoladamente.
10

11.
Backing Services
• Serviços devem ser configurados via um único ponto de
entrada
• O apontamento deve ser externo, como uma URL em
um arquivo de configuração
Trate o consumo de
serviços como
recursos atachados
Os serviços que a aplicação consome, como banco de dados, provedores de email
e etc devem poder ser “atachados” ou “desatachados“ facilmente por meio de um
único ponto de entrada, normalmente uma URL, com seu apontamento em um
arquivo de configuração
11

12.
Disposability
• Os ambientes devem poder ser descartados e
escalados sempre que necessário
• A aplicação deve poder trocar de ambiente sem impacto
no funcionamento
Maximize a robustez
com startups rápidos e
“graceful shutdowns”
“Servidores não são bichinhos de estimação”
Originalmente, devido ao modelo de desenvolvimento e operações, os servidores
eram tratados com “carinho”. O custo operacional e financeiro para trocar a
aplicação de ambiente era alto.
No desenvolvimento moderno, as aplicações podem ser facilmente trocadas de
ambiente caso haja a necessidade. Utilizando infraestrutura como serviços a
velocidade para realocar aplicações saindo de um servidor com problemas para
um saudável é mínima. Com Plataforma como Serviços (PaaS) ou orquestradores
de containers, como Kubernetes, isso é feito automaticamente sem a
necessidade de intervenção manual.
Isso é possível porque ao cumprir os 12 fatores, os processos de aplicação são
descartáveis, rápidos para inicializar e “graciosos ao encerrar”. No caso de
processos web isso implica em finalizar as requisições em execução
adequadamente sem deixar processos presos, conexões abertas ou “rastros”. As
aplicações também são preparadas para lidar com interrupções súbitas.
12

13.
Fatores de Build &
Release
13

14.
Codebase
• Use um versionador de código (git)
• Aplicações que possuem ciclos de vida distintos devem
estar em repositórios distintos
• O que é promovido é o artefato, não o código
• Escolha uma estratégia de branches adequada
• Configure a integração contínua
Uma única base de
código rastreada em
um sistema de revisão
com múltiplos deploys
Existe sempre uma correlação um-para-um entre a base de código e a
aplicação:
• Se existem várias bases de código, isto não é uma app – é um sistema
distribuído. Cada componente do sistema é uma app, e cada uma pode
individualmente ser compatível com os 12 fatores.
• Múltiplas apps compartilhando uma base de código é uma violação dos
12 fatores. A solução aqui é dividir o código compartilhado entre
bibliotecas que podem ser incluídas através do gerenciador de
dependências.
14

15.
Dependencies
• Deixe claro quais dependências e versões sua aplicação
utiliza
• Não utilize dependências compartilhadas entre
aplicações (GAC, Com+)
• Isole o ambiente da aplicação
Declare de forma
explícita e isole as
dependências
As dependências da aplicação e suas versões estão claramente enumeradas
(packages.json, arquivos pom, etc).
Não utilize dependências compartilhadas. Quando mais de uma aplicação utiliza a
mesma dependência no sistema operacional, a atualização de uma pode impactar
na outra.
Isso facilita o setup da aplicação na máquina de desenvolvimento, por exemplo.
Após obter o código, executar um comando simples, como nuget restore ou npm
install será o suficiente para baixar todas as dependências corretas e deixar a
aplicação pronta para ser compilada.
15

16.
Config
• Não utilize apontamentos e varíaveis de uma forma que
seja necessária a recompilação da aplicação
• As configurações que dependem do ambiente em que a
aplicação será publicada devem ser isoladas para o
ambiente em questão
• Utilize variáveis de ambiente, arquivos ou serviços
externos de configuração
• Se você fosse abrir o código da sua aplicação hoje,
alguma informação confidencial seria comprometida?
Armazene a
configuração do
ambiente no próprio
ambiente
16

17.
Build, Release, Run
• Release: Artefato de Build + Parâmetros, arquivos de
configuração e secrets relativos ao ambiente
Separe os estágios de
construção e execução
Uma base de código é transformada num deploy através de três estágios:
• Build: O estágio de construção é uma transformação que converte um
repositório de código em um pacote executável, ou artefato.
• Release: O estágio de entrega obtém o artefato produzida pelo estágio de
construção e o combina com a configuração atual do ambiente em que será
publicado, resultando em uma aplicação pronta para ser executada.
• Run: O estágio de execução roda o app no ambiente de execução, através do
início de alguns dos processos do app com um determinado artefato.
Com a implementação adequada de integração contínua e entrega contínua, o
artefato é rastreado facilmente à versão de código que o gerou.
17

18.
Dev/Prod Parity
• Ambiente de desenvolvimento, testes e produção deve
ser tão compatível quanto possível
• Mesmas dependências e serviços consumidos
• Base de código deve ser semelhante à produção
(Continuous Deployment)
• Desenvolvedores devem estar próximos do deploy
Mantenha o
desenvolvimento,
homologação e
produção tão similares
quanto possível
Historicamente, houveram lacunas substanciais entre desenvolvimento (um
desenvolvedor codificando) e produção (a aplicação disponível para os usuários
finais). Essas lacunas se manifestam em três áreas:
• A lacuna do tempo: Um desenvolvedor pode trabalhar em código que demora
dias, semanas ou até meses para ir para produção.
• A lacuna de pessoal: Desenvolvedores escrevem código, engenheiros de
operação fazem o deploy dele.
• A lacuna de ferramentas: Desenvolvedores podem estar usando um conjunto
como Nginx, SQLite, e OS X, enquanto o app em produção usa Apache, MySQL,
e Linux.
Olhando as três lacunas descritas acima:
• Diminua a lacuna de tempo: um desenvolvedor pode escrever código e ter o
deploy feito em horas ou até mesmo minutos depois.
• Diminua a lacuna de pessoal: desenvolvedores que escrevem código estão
proximamente envolvidos em realizar o deploy e acompanhar seu
comportamento em produção.
• Diminua a lacuna de ferramentas: mantenha desenvolvimento e produção o
mais similares possível.
18

19.
Fatores de
Gerenciamento
19

20.
Logs
• Um log é um stream de eventos sequenciais produzidos por
uma aplicação em execução
• Um log não tem início, nem fim, mas é contínuo enquanto a
aplicação estiver rodando
• A aplicação não deveria se preocupar em armazenar o log
• Os logs podem ser vistos no terminal
• Um serviço externo deve ser configurado para coletar os logs e
armazená-los em um local centralizado
Trate logs como fluxo
contínuo de eventos
Tradicionalmente as aplicações salvam os logs em algum arquivo de output, e
isso traz a preocupação com armazenamento e gerenciamento de logs.
Na metodologia 12 fatores, os logs são tratados como um fluxo contínuo de
eventos sem começo ou fim, disponível no terminal, e outras aplicações são
responsáveis por coletá-los e armazená-los.
20

21.
Admin Processes
• Tarefas administrativas devem fazer parte do deploy da
aplicação que estão relacionadas
• Exemplos: scripts de migração, monitoramento ou correções
de ambiente
Execute tarefas de
administração/gestão
como processos
pontuais
Algumas aplicações possuem tarefas administrativas, como migração de modelo
de banco de dados ou inspeção de ambiente.
Esse tipo de tarefa é tratada como parte da aplicação, desde a base de código até
a construção e entrega.
Um operador não terá que fazer alterações no ambiente de execução da aplicação
para executá-las porque elas já estarão prontas e disponíveis no ambiente.
21

22.
Próximos passos
22

23.
Próximos passos
• Os 12 fatores tem um objetivo claro, envolvendo portabilidade
e escalabilidade
• Podem ser utilizados como uma Checklist para o
desenvolvimento e deploy de aplicações
• Por mais que não envolva padrões de qualidade de códido, não
significa que esse assunto deva ser ignorado
• A metodologia pode ser estendida para contemplar outros
fatores que o time julgue necessário
Telemetria
Segurança
Padrões de qualidade
O que mais?
23

24.
Excelência técnica para acelerar sua jornada digital.
w w w . l a m b d a 3 . c o m . b r
24