Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : Arquitetura de Soluções

Algumas palavras sobre Projetos de Missão Crítica

wcamb — Fri, 06 Nov 2009 22:01:00 GMT

Olá pessoal, tudo certo?

Essa semana acompanhei algumas discussões no forum do Grupo .NET Architects. Entre vários assuntos, um em especial chamou minha atenção: projetos de Missão Crítica.

O que você entende por um Projeto de Missão Crítica?

Do wikipedia temos que o termo Missão Crítica refere-se a qualquer fator (equipamento, processo, procedimento, software, etc.) que seja crucial para o sucesso ou completude de uma atividade ou projeto. Também pode se referir a um projeto cujo o sucesso é vital para a missão da organização ou negócio da empresa.

Falando em projetos, vejamos alguns exemplos que considero de Missão Crítica:

- Um sistema de controle e coleta de dados de um projeto em Física Experimental para criação de estado de plasma, rodando sobre sistema operacional Debian/Linux, com processos em C, usando pilha TCP, pode ser considerado de missão crítica para o laboratório, devido as restrições e riscos envolvidos na monitoração e controle de equipamentos;

- Um núcleo de negociação para o mercado financeiro, tratando milhões de operações/dia, envolvendo mensageria em banco de dados, cache distribuído, gerenciamento de recursos em memória, etc., com requisitos rígidos de baixa latência, também é um exemplo de missão crítica;

- Um SDCD – Sistema Digital de Controle Distribuído – para monitoração e atuação de bicos de óleo em caldeiras para a geração de vapor num planta industrial, também é um belo exemplo. Vapor é um elemento chave em diversos processos industriais, de petroquímicas a processamento de atum em lata :)

- Um monitor transacional de alto desempenho, aplicando conceitos como ACID, MUTEX, CRITICAL SESSIONS, SEMÁFOROS, árvores de falhas, etc, é outro exemplo. Uma leitura obrigatória sobre o assunto é o livro Transaction Processing, confira aqui!

- Um sistema SaaS – Software as a Service – sobre algum provedor em nuvem, para uma solução multi-inquilino com interfaces Web, responsável pelo núcleo de faturamento da empresa, é de missão crítica, com requisitos de disponibilidade, responsividade e desempenho. Imagine um sistema SaaS para a venda de ingressos do show de Eric Clapton ou B.B. King! :)

- Um sistema de automação para controle de caixas margem de via, por exemplo, para determinação de presença de trens de metrô e vagões em trechos da via, abertura de portas, desvios de ramais, movimento, etc. O próprio controle do carrossel de composições na via também é crítico. Qual é o trem mais seguro? Um trem parado ou um trem na oficinal, fora da via? :)

- Um sistema para contabilidade e bilhetagem de chamadas em telefonia celular, também é crítico;

- Em muitos cenários, até mesmo um sistema de emails é um sistema de missão crítica para a empresa. Algumas corporações simplesmente param ou perdem negócios em casos de falha em suas caixas postais, por mais commodities que possam parecer. Impacto financeiro a vista!;

- Um sistema de controle de equipamentos médicos, como scanners, tomógrafos, dispositivos de ultra-som, leitores dopplers em tempo real (opa!), entre outros mais sofisticados em medicina, são extremamente críticos em seus resultados.

Considero todos os exemplos acima como sistemas de Missão Crítica em diferentes níveis, pois envolvem riscos para o negócio da empresa.

Assim, podemos destacar três tipos de riscos envolvidos:

Riscos Materiais;
Riscos Financeiros;
Riscos envolvendo Vidas Humanas;

Alguns sistemas de Missão Crítica podem envolver requisitos de Tempo Real (Real Time), isto é, janelas de atuação e tempos resposta bem definidos, que devem ser respeitados. Nesses casos, o número de processos envolvidos, o volume ou o número de chamadas disparadas não deve interferir no tempo de resposta do sistema.

Qual é o tempo de resposta envolvido no tempo real (em milisegundos, por exemplo)? Dependerá do cenário que estamos tratando, seja um canal de feeders de notícias com filtros sobre política ou mensagens para a abertura de cofres em sistemas de segurança bancário.

Normalmente, condições de tempo real estão envolvidas em cenários de missão crítica, mas não são obrigatórias.

Meu ponto aqui é que não podemos considerar como Missão Crítica apenas o aspecto de desempenho e tempo de resposta envolvidos. Para algumas indústrias, outros atributos são tão importantes quanto, como o impacto financeiro, disponibilidade e riscos diversos.

Quão crítico é o sistema em que você está trabalhando hoje? Ele envolve riscos financeiros, riscos humanos ou riscos materiais?

Em resumo, qual é o impacto de uma falha em seu sistema para a execução do negócio de sua empresa? Aspectos como recuperação de falhas, tratamento de exceções, árvore de falhas, etc., tornam-se importantes em muitos casos.

