Construindo aplicações saudáveis e prontas para envelhecer

1. Construindo aplicações saudáveis e prontas para envelhecer ! The 12(15) Factors Roberto Santacroce Martins

2. 12 Factor App - Foi criada por Adam Wiggins enquanto trabalhava no Heroku por volta de novembro de 2012 - Crescimento orgânico de uma aplicação pelo tempo - Altera a dinâmica de colaboração entre os desenvolvedores - Software As a Service (Software como um Serviço) - Auxilia você a medir o quanto a sua aplicação está pronta para o Cloud - Revisitado pela Pivotal em 2016 - Beyond the 12 Factor App (Kevin Hoffman)

3. 12 Factor App ● ESCALABILIDADE ELÁSTICA ● SISTEMA DE ARQUIVOS EFÊMERO ● STATELESSNESS (SEM ESTADO.) ● TRATE TUDO COMO SERVIÇO ● ESCALE E FAÇA DEPLOY RAPIDAMENTE

4. A promessa “Java Servlet API 2.2 includes one new feature so significant it may change the way Web works. That feature: Web applications.” “With Web apps, the entire application can be contained in a single archive file and deployed by placing the file into a specific directory.” - Javaworld.com, 1999

5. OS 12 FATORES ● Base de Código ● Dependências ● Configurações ● Serviços de Apoio ● Build, release and run ● Processos ● Port Binding ● Concorrência ● Descartabilidade ● Dev/Prod Semelhantes ● Logs ● Processos de Admin

6. OS 15 FATORES Um Repositório, Um App API First Gerenciamento de Dependências Design, Build, Release and Run Configurações, Credenciais e Código Logs Descartabilidade Serviços de Apoio Dev/Prod Semelhantes Processos Administrativos Port Binding Processos Stateless (Sem Estado) Concorrência Telemetria Autenticação e autorização

8. Um Repositório, Um App Repositório de código ÚNICO para MÚLTIPLOS RELEASES IMUTÁVEIS um para cada ambiente Múltiplas aplicações com o um único código fonte é geralmente um sinal de que muitos times estão trabalhando no mesmo código "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" Conway's Law - Circa 1968

10. API First Integrações do inferno, os ambiente não tem arco-iris nem tampouco unicornios Extensão do "Contract First Pattern" Desenvolvedores mantém uma interface coerente e com o auxílio de Continuous Integration valida as comunicações API Mock Mobile First

12. Gerenciamento de Dependências Servidor da Mamãe, nele temos o application server, o gerenciador de ﬁlas, o gerenciador de backup, o ﬁrewall e a NOSSA APLICAÇÃO Modelo Enterprise (criança) - Cloud (papai) Aplicações precisam amadurecer para tirar melhor vantagens do ambiente Gerenciadores de dependencias explícitos como: Maven, Gradle, NPM, CPAN e outros ...

14. Design, Build, Release and Run Design: Mapeamento de Dependências Build: Compilação e produção do artefato Release: Empacota a aplicação com suas conﬁgurações Run: Deploy

15. Modelo de deploy tradicional

16. Deploy moderno de um aplicação java

17. Modelo de deploy moderno

19. Configurações, Credenciais e Código Configurações são parâmetros que MUDAM quando o AMBIENTE muda Arquivos properties, XML ou YAML nem sempre são a melhor opção Utilize uma mescla de arquivos de configuração + variáveis de ambiente Uma boa prática é usar um servidor de configuração capaz de fornecer as configurações para as aplicações em tempo de execução (Spring Cloud Config, Consul, etc …)

20. LINUX /etc/... TOMCAT context.xml server.xml Conﬁgurações HOJE WAR web.xml

21. AMBIENTE PATH DATABASE_URL TOKEN_ACCESS_CODE JAVA_OPTS Conﬁgurações 12 Factors Java Application

23. Logs Trate logs de forma efêmera, o ambiente é responsável por gerenciar o local de armazenamento dos logs e a sua rotatividade Pense em logs como eventos de informações relacionadas a sua aplicação Utilize ferramentas como agregaçõa de logs como Elasticsearch Logstash Kibana e/ou Splunk

