Matando WebForms e

modernizando um Grande

Varejista

Como é possível modernizarmos o velho, mantermos compatibilidades e garantirmos o negócio?

Apresentação

Palestrante: José Roberto Araújo

Palestrante | Arquiteto de Sistemas

Onde me encontrar? Email: jroberto.araujo@gmail.com e também...

Grupos:

@CrazyTechGuys

@IoTWeekend@AspNet BR

Redes Sociais:

@Slideshare { /jroberto.jr }

@Facebook { /joserobertoaraujo }

@Twitter { @jrobertofaraujo }

@Linkedin { /joserobertoaraujo }

@Blog { http://www.jrobertoaraujo.net }

Um pouco da história

O Grande Desafio...

Inovar o ecommerce, mantendo

conversão de clientes e vendas

Aumentar performance, sem

aumentar o consume de vCPUs,

Memória e I/O de disco e Rede

Reutilizar o checkout? Usaram Api,

Não? Não!!! Aumento da curva de aprendizado do time !!!

Backoffice, onde fica nisso tudo?

Inovar aplicando os conceitos web

de SEO, WPO (Web Presentation

Optimized)

Estratégia da Convivência

Como estava o cenário?

Cenário caótico e com váriasdefinições de negócio divergentes

Aplicação com várias falhas de desenvolvimento e lógica

Descrédito sobre a utilização do REDIS. Porquê? Qual foi a outrasolução?

Não havia servidores de Testes integrados e Staging (Pré-Produção)

Tudo baseado no AspNet Cache, serviço windows, entreypoint únicopara atualização do cache, tudonum único Application Pool

NGINX desatualizado e mal configurado

Sem Rumo = CAOS

Ações planejadas

TDD + MTM

DDD ? Sim, para alguns casos!

Entityframework? Sim, usamos !

Implementação de técnicas de WPO

Implementação de carregamento assincrono dos Assets: Javascript e CSS

Implementação de recomendações de SEO

Continuar com AspNet Cache? Porquê? Quais ganhos? Quais perdas?

Grande inclinação para utilizar o REDIS

Servidores de Testes e Staging

Teste de Carga

Atualização do Nginx e Revisão de suas configurações

Refatoração e adequação do Backoffice

Colocando cada coisa em seu lugar…

Migrar 100% não seria o caminho?

Esse seria o caminho…

Não daria para entregar o

projeto completo, em

tempo hábil. (4 meses)

Morte do Projeto e Desgaste dos Desenvolvedores

WPO – Web Performance Optimization

WPO – Web Performance Optimization

O que aconteceu ao subir as novidades

da Nova Plataforma?

ROLLBACK por 3X

Porquê?

Consumo altíssimo das vCPUs

Consumo altíssimo de Memória

Alto indice de I/O nos Web Servers

Mas onde estavam os problemas? Ação HARD...

E…

Só tinhamos mais uma chance, final de

Setembro/2015! E fizemos um novo Deploy

Nem tudo são flores…

Lock de objetos implementados inadequadamente

Implementação LINQ utilizando vários .Includes

Stored Procedures mal implementadas Lockando

registros

Paralelismo utilizado inadequadamente

Problemas de performance na aplicação REDIS,

pagando o preço por estrégias inadequadas

Tivemos que abrir mão dos testes de unidade já

iniciados (Diante de alguns rollbacks, não tinhamos

tempo para “desperdiçar” com TDD – Doce ilusão)

Retorno do filho pródigo: AspNet Cache !!!

O que houve com o Redis?

Armazenamento mal planejado

Estratégia das chaves-valor sem lógica e

fora dos padrões recomendados

Throughput muito alto de rede (Tráfego

de um grande volume de objetos em

requisições simples)

Mas o REDIS não resolve cenários de alta

performance?

Retorna, assim, o AspNet Cache!!!

Vejo sinais de Code Smell

1º Arquitetura utilizada na plataforma

Como ficou ao de subir as novas

implementações da Nova Plataforma?

Overload de CPU?

107% em algumas CPUs

O que levou a esse cenário?

Utilização de recursos de programação de forma inadequada

Paralelismo em consultas LINQ

Lock em blocos de código, segurando outras requests a executarem o código

Pagamento da dívida de ter removido os Testes de Unidade

Várias requests e consultas sendo executadas pela aplicação, para a mesma informação

Iterações em 10k+ registros aplicando operações com strings com Regex

O que tivemos que analisar?

Dump de memória de Produção e Homologação

Aplicação de filtros e indicadores para análise de performance através do PerfMon

Aplicação do Dump de memória ao Debug Diagnostic Tools

O que tivemos que analisar?

O que tivemos que analisar?

Onde está Wally? Ou melhor Code Smell?

O bom filho a casa torna: REDIS !!!

Estratégias utilizadas

Análise do fluxo do negócio

Análise sobre a utilização das informações e grau de mudança das informações no site

Levantamento sobre qual navegabilidade o usuário esperava do portal

Chaveamento das informações por departamento, dentro do portal

Aplicação do conceito Get-Fetch (Buscar e Carregar)

Aplicação de filtros de dados dentro nas estruturas de dados no Redis

Implementação dos servidores do Redis no mesmo barramento de Rede dos WebServers

2º Arquitetura utilizada na plataforma

Blackfriday após a subida das melhorias

Como ficou o Load time comparado aos

concorrentes ?

Processamento Backoffice

Dashboard de acompanhamento do

processamento do Backoffice

Talk is Cheap…

Conclusão

1. Realize SEMPRE uma Análise sobre as expectativas do seu cliente.

Frustra-las será seu pior fracasso.

2. Busque SEMPRE inovar, com MODERAÇÃO.

NÃO utilize tudo de novo que o Mercado oferece, nem tudo se encaixa com suas necessidades.

3. Entenda o perfil do seu time.

Você será o principal fator para seu time performar

4. Mesmo tomando todos os cuidados, tenha ferramentas, estratégias e conhecimento para sanar osproblemas.

Caso contrário, um pequeno ponto no código poderá levar seu projeto ao fracasso.

5. Fique sempre antenado no Mercado e busque aplicar as melhores práticas.

Elas normalmente te encaminharam para o sucesso do seu projeto, motivação do seu time e garantia de um cenário mais controlado.

6. Trabalhem bem sua arquitetura, NUNCA a Negligencie.

O preço dela é ALTÍSSIMO, a conta chega e o pagamento, as na maioria das vezes não é tão trivial. Gerandocenários nocivos ao seu negócio.

Dúvidas / Perguntas

Obrigado !!!