Uma vez identificado o cenário de missão crítica, como conduzir o projeto?

Algumas perguntas são recorrentes neste momento, como:

Qual é o melhor sistema operacional para cada cenário?
Qual é a melhor linguagem de programação para cada cenário?
Qual é a melhor abordagem de patterns para cada cenário?
Quais são as restrições de memória e disco para o SO? Poucos recursos? Desktops? Servidores?
Quais são as necessidades de comunicação com dispositivos e periféricos diversos nesse ambiente de missão crítica?
Quais são os drivers disponíveis para o SO escolhido? Teremos que implementar esses drivers? Existem fornecedores no mercado?
Quais são as latências de rede e pilhas de transporte suportados? O TCP é suficiente? IPv6? Vamos precisar adotar protocolos de Tempo Real (RTP – Real Time Transport Protocol)? Vamos implementar bindings customizados para a entrega de mensagens com baixa latência? Transporte customizado?
Qual a necessidade por tempo real, paralelismos de processos, high performance computing, cluster computing ou grid computing?

Sem falar ainda em questões adjacentes, como:

Qual será o suporte necessário para a solução?
Como será evolução da pilha de software ao longo do tempo?
Qual é o perfil de profissionais capacitados, exigidos para o projeto?
Quais são os guias de desenvolvimento e patterns disponíveis?
Quais são as ferramentas para a construção de software, metodologias, documentação, etc.

Através aqui do blog, temos acompanhado a plataforma Microsoft e seu suporte para aplicações de missão crítica em diferentes níveis.

Existem diversos recursos que atendem esses cenários, seja sobre a plataforma .NET ou mesmo sobre código não gerenciado, com processos em C++ sobre Windows Server. No ambiente gerenciado, recursos como interfaces de serviços em WCF – Windows Communication Foundation, mensageria com MSMQ, paralelismo, sincronização e sistemas de integração com baixa latência são alguns exemplos. Em todos os casos, o impacto para o negócio da empresa está presente.

Em breve, teremos ainda novos recursos disponíveis na plataforma Microsoft, como o Dublin (para hospedagem de serviços e processos sobre o Windows Server), o Velocity (para cache distribuído e aplicações de alto desempenho), novos recursos sobre WCF 4 e WF 4, além da integração com a plataforma de alta escalabilidade e disponibilidade do Windows Azure, que já está em contagem regressiva para seu lançamento, durante o PDC 2009.

Finalizando, procure identificar em quais cenários de Missão Crítica você está pessoalmente envolvido e como será a evolução destes nos próximos meses. Você vai perceber que sua TI tem um impacto direto para o sucesso de sua empresa!

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

Waldemir.

Leitura Recomendada: Microsoft Application Architecture Guide 2nd Edition

wcamb — Thu, 05 Nov 2009 21:45:00 GMT

Olá pessoal, tudo certo?

Como anunciado por aqui, o App Arch Guide 2 foi lançado de forma impressa e já está disponível na Amazon, veja:

Microsoft® Application Architecture Guide, 2nd Edition (Patterns & Practices)
Ref.: http://www.amazon.com/Microsoft%C2%AE-Application-Architecture-Patterns-Practices/dp/073562710X/ref=sr_1_1?ie=UTF8&qid=1257457119&sr=8-1-spell

Confira aqui o post do J.D. Meier sobre o anúncio, feito hoje!

Now Available: patterns & practices Application Architecture Book
Ref.: http://blogs.msdn.com/jmeier/archive/2009/11/05/now-available-patterns-practices-application-architecture-book.aspx

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

Waldemir.

Exemplo de arquitetura em camadas para o .NET 3.5 SP1

wcamb — Wed, 04 Nov 2009 16:28:00 GMT

Olá pessoal, tudo certo?

Semana passada, o especialista Rafael Godinho comentou com o pessoal sobre um belo exemplo de projeto em .NET 3.5 SP1, que está disponível no codeplex para estudo.

O projeto é um exemplo de arquitetura em camadas usando o .NET 3.5 SP1, com interface de serviços WCF e camadas de negócios bem definidas. Com frequência recebo pedidos de exemplos de projeto e organização de arquiteturas em camadas para aplicações sobre o .NET 3.5.

Assim, aqui vai uma dica interessante de estudo:

Layered Architecture Sample for .NET
Ref.: http://layersample.codeplex.com/

Os fontes estão disponíveis para donwload, falta um guia ou passo-a-passo para estudos, mas o projeto é um bom exemplo de organização, que vale o estudo. Confira!

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

Waldemir.

ebook Arquitetura de Soluções no Download Center do MSDN

wcamb — Sat, 31 Oct 2009 20:26:00 GMT

Olá pessoal, tudo certo?

Disponibilizei o ebook Arquitetura de Soluções no download center do MSDN, facilitando assim seu acesso, confira:

