Em Outubro de 2009, fiz a publicação do ebook Arquitetura de Soluções, consolidando 2 anos de posts sobre diversos temas. Veja ele aqui:

eBook Arquitetura de Soluções 2009
Ref.: https://sdrv.ms/19v9tGc

Para manter o padrão, publico agora o novo ebook Arquitetura de Solução edição 2011, com mais de 300 posts organizados nos vários temas que vimos aqui no blog nesses últimos dois anos. Entre os assuntos encontramos Enterprise Architecture, Solutions Architecture, Cloud Computing, Windows Azure, Application Platform, entre outros.

Assim, a nova edição consolida os posts publicados entre 2009 - 2011 e está disponível para download no link abaixo:

eBook Arquitetura de Soluções 2011
Ref.: https://cid-ac0dc53ca97927a5.skydrive.live.com/browse.aspx/ebookAS2011 

Gostaria de agradecer a todos que ajudaram com ideias, comentários e feedbacks constantes aqui no blog. Sem dúvida, esse material seria muito diferente e bem menor sem a participação dos leitores. Muito obrigado a todos!

Boa leitura e espero que gostem!

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

Waldemir.

Essa semana tive um almoço de arquitetura com um grande amigo (super arquiteto Diego). Falamos muitos sobre os desafios presentes na mesa do arquiteto de TI e como os departamentos ou gerências de TI são confrontados por resultados, melhor time-to-market e acima de tudo, alinhamento com o resto da empresa.

Um dos assuntos mais importantes na pauta de um CIO ou Diretor de TI/Arquitetura é o gerenciamento do portfolio de aplicações. Como você gerencia o portfolio de aplicações presentes em sua TI?

Existem diversas maneiras de se fazer esse tipo de gerenciamento e esse post realmente não teria espaço para cobrir todos eles. Mas vale aqui algumas ideias e tópicos de destaque.

Sempre falamos que um dos principais pensamentos de todo CIO é construir ou melhorar o alinhamento entre TI e Negócio. Porém, um grande desafios para essa realização está nos próprios inibidores presentes na TI. Entre eles, o fato de termos um número muito maior de sistemas e aplicações do que as reais necessidades de negócio. Ou seja, passamos a maior parte do tempo inibidos/ocupados com manutenções, operações e evoluções de um número grande de aplicativos, que não suportam as necessidades dos times de negócio. Concorda?

Isso é ilustrado em diversos cenários e indústrias. Por exemplo, alguns bancos possuem entre 3 a 5 portais de comunidades técnicas e repositórios de documentos para seus projetos, quando na verdade apenas um seria suficiente. Essa duplicidade de portais gera manutenções de servidores, migrações, versionamento de páginas, operações duplicada, etc.

Outras empresas possuem ainda versões históricas de seus sistemas de apoio, como CRM’s ou cadastros de negócio que ficaram obsoletos com o tempo. Porém, continuam instalados, operando e exigindo manutenção contínua, devido umas poucas funcionalidades presentes para alguns poucos usuários de negócio.

Qual é o papel da Arquitetura num cenário como esse? Como um time de Arquitetura ou um Arquiteto pode ajudar a empresa a eliminar esse tipo de impedimento na TI?

