https://speakerdeck.com/fellipems 2021-09-15 12:00:06 -0400 MICROSERVIÇOS: É um tipo de arquitetura e desenvolvimento de software em que a aplicação consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. As arquiteturas de microsserviços facilitam a escalabilidade e agilizam o desenvolvimento de aplicativos. -- ARQUITETURA EVOLUTIVA: O primeiro princípio de uma arquitetura evolutiva é as mudanças estruturais que não, entre aspas, quebram a aplicação. A arquitetura baseada em microsserviços, é um bom exemplo deste tipo de arquitetura. Mais usado quando não sabemos todas as funcionalidades de nossa aplicação ou a proporção que ela poderá tomar, então ela suporta mudanças contínuas e incrementais. Disponibilizamos pequenas mudanças com decisões reversíveis, alterando conforme a nossa necessidade. Evolutivo ao previsível. Cultura da experimentação, sustentado à hipóteses. Começar simples e, conforme forem surgindo novas funcionalidades, ir também evoluindo e adaptando a arquitetura. A arquitetura deve acompanhar e crescer paralelamente à aplicação, assim, deve ser ágil. -- SERVICE MESH: Em português - malha de serviço. Nada mais é do que uma das camada de infraestrutura configurável de comunicação entre vários microsserviços que fazem parte uma determinada aplicação/solução com uma série de funcionalidades. -Segurança por encriptação (mTLS, etc); -Balanceamento de carga (load balancing); -Observabilidade (do inglês “observability”, são insumos para se determinar o comportamento e estado da aplicação); -Rastreabilidade (do inglês “traceability”, é capacidade de correlacionar eventos e transações em uma linha temporal); -“Circuit breaker” (interrupção de um fluxo de comunicação para evitar outras falhas em cadeia); -Autenticação e autorização e estratégias de ROLLOUT. -- ROLLOUT: A grosso modo, é estratégia para implementar uma nova versão e testar alguma hipótese no negócio. Tipos de Rollout: -BLUE/GREEN: é um modelo de release que transfere o tráfego do usuário de uma versão anterior de um aplicativo ou microsserviço para uma nova versão basicamente idêntica — ambos estão em execução em produção. A versão antiga pode ser chamada de ambiente azul, enquanto a nova versão pode ser conhecida como o ambiente verde. Já que terá dois ambientes idênticos em produção, pode deixar o tráfego no ambiente antigo e ir testando a versão azul, para depois transferir todo o tráfego para a versão nova. Uma vez que o tráfego de produção é totalmente transferido do azul para o verde, o azul pode ficar de prontidão em caso de reversão ou retirado da produção e atualizado para se tornar o modelo sobre o qual a próxima atualização é feita.), - CANARY(Muito parecido com o Blue/Green é uma técnica para reduzir o risco da introdução de uma nova versão do software em produção, fazendo o lançamento gradual da mesma para uma pequena parte do conjunto de usuários antes de implantá-la em toda a infraestrutura e torná-la acessível a todos.), -A/B TESTING(verifica alguma feature através de características(se tiver acessando pelo celular acessa tal versão, pelo PC outra versão) várias versões executadas em paralelo, controle total sobre a distribuição do tráfego, requer load balancer inteligente, difícil de solucionar erros em uma determinada sessão pois consistem em direcionar um subconjunto de usuários para uma nova funcionalidade em condições específicas. Geralmente é uma técnica para tomar decisões de negócios com base em estatísticas, em vez de uma estratégia de implantação. No entanto, ele está relacionado e pode ser implementado adicionando funcionalidade extra a uma implantação canária. Aqui está uma lista de condições que podem ser usadas para distribuir tráfego entre as versões: -Por cookie do navegador -Parâmetros de consulta -Geolocalização -Suporte à tecnologia: versão do navegador, tamanho da tela, sistema operacional, etc. -Idioma -- Automatizando Service Mesh com Charles C.D - ferramenta de Continuous Deployment - auxilia na publicação com estratégia de deploy segmentado(para algum tipo de usuário/cliente e afins). É uma nova abordagem que conseguimos segmentar os usuários em múltiplas versões da mesma aplicação com propósitos e segmentos distintos. -- Istio, o que é? É um service mesh open source que se associa a diversas camadas da aplicação distribuída, de forma transparente. Os recursos do Istio fornecem uma maneira uniforme e mais eficiente de proteger, conectar e monitorar os serviços. Balanceamento de carga, autenticação, serviço a serviço e monitoramento com poucas ou nenhuma alteração no código da aplicação. -- https://www.redhat.com/cms/managed-files/service-mesh-1680.png Em um service mesh, as solicitações são comunicadas entre microsserviços utilizando proxies em uma camada própria. Por esse motivo, os proxies que compõem uma service mesh são, às vezes, chamados de "sidecars", pois são executados paralelamente a cada serviço, não dentro dele. Juntos, esses proxies "sidecars", desacoplados de cada serviço, formam uma rede em malha. -- REFERÊNCIAS https://aws.amazon.com/pt/microservices/ https://www.objective.com.br/insights/arquitetura-evolutiva-o-que-voce-precisa-saber/ http://equinocios.com/arquitetura/2017/03/03/Introducao-a-arquitetura-evolutiva/ https://www.redhat.com/pt-br/topics/microservices/what-is-a-service-mesh https://www.infoq.com/br/articles/service-mesh-ultimate-guide/ https://istio.io/latest/about/service-mesh/ https://medium.com/codigorefinado/oque-%C3%A9-service-mesh-e-porque-n%C3%B3s-precisamos-disto-5e48ed31b7ea https://martinfowler.com/bliki/BlueGreenDeployment.html https://www.thoughtworks.com/pt-br/insights/blog/implanta%C3%A7%C3%B5es-can%C3%A1rio https://thenewstack.io/deployment-strategies/ MICROSERVIÇOS: É um tipo de arquitetura e desenvolvimento de software em que a aplicação consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. As arquiteturas de microsserviços facilitam a escalabilidade e agilizam o desenvolvimento de aplicativos. -- ARQUITETURA EVOLUTIVA: O primeiro princípio de uma arquitetura evolutiva é as mudanças estruturais que não, entre aspas, quebram a aplicação. A arquitetura baseada em microsserviços, é um bom exemplo deste tipo de arquitetura. Mais usado quando não sabemos todas as funcionalidades de nossa aplicação ou a proporção que ela poderá tomar, então ela suporta mudanças contínuas e incrementais. Disponibilizamos pequenas mudanças com decisões reversíveis, alterando conforme a nossa necessidade. Evolutivo ao previsível. Cultura da experimentação, sustentado à hipóteses. Começar simples e, conforme forem surgindo novas funcionalidades, ir também evoluindo e adaptando a arquitetura. A arquitetura deve acompanhar e crescer paralelamente à aplicação, assim, deve ser ágil. -- SERVICE MESH: Em português - malha de serviço. Nada mais é do que uma das camada de infraestrutura configurável de comunicação entre vários microsserviços que fazem parte uma determinada aplicação/solução com uma série de funcionalidades. -Segurança por encriptação (mTLS, etc); -Balanceamento de carga (load balancing); -Observabilidade (do inglês “observability”, são insumos para se determinar o comportamento e estado da aplicação); -Rastreabilidade (do inglês “traceability”, é capacidade de correlacionar eventos e transações em uma linha temporal); -“Circuit breaker” (interrupção de um fluxo de comunicação para evitar outras falhas em cadeia); -Autenticação e autorização e estratégias de ROLLOUT. -- ROLLOUT: A grosso modo, é estratégia para implementar uma nova versão e testar alguma hipótese no negócio. Tipos de Rollout: -BLUE/GREEN: é um modelo de release que transfere o tráfego do usuário de uma versão anterior de um aplicativo ou microsserviço para uma nova versão basicamente idêntica — ambos estão em execução em produção. A versão antiga pode ser chamada de ambiente azul, enquanto a nova versão pode ser conhecida como o ambiente verde. Já que terá dois ambientes idênticos em produção, pode deixar o tráfego no ambiente antigo e ir testando a versão azul, para depois transferir todo o tráfego para a versão nova. Uma vez que o tráfego de produção é totalmente transferido do azul para o verde, o azul pode ficar de prontidão em caso de reversão ou retirado da produção e atualizado para se tornar o modelo sobre o qual a próxima atualização é feita.), - CANARY(Muito parecido com o Blue/Green é uma técnica para reduzir o risco da introdução de uma nova versão do software em produção, fazendo o lançamento gradual da mesma para uma pequena parte do conjunto de usuários antes de implantá-la em toda a infraestrutura e torná-la acessível a todos.), -A/B TESTING(verifica alguma feature através de características(se tiver acessando pelo celular acessa tal versão, pelo PC outra versão) várias versões executadas em paralelo, controle total sobre a distribuição do tráfego, requer load balancer inteligente, difícil de solucionar erros em uma determinada sessão pois consistem em direcionar um subconjunto de usuários para uma nova funcionalidade em condições específicas. Geralmente é uma técnica para tomar decisões de negócios com base em estatísticas, em vez de uma estratégia de implantação. No entanto, ele está relacionado e pode ser implementado adicionando funcionalidade extra a uma implantação canária. Aqui está uma lista de condições que podem ser usadas para distribuir tráfego entre as versões: -Por cookie do navegador -Parâmetros de consulta -Geolocalização -Suporte à tecnologia: versão do navegador, tamanho da tela, sistema operacional, etc. -Idioma -- Automatizando Service Mesh com Charles C.D - ferramenta de Continuous Deployment - auxilia na publicação com estratégia de deploy segmentado(para algum tipo de usuário/cliente e afins). É uma nova abordagem que conseguimos segmentar os usuários em múltiplas versões da mesma aplicação com propósitos e segmentos distintos. -- Istio, o que é? É um service mesh open source que se associa a diversas camadas da aplicação distribuída, de forma transparente. Os recursos do Istio fornecem uma maneira uniforme e mais eficiente de proteger, conectar e monitorar os serviços. Balanceamento de carga, autenticação, serviço a serviço e monitoramento com poucas ou nenhuma alteração no código da aplicação. -- https://www.redhat.com/cms/managed-files/service-mesh-1680.png Em um service mesh, as solicitações são comunicadas entre microsserviços utilizando proxies em uma camada própria. Por esse motivo, os proxies que compõem uma service mesh são, às vezes, chamados de "sidecars", pois são executados paralelamente a cada serviço, não dentro dele. Juntos, esses proxies "sidecars", desacoplados de cada serviço, formam uma rede em malha. -- REFERÊNCIAS https://aws.amazon.com/pt/microservices/ https://www.objective.com.br/insights/arquitetura-evolutiva-o-que-voce-precisa-saber/ http://equinocios.com/arquitetura/2017/03/03/Introducao-a-arquitetura-evolutiva/ https://www.redhat.com/pt-br/topics/microservices/what-is-a-service-mesh https://www.infoq.com/br/articles/service-mesh-ultimate-guide/ https://istio.io/latest/about/service-mesh/ https://medium.com/codigorefinado/oque-%C3%A9-service-mesh-e-porque-n%C3%B3s-precisamos-disto-5e48ed31b7ea https://martinfowler.com/bliki/BlueGreenDeployment.html https://www.thoughtworks.com/pt-br/insights/blog/implanta%C3%A7%C3%B5es-can%C3%A1rio https://thenewstack.io/deployment-strategies/ Wed, 15 Sep 2021 00:00:00 -0400 https://speakerdeck.com/fellipems/arquitetura-evolutiva-e-service-mesh https://speakerdeck.com/fellipems/arquitetura-evolutiva-e-service-mesh