Download do ebook Arquitetura de Soluções
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=df61c997-8718-4836-8b4c-eb55042e379e&DisplayLang=pt-br

Por enquanto é só! Bom feriado para todos e até o próximo post :)

Waldemir.

Novidades no Application Architecture Guide 2.0

wcamb — Tue, 20 Oct 2009 22:18:00 GMT

Olá pessoal, tudo certo?

Que tal o Application Architecture Guide 2.0 no formato .CHM, mais fácil de navegar pelos temas desejados?

App Arch Guide 2.0a - CHM File
Ref.: http://apparchcontrib.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=33990

O arquivo acima ainda está em Beta, sendo revisado pelo time do patterns&practices. Feita a ressalva, vale conferir o arquivo!

Outra novidade é que até o final deste ano, uma versão impressão do App Arch Guide 2.0 será lançada, veja a capa:

O livro ainda virá com algumas atualizações!!!

O formato original em PDF da versã0 2.0 encontra-se no link:

patterns & practices: App Arch Guide 2.0 Knowledge Base
Ref.: http://www.codeplex.com/AppArch

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

Waldemir.

Novo portal do msdn já está no ar!

wcamb — Tue, 20 Oct 2009 12:11:00 GMT

Olá pessoal, tudo certo?

Novidades na página do msdn! Agora o portal está com novo layout, além de um novo logo!

Ref.: http://msdn.microsoft.com/pt-br/default.aspx

Para os times trabalhando com Windows Azure, o portal de Azure também mudou:

Ref.: http://msdn.microsoft.com/pt-br/azure/default.aspx

E para os arquitetos, confira o novo Centro de Arquitetura MSDN:

Ref.: http://msdn.microsoft.com/pt-br/architecture/default.aspx

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

Waldemir.

Leitura Recomendada: eBook Arquitetura de Soluções

wcamb — Thu, 01 Oct 2009 16:47:00 GMT

Olá pessoal, tudo certo?

Comemorando os dois anos deste blog, estou publicando aqui meu primeiro eBook, sobre Arquitetura de Soluções! :)

ebook Arquitetura de Soluções

Ref.: http://cid-ac0dc53ca97927a5.skydrive.live.com/browse.aspx/ebookAS

Pois é, nesse mês de outubro de 2009 o blog “Arquitetura de Soluções” faz dois anos e parece que foi ontem que ele começou. Já foram mais de 270 posts publicados sobre vários assuntos e temas relacionados à arquitetura de software.

Para registrar essa data, resolvi consolidar os principais posts por assuntos num ebook, que fica assim disponível para sua leitura off-line.

Entre os tópicos principais você vai encontrar SOA, SOI, WCF, SAAS, Aplicações Compostas, Windows Azure, entre outros.

Como todo ebook, essa é apenas a versão 1.0. Fiquem a vontade para sugestões, comentários ou correções que acharem interessante!

Espero que gostem!

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

Waldemir.

Lightweight Architecture Alternative Assessment Method (LAAAM)

wcamb — Mon, 28 Sep 2009 19:00:00 GMT

Olá pessoal, tudo certo?

Semana passada, descobri um assunto bem interessante (thanks Markus!) sobre métodos para definição de arquiteturas e entre eles o LAAAM - Lightweight Architecture Alternative Assessment Method.

Em resumo, o LAAAM é um método que tem por objetivo orientar as definições de arquitetura de forma alinhada às reais necessidades do negócio da aplicação, de modo rápido e eficiente.

Como sabemos, as decisões em arquitetura possuem um impacto direto no sucesso de um projeto. Por isso, antecipá-las já nos primeiros passos do ciclo de desenvolvimento de software ajuda a diminuir os riscos de projeto, economizando também recursos e tempo de desenvolvimento com correções tardias. Já observamos a presença do arquiteto ao longo do ciclo de vida do projeto, por exemplo, em métodos ágeis como o MSF for Agile.

O principal mecanismo do método LAAAM é focar na definição sobre a qualidade de um sistema ou produto. Normalmente, estamos preocupados com qualidades de alto nível, porém, o LAAAM promete ajudar a determinar aspectos mais concretos, como:

qual o tipo de escalabilidade ou flexibilidade o sistema deve atingir;
quais são os atributos de qualidade mais importantes para atender os objetivos do sistema;
qual é o processo racional de decisão para cada parte da arquitetura, entre outros.

Descobri um vídeo bem interessante que comenta alguns aspectos sobre o LAAAM, no link abaixo:

Ref.: http://channel9vip.orcsweb.com/shows/ARCast.TV/ARCastTV-Using-LAAAM-to-Make-Good-Architectural-Decisions-Fast/

Para saber mais, veja ainda esse post, do próprio Jeromy:

Lightweight Architecture Alternative Assessment Method (LAAAM)
Ref.: http://blogs.msdn.com/jeromyc/archive/2005/08/27/457081.aspx

