No principio era a dúvida entre scale-up e scale-out, sendo que o scale-up apenas ganhava, de vez em quando, do scale-out devido a falta de softwares adequados para controlar o processo de scale-out.
No treinamento de ASP.NET Avançado, no qual são estudadas várias técnicas para escalabilidade, uma das coisas que vemos é que o uso tradicional de gridViews é um erro. O uso mais correto seria ou trazermos os dados para os servidores web e fazermos cache ou criarmos custom paging com a gridview
Os recursos de cache tem se aprimorado cada vez mais em direção a cache dependency, que pode ser criada com o banco (através do complexo service broker - difícil de configurar e só a partir do 2005), com arquivos ou de forma personalizada.
Porém o cache ainda não encontrava-se totalmente integrado com um ambiente de NLBS. Cache sempre foi basicamente inProc, faltava-nos uma solução de cache distribuido através dos servidores web ou de servidores próprios - os servidores de cache.
Esse é o projeto Velocity : Um serviço de cache distribuido que é facilmente instalado em multiplos servidores e pode ser acessado pelo .NET através de classes criadas no namespace System.Data.Cache
É claro que não faz muito sentido utilizar o Velocity para recursos que estejam já muito próximos da aplicação, mas a idéia é utilizar o Velocity para recursos mais distantes da aplicação - até mesmo para dados em webServices - ou para recursos que necessitem de alta escalabilidade com scale-out
Algumas características importantes de se destacar no Velocity :
-
Estrutura dividida em Cluster->Hosts->Named Cache->Region->Item - Named Cache separa aplicações
- Regions agrupam dados que podem ser pesquisados em conjunto
- Os itens podem ser marcados com tags para fins de pesquisa.
- As informações de cache podem ser distribuidas através do scale-out, criando redundância em caso de um dos servidores de cache sair do ar
-
A administração do Velocity, até o momento, é feita via powershell, demonstrando a tendência de se criar novos recursos fortemente atados a cmdLets e só posteriormente criar a interface gráfica de gerenciamento, gerando softwares muito mais confiáveis com um núcle OO altamente bem planejado. - Planeja-se incluir no Velocity integração com SQL Server, de forma a poder ter cache dependency. Já callback é recurso já previsto.
A configuração de cada servidor do Velocity pode ser feita localmente, através de um network share ou através de um banco de dados - O velocity já possui um custom sessionStateProvider de forma a permitir jogar toda a sessão do ASP.NET para dentro do Velocity, fazendo com que a sessão do ASP.NET torne-se um poderoso ambiente de cache distribuido
- A arquitetura do Velocity se interliga com WCF para comunicação. Além de já haver previsão dos recursos do WCF serem utilizados em segurança de transporte do Velocity, imagino utilizações bem amplas para isso
Previsão de lançamento : Atualmente estamos no CTP 2, o CTP 3 será disponibilizado a partir do MIX 09, a versão final será lançada em meados de 2009. A versão 1.0 será GRATUITA para uso com .NET Framework
Questão interessante : Os recursos de Cache Extension para o ASP.NET 4.0 são construidos voltados a cache distribuido - Velocity - porém são construidos prevendo-se muitas limitações no cache distribuido, tal como limitação de não terem callback nem cache dependency, coisa que o Velocity terá. Será que as duas equipes devem se comunicar melhor ?