Mais um projeto em produção, mais lições aprendidas
Minha primeira semana após as férias foi do jeito ideal para recuperar o ritmo de trabalho: cheia de emoções 
Com subidas para produção durante o dia e longas noites de preparação para o fim de semana, consegui rapidamente trocar na minha cabeça o contexto das férias para a rotina de trabalho. No sábado às 23:30 cheguei à empresa para começar a janela de subida do novo e-mail da Globo.com. Fui sair de lá só no domingo ao meio-dia, mas foi uma janela bem sucedida e sem sustos, embora bem trabalhosa.
Este projeto se alongou bastante muito mais por questões comerciais do que questões técnicas, e foi ótimo finalmente colocá-lo no ar.
O projeto de migração de e-mail foi provavelmente o mais crítico que já trabalhei, pois estávamos lidando com uma grande massa de usuários e uma gigantesca massa de e-mails, o que trouxe alguns desafios interessantes. A parte do projeto que era a minha principal responsabilidade era a integração das nossas aplicações com os serviços do novo provedor de e-mails.
Nesta integração, usamos REST na comunicação entre aplicações desenvolvidas por nós e também para comunicação entre a Globo.com e o novo provedor de e-mail. Todos gostamos bastante dos resultados dessa forma de comunicação e cada vez mais nossas aplicações estão seguindo por esse caminho. Por questões de priorização do Product Owner, é claro que as melhorias técnicas muitas vezes têm que ser adiadas, mas estamos progressivamente refinando nossa arquitetura e usando cada vez menos as comunicações EJB legadas e cada vez mais os serviços REST.
Bom, entre as lições aprendidas neste projeto, está a de desconfiar de todos os componentes, e tratar minuciosamente de possíveis situações de contingência, até as que pareciam improváveis. Vou confessar que fomos um pouco ingênuos em alguns aspectos. Devido ao enorme gabarito da empresa com a qual estávamos nos integrando, tínhamos aquela idéia de que os servidores deles seriam “quase invulneráveis” e que a API deles seria infalível.
Bom, continuo tendo um enorme respeito pela empresa, mas vi que eles também falham, e não é tão pouco como pensávamos. Alguns tratamentos de contingência que fizemos tiveram que ser revistos e acabamos aprendendo bastante com esse processo.
Foi interessante que no domingo depois termos colocado a aplicação no ar eu li um post do Dan Pritchett sobre disponibilidade de 99,999%. Talvez se eu tivesse lido esse post uns 6 meses atrás eu acabaria só lendo rapidamente sem tanta atenção. Mas como vivenciei bem algumas questões que ele levantou, isso acabou realimentando um pouco as minhas idéias sobre o assunto.
Bom, para quem já está usando o novo e-mail da Globo, espero que a experiência esteja sendo a melhor possível. Para mim esta virada foi uma experiência muito proveitosa e torço para que venham mais e mais projetos desafiadores como esse.
August 20th, 2008 at 2:15 pm
Caro,
não vejo muitas vantagens em se “enchurrar” uma arquitetura com serviços REST ou mesmo WS indiscriminadamente e tratar isso como melhoria técnica (num cenário mais genérico).
Essa idéia de substituição dos “EJBs” legados por uma “estrutura” mais flexível,e tudo mais que se fala a respeito de orientação a serviços,esconde armadilhas tais como a dificuldade de se gerenciar um fluxo de negócio composto de várias “atividades” particulares,cada uma com a sua complexidade.Temos ainda o problema da baixa performance entre outros.
Assim,mantendo-se nesse cenário mais genérico,dá “empate técnico” ou seja,a mesma coisa que trocar seis por meia dúzia.
Em tempo,sempre é bom considermarmos o nível maturidade do velho EJB e das equipes que trabalham com ele.
OBS:Não sou tão velho assim….rsrsrs
August 20th, 2008 at 11:08 pm
Bom Alex, sobre suas observações eu tenho alguns comentários.
1: Meu time mantém uma aplicação que possui dezenas de aplicações clientes na Globo.com. Esta aplicação utiliza EJBs na versão legada para comunicação entre clientes e servidores.
O nível de acoplamento é muito alto, pois o contrato de comunicação é Java, e com isso o progresso técnico do servidor fica limitado pelos clientes mais antigos, que são aplicações que não são mais desenvolvidas, então sem chance de atualizá-las.
Você sabe o quão agradável é ter que manter códigos compatíveis com JDK 1.3 até 2007 e ainda não poder usar JDK 1.5 em 2008? A nossa versão legada tem essas restrições. Contratos de comunicação em XML não te forçam a usar nenhuma plataforma específica, e muito menos uma versão específica da plataforma.
2: Talvez você já tenha percebido a enorme gama de novas linguagens e plataformas que estão surgindo recentemente. Ruby, Groovy, Python, Php, .NET, Scala, etc etc etc. Com exceção de Scala, há várias aplicações que já usam todas essas linguagens/plataformas. Você acha que isso vai diminuir ou aumentar? Eu tenho certeza de que só vai aumentar, então será que é uma boa idéia eu ter a minha comunicação com EJBs??
3: Sobre performance, te garanto que você está enganado. EJBs não são necessariamente mais rápidos que web services, principalmente se forem web services REST.
Você pode julgar que a conversão para XML é muito custosa, mas hoje em 2008 isso não é tão significativo. Há alguns anos as APIs de XML eram menos performáticas, mas hoje em dia já são bem rápidas.
Comunicações com EJBs possuem a etapa de serialização de objetos, que é da mesma ordem de grandeza que a conversão para XML atualmente. Na prática você não tem nenhum ganho de performance por usar EJBs, pois o peso das comunicações fica muito mais nas chamadas remotas de rede do que na serialização Java ou XML. Não estou te falando isso com base em suposições. Faça testes de carga criteriosos e você perceberá isso. Eu já fiz os testes e isso reforçou minhas opiniões.
4: Você já pensou na conveniência de ter exatamente a mesma interface gerando e recebendo dados tanto em XML como em JSON e outros formatos? Não acha interessante ter a flexibilidade de ter um cliente Ajax e um cliente XML para o mesmo serviço, sem precisar modificar nada?
Se você quiser continuar vivendo feliz com EJBs, vá em frente e siga por esse caminho. Podemos escrever software de qualidade com várias tecnologias e linguagens, e o mesmo também vale para software ruim. Na minha opinião, EJBs têm ainda seu espaço, mas este espaço não inclui a integração entre aplicações. Hoje em dia eu só usaria EJBs em um projeto novo se fosse para controle transacional dentro do container. E olhe lá, porque temos outras opções de qualidade para isso, como o Spring, que nem te obriga a usar um servidor Java EE completo.
Sinta-se à vontade para discordar, e boa sorte nas suas escolhas
August 21st, 2008 at 1:57 pm
Caro,
concordo em grande parte com o seu ponto de vista e acho que passei a impressão de que sou amante de “EJBs” para todos os cenários.Não é verdade.
No entanto no meu caso eles foram mais eficientes que os serviços web dado que o projeto “era pra rua”,ou seja,lidava com uma carga muito grande de acessos e precisava de uma resposta rápida e com um fluxo de negócios também complexo.Fizemos sim testes criteriosos e justamente por isso mudamos de idéia (tínhamos em mente usar WS originalmente).
Não estou indo contra a maré,mas defendo uma análise mais cuidadosa na adoção de soluções,poderíamos discutir dias sobre Spring X EJB e impressionar nossos clientes para gastarem uma fortuna para migrar suas tecnologias sem nescessariamente terem ganhos significativos com isso.
Se for pra começar do zero aí é outra história!
abçs