Como você, estou apenas iniciando minhas leituras sobre o LAAAM, que tem sua raiz em outro método, o Architecture Tradeoff Analysis Method, desenvolvido por um dos times da SEI - Software Engineering Institute, na Carnegie Mellon University.

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

Waldemir.

Programação Paralela com DryadLINQ

wcamb — Mon, 21 Sep 2009 17:50:00 GMT

Olá pessoal, tudo certo?

Depois de um post do Otávio na semana passada, acabei dando uma circulada pelos projetos da Microsoft Research e encontrei algo bem legal!

Para quem não viu, o Otávio falou rapidamente sobre MapReducing, uma estratégia interessante para a divisão de tarefas no processamento paralelo, que é bem aderente para uma série de cenários com demanda de alta performance, como em pesquisas científicas e simulações.

Usando as palavras do Otávio, “…a idéia é simples: se quisermos aumentar o paralelismo de uma operação, um processo Mestre deve dividir a tarefa em diversas partições, uma para cada processo Trabalhador. Chamamos este passo de Map. Em seguida, cada processo retorna seu resultado parcial para o processo Mestre, que aglutina e retorna todas as respostas para quem requisitou o processamento. Chamamos este passo de Reduce…”

O post original continua a explicação sobre o tema e como podemos aplicar a estratégia sobre o Windows Azure, um ambiente de alta escalabilidade e armazenamento de dados ilimitado. Tipos como Web Roles, Worker Roles, Queues e Tables permitem uma implementação suave desse tipo de abordagem para uma computação de alto desempenho.

Na Microsoft Research, encontrei o projeto DryadLINQ, que é um ambiente de programação para a construção de aplicações paralelas de alta escalabilidade de dados, rodando sobre clusters de PC. Como descrito pelo time da Research, o objetivo do projeto é tornar a computação paralela simples o suficiente para projetos do dia-a-dia.

O desenho abaixo ilustra a arquitetura do projeto DryadLINQ, veja:

DryadLINQ …pronuncia-se [dr’aied link] :)
Ref.: http://research.microsoft.com/en-us/projects/dryadLINQ/

Já está disponível uma versão acadêmica para testes, assim como uma documentação em .PDF bem completa. A partir desta documentação, retirei a listagem abaixo, onde vemos a referência para a biblioteca LinqToDryad e o código para a listagem de conteúdo de um arquivo texto (só para ilustrar).

   1: using System;   2: using System.Collections.Generic;   3: using System.Linq;   4: using System.Text;   5: using LinqToDryad;   6:     7: public static class Program   8: {   9:     static void ShowOnConsole<T>(IQueryable<T> data)  10:     {  11:         foreach (T r in data)  12:             Console.WriteLine("{0}", r);  13:     }  14:     static void Main(string[] args)  15:     {  16:         string basedirectory = @"file://\\machine\directory";  17:         string filename = "inputfile.txt";  18:         DryadDataContext ddc = new DryadDataContext(basedirectory);  19:         DryadTable<LineRecord> table = ddc.GetTable<LineRecord>(filename);  20:         ShowOnConsole(table);  21:         Console.ReadKey();  22:     }  23: }

Para conferir a versão já disponívei e alguns exemplos em DryadLINQ, veja:

Dryad and DryadLINQ: Academic Release
Ref.: http://connect.microsoft.com/site/sitehome.aspx?SiteID=891

Some sample programs written in DryadLINQ
Ref.: http://research.microsoft.com/pubs/66811/tr-2008-74.pdf

A programação paralela envolve diversos desafios, assim como abordagens específicas para seu tratamento.

Porém, temos visto muito de sua aplicação restrita em ambientes de pesquisa e universidades. Creio que iniciativas como o DryadLINQ e mesmo técnicas como o MapReducing sobre ambientes de computação na nuvem devem trazer a programação paralela para mais perto das iniciativas comerciais num futuro próximo. O próprio .NET 4.0 está chegando com alguns recursos importantes para programação paralela, como o Task Parallel Library (TPL), o Parallel LINQ (PLINQ), o Coordination Data Structures (CDS), além de melhorias na System.Threading. Cada um desses recursos deve merecer um post dedicado no futuro.

Olhando um pouco o Parallel LINQ (PLINQ), ele permite aos desenvolvedores aproveitarem os múltiplos núcleos de uma máquina multicore, através do modelo de programação do LINQ.

Veja abaixo um exemplo de código com PLINQ, onde notamos o uso da cláusula .AsParallel(), que ativa o aproveitamento multicore disponível na máquina:

   1: var q = from p in people.AsParallel()   2:         where p.Name == queryInfo.Name &&    3:               p.State == queryInfo.State &&   4:               p.Year >= yearStart &&   5:               p.Year <= yearEnd   6:         orderby p.Year ascending   7:         select p;

