Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuários
1.
2. Estudo de Caso: Aplicação DataSnap para 10.000
usuários
Mario Guedes
3. Que Mario?
• 40 anos, pai do Júlio e da Fernanda
• Conectado desde 1999 (20 anos!)
• Sou artesão de Software em Delphi, Python, Lua, JavaScript, noSQL ...
• Estou CTO na Sofie Tecnologia
• Vivência em soluções de grande porte para Contact Center
• Em todas as redes: @jmarioguedes
• jmarioguedes@gmail.com
4. Minha jornada no grupo empresarial TL2M
• 2008 .. 2009 – Softwares de integração com telefonia – Desenvolvedor
Pleno
• 2010 .. 2011 – Contact Studio que deu errado – Desenvolvedor Sênior
• 2012 .. 2013 – NCS – Líder Técnico
• 2014 .. 2017 – Contact Studio que deu certo! – Gerente de Desenvolvimento
• 2018 – Início de uma nova fase - Diretor de Tecnologia
5. Proposta do workshop
• Compartilhar minha experiência no desenvolvimento de uma plataforma
escalável e resiliente na Contact Studio Software:
• Escalável: Capacidade de atender 10 ou 10.000 usuários sem reescrita de código
• Resiliente: Capacidade de tolerar e se recuperar rapidamente de rupturas
• Não vou me ater à códigos ou configurações mas sim em elencar o que deu
certo e o que de errado sob meu ponto de vista.
6. O que é um Contact Center?
• Contact Center é um Call Center bombado
• Basicamente é uma estrutura montada para interagir com os clientes de forma
ativa ou receptiva
• Vendas
• Reclamações
• Cobranças
• Dúvidas e suporte técnico
• Elogios (aham)
• E todas as coisas chatas do dia à dia
• Hoje o desafio é lidar com os vários canais possíveis:
• Telefone, Fax e SMS(clássicos)
• e-Mail (o novo fax – no sentido de estar em desuso)
• Chats (Plataforma próprias e populares como Facebook)
• Mídias Sociais (Twitter, Facebook, Instagram e etc)
7. Que tipo de soluções são necessárias?
• Processos de WorkFlow – Nível 1 e Back Office
• CTI – Integração entre Computador e Telefonia
• Receptivo
• Screen-Pop
• Discador automatizado
• Power
• Preview
• Preditivo
• Gravação de ligações telefônicas
• Tabulador
• URA – Unidade de Resposta Audível
• FAX
• SMS
• Chat
• Bot
• Mídias Sociais
• Integração não invasiva
8. Desafios chave
• Integração com a telefonia interna do cliente provendo o chamado “screen
pop” que é a sincronia entre voz e tela.
• Tudo que acontece no ramal do atendente deve refletir no front-end dele.
• Pelo front-end ele deve ser capaz de se logar na telefonia, se colocar em
pausa, se deslogar e por ai vai.
• O mesmo se aplica, obviamente, aos outros canais de atendimento como
eMail, Chat e por ai vai.
9. Cenário existente – 2009
• Sistema cliente servidor, desenvolvido em Delphi 6 com SQL Server
• Sistemas instalados na casa do cliente, majoritariamente Contact Centers
• Tudo é muito difícil:
• Servidor
• Software
• Pessoas
• Instalação e atualização nas estações de trabalho
• Customização
• Tudo!
• Logo, o software era caro.
• Alguém aqui se identifica? Levanta a mão!
11. Viva o erro! - 2011
• Ano de 2011 e 2012
• Retumbante fracasso em reescrever o software da empresa
• Era para rodar na nuvem e não usamos HTTP (usamos o KBMMW)
• O front-end era Win32 implicando em down-time para atualização
• Era para ser escalável e não suportava mais de 100 usuários conectados
• Era para ser facilmente customizável mas tinha que ficar instalando exe e suas dependências
a todo momentos em todas as PAs
• Era para ser flexível mas esbarrava no DBA para criar uma nova coluna na tabela
• E diversos outros, digamos, inconvenientes.
• Ano de 2013
• Versão emergencial com DataSnap para atender o maior cliente sob pena de fecharmos
• A situação melhorou mas continuou sofrível
• O banco de dados relacional passou a ser o ofensor
• Sendo necessário “desnormalizar” o banco!
13. Mas afinal, o que deu errado?
• Se só tinha fera na equipe?
• Se usávamos o último Delphi e uma porrada de componentes de terceiros?
• Se tínhamos dois DBA’s em SQL Server?
• Se tínhamos especialistas Delphi?
• Exemplos emblemáticos:
“Para importar um mailing leva-se quase meia hora e tinha que ser feito
fora de horário para não baixar o nível de serviço do sistema.”
“Era proibido tirar relatório durante o horário de produção!”
“Um simples novo campo no layout demandava programador, DBA e uma
RDM noturna.”
14. Finalmente acertamos a mão!
• Descobrimos que se as perguntas mudaram, as respostas não poderiam ser
as mesmas.
• Descobrimos que existe um mundo além do Windows + Delphi + SQL
Server.
• Descobrimos que tudo que sabíamos é que nada sabíamos.
16. Mas calma!
• Estou falando o que deu certo para mim
• Não necessariamente serve tudo para você
• E não fiz nada sozinho, tem uma pequena mas valorosa equipe por trás
• E não foi fácil!
• Lembre-se: PESSOAS > TECNOLOGIA
• E por favor:
Tenha a mente aberta – as perguntas mudaram e por isso as respostas
também mudaram
18. Metas
• Oferecer uma solução cloud para o setor de Contact Center
• Ter flexibilidade para customizações
• Multi empresa
• Responder rapidamente às mudanças de estado
• Sincronia voz e tela
• Ser relativamente barato economicamente
• “Saving, saving, saving!”
• Parar de depender de grandes mas poucos clientes
• Passar a privilegiar muitos, mesmo que pequenos, clientes – Mercado SoHo
• CCaaS – Contact Center como um Serviço
19. Estratégia
• Codificar menos, entregar mais
• Falhar localmente
• Escalabilidade horizontal
• Desacoplamento
• A tecnologia certa para o problema certo
• Front end web estilo SPA
• Assíncronicidade sempre que possível
• Adoção de uma linguagem interpretada
• Preparar terreno para o Data Science
20. Os três pilares da nova arquitetura
• REST/JSON
• REST não guarda estado o que proporciona escalabilidade
• JSON é extremamente portável
• Micro serviço
• Alta especialização
• Baixo escopo
• noSQL
• Sem esquema
• Alta clusterização balanceando escrita e leitura
23. NGINX – Servidor Web Raiz
• Servidor web de alta densidade
• Promete suportar 10.000 conexões simultâneas
• https://nginx.org/en/
• Instalação para Windows (não para produção)
• http://nginx.org/en/docs/windows.html
• Software russo (curiosidade apenas)
• Extensível via linguagem Lua
• Proxy reverso
• Encaminhador de requisições
• Balanceador
• Fail over
• Altamente configurável
24. REDIS - REmote DIctionary Server
• Orientado à chave e valor, como um “arquivo INI gigante”
• Cacheamento lado servidor
• “O processamento mais rápido é aquele que não é feito”
• Mensageria entre processos
• PubSub -Publicação e Assinatura
• Enfileiramento
• Para um uso mais intenso considere o uso de um artefato especialista como o
RabbitMQ
• Possibilidade de se usar TTL nas chaves
• Execução de script em Lua
25. MongoDB
• Por já armazenar JSON, diminuímos a incompatibilidade de impedância
• É o esforço de mapear os dados entre as estruturas da linguagem e o banco
de dados relacional
• Aderente aos conceitos de Big Data
• Utiliza agregação e map-reduce para processamento
28. Por que o MongoDB?
• Permite escalabilidade horizontal
• Por trabalhar em cluster
29. Python – Sua nova segunda linguagem
• Python é uma linguagem fantástica e é uma boa opção para entender a sua
solução.
• Amanhã falaremos mais sobre isso.
30. Delphi – Protegendo o legado
• Legado não é um termo pejorativo
• Você trabalhou duro nos últimos anos e
tem o dever de preservar e adequar o
seu legado
• Se o Delphi é sua linguagem principal é
importante tentar quebrar os artefatos
em micro serviços.
• A solução não esta em nenhuma
tecnologia isolada, mas na arquitetura!
31. Próximos passos para a arquitetura
• Adoção de um message broker “de ofício”: RabbitMQ
• Adoção de containers para otimizar os servidores
• Integração com Blockchain
• Implantação de Aprendizado de Máquina e Data Science de um modo geral
• Otimização de discagens
• Análise de sentimentos
• Tecnologia cognitiva
• Predição de picos e vales para melhor planejamento
33. O segredo esta no conhecimento
• Se permita a conhecer tudo mas cuidado com as modinhas.
• Não tenha paixões – são apenas ferramentas.
• Cuidado, muito cuidado, com o vendor lock-in: Aprisionamento tecnológico
• Aplique a política “Baby Steps” – Um passo por vez!
• Erre rápido, aprenda rápido, corrija rápido!
34. Cuide das pessoas!
• O meu maior erro foi não considerar o “mapa mental” da equipe no
momento da mudança.
• Isso criou resistências e melindres absolutamente desnecessários.
• Isso deveria ser previsível, estávamos mexendo no status quo.
• Passado o perrengue:
• O DBA virou cientista de dados.
• O carinha do suporte virou um ninja web.
• O rapaz da infra virou DevOps.
• O programador Delphi conhece 3, 4 linguagens.
• Mas poderia ser menos traumático!
35. Materiais produzidos sobre estes e outros assuntos
• Meu blog: http://eugostododelphi.blogspot.com/
• Meu SlideShare: https://www.slideshare.net/jmarioguedes
• CodeRage Brasil III: Tudo sobre o REST Client Library:
https://youtu.be/ajl2GEJonQA