25. Descartabilidade Aplicações não devem manter ESTADO em memória Aplicações podem ir e vir com intervenção ou exceções Aplicações devem iniciar em segundos e não minutos (aumentar o timeout não resolve o problema) Aplicação devem morrer de forma graciosa Nos permite extender a aplicação rapidamente no ambiente de Cloud

27. Serviços de Apoio (Backing Services) Todo o serviço que sua aplicação depende para funcionar Outras aplicações devem ser tratadas como Serviços de Apoio Essas dependências devem ser DECLARATIVAS Banco de dados, ftp, smtp, gerenciadores de ﬁlas, etc ….

29. Dev/Prod Semelhantes - Every Commit Is a Candidate for Deployment "Funciona na minha maquina" - Programador desavisado Manter de forma DECLARATIVA as dependências para construir o ambiente Tempo: Espaço de tempo muito grande entre o código e o deploy Pessoas: Deploy e/ou tarefas de provisionamento são feitas por humanos criando um mar de possíveis erros Recursos: Manter um ambiente local o mais próximo da produção inclusive com ferramentas, etc ….

30. Containerless O container está morto Longa vida ao container SERVLET CONTAINER APPLICATION SERVER DOCKER LXC

35. Processos Administrativos Migrações de Banco de Dados REPL: Ambiente interativo de programação Batch scripts Devem ser separados da aplicação

37. Port Binding Platform as a Service Evite containers que gerencia aplicações enterprise, quando usar sempre manter 1:1 Container:Aplicação Rode seus serviços anexando PORTAS e use DNS para facilitar a vida dos usuários Aplicações são Backing Services (Serviços de Apoio)

39. Processos Stateless (Sem Estado) Não deve depender dos dados em memória para iniciar o seu processamento Todos os ESTADOS que devem ser persistidos por algum tempo devem estar em Backing Services/Serviços de Apoio "Sharing Nothing Pattern": O sistema de arquivos não é um Backing Service e não deve ser usado para troca de informações. Ele é efêmero. Data Caching: Não use cache em sua aplicação pode acabar com a sua RAM. Use um serviço especializado (Backing Service) para a tarefa (Gemﬁre, Redis, etc ….)

41. Concorrência Se você aumenta Memória, CPU e/ou RAM você está "Escalando Verticalmente" Quando você tem muitas instâncias da sua aplicação você está "Scaling Out" ou "Escalando Horizontalmente" Se você segue os princípios de Descartabilidade, Stateless e Share-nothing suas aplicações estão prontas para "Escalar Horizontalmente"

43. Telemetria Application Performance Monitoring (APM) New Relic, jvisualvm Domain-speciﬁc telemetry Health and System Logs Informações sobre a saúde da aplicação (check-up)

45. Autenticação e Autorização Pense no inicio, hoje toda aplicação carrega consigo o requisito funcional de segurança Não deixe a conﬁança te trair Faça um vasto uso de criptograﬁa RBAC - Role-Based access control Padrões são bem vindos para a implementação (OAUTH2, OpenID, etc …)

46. RESUMO 1. Desacople os dados. Você não os quer dentro do seu sistema 2. Resiliência - Componentes "fazendo uma coisa e fazendo muito bem" (Do one thing and do it well) 3. Mantenha a comunicação a um mínimo possível. Você tem que ter acesso aos dados mesmo se os componentes morrerem 3. Pense em como vai performar com alto volume 4. Segurança - Pense nisso desde o inicio. SÉRIO !

47. UM POUCO DE HISTÓRIA The Unix Philosophy foi iniciado com o Ken Thompson Um conjunto de normas culturais e uma abordagem ﬁlosóﬁca para o - minimalismo computacional: usar o mínimo de software e hardware o possível "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." - Peter H. Salus The Art of Unix Programming - Eric Steven Raymond Worse is Better - Richard Gabriel - less functionality is better usability

Construindo aplicações saudáveis e prontas para envelhecer

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Construindo aplicações saudáveis e prontas para envelhecer

Semelhante a Construindo aplicações saudáveis e prontas para envelhecer (20)

Construindo aplicações saudáveis e prontas para envelhecer