Um assunto puxa o outro e as oportunidades são imensas.

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

Waldemir.

Sessões Back to Basics? Por que não?

wcamb — Mon, 14 Sep 2009 19:56:00 GMT

Olá pessoal, tudo certo?

Estamos em tempo de mudança. Como o Markus fala de vez em quando, “o Mundo Mudou!”. Concordo com vocês, as vezes é difícil acompanhar o ritmo das mudanças e inovações que atingem nossa área. TI é assim! Durante o último Tech-ed Brasil 2009, eu ouvi o mesmo comentário de vários participantes: “Qual tecnologia eu devo usar?”, “O que eu preciso estudar agora?”, “Porque temos tantos frameworks e opções diferentes disponíveis?”, “O que eu uso para uma aplicação Web?”, entre outros.

De fato, não temos uma resposta padrão ou simples para todas essas perguntas. Tenho trabalhado em TI nos últimos 15 anos e já vi diversas mudanças em arquitetura, alavancadas por diferentes fatores. Quem aqui não viu (tudo bem, alguns aqui não viram) o nascimento do cliente/servidor, aplicações com C++, VB6, componentes em COM+ sobre Windows Server 2000, as novidades do mundo Web, a adoção de Web Services em alta escala pelas empresas, etc. Você viu também a publicação do .NET Framework, sua evolução com as versões 2.0, depois 3.0 com o WCF e o WPF, o uso de serviços REST, o .NET 3.5 SP1. Finalmente, vimos o crescimento da discussão em torno de SOA, SOI, SAAS e mais recentemente o Cloud Computing, o provisionamento dinâmico, a computação de alta escala, o Windows Azure, etc.

Durante o Tech-ed Brasil, tive a oportunidade de falar sobre a iniciativa Software + Serviços da Microsoft, que oferece uma visão para a TI do futuro. Um dos slides que usei mostra a evolução das arquiteturas dominantes nas últimas décadas. Claro, é uma simplificação do que aconteceu em TI, mas vale como ilustração, veja:

Em cada década, tivemos uma arquitetura dominante, que definiu o estilo e o comportamento do software que era construído para o mercado e para nossos usuários. Vale destacar que cada nova arquitetura apareceu como uma nova alternativa de infraestrutura, adicionando valor e novas opções de recursos para as arquiteturas existentes. Essa combinação tem sido observada até hoje e muitas empresas ainda convivem com várias dessas arquiteturas, ao mesmo tempo.

Mas retornando às dores de nosso dia-a-dia e pensando nas perguntas que vimos no começo deste post, existe ao menos uma coisa que é constante nessa evolução toda: a aplicação de bons príncípios de engenharia de software. Independente do tipo de framework, camada, componente ou novos recursos que você adote, lembre-se sempre de princípios como:

Programação Estruturada;
Programação Orientada a Objetos;
Modelagem de Dados e Teoria de Conjuntos;
Bons Patterns de Arquitetura;
Tipos Abstratos de Dados, Filas, Pilhas, Listas Ligadas, Caches;
Otimização de Algortimos, etc.

Como arquitetos de software, creio que é saudável manter “frescos na memória” esses conceitos. Separe um tempinho de seu corrido dia para relembrar os tópicos acima.

Creio que uma sessão “back-to-basics” de vez em quando vai ajudá-lo a olhar os vários recursos e frameworks sob um prisma diferente. Isso também vai ajudá-lo a reconhecer quais tecnologias você pode aplicar em sua empresa, no momento certo de sua necessidade.

É o que eu tenho feito e tem funcionado!!!

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

Waldemir.

Pensando na evolução da TI de uma empresa.

wcamb — Fri, 11 Sep 2009 20:54:00 GMT

Olá pessoal, tudo certo?

Durante o Tech-ed Brasil 2009, tive algumas discussões que mais ou menos foram replicadas essa semana, com outras empresas e arquitetos.

Uma dessas discussões foi sobre a evolução da TI numa empresa, com o foco em sua organização e maturidade. Veja o desenho abaixo:

No primeiro bloco, vemos o que é chamado de uma arquitetura “Spaghetti” ou “Macarronada” ou digamos “Noooooossa” :) É muito comum encontrarmos esse tipo de organização de TI, onde para cada comunicação entre sistemas temos um tipo dedicado de conexão, sem padronização, reuso de funcionalidades ou normalização de mensagens e formatos de dados. O custo de manuteção desse tipo de arquitetura é alto, assim como sua administração é complicada, com erros recorrentes. Atualmente, tenho visto muitas empresas iniciando ações para sair desse tipo de arquitetura e organização em TI.

