Freigeben über


Como mapear camadas de uma aplicação para uma TI com private cloud? Parte 2/2

Olá pessoal, tudo certo?

No post anterior, vimos o início de uma discussão sobre soluções para um ambiente em private cloud. O assunto continua:

Como garantir que uma arquitetura de referência para soluções esteja corretamente mapeada nos componentes provisionados na TI de uma empresa com private cloud?

Para se garantir que a arquitetura de referência (de soluções) esteja aderente ao modelo de private cloud da empresa, precisamos de PADRONIZAÇÃO.

Ou seja, precisamos padronizar os componentes de banco de dados, de segurança, de hosting, de caching, web e clusters que são provisionados pela solução de private cloud.

Para esses componentes, precisamos mapear as camadas de nossa arquitetura de solução. Isso irá gerar uma maior aderência da aplicação aos cenários de provisionamento, que irão ocorrer conforme a necessidade.

Por exemplo, se precisamos de mais banco de dados, basta encomendar para a solução de private cloud mais N GB de base de dados. Se precisamos escalar o Web Farm, basta fazer o mesmo e teremos mais máquinas disponíveis. Quando o período de pico passar, podemos apenas liberar as máquinas provisionadas e retornamos ao planejamento de infraestrutura original da aplicação.

Espere um pouco!!! Isso parece Windows Azure, com seu modelo de provisionamento dinâmico para SQL Azure e Web Roles, Worker Roles, Azure Storage, etc.

Correto!!! 

O que permite o provisionamento de aplicações com alta escalabilidade no Azure é a PADRONIZAÇÃO, tanto de máquinas virtuais do Azure (Infraestrutura como Serviço) , como de componentes via AZURE ROLES e tipos do AZURE STORAGE (Plataforma como Serviço).

Essa padronização é vista através dos componentes de uma solução para o Windows Azure, que aparecem no próprio Visual Studio, como vemos a seguir:

image

Temos então os templates para ASP.NET WEB ROLE, ASP.NET MVC WEB ROLE, WCF SERVICE WEB ROLE, WORKER ROLE e outros que podem ser lançados pelo time de produto no futuro.

Agora imagine nos possíveis componentes e templates de aplicações para sua TI local baseada em uma nuvem privada. Imagine o cenário a seguir na frente de seu desenvolvedor:

image

Nesse cenário, o desenvolvedor teria uma série de templates preparados, aderentes aos modelo de deployment disponível na empresa. Uma solução baseada em Web seria mapeada para máquinas virtuais templates de um Web Farm. Soluções baseadas em serviços teria o mapeamento para máquinas virtuais com suporte para WCF/WF e WINDOWS SERVER APPFABRIC, e assim por diante. Sobre essa camada de provisionamento de plataforma, agentes de monitoração e management packs já estariam preparados para monitorar a aplicação recém implantada, de forma automática.

De fato, isso é possível de ser implementado com as tecnologias atuais, baseadas na família SYSTEM CENTER, OPALIS, AVICODE, HYPER-V, WINDOWS SERVER APPFABRIC, VISUAL STUDIO 2010, SHAREPOINT SERVER 2010, IIS 7.0, WCF 4 e WF 4. Já é possível criar esse modelo localmente em sua TI.

Se você já possui uma solução de PRIVATE CLOUD (mesmo sobre VMWARE, a ideia vale para qualquer plataforma de virtualização dinâmica), garanta a padronização de suas máquinas virtuais e recursos provisionáveis de alto nível (como bases de dados, serviços de segurança, autenticação, hosting de serviços, web farms, autorização, etc.).

Na sequência, identifique os componentes provisionáveis de sua aplicação e transforme-os em templates de desenvolvimento, patterns ou guias de composição desacoplados. Você pode começar dividindo sua aplicação em camadas, como sugerido no Application Architecture Guide. No final, você poderá colecionar templates de VISUAL STUDIO devidamente mapeados em recursos de sua nuvem privada. O processo de agendamento dos recursos para provisionamento pode ser implementado nas páginas do dashboard em SharePoint Server, como já acontece no modelo de HYPER-V da Microsoft.

Mas preste atenção sobre algumas garantias necessárias para esses templates, como desacoplamento de componentes, escalabilidade horizontal, não manutenção de estados, uso de caching distribuído, etc.

Esse assunto é bem interessante, mas está longe de terminar em apenas 2 posts! Por isso, aguarde novos debates sobre ele.
Se tiver dicas, feedbacks ou sugestões, fique a vontade para colocar um comentário!

Por enquanto é só! Até o próximo post :)

Waldemir.