Em pesquisa recente da Capgemini (https://www.capgemini.com/insights-and-resources/by-publication/application-landscape-report-2011-edition/) confirmamos que uma das principais preocupações dos CIO’s de hoje é a RACIONALIZAÇÃO de aplicações. Esse processo busca otimizar o portfolio de aplicações presentes na TI.

Como fazer uma otimização do portfolio de aplicações?

Existem diversos modelos para abordar o problema, como:

Modelo top-down: modela a arquitetura da organização de cima para baixo, definindo serviços baseados nos modelos de negócio da organização, agrupando serviços em componentes e orientando a implementação desses componentes junto aos times de sistemas e desenvolvimento. Esse modelo exige uma visão ampla sobre as linhas de negócio da empresa, além da definição prévia de processos e modelos de negócio.

Modelo de comando e controle: aqui, o grupo de arquitetura define o portfolio de aplicações que será empregado e orientada a implementação de suas escolhas. Vejo muitas empresas criando grupos de arquitetura baseados nesse modelo, que possuem vantagens e desvantagens. O maior desafio aqui está na correta condução das definições de arquitetura que serão implementadas, além de um bom plano de comunicação com os times de negócio, sobre essas definições. Tanto para o modelo top-down como para o comando e controle, é importante identificar quais capacidades de negócio estão sendo atendidas na arquitetura proposta.

Baseado nos modelos da organização: o gerenciamento do portfolio de aplicações baseado em modelos exige uma rígida disciplina de modelos pré-definidos na organização. Tenho visto poucas empresas com esse mapeamento completo para todas as linhas de negócio, por isso o maior desafio desse tipo de gerenciamento.

Modelo padronizado para a plataforma de tecnologia adotada: esse modelo é muito comum hoje em dia, quando temos um time de arquitetura focado apenas em plataformas e tecnologias presentes no ambiente de TI. Em muitos casos, o resultado é um bom blueprint de arquitetura, padronizado e organizado para os tipos de componentes e sistemas que suportam linhas de negócio. Porém, pode não ser suficiente para uma visão maior de integração de linhas de negócio, podendo ser simplista para cenários multi-plataforma ou ambientes complexos de TI. Também pode pecar na falta de um alinhamento mais alto-nível com as linhas de negócio da empresa.

Modelo baseado na consolidação de aplicações: nesse modelo, o foco é manter um regime de racionalização de aplicações de negócios, buscando sempre a consolidação/merge de aplicações, consolidando tecnologias nas plataformas adotadas. A consolidação de aplicações gera um menor esforço de operação na produção, simplificando o ambiente de TI. Porém, pode não ser a melhor escolha para cenários com linhas de negócio muito diversas, que exigem customizações ou soluções domésticas nativas da indústria.

Com certeza, não será apenas um modelo de gerenciamento de aplicações que irá resolver seu problema. Na verdade, um MIX desses modelos e ainda outras estratégias emergentes irão ajudá-lo na difícil tarefa de RACIONALIZAÇÃO e OTIMIZAÇÃO de seu portfolio de aplicações.

A pergunta final continua sendo: como o time de arquitetura pode ajudar a empresa na otimização da TI?

Cada vez mais, seremos cobrados como arquitetos para devolver resultados para a compania, seja através de redução de custos operacionais, simplificação de arquiteturas e sistemas, melhorias de processos, inovação e geração de novos negócios.

Pense nisso!

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

Waldemir.

Esses dias estive as voltas com cenários de CBA novamente. Para quem não se lembra, CBA é o modelo de autenticação baseada em declarações, que oferece grandes benefícios para aplicações, no tratamento de autenticação e autorização, de uma forma mais desacoplada e limpa.

Alguns links que valem a leitura são:

Claims-Based Authorization with WIF, Michele Leroux Bustamante, Nov 2009
https://msdn.microsoft.com/en-us/magazine/ee335707.aspx

Claim-based Authentication (CBA) e Windows Identity Foundation (WIF) com o Windows Azure
https://blogs.msdn.com/b/wcamb/archive/2010/04/22/claim-based-authentication-cba-e-windows-identity-foundation-wif-com-o-windows-azure.aspx

Claim Based Authentication in SharePoint 2010 for Community Day 20112
https://www.slideshare.net/jplq631/claim-based-authentication-in-sharepoint-2010-for-community-day-2011

E o livro obrigatório…

A Guide to Claims–based Identity and Access Control
https://msdn.microsoft.com/en-us/library/ff423674.aspx

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

Waldemir.

Enquanto o tempo passa, algumas arquiteturas evoluem de forma bem interessante. Resgatando alguns documentos e guias do passado, veja o que notei.

Entre 2000 e 2003, uma solução Web em plataforma Microsoft era frequentemente apresentada como vemos abaixo:

A partir de 2005, com o lançamento do .NET 3.0 e o Windows Communication Foundation, passamos a substituir os Web Services ASMX por serviços em WCF (.SVC).

Num primeiro momento, regras de negócio ainda em COM+ e Enterprise Services eram mantidas e escondidas por serviços WCF. Aos poucos, algumas regras foram sendo convertidas para serviços, como vemos no desenho abaixo:

Ainda encontro empresas com regras de negócio em COM+ sendo exportadas a partir de Web Services WCF. O impacto disso é latência em alguns casos, principalmente para componentes legados antigos.

Mais recentemente, diversas aplicações corporativas ampliaram o uso de serviços, criando camadas e funcionalidades exportadas para diferentes canais de consumo, como desktop, web, ambientes móveis, etc. Desenhos como a figura abaixo tornaram-se comuns em muitas empresas, onde vemoos uma camada de serviços bem definida através de interfaces de serviços e tipos de mensagens:

Enquanto a empresa amplia o número de serviços expostos para domínios de aplicações diferentes, alguns desses serviços tornam-se bons candidatos para reuso. Nesse cenário, uma visão de barramento de serviços ou virtualização de serviços, onde podemos concentrar sua exposição e governança torna-se bem interessante.

Barramentos de serviços sempre foram um tópico importante no cenário corporativo, onde questões como governança de serviços, monitoração, segurança, versionamento, administração e composição são críticos.

Veja um desenho que ilustra esse cenário:

Além da exposição central de serviços, o barramento também suporta aspectos de integração entre plataformas heterogêneas, como .NET e JAVA, SQL e ORACLE, camadas de apresentação e aplicações do legado, etc.

Qual é o desenho de arquitetura do momento?

Com certeza, a integração entre on-premise e nuvem é bem promissora, já que existe uma tendência de migração de alguns cenários de aplicações para um ambiente externo da empresa. Isso fará com que a monitoração e o controle sobre os serviços hospedados na nuvem sejam muito importantes! Não é admissível que uma solução colocada na nuvem e integrada com um ambiente on-premise corporativo não seja monitorada ou administrada de forma integrada ao modelo de monitoração corrente. Se a empresa não possui esse modelo de governança em sua TI, o problema é mais grave e deve ser tratado antes mesmo de se pensar em uma solução na nuvem.

Que ver um exemplo simples? Veja o desenho abaixo:

Acima, vemos uma solução local (on-premise), integrada com serviços no ambiente na nuvem. Ainda, a segurança proposta aqui é baseada em tokens de segurança SAML, emitidos por servidores de token (STS), baseando a solução na abordagem CBA – Claim-Based Authentication.

É provável que no futuro próximo, os barramentos locais e na nuvem também estejam integrados, como vemos a seguir:

Estive com o Giovanni Bassi esses dias e gostei muito de um comentário que ele fez, sobre os ”arquitetos de uma arquitetura só”. São profissionais que não evoluem ao longo tempo. Enquanto que novas combinações e alternativas de soluções são apresentadas, eles continuam fazendo uso da mesma arquitetura, sempre!

Fica a dica: busque sempre avaliar alternativas, novas metodologias, novas tecnologias e formas diferentes de integrar, combinar, desenvolver, etc. Seja um “arquiteto antenado e atualizado com as tendências em TI”.

Sobre as figuras e tópicos que falamos aqui, confira:

Building Secure ASP .NET Applications .pdf Download (2002)
https://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=19032

patterns & practices Improving Web Services Security Guide (2008)
https://wcfsecurityguide.codeplex.com/releases/view/15892

Microsoft Application Architecture Guide, 2nd Edition (2009)
https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16236

AppFabric Connect (2011)
https://www.microsoft.com/biztalk/en/us/appfabricconnect.aspx

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

Waldemir.

Essa última semana falei bastante sobre patterns de soluções corporativas com alguns grupos de projetos. O assunto é sempre importante, como premissa para a construção de soluções de qualidade. Em tempos de tamanha pressão por prazos e entregas apertadas, algumas vezes o uso de patterns é esquecido ou simplesmente deixado de lado pelos times de desenvolvimento e arquitetos.

Um artigo que fala de alguns patterns importantes é esse abaixo:

Patterns for Building Enterprise Solutions
Ref.: https://msdn.microsoft.com/en-us/library/ff648303.aspx 

Apenas para lembrar, um pattern descreve um problema recorrente que ocorre em um determinado contexto e, com base em um conjunto de forças de orientação, recomenda uma solução. A solução geralmente é um mecanismo simples, uma colaboração entre duas ou mais classes, objetos, serviços, processos, threads, ou componentes que trabalham juntos para resolver o problema identificado no pattern.

Veja um exemplo, definindo o Contexto, o Problema e a Solução.

Outro material interessante sobre assunto você encontra a seguir:

patterns & practices Application Architecture Guide 2.0
Ref.: https://apparchguide.codeplex.com/

Improving .NET Application Performance and Scalability
Ref.: https://msdn.microsoft.com/en-us/library/ff649152.aspx

E para terminar, o portal do patterns & practices é importante:

Microsoft patterns & practices
Ref.: https://msdn.microsoft.com/en-us/practices

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

Waldemir.

O que você chama de “Alta Disponibilidade”?

Esses dias estive envolvido nessa discussão e surgiram algumas dúvidas no time. Vou aproveitar esse post para compartilhar alguns tópicos do assunto.

Podemos começar a discussão fazendo uma definição sobre o termo “Disponibilidade”. Em TI, um sistema ou solução pode ser chamado de disponível quando está:

• Presente e pronto para uso; acessível para usuários;
• Qualificado e pronto para ser servido;
• Disponíveis para consumo com garantias prévias de níveis de serviços oferecidos;

Uma definição do Wikipedia segue abaixo:

• “Um sistema de alta disponibilidade é um sistema resistente a falhas de software e energia, cujo objectivo é manter os serviços disponibilizados o máximo de tempo possível.”  by wikipedia.
  Ref.: https://pt.wikipedia.org/wiki/Sistema_de_alta_disponibilidade

Ou seja, se precisamos garantir a disponibilidade para um determinado sistema, precisamos garantir a oferta de seus serviços em diferentes situações de operação (falhas, carga, desastres, etc), com níveis de qualidade pré-estabelecidos. As situações de operação mais conhecidas são:

• Tolerância a falhas;
• Suporte a picos de carga e alta demanda;
• Recuperação de desastres;
• Cenários de redundância de dados;
• Cenários de redundância de aplicações e funcionalidades;

Veja, essas situações exigem uma combinação de requisitos de software e hardware. Podemos ainda usar métricas para determinar o nível de disponibilidade que precisamos, como:

Os níveis de disponibilidade exigidos para a aplicação devem estar alinhados aos requisitos do negócio. Ainda, maiores níveis de disponibilidade exigem maiores níveis de investimentos e definições de hardware, software e redes que suportam adequadamente os níveis exigidos.

Portanto, Alta Disponibilidade deve ser classificada de acordo com o cenário e nível de serviço que estamos considerando. Veja um exemplo de arquitetura clássica de alta disponibilidade para dois nós em cluster, com base de dados compartilhada:

by wikipedia.

A plataforma Windows Server 2008 R2, por exemplo, oferece uma série de recursos que apoiam a construção de soluções com alta disponibilidade, como:

• Failover Clustering
• Network Load Balancing
• Windows Hardware Error Architecture (WHEA)
• Dynamic Hardware Partitioning
• Fault Tolerant Hardware
• Scaling Up (até 256 processadores)
• Shadow Copy
• Windows Server Backup
• Windows Recovery, etc.

Pensando na arquitetura de hardware e infraestrutura, diversos fornecedores oferecem soluções combinadas envolvendo SAN - Storage Area Network, SCSI - Small Computer System Interface, SATA - Serial AT Attachment e RAID - Redundant Array of Independent Drives, criando cenários que podem ser combinados para a construção de ambientes de alta disponibilidade, como vemos a seguir:

Assim, vemos soluções para disponibilidade de dados, alta disponibilidade de aplicações, alta disponibilidade de interfaces Web, compartilhamento de dados na rede, balanceamento de serviços, espelhamento de ambientes, cluster de servidores de dados, de máquinas virtuais, etc.

Outro exemplo interessante é o uso de virtualização para cenários de alta disponibilidade, onde uma combinação de máquinas virtuais, com clusterização de servidores e gerenciamento ativo geram uma infraestrutura robusta, tratando situação de recuperação, falhas e balanceamento de carga que tornam as aplicações mais disponíveis e com provisionamento dinâmico para cenários de nuvens privadas.

Uma pergunta importante: qual é a real necessidade do negócio quanto a alta disponibilidade da aplicação?

Veja o exemplo a seguir, para uma infraestrutura de alta disponibilidade consolidando máquinas virtuais, balanceamento de carga, monitoração integrada e cluster de servidores sobre plataforma Microsoft, usando o iSCSI Software Target:

Whitepaper: How to Build a Hyper-V Cluster Using the Microsoft iSCSI Software Target v3.3
Ref.: https://www.aidanfinn.com/?p=11164

Microsoft iSCSI Software Target 3.3
Ref.: https://www.microsoft.com/download/en/details.aspx?id=19867

O exemplo acima é um laboratório simples de dois nós de máquinas virtuais, suportando aplicações com alta disponibilidade sobre o iSCSI Software Target 3.3 da Microsoft.

Finalmente, até esse ponto, não falamos sobre o impacto desse tipo de arquitetura sobre as aplicações. Para muitos cenários, é recomendado que se faça uma avaliação sobre o comportamento e a arquitetura de software presente nas aplicações envolvidas. Para alguns cenários, as aplicações irão precisar de ajustes importantes para que suportem o ambiente de alta disponibilidade criado. Exemplos de cuidados para aplicações são:

• Monitoração com Microsoft System Center Suite, com gerenciamento de níveis de serviços e orquestração de atividades.
• Hospedagem com Windows Server AppFabric/IIS, com hospedagem de serviços e workflows, com caching, monitoração integrada, persistência, etc.
• Patterns de arquitetura de aplicações, como suporte ao balanceamento de carga, tratamento de exceções, instrumentação, orientação a serviços, etc.

Portanto, em sua próxima definição de arquitetura, avalie a necessidade de alta disponibilidade em sua solução final. Para completar o post, veja os artigos da seguinte edição da revista The Architecture Journal:

Journal 11 - The Architecture Journal
Ref.: https://msdn.microsoft.com/en-us/architecture/bb491107

Journal 24: The Different Paths to Virtualization
Ref.: https://msdn.microsoft.com/en-us/architecture/ff803567

Mass-Hosting High-Availability Architectures
Ref.: https://msdn.microsoft.com/en-us/library/bb491120.aspx

Espero que ajude!

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

Waldemir.

Esses dias tenho participado de algumas discussões envolvendo integração de diferentes domínios de aplicações e barramentos de serviços. Como também estou devendo alguns comentários sobre o tema para o maestro Evilázaro, segue aqui esse post. :)