Um segundo estágio nessa evolução pode ser o uso de um motor de EAI – Enterprise Application Integration. Uma infraestrutura de EAI oferece um cenário padronizado de conectividade entre sistemas, facilitando a comunicação entre os serviços existentes através de adaptadores padronizados, schemas de mensagens, formatos de dados versionados, além de uma série de patterns para transformação de mensagens, subscrição, publicação, auditoria, tracing, entre outros, de forma centralizada. Porém, algumas empresas aplicam cenários de EAI em alguns departamentos, enquanto ainda permitem a continuidade de arquiteturas “macarrônicas” em outros andares, seja por problemas históricos, políticos ou de investimentos.

Finalmente, coloco aqui um terceiro estágio de evolução, o ESB – Enterprise Service Bus, ou barramento corporativo de serviços. Podemos pensar num ESB como um conjunto de patterns de EAI, adicionado a patterns de roteamento de mensagens, composição de mensagens e serviços, tratamento de exceção, resolução de chamadas para serviços, etc. Uma grande diferença entre EAI e um ESB é a possibilidade de composição dinâmica de serviços. Enquanto que num cenário de EAI temos links estáticos entre clientes e provedores, no modelo ESB o desacoplamento é ainda maior, sendo possível a composição dinâmica de chamadas. A presença de um repositório ou catálogo de serviços também é parte desse tipo de solução, seja através de um UDDI ou mesmo de catálogo em bancos de dados.

O que achei interessante essa semana foi ver como cenários assíncronos de mensageria, assim como a possibilidade de publicação de serviços ou dados num ambiente na nuvem tornam-se participantes dessa nova TI que arquitetos começam a imaginar. Mensageria não é novidade de forma alguma, mas mensageria entre diferentes infraestrutura de TI me pareceu interessante.

Como tenho dito para algumas pessoas, nossa TI no futuro será cada vez mais híbrida, combinando serviços e dados ora no ambiente local (on-premise), ora no ambiente hospedado (em hosters e provedores) ora na nuvem. Um dos aspectos importantes que teremos será a combinação de SLA’s e níveis de operação, assim como mecanismos de monitoração, logging e administração unificados, que torne a vida do ITPro mais fácil para esses cenários.

Cloud Computing é uma evolução de SOA? Depois de um EAI, sigo para um ESB? E depois de um ESB, sigo para o uso de um ISB – Internet Service Bus? De fato, penso que essas perguntas não têm muita relevância. O mais importante será mesmo aproveitar o melhor de cada infraestrutura, de acordo com as reais necessidades de sua aplicação, solução ou negócio. Fique atento ao que realmente interessa para sua empresa! Se você é um ITPro, fique atento às ferramentas de administração que estão aparecendo. Se você é um desenvolvedor, fique atento aos frameworks e opções de tecnologias que surgem para a construção de aplicações. E se você é um arquiteto, seja de soluções ou de infra, fique atento na hora de aplicar a melhor tecnologia que atende sua empresa.

Seja usando SAAS, EAI, ESB, ISB, ERP, CRM, SC, UDDI, SOAP, REST, HTTP, TCP, etc. o que vale mesmo é atender corretamente seu usuário final, não é mesmo?

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

Waldemir.

Qual a importância de um arquiteto?

wcamb — Fri, 14 Aug 2009 15:19:00 GMT

Olá pessoal, tudo certo?

Semana passada, o Markus Christen havia iniciado uma discussão sobre o papel do arquiteto no ARQBR. Algumas pessoas avançaram as discussões offline e tivemos algumas conclusões. Gostaria de colocar aqui uma visão consolidada sobre o tema.

Pessoalmente, tenho visto diversos tipos de profissionais atuando como arquitetos no mercado.

Pensando em arquitetos de soluções, focados em projetos e na construção de sistemas, qual a importância deles? Gosto muito da seguinte frase para explicar a importância do arquiteto de soluções: "Arquitetura de software é o conjunto de decisões de design as quais, se feitas incorretamente, podem provocar o cancelamento de seu projeto". :)

Ainda pensando na construção de software, a SEI - Software Engineering Institute | Carnegie Mellon, tem conduzido uma pesquisa sobre definições para arquitetura de software em todo o mundo, através do link abaixo:

Ref.: http://www.sei.cmu.edu/architecture/community_definitions.html

Lendo as várias definições, fica claro que mesmo pensando na construção de software, o papel do arquiteto e suas atividades são muito diversificados. Mas é sempre direcionado pelas decisões que podem conduzir uma solução para o sucesso ou fracasso, decisões essas relacionadas com a escolha e a combinação de tecnologias aplicáveis para aquela solução. Assim, creio que podemos resumir a importância do arquiteto de solução nessa palavra: direção! Direção para a melhor arquitetura de software que será empregada, buscando a aplicação de uma boa engenharia de software sempre.

