Estudo de caso : um mapa para decisões de projeto
Olá pessoal, tudo certo?
Recentemente, acompanhei algumas discussões interessantes sobre aspectos para a decisão pela plataforma .NET em um determinado projeto.
A partir desse bate-papo, achei que seria bom comentar aqui uma solução que acompanhei para um projeto Web multi-tenant de média/alta complexidade no ambiente corporativo. Assim, vamos explorar alguns dos pontos avaliados pela equipe para a decisão pela plataforma .NET.
Considere esse projeto apenas como uma abordagem possível, já que:
- projetos são sempre diferentes entre si, seja em recursos, tempo ou equipes. Faça suas adaptações e avaliações de acordo com a sua realidade;
- pessoas bem capacitadas é sempre importante, para qualquer plataforma, seja .NET, JAVA, PHP ou RUBY;
- um mapa claro das reais necessidades da empresa também ajuda para manter as expectativas sob controle, assim como a escolha pela tecnologia mais aderente.
Considere ainda a necessidade por uma boa engenharia de software versus o atendimento de um cenário mais simples, com pouco perspectiva de evolução.
Para começar, veja o desenho de arquitetura escolhido para o projeto, conforme temos no Application Architecture Guide 2.0:
A partir desse mapa, vejamos alguns pontos que a equipe considerou ao escolher a plataforma .NET:
1. EVOLUÇÃO: A plataforma .NET tem evoluído desde 2002. Desconsiderando o .NET 1.0 (2002) e o .NET 1.1 (2003), da versão 2.0 em diante (2005) tem sido adicionado novos recursos e protocolos de forma integrada ao framework, atendendo uma série de cenários no mercado. Alguns exemplos são serviços REST, consultas integradas via LINQ, AJAX, padrões MVC, frameworks de sincronização, caching, etc. Como a evolução é contínua, isso garante o atendimento de novos cenários não originalmente previstos;
2. LINGUAGEM: A plataforma .NET oferece 2 grandes linguagens para o desenvolvimento de aplicações, C# e VB.NET. Claro, existem outras, mas são as de maior presença no mercado. A equipe considerou a linguagem C# como alternativa por decisão de projeto apenas, já que os recursos e namespaces oferecidos são os mesmos sobre .NET. A síntaxe de C# também pesou na decisão, devido alguns membros trabalharem em Java em projetos paralelos;
3. WEB+RIA: Para cenários de aplicações WEB evoluindo para RIA - Rich Internet Application, a dupla ASP.NET + AJAX foi bem avaliada, considerando uma evolução para ASP.NET + SILVERLIGHT em alguns cenários. Na época, era o Silverlight 2.0. Hoje, temos o Siverlight 3.0 com o framework em desenvolvimento .NET RIA SERVICES, que promete implementação interessante, integrando serviços Web Services em JAVA, camadas em nHibernate e bancos ORACLE, serviços REST, etc. A solução hoje é 80% ASP.NET + AJAX, considerando algumas funcionalidades de LOB para Silverlight 3.0. Por ter iniciado antes do lançamento, o ASP.NET MVC está sendo avaliado somente agora;
4. SERVIÇOS: De modo geral, o suporte de serviços no lado do servidor e na camada de negócios foi bem implementado com o WCF - Windows Communication Framework, presente na plataforma .NET desde sua versão 3.0 (2006). Uma das grandes características do WCF é sua extensibilidade com a adição de novos Bindings de conectividade, seja através de soluções domésticas ou de mercado. Na solução em questão, foram aplicados os bindings padrão TCP, wsHTTPBinding e basicHTTPBindig para integração Java;
5. PERFORMANCE: A estabilidade e robustez do modelo ASP.NET+WCF foi bem avaliada desde as provas de conceito. Isso contou para garantir uma plataforma que tivesse alta escalabilidade ao longo do tempo. Os números para mensagens por segundo e suporte para múltiplas instâncias de serviços foram muito bons! Realize provas de conceito, sempre. Veja um artigo clássico sobre performance do WCF, aqui. Para os testes usaram o Web Capacity Analysis Tool do Internet Information Services (IIS) 6.0 Resource Kit Tools, além das ferramentas de Web Testing do Visual Studio 2008.
6. PROCESSOS: Em cenários de coordenação de processos, o WF - Windows Workflow Foundation também foi avaliado, uma vez que sua implementação é visual e integrada a própria IDE do Visual Studio. Alguns desses workflows fazem chamadas para serviços WCF, coordenando processos de negócio. O template Sequential Workflows Service Library foi o mais adotado. Já falamos dele por aqui, veja;
7. TRANSAÇÃO: O suporte transacional obtido com o WCF e WF garantiu também a aplicação de transações distribuídas, integrando serviços em .NET e JAVA, através do protocolo WS-AT (Atomic Transaction), suportado pelo WCF e WF no .NET. Como alguns web services participantes estão em Java, foi usado o WSIT para o suporte transacional, com interoperabilidade Java e .NET. Veja mais aqui.
8. HOSTING: Outro aspecto importante avaliado foi o HOSTING, isto é, onde as camadas de apresentação e lógica seriam hospedadas. No cenário sobre .NET, as páginas ASP.NET e porções em Silverlight foram hospedados em baterias de máquinas de apresentação, sobre IIS7 (Windows Server 2008). Para a camada de negócios e serviços, máquinas W2k8 foram dedicadas para hospedagem de serviços sobre a dupla IIS7/WAS - Windows Process Activation Service . Desse modo, foi possivel garantir o "desacoplamento" desejado para o projeto, separando a frente de apresentação e balanceamento de carga Web da frente de serviços e negócios, permitindo a futura exportação de serviços para outros sistemas. Avalie esse cenário como uma expansão futura real e desejável. De modo geral, pense em Web Services sobre HTTP/SOAP. Para cenários de serviços com alta performance, usamos o WAS para suportar o transporte em TCP/Binário e não em HTTP/SOAP/XML apenas. Veja mais sobre arquitetura WAS aqui;
9. ADMINISTRAÇÃO: Foi avaliado que a construção de serviços WCF e WF e a preparação da equipe sobre a plataforma .NET garantiria a adoção de Dublin sobre o Windows Server 2008 no futuro. O Dublin deve ampliar as funcionalidades de gerenciamente e administração de serviços WCF e WF no servidor de aplicações, criando um hosting com melhor governança para a solução. Mais um ponto para a adoção do .NET. A equipe começou com W2k3 e passou logo para W2K8 durante o projeto;
10. SEGURANÇA: Para cenários de autenticação, autorização e controle de acesso, aplicamos os exemplos disponíveis na Enterprise Library , o que ajudou muito na produtividade;
11. TESTES: Avaliamos também a aplicação de cenários de testes sobre o Visual Studio 2008, diretamente relacionado a plataforma .NET;
12. CONFIGURAÇÃO: Considerando a dupla ASP.NET+WCF, tivemos bons resultados na velocidade de configuração do ambiente de produção, devido principalmente o desacoplamento entre ambos. A configuração via XML e EndPoints também foi um ponto interessante de avaliação no uso de serviços em WCF, recurso muito bem avaliado na plataforma .NET;
13. PRODUTIVIDADE: Em relação ao processo de desenvolvimento em si, aplicamos alguns templates customizados, criados em tempo de planejamento e arquitetura. Desse modo, foi possível disponibilizar em servidores da rede de desenvolvimento alguns templates específicos para páginas CRUD e serviços WCF, aumentando muito a produtividade da equipe de desenvolvimento. Avaliamos também o uso de guias de automação sobre o Visual Studio, como a dupla GAT/GAX, mas o cenário foi bem atendido apenas com os templates puros em .vstemplate para páginas ASP.NET e serviços WCF/WF;
14. PERSISTÊNCIA: Considerando bancos de dados em Oracle e SQL Server, foi aplicada uma camada ORM com nHibernate, em .NET. A equipe está realizando testes com o Entity Framework, aguardando a versão 2.0 ser lançada. Para a manipulação das coleções obtidas de consultas, diversos módulos de negócio manipulam os itens através de consultas LINQ, integradas ao C# no .NET. Essa abordagem de manipulação integrada permitiu um grande ganho de produtividade, devido o uso do intellisense em tempo de desenvolvimento, assim como facilidade de construção de consultas e filtros sobre coleções;
15. CAPACITAÇÃO: Em relação a capacitação da equipe, foi planejado 40 horas de treinamento formal em WCF e 24 horas de treinamento formal WF. O uso de templates bem formatados para cada camada do projeto garantiu uma curva de aprendizado suave para a equipe;
16. RECURSOS: Foram considerados alguns sites importantes para o apoio da equipe. Entre os links principais, cito:
WCF – Windows Communication Foundation
https://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_WCF.aspx
WF – Windows Workflow Foundation
https://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_Windows%20Workflow%20Foundation.aspx
Sem esquecer do material impresso, através de livros para o .NET 3.x (WCF, WF e ASP.NET).
17. PROJETO: Em relação ao processo de gerenciamento, o time não aplicou o SCRUM de forma rígida, mas manteve o PRODUCT BACKLOG, assim como o papel do SCRUM MASTER, SPRINTs de 3 a 4 semanas e as SCRUM Meetings diárias.
18. COMPLEXIDADE: Avalio o projeto como de média para alta complexidade, considerando o potencial de crescimento e escalabilidade prevista. Apesar do aspecto multi-tenant (multi-inquilino), a integração com o legado, o controle de acesso, a integração transacional com serviços Jrava e a necessidade de crescimento de novas funcionalidades foram fatores também críticos. Para os mais rígidos, aplicar a Análise por Pontos de Função também ajuda.
19. FRAMEWORKS: Não foi construído um framework de desenvolvimento para o projeto. Ao invés, foram construídos bons templates para páginas CRUD e façades de serviços e workflows. Dessa maneira, a equipe conseguiu grande produtividade no desenvolvimento sem o custo adicional de manutenção de um framework doméstico. Fábricas de Software ou DSL’s não foram consideradas pela equipe por enquanto. :)
20. ALM – Application Lifecycle Management: como parte importante do projeto, foram considerados os vários papeis e processos previstos no ALM aplicado sobre MSF for Agile (MSF for Agile Software Development Process Guidance). O uso de VSTS – Visual Studio Team System como ferramenta de apoio ao processo de desenvolvimento e projeto também foi importante para o sucesso do ALM adotado.
Assim, fizemos as seguintes considerações para a plataforma .NET:
- capacidade de desacoplamento entre apresentação e serviços (via WCF);
- suporte para a construção de serviços com transporte via HTTP, MSMQ e TCP (via WCF);
- facilidade na construção de processo por workflows, realizando chamadas coordenadas para serviços (via WF);
- integração do desenvolvimento e testes com a ferramenta de desenvolvimento principal, via Visual Studio 2008;
- suporte a frameworks de sincronização, caching, xml, coleções, etc, além da possibilidade de se trabalhar com configuração desacoplada para a camada de apresentação e de negócios (via web.config);
- disponibilidade de bons exemplos de código na web (via a Enterprise Library 3.1 e 4.1). Mais recentemente, o Hands On Lab da EntLib 4.1 trouxe bons exemplos para alguns cenários não avaliados originalmente;
- facilidade de construção de Web Forms via RAD no Visual Studio;
- suporte para integração futura com outros cenários de apresentação e canais de relacionamento, como o ambiente Mobile;
Passamos aqui por alguns aspectos de decisão do projeto e algumas justificativas que levaram a adoção da plataforma .NET no cenário acima.
A partir desse exemplo, podemos montar uma planilha de decisão mais ampla, para a comparação ou avaliação de outras tecnologias, considerando:
1. redução de custos de desenvolvimento;
2. redução de custos de manutenção;
3. agilidade no processo de desenvolvimento;
4. produtividade e ferramentas de automação no desenvolvimento;
5. facilidade de integração com sistemas legados;
6. interoperabilidade com outras plataformas;
7. segurança;
8. suporte transacional;
9. mobilidade;
10. capacitação da equipe;
11. conectividade com web services e padrão WS-I.org;
12. suporte a padrões W3C;
13. facilidade de depuração e ferramentas;
14. integração e rastreabilidade no ambiente de infra-estrutura;
15. custo total de infra-estrutura necessária, etc.
Para pensar…
Creio que um dos aspectos importantes na adoção da plataforma .NET no cenário acima foi a decisão pela boa engenharia de software. O projeto precisava considerar balanceamento de carga, crescimento e escalabilidade ao longo do tempo, integração com o legado e diferentes plataformas, múltiplos bancos, processos via workflows e interfaces de serviços, etc. Era uma solução Web multi-inquilino, com potencial de crescimento no ambiente corporativo, e que sinalizava evolução ao longo do tempo.
Veja que a equipe não avaliou outros recursos importantes, como Live Services ou Cloud Computing através da plataforma Azure. Considerando valores de pricing da plataforma, assim como o desenvolvimento e depuração integrados sobre o Visual Studio 2008, a nuvem passa a ser uma opção cada vez mais interessante para projetos semelhantes também de baixa e média complexidade. Avalie se sua aplicação SAAS sobre ASP.NET + Banco de Dados não é também aderente ao modelo elástico da nuvem.
Em cenários menores, a análise acima pode ser exagerada (exemplo, um site simples sobre 1 única máquina consumindo 1 único banco de dados, com equipe reduzida). Mas se sua aplicação tem potencial de crescimento ou aspectos SaaS / Web 2.0 mais corporativos, passa a ser importante considerar os componentes de arquitetura de forma mais completa. A lista abaixo foi retirada do App Arch Guide 2.0:
Veja o que você realmente precisa em sua solução e escolha a melhor tecnologia de forma racional e com boas memórias de cálculo justificando suas decisões.
Por enquanto é só! Até o próximo post :)
Waldemir.
Comments
Anonymous
July 29, 2009
muito bom o post Waldemir, muito boa a explicação para decidir qual "norte" seguir no projeto, dá para ter uma boa idéia e sem sombra de dúvida na plataforma MS.Anonymous
July 29, 2009
No Exchange nós usamos uma arquitetura similar a descrita aqui para implementar a nossa 'Web Management Interface'. Por coincidência, ontem mesmo eu escrevi um blog sobre nosso caso: http://blogs.msdn.com/fpintos/archive/2009/07/29/inside-the-exchange-2010-web-management-interface-part-i.aspxAnonymous
July 31, 2009
sempre procuro analisar o projeto independente de plataforma, mas no final a MS acaba "cobrindo" todos os requisitos de engenharia.