Como sabemos, o principal servidor de integração da plataforma Microsoft é o Microsoft BizTalk Server 2010. Esse produto está em sua 7 edição e já possui mais de 10 anos de janela. No mundo, são mais de 10 mil deployments em grandes empresas de diferentes indústrias. Ao longo do tempo, a plataforma sofreu mudanças, evoluindo em funcionalidades e recursos para diversos cenários de integração, mensageria e barramento de serviços. Quem chegou a trabalhar com a versão 2004 deve se lembrar do impacto da chegada da versão 2006, com uma administração muito melhorada, por exemplo.

Veja as inúmeras versões da plataforma no desenho abaixo:

Para quem não conhece o produto, o BizTalk Server é o servidor de integração da plataforma Microsoft, oferecendo recursos e patterns que suportam soluções de integração entre diferentes domínios de aplicação. Além de oferecer os principais patterns de uma solução de Enterprise Application Integration (EAI), o BizTalk Server ainda suporta um modelo de conectividade baseada em Adaptadores, com inúmeras alternativas como EDI, File, HTTP, FTP, SFTP, SMTP, POP3, SOAP, SQL, MSMQ, SharePoint Services, WebSphere MQ, WCF-BasicHTTP, WCF-WsHTTP, WCF-Custom, WCF-SQL, Custom, entre outros.