Pensando em arquitetos enterprise ou corporativos, esses estão mais distantes do mundo de soluções, muito envolvidos com o negócio da empresa. Qual o papel da TI para a missão da empresa? Qual o impacto de longo prazo do investimento em uma determinada tecnologia ou abordagem de solução. Alguns exemplo? Pense na adoção de um sistema Web para o terminal de auto-atendimento de um banco de varejo. Estamos falando de quantos terminais espalhados pelo Brasil? Pense na adoção de uma plataforma baseada em serviços para a oferta de produtos para corretoras de valores? Qual o impacto de segurança e velocidade de implantação de novos produtos nessa infra-estrutura? Enfim, uma decisão tomada pelo arquiteto corporativo é apresentada para o núcleo de negócios da empresa e normalmente, tem um tempo de maturidade e implantação de médio e longo prazo. Mas são importantes pelo poder de influência e impacto no dia-a-dia de todos da corporação. Qual a importância desse profissional hoje em dia?

Finalmente, pensando em arquitetos de infra-estrutura, estamos num momento muito especial em TI, vendo o nascimento de uma nova plataforma de infra-estrutura disponível na nuvem. Nos próximos anos, o cloud computing será uma realidade para muitas empresas, que buscam a composição de custos entre software e infra-estrutura on-premise e software e serviços na nuvem. O arquiteto de infra-estrutura e IT Pros, que atuam diretamente nesse ambiente de suporte a software poderão focar cada vez mais nas capacidades de TI, oferecendo uma infra-estrutura combinada que irá permitir a construção de soluções mais flexíveis, dinâmicas e transparentes para o usuário final. Qual a importância do arquitetura de infra-estrutura? Suas decisões, o quanto mais alinhadas com a direção de negócio e desenvolvimento da empresa, permitirão uma maior velocidade na adoção de novas tecnologias, consequentemente, um posicionamento melhor no mercado de atuação de sua empresa.

Agora, uma nova pergunta: você que está na carreira de arquiteto, como está se preparando para tomar as decisões corretas em sua empresa?

O impacto de suas decisões pode ser tão grande quanto o sucesso ou fracasso de uma campanha, de um projeto, de um produto ou de um lançamento em sua empresa. Prepare-se!

Alguns links interessantes:

Worldwide Institute of Software Architects - WWISA
Ref.: http://www.wwisa.org/

IASA - International Association of Software Architects
Ref.: http://www.iasahome.org/web/home/home
http://www.wwisa.org/

The Architecture Journal
Ref.: http://msdn.microsoft.com/en-us/architecture/bb410935.aspx

Dev Center de Arquitetura no MSDN Brasil
Ref.: http://msdn.microsoft.com/pt-br/architecture/default.aspx

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

Waldemir.

O ritmo da inovação e o papel do arquiteto

wcamb — Wed, 05 Aug 2009 17:15:00 GMT

Olá pessoal, tudo certo?

Semana passada estive com uma equipe de arquitetura de uma empresa do setor financeiro, discutindo sobre tendências em TI e a visão para a computação na nuvem. Com certeza, 2009 está sendo o ano do Cloud Computing.

Uma pergunta que aparece nesse tipo de discussão é sobre quando adotar uma nova plataforma. Vale a pena investir na computação na nuvem? Quais benefícios a plataforma pode oferecer para o meu negócio?

Esse é o mesmo dilema quando pensamos em investir em treinamentos sobre novas tecnologias, como frameworks, ferramentas de desenvolvimento ou plataformas de aplicações. O cenário é mais crítico quando a TI da empresa está desatualizada em relação ao mercado. Se você ainda desenvolve em ASP com componentes COM+ em VB6 e possui alguns sites em ASP.NET com .NET 1.1, por exemplo, o impacto de uma evolução é maior, tanto na capacitação de sua equipe como na percepção de melhorias para o usuário e para o negócio da empresa.

Veja o gráfico abaixo, onde temos o tempo no eixo “x” e a vantagem competitiva de uma empresa num determinado mercado no eixo “y”.

O desenho ilustra o impacto da adoção de uma inovação tecnológica ao longo do tempo. Imagine 3 empresas para uma determinada área de atuação.

A primeira é uma empresa ágil, que rapidamente incorpora inovações estratégicas e consegue um melhor posicionamento no mercado em relação a seus concorrentes. Para isso, essa empresa investe em novas tecnologias, acompanha o lançamento de novas plataformas e ferramentas de mercado, assim como mantém uma cultura de constante avaliação de suas soluções em relação ao negócio da empresa. Como resultado, é reconhecida como uma empresa inovadora e que lança tendências ou aproveita os benefícios de uma nova tecnologia, melhorando sua produtividade, tempo para o lançamento de novos produtos, redução de custos, alcance para novos mercados, etc.

Com o passar do tempo, uma segunda empresa adota a mesma inovação, ainda conseguindo um bom posicionamento no mercado. Muitas vezes, essa empresa é uma seguidora de líderes da indústria, um cenário muito comum no mercado financeiro e entre bancos.

Finalmente, uma terceira empresa adota as inovações estratégicas de forma tardia, não aproveitando os benefícios e oportunidades da adoção de uma nova tecnologia, apenas corrigindo sua posição no mercado. Muitas vezes, essa empresas trata a área de TI como um universo apenas operacional, de suporte ao negócio da empresa sem relevância, não reconhecendo o impacto e possíveis oportunidades que a primeira empresa conseguiu aproveitar.

Existem diversos motivos que posicionam uma empresa em cada um desses 3 perfis, como cultura organizacional, histórico de projetos, tamanho da empresa, tolerância ao risco, burocracia, inércia das áreas envolvidas, resistência a novas formas de trabalho, etc. Reconhecer em qual grupo sua empresa está é o primeiro passo nessa auto-análise tecnológica. A partir desse diagnóstico, identificar quais benefícios e o impacto de uma nova tecnologia para o negócio da empresa deve oferecer bons argumentos para uma tomada de decisão.

Ao mesmo tempo, um tópico que aparece é o chamado “dilema da inovação”. O aparecimento de novas tecnologias e inovações estratégicas também pode criar empresas emergentes, que aproveitam com maior sucesso de novas demandas do mercado ou de seus clientes, que também percebem os benefícios da inovação disponível.

Entre 2009 e 2010, vamos acompanhar de perto uma das maiores ondas de lançamentos de tecnologias e inovações na plataforma Microsoft. Teremos Office 2010, SharePoint 2010, Exchange 2010, Visual Studio 2010, .NET 4.0, Windows Azure, Windows Server 2008 R2, Windows 7, entre tantos outros.

Em tempo de crise, investir em inovação é tão importante quanto controlar os custos operacionais da empresa. Cada empresa possui um histórico próprio que explica seu posicionamento e seu grau de inovação no mercado.

Como arquitetos, como podemos ajudar nossa empresa no entendimento dessas questões, para dar o próximo passo evolutivo no ritmo das inovações em TI? Fica para pensar…

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

Waldemir.

Estudo de caso : um mapa para decisões de projeto

wcamb — Wed, 29 Jul 2009 18:04:00 GMT

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
http://www.msdnbrasil.com.br/microsoft.MediaCenter/Default.aspx_x_CATEGORY_x_WCF.aspx

WF – Windows Workflow Foundation
http://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.

Pricing no Windows Azure

wcamb — Thu, 16 Jul 2009 15:12:00 GMT

Olá pessoal, tudo certo?

Saiu!!! Foi publicada na terça-feira (14/07) a lista de preços para a primeira onda de países suportados comercialmente pelo Windows Azure. Confira:

Confirming Commercial Availability and Announcing Business Model
http://blogs.msdn.com/windowsazure/archive/2009/07/14/confirming-commercial-availability-and-announcing-business-model.aspx

Pricing & Licensing Overview
http://www.microsoft.com/azure/pricing.mspx

Na primeira onda teremos Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, India, Italy, Japan, Netherlands, New Zealand, Norway, Portugal, Spain, Sweden, Switzerland, UK e United States.

Na segunda onda, prevista para Março de 2010 teremos Brasil, Chile, Colombia, Czech Republic, Greece, Hong Kong, Hungary, Israel, South Korea, Malaysia, Mexico, Poland, Puerto Rico, Romania, Singapore e Taiwan.

A tabela de preços é a seguinte:

Em algum momento deveremos ter simuladores online disponíveis no portal do Azure para o cálculo de diferentes cenários, combinando horas de computação, espaço contratado (storage), banda, transação, etc. Mas já podemos fazer algumas contas em nossas planilhas pessoais.

Nesse exercício, vale identificar os corretos valores de comparação, não apenas os valores acima com a operação do software. Pense em custos locais (on-premise) que temos hoje, como utilities, manutenção, downtime, custos por falhas, pessoal, etc. Já troquei algumas palavrinhas com o Otávio e o Condé, sobre o que seriam exemplos de análise. Assim que os primeiros rascunhos fecharem, publico aqui um exemplo para nossas discussões.

Outro assunto interessante é sobre a qualidade do software escrito. Considerando que alguns custos são diretamente relacionados com o modelo de operação da aplicação, pensar num desenvolvimento que seja otimizado em relação a banda, consolidação de transações, número de mensagens trocadas, etc. passa a ser relevante na conta, não concorda?

Assim, creio que teremos 2 novas ondas pela frente: uma primeira onde de TI, visando identificar as aplicações mais aderentes ao modelo elástico de computação na nuvem, por indústria (manufatura, finanças, bens e consumo, etc); e uma segunda onda, que deve identificar as otimizações e melhores práticas para o desenvolvimento de aplicações na nuvem, para uma redução de custos associados ao modelo do micro-pagamento e custos por operação.

Sem dúvida, a nova década da computação já começou…

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

Waldemir.