A resolução de endereços de serviços suporta os modelos UDDI 2.0/3.0, XPATH, Static e Business Rules Engine (BRE) e permite a construção de cenários complexos de orquestração e roteamento de mensagens.

Abaixo, segue um desenho macro sobre a mensageria e orquestração oferecida pelo BizTalk Server:

Note que o motor principal do produto é baseado numa MessageBox, uma caixa de mensagens que persiste historicamente as mensagens e dados trafegados pelo produto. Para mensagens recebidas de diferentes fontes de dados, o BizTalk pode disparar novas mensagens ou roteá-las para seus destinos, usando portas de comunicação pré-configuradas (Receive Ports e Send Ports). Da mesma forma, mensagens específicas podem disparar processos e orquestrações (Pub/Sub) que implementam regras de negócio, permitindo a criação de cenários de integração e orquestração de serviços e workflows.

Uma das principais ampliações de funcionalidade do BizTalk foi a adição da camada de abstração para Enterprise Service Bus (ESB) ou Barramento de Serviços. O Microsoft BizTalk Server 2010 ESB Toolkit adiciona ao ambiente BizTalk uma série de patterns e recursos que permitem a construção de barramentos corporativos, com funcionalidades de roteamento, mensageria, transformação, tratamento de exceção, discovering, resolução e itinerário de serviços.

O desenho abaixo ilustra a arquitetura macro do ESB Toolkit, veja:

Outro aspecto importante para projetos envolvendo o BizTalk Server é a definição de papéis claros de atuação. Podemos destacar 3 profissionais específicos: desenvolvedores (Developers), analistas de processos ou negócios (Information Worker) e administradores de redes (IT Pro’s).

O assunto é muito vasto. Esse post está longe de dar uma visão completa sobre os recursos e funcionalidades do BizTalk Server. A ideia foi mesmo dar algumas palavrinhas sobre o assunto.

Em minhas leituras, encontrei um material atualizado excelente na Web, que recomendo a seguir:

>BizTalk Server 2010 Documentation
>https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11503

>BizTalk 2010 Developer Training Kit (excelente!)
>https://www.microsoft.com/downloads/en/details.aspx?FamilyID=38c2ccfc-510c-4627-a33c-95e9d19f3478

>Microsoft BizTalk Server 2010 ESB Toolkit
>https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11847

>Microsoft BizTalk Server 2010 Performance Optimization Guide
>https://www.microsoft.com/downloads/en/details.aspx?FamilyID=9094204c-3bc3-4f46-bdb9-6c7bc903330f

>BizTalk Server Best Practices Analyzer V1.2
>https://www.microsoft.com/downloads/details.aspx?FamilyID=93d432fe-1370-4b6d-aaa8-a0c43c30f5ab&displaylang=en

>BizTalk Server 2010 Posters
>https://dotnetbase.co.uk/post/2011/01/08/BizTalk-Server-2010-Posters.aspx

>BizTalk Benchmark Wizard
>https://bbw.codeplex.com/

Finalmente, destaque especial para dois grandes MVP’s do produto: Ruth Rezende (Brasil) e Sandro Pereira (Portugal). O material publicado em seus blogs é Leitura Obrigatória para quem está envolvido em projetos com a plataforma BizTalk, confira!

MVP de BizTalk no Brasil - Ruth Rezende
Ref.: https://www.biztalkbrasil.com.br/

MVP de BizTalk em Portugal - Sandro Pereira
Ref.: https://sandroaspbiztalkblog.wordpress.com/

E como não poderia faltar, confira os posts sobre Barramento de Serviços e arquitetura SOA/SOI do arquiteto Markus Christen, aqui da Microsoft.

Blog do Markus Christen
https://blogs.technet.com/b/markuschristen/archive/tags/enterprise+service+bus/

Para terminar, a certificação sobre o BizTalk Server 2010 foi lançada em março desse ano, confira:

Exam 70-595: TS: Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2010
https://www.microsoft.com/learning/en/us/exam.aspx?ID=70-595

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

Waldemir.

Nem só de serviços WCF e workflows WF vive um arquiteto na plataforma Microsoft. Um dos tópicos importantes de uma solução é saber como anda a infraestrutura e como monitorar sua evolução.

Nesse ponto, os próximos 12 meses serão de grandes novidades. Entre as principais tecnologias que devem atualizar a pilha de infraestrutura na plataforma Microsoft temos:

Service Manager 2010 R2
https://systemscentre.blogspot.com/2010/11/service-manager-2010-roadmap-sp1-r2.html

Configuration Manager 2012 Beta 2
https://www.microsoft.com/systemcenter/en/us/configuration-manager/cm-vnext-beta.aspx

Virtual Machine Manager 2012 Beta
https://www.microsoft.com/systemcenter/en/us/virtual-machine-manager/vm-vnext-beta.aspx

System Center Operations Manager 2012 Beta
https://blogs.technet.com/b/systemcenter/archive/2011/07/19/system-center-operations-manager-2012-beta-is-live_2100_.aspx

Data Protection Manager 2012
https://blogs.technet.com/b/aralves/archive/2011/03/28/dpm-2012-the-preview.aspx

System Center Orchestrator (Opalis) 2012 Beta
https://technet.microsoft.com/en-us/library/hh237242.aspx

Basicamente, as novas versões acima atualizam os processos de configuração, gerenciamento de serviços, gerenciamento de virtualização, operações e orquestração de tarefas no ambiente de infraestrutura sobre os produtos da família System Center.

Durante a modelagem de sua aplicação ou arquitetura de solução, é importante visualizar os componentes de infraestrutura, monitoração e gerenciamento relacionados, que estarão a disposição da solução quando em produção.

Se esses componentes não existirem no ambiente atual, é importante o arquiteto avaliar o impacto dessa falta e sugerir o tratamento dessa infraestrutura para evoluções futuras.

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

Waldemir.

Leitura Obrigatória para IT Pro’s e administradores de redes.

Windows Sysinternals Administrator's Reference [Paperback]
Mark E. Russinovich (Author), Aaron Margosis (Author)
Paperback: 496 pages
Publisher: Microsoft Press; 1 edition (July 20, 2011)
Language: English
ISBN-10: 073565672X
ISBN-13: 978-0735656727

Windows Sysinternals Administrator's Reference
Ref.: https://technet.microsoft.com/en-us/sysinternals/hh290819

 Mais um livro interessante de Mark Russinovich. Entre os principais assuntos temos:

- Process Explorer
- Process Monitor
- Autoruns
- PsTools
- Process and Diagnostic Utilities
- Security Utilities
- Active Directory Utilities
- Desktop Utilities
- File Utilities
- Disk Utilities
- Network and Communication Utilities
- System Information Utilities
- Miscellaneous Utilities

Lançamento!

Por enquanto é só! Bom final de semana  e até o próximo post :)

Waldemir.

Imagine o seguinte cenário: você precisa submeter 100 mil e-mails em 1 hora, para uma campanha de Marketing bem agressiva. Para esse envio, cada e-mail ainda exige um pequeno processamento ou cálculo, antes de submeter a mensagem. A lista de e-mails lhe foi dada em formato texto, com 1 coluna apenas com os diversos e-mails para destino. Você está considerando que todos os e-mails são válidos, não precisando fazer qualquer checagem.

O que você faria?

Podemos pensar em algumas soluções como o uso de LINQ to HPC, já ouviu falar?

Fonte: INTRODUCING LINQ TO HPC - PROCESSING BIG DATA ON WINDOWS, DAVID CHAPPELL, MAY 2011

Introducing LINQ to HPC: Processing Big Data on Windows
Ref.: https://www.microsoft.com/download/en/details.aspx?id=13615

Claro, podemos usar outras soluções para o envio de tantos e-mails em pouco tempo, mas a ideia de usar MapReduce é tentadora.

O LINQ to HPC é bem explicado no documento acima, escrito por David Chappell. Em resumo, o modelo de MapReduce é utilizado e pode ser uma alternativa para nosso caso, onde um Job Scheduler é chamado, recebendo a lista de e-mails para processamento. Na sequencia, a lista é quebrada em blocos de processamento, cada um enviado para um novo Nó de Processamento ou Lógica. Esses nós irão demandar o uso de nós computacionais para o processamento. Para cenários de processamento mais intensos que apenas mandar e-mails, com certeza o modelo de HPC é obrigatório. No final, uma Role de consolidação monitora o encerramento de todos os processamentos.

A solução acima é baseada em Windows Server 2008 local, com o HPC em ambiente on-premise.

Agora, pensando essa solução sobre a plataforma Windows Azure, essa semana tivemos uma atualização no projeto Daytona, que permite a construção de soluções de MapReduce sobre a plataforma na nuvem, veja:

Project Daytona: Iterative MapReduce on Windows Azure – CTP Refresh (July 26, 2011)
Ref.: https://research.microsoft.com/en-us/downloads/cecba376-3d3f-4eaf-bf01-20983857c2b1/ 

A solução respeita o modelo de MapReduce, onde uma entidade Mestre distribui as Tarefas para entidades Escravas, que fazem o processamento em blocos. Ao final, os resuldados são consolidados por uma entidade de fechamento ou simplesmente o processo é terminado pelas entidades escravas.

O grande interesse aqui está na possibilidade de contratação de máquinas escravas de forma dinâmica, conforme a necessidade, com o poder de processamento oferecido pelos datacenters da plataforma Windows Azure (que em muitos casos é bem maior que o poder de processamento de nossos datacenters corporativos locais).

Esse modeo é muito interessante para diversos cenários de aplicações que exigem o processamento de grandes quantidades de dados. Vale a pena estudar e acompanhar o projeto Daytona, que ainda está em CTP para o Windows Azure.

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

Waldemir.