Windows Nano Server - A maior evolução para o DevOps Microsoft

O grande gargalo para o uso de sistemas Windows em ambientes de nuvem e para uma boa infraestrutura de DevOps fora do Microsoft Azure é sem dúvida o footprint gigantesco do sistema. Manter uma maquina virtual onde apenas processos de backend precisam ser executados demanda a instalação do sistema operacional completo, incluindo ferramentas gráficas e tudo que as suporta, algo completamente desnecessárias nesse tipo de cenário. 

Atualmente, para preparar uma maquina Windows Server precisamos de cerca de 32GB de espaço em disco, com sorte, o que torna praticamente inviável o uso do sistema em muitos cenários, levando à preferência por ambientes mais leves e modularizados, casos das inúmeras distribuições Linux que temos hoje dominando os ambientes de nuvem e containers.

No entanto, neste último dia 8 de Abril, a Microsoft anunciou o desenvolvimento do Windows Nano Server, uma versão reduzida do sistema operacional, contendo apenas aquilo que é de fato necessário para a execução de uma infraestrutura de nuvem, removendo totalmente sua interface gráfica e demais funcionalidades desnecessárias. Com isso o footprint do sistema caiu expressivos 93%, o que nos leva a crer que poderemos ter uma maquina Windows Nano Server, totalmente viável para a execução de sistemas de backend, com razoáveis 2,3GB de espaço em disco, talvez até menos.

Isso torna viável também o uso do Windows Nano Server com Vagrant e, segundo a Microsoft, até Docker, simplificando absurdamente a criação de ambientes de DevOps para softwares desenvolvidos para a plataforma .NET, principalmente considerando o desenvolvimento do novo .NET Core 5 e ASP.NET 5, também bastante reduzidos em tamanho e muito melhor modularizados, se comparados às versões atuais.

A partir do lançamento desse novo sistema, com pouco investimento, será possível a distribuição e gestão do ciclo de vida de serviços de backend executados sobre a plataforma .NET e Windows em ambientes como o IBM BlueMix, ou Amazon AWS, de forma tão prática quanto é feita hoje para sistemas Java executados sobre uma distribuição Linux.

Essa foi sem dúvida a melhor notícia dos últimos tempos para desenvolvedores .NET e administradores de infraestrutura Windows. Ansioso para ver tudo isso funcionando na prática. Que 2016 chegue logo.

Atualização: Na Build 2015, foi anunciado que o Nano Server tem uma imagem de cerca de 400MB, contra quase 5GB da versão Server Core, a menor disponível atualmente. Além disso, o sistema gasta cerca de 40 segundos para ser instalado, 15 segundos para ser inicializado e ocupa apenas 63MB de memória. Números realmente impressionantes, mesmo em comparação ao atual Server Core.

Vejam mais detalhes em:

• Novo: http://channel9.msdn.com/Events/Build/2015/2-755
• http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx
• http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx

Resista à tentação de criar seu próprio monstro.

Há algum tempo falei aqui sobre a sindrome do arquiteto astronauta, e retomo o tema hoje.

Caso você seja um arquiteto de software, ou tenha tendências a se tornar um, provavelmente está nesse momento implementando ou criando em sua mente algum SeiLaOQueFX, aquele framework que irá satisfazer a tara que todos nós temos por reuso, coesão, simplicidade. Simplicidade? Sim, ao menos é o que normalmente pensamos.

Com o SeiLaOQueFX você e os demais programadores da sua equipe não terão mais dificuldade em implementar um processo de negócio qualquer, poderão se abstrair dos requisitos não-funcionais e focar apenas no que interessa ao negócio. A produtividade da equipe será foda, ninguém mais precisará repetir código, reimplementar padrões, ter que conhecer tais padrões, pra começo de conversa.

Claro que o fato de todo mundo agora ter que conhecer o SeiLaOQueFX mais que qualquer coisa que já estudou ou usou na vida é um mero detalhe, e você está ali para resolver qualquer problema. O fato de você reescrever todas as rodas e engrenagens possíveis também é só outro detalhe. É necessário, afinal o que tem por ai para ser reutilizado é genérico demais e não é bom o suficiente para satisfazer nossa tara por reuso.

Mas aqui vai o que lhe espera, e não negue esta verdade, será pior pra você: Riscos, risco em toda parte. E alguém pagará a conta; se não for você, será sua equipe, ou seu empregador. Sua satisfação inicial em criar o tão sonhado SeiLaOQueFX dará lugar a um sentimento de frustração, de impotência, afinal o fracasso não será culpa sua. E neste ponto não estou sendo apenas irônico. Provavelmente não será mesmo. Mas contará com a sua conivência em todo caso.
Mas o que fazer para não cair nessa armadilha, e não ser um eterno frustrado por nunca ter dado vida ao SeiLaOQueFX?

Uma primeira alternativa é fazer isso fora do trabalho. Se é tão importante pra você, você encontrará tempo. Isso evita que você comprometa seu emprego, sua equipe e seu empregador com os vários riscos que um framework escrito do zero traz.
"Mas sem o SeiLaOQueFX meu trabalho será tedioso, repetitivo, ineficiente". Provavelmente, pois é justamente isso que nos leva a querer ser pai de uma criatura como esta. Mas há outra motivação, interna e quase sempre negada, para fazermos isso. A preguiça. Isso mesmo, preguiça. Palavra forte, mas é o que acontece. Desenvolver nosso próprio EntityFramework, nosso próprio ASP.NET MVC, nosso próprio WCF é sempre mais motivador que aprender a usar estes aí.

Mas é aí que os riscos entram em cena. Todos sabemos que nunca temos à nossa disposição o prazo que precisamos para fazer o trabalho como queremos. Além disso, nosso empregador está pouco se lixando para o SeiLaOQueFX; o que interessa pra ele, e ele está certo em pensar assim, é o produto que ele está lhe pagando para entregar aos clientes dele. Com um framework desenvolvido do zero, inúmeros problemas inerentes ao framework, e não ao software que o utiliza, precisarão ser resolvidos, e quando estes problemas surgirem, não adianta ir tentar explicar ao seu empregador que o SeiLaOQueFX é foda e precisa de mais tempo. Você não está sendo pago para desenvolver frameworks, está sendo pago para desenvolver produtos de software e o desenvolvimento do SeiLaOQueFX está por sua conta e risco. Resultado: Gambiarras. Gambiarras em toda parte. Como você não tem tempo para aplicar o seu brilhantismo e resolver os problemas do seu framework com dignidade, você o fará sem dignidade mesmo, e a culpa é do seu empregador, que não lhe deu tempo pra isso. Portanto, ele que se ferre com a perda de qualidade.

Nesse momento sua equipe estará entrando em colapso. Muitos não irão mais querer usar aquilo que você diz que eles tem que usar e alguns pularão do barco até; outros seguirão paralisados, com uma produtividade cada vez mais baixa. Por fim, tudo aquilo que você sonhou como produto do SeiLaOQueFX se manifestará com sinal invertido, e em um nada belo dia você brigará com todos, discutirá com seu empregador e seguirá seu rumo; irá para algum lugar onde seu brilhantismo seja reconhecido. E ai, ai ferrou pra quem herdou a criança. Sua reputação estará manchada e no fundo você saberá que enfiou os pés pelas mãos, embora dificilmente admita.

Portanto, resista à tentação de criar seu próprio monstro.

Obtendo sucesso com Arquitetura de Microserviços

Muito tem-se falado em Arquitetura de Microserviços recentemente. Resumidamente, trata-se de um estilo arquitetural em que a lógica da aplicação é dividida em pequenos (micro) serviços os quais podem ser escalados e distribuídos independentemente. Parece simples, mas na prática surgem inúmeras dúvidas sobre como interpretar cada um dos conceitos envolvidos e como implementar cada um deles.
Neste artigo darei algumas dicas baseadas na experiência positiva que tenho tido com a implementação desse estilo nos últimos tempos.

Primeiramente, não se trata de integração de aplicações. Microserviços não é SOA. É muito parecido, mas não tem o mesmo objetivo. Está mais para objetos distribuídos de um mesmo sistema do que para integração de diferentes sistemas, embora os mecanismos usados para a integração entres esses 'objetos' seja muito mais semelhante aos usados em SOA que aos usados em estratégias convencionais de objetos distribuídos, como CORBA, EJBs ou .NET Remoting.

Em segundo lugar, também não se trata de objetos distribuídos tradicionais. Não pense em criar seus objetos de modo que possam ser usados tanto localmente quando de modo distribuídos e deixar alguma infraestrutura de comunicação tomar conta da integração entre eles. Isso é lento e foi o que deu a fama negativa que as tecnologias citadas no paragrafo anterior tem no que se refere a performance.

Se não são aplicações distintas, nem objetos comuns de uma única aplicação sendo integrados, o que são portanto esses microserviços?

Quando iniciei minha experiência com esse estilo arquitetural, o termo Arquitetura de Microserviços ainda não me havia sido apresentado, portanto não precisei me preocupar em seguir uma definição ao pé da letra para poder dizer que era isso o que eu fazia. E isso vale para quem já conhece os termos. Padrões servem para nos apontar o caminho, não para serem seguidos como religiões. Mas voltando ao meu caso, só percebi que o que eu havia construído era aderente a esse estilo depois que já estava quase tudo pronto. Foi um processo bastante natural e como fui guiado pelos mesmo requisitos arquiteturais que levaram à definição do termo Arquitetura de Microserviços, minha implementação já nasceu naturalmente aderente a ele.

A resposta para a última pergunta, no meu caso, veio da metodologia conhecida como Domain-Driven Design (DDD). Embora possa parecer àqueles que a desconhecem que tal metodologia trate apenas de técnicas para organizar objetos de domínio, ela é muito mais que isso. DDD é por si só um estilo arquitetural, o qual define a estrutura de toda a aplicação, não apenas dos objetos de domínio.

Um dos conceitos mais importantes em DDD é o conceito de Serviço de Aplicação. Um Serviço de Aplicação tem a função de coordenar tarefas recebidas de um cliente externo, seja uma IHM ou outra aplicação/serviço, orquestrando a interação entre seus objetos e serviços de domínio, e por fim consolidando o resultado da operação solicitada. As operações executadas por um Serviço de Aplicação devem ter início e fim, sem depender de outros Serviços de Aplicação. E embora um serviço de aplicação possa realizar diferentes funções, cada uma delas deve ser muito bem definida, bem de acordo com o princípio da responsabilidade única, além é claro de estarem de algum modo bem relacionadas.

Dessa forma, uma vez que recebida uma solicitação e um conjunto de dados de entrada, um Serviço de Aplicação irá realizar a função solicitada por completo e produzir um resultado também completo. E isso é exatamente o que precisamos ter em um Microserviço para que ele não nos traga problemas. Na solução a qual me refiro neste artigo, cada função de um Serviço de Aplicação foi implementada como um Microserviço*. Sendo assim, um Serviço de Aplicação não era pra mim uma unidade computacional única, mas sim um agrupamento lógico de Microserviços intimamente relacionados**. Desse modo, cada Microserviço poderia residir em sua própria unidade computacional ou compartilhar uma mesma unidade computacional com demais microserviços que escalassem de maneira semelhante.

No caso de uma aplicação .NET, uma unidade computacional pode ser criada como um Windows Service, por exemplo, enquanto que um Serviço de Aplicação poderia ser composto por uma Class Library contendo os Microserviços que representam suas funções. Já em Java a unidade computacional poderia ser um WAR enquanto que o Serviço de Aplicação poderia ser um simples JAR, apenas para contextualizar.

Mas como seria feito o acesso a esses Microserviços? Para serviços consumidos diretamente por uma página WEB, uma API Web, no formato REST, seria uma boa escolha, no entanto a maior parte dos serviços de um sistema desenvolvido sobre uma Arquitetura de Microserviços só terão interação com outros serviços de backend. Imagine por exemplo uma função de cálculo extremamente complexa e composta por inúmeras etapas. Um primeiro serviço poderia receber a solicitação através de uma página web, via API Web, e então iniciar a primeira etapa do processo de cálculo. Ao concluir essa etapa, o Microserviço que a realizou publicaria o resultado e se colocaria novamente à disposição para o recebimento de outras solicitações. Nesse momento, um segundo Microserviço, responsável pela segunda etapa do cálculo, receberia o resultado publicado pelo primeiro Microserviço e executaria a segunda etapa usando o resultado do primeiro como insumo, por fim publicando o seu resultado para que possa ser usado por um eventual terceiro Microserviço, até que todo o processo de cálculo esteja concluído. Eventualmente a página WEB receberia uma resposta contendo o resultado do cálculo e notificaria o usuário.

Nesse momento chegamos a um ponto extremamente importante. A integração entre Microserviços é quase sempre assíncrona e desacoplada. Um Microserviço deve publicar seu resultado e esquecer dele. Alguém irá recuperá-lo em algum momento e fazer bom uso dele, mas o Microserviço não deve se preocupar com isso, ou aguardar um reconhecimento do Microserviço que porventura dará continuidade a seu trabalho. Microserviços são como aquele colega de trabalho que você um dia teve, que faz a sua parte do trabalho e diz um foda-se para o restante da equipe. E é isso que garante sua alta disponibilidade, sua robustez, e permite que ele seja facilmente substituído caso necessário.

Para alguns casos no entanto, como o caso do primeiro serviço desse nosso exemplo, que recebeu a solicitação da página WEB e deve devolver uma resposta a ela, pode ser necessário aguardar o término do processo por algum tempo, ou considerar que ele falhou. Ou pode-se também iniciar um outro serviço que terá como única função notificar a página WEB quando todo o processo tiver terminado, de modo que o primeiro serviço irá responder à página WEB de imediato, informando apenas que recebeu e encaminhou sua solicitação para que fosse processada. Em todo caso as características marcantes são a assincronia e o desacomplamento.

Okay, mas como realizar esse troca de mensagens entre esses malditos Microserviços? A resposta no meu caso foi o padrão publish-subscribe, implementado através de um Middleware de Mensageria, sobre o padrão AMQP.

Acredito que eu já tenha escrito demais por hoje. Se você chegou até aqui é porque se interessa pelo tema, e estou a disposição para falar mais sobre o assunto. Deixe suas dúvidas ou sugestões no campo de comentários abaixo que procurarei responder, diretamente ou em forma de um novo artigo.

* Atenção ao fato de que me refiro a funções dos Serviços de Aplicação, as quais possuem uma granularidade bastante grande. Modelar funções de Objetos ou Serviços de Domínio como Microserviços seria voltar aos tempos dos objetos distribuídos, e voltar a ter os problemas de desempenho característicos destes.

** E antes de dizer que não é isso que dizem os livros do Evans ou do Vernon, lembrem-se que padrões são guias, não religiões.

Artigos Recomendados:
https://rclayton.silvrback.com/failing-at-microservices
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

Módulos de Negócio vs Módulos de Infraestrutura

Módulos de Negócio versus Módulos de Infraestrutura. Essa é uma das discussões que me deixam mais empolgados quando o assunto é Arquitetura de Software. Mas antes de mais nada, uma breve revisão sobre o que são Módulos.

Um Módulo de Software pode ser visto como uma peça de software que implementa uma determinada especificação e realiza um determinado trabalho conforme especificado. Tais módulos podem ser compostos por um arquivo, uma classe, uma DLL, ou até mesmo um conjunto de DLLs, dentre outras possibilidades, desde que em conjunto esses artefatos implementem uma dada especificação e realizem um determinado trabalho conforme especificado.

Sempre que falamos em Módulos de Software, é comum alguém fazer a comparação com Módulos de Hardware, e gosto bastante dessa comparação. Um módulo de hardware, um componente eletrônico normalmente, pode ser facilmente substituído por um outro semelhante, desde que este outro implemente as mesmas especificações. Os demais módulos que interagem com aquele que for substituído se quer perceberão a mudança. E este seria o Santo Graal da modularização de software, poder simplesmente remover um módulo e substituí-lo por outro que implemente a mesma especificação, sem que os demais módulos reclamem da mudança.

Infelizmente isso ainda é uma realidade pouco comum. Arrisco dizer que a grande maioria das aplicações desenvolvidas no país, ainda que considerando apenas a pequena amostra a que tive acesso, são mal modularizadas e acabam mantendo um alto acoplamento entre seus módulos. E isso prejudica não apenas a possibilidade de fazer substituições de uma implementação por outra, algo que apesar de muito bonito não é tão necessário assim, mas também a definição das fronteiras do escopo de cada módulo, e é ai que está o grande prejuizo em modularizar mal uma aplicação.

De volta ao tema desta postagem, vamos supor que estamos trabalhando no desenvolvimento de um sistema em que há uma boa modularização, em que o papel de cada módulo está bem definido, o acoplamento está baixo e as fronteiras entre os módulos muito bem definidas.

Se tivermos essa realidade, será fácil identificar a separação entre Módulos de Negócio, aqueles que implementam exclusivamente funcionalidades específicas do negócio que está sendo automatizado pelo software, e Módulos de Infraestrutura, que implementam funcionalidades de suporte, drivers de acesso a bancos de dados ou sistemas de mensageria, ferramentas de log e auditoria, gerenciamento de usuários e tantas outras que estarão presentes, sem muita variação, em praticamente toda aplicação que viermos a desenvolver.

Módulos de Infraestrutura são componentes genéricos, reutilizáveis, que podem ter seu desenvolvimento e manutenção totalmente desacoplado dos sistemas que os utilizam. E ai está a grande vantagem em sermos capazes de fazer essa distinção. Quando baixamos um módulo como o Json.NET ou o FluentAssertions através do NuGet, recebemos uma peça de software pronta que apenas consumiremos. Por que não pode ser assim com os Módulos de Infraestrutura desenvolvidos pela própria equipe que consome esses módulos desenvolvidos por terceiros?

Pense que há na empresa em que você trabalha, e não há porque não haver caso você desenvolva aplicações .NET, um repositório NuGet privado, assim como uma política de Gestão de Reuso que defina que todo Módulo de Infraestrutura deva ser desenvolvido de modo independente das aplicações que os consomem, e que devam ser disponibilizados neste repositório uma vez que atinjam uma versão estável. Isso permitirá que esses módulos sejam utilizados pelas equipes de desenvolvimento da empresa, incluíndo as equipes que os desenvolveram, pois estas também deverão consumí-lo através do repositório NuGet, e não através de referências diretas a projetos da mesma solução.

Num cenário como este, teriamos uma solução limpa, composta apenas por Módulos de Negócio se referenciando entre si e consumindo, via NuGet, os Módulos de Infraestrutura que precisam.

Pensem nas possibilidades que um cenário como esse lhe proporcionaria. Pense em possibilidades como abrir alguns desses módulos como projetos Open Source, ganhando a contribuição de desenvolvedores de todo o mundo. Ou a vantagem de poder vender a seus clientes apenas o que realmente precisa e deve ser entregue exclusivamente a esses clientes: seus Módulos de Negócio. Afinal, se você pode consumir componentes de terceiros não relacionados ao negócio do seu cliente sem ter que fornecer a ele a propriedade sobre o código desses componentes, por que não poderia fazer o mesmo com o código dos Módulos de Infraestrutura que você mesmo desenvolve?

Por hoje era isso! Deixem suas opiniões nos comentários.

Arquitetura de Microserviços e DDD

DDD já é velho conhecido de muitos desenvolvedores de software já há mais de 10 anos, no entanto o termo Microservices Architecture tem ganhado popularidade apenas recentemente.

Venho trabalhando em uma arquitetura de micro serviços, desenvolvida sobre o .NET Framework, já há quase 1 ano, desde antes da popularização do termo e até mesmo antes da publicação do Manifesto Reativo. No entanto, essa arquitetura tem se mantido desde o início bem aderente a esses dois conceitos.

Chamada aqui de Plataforma ST (nome real omitido), trata-se de uma arquitetura que permite que pequenos serviços de aplicação coexistam e se comuniquem entre si, de modo seguro, escalável e permitindo que novos serviços possam ser incluídos na plataforma a qualquer momento, complementando as funcionalidades já existentes. Note que não se trata de um único produto composto por múltiplos serviços relacionados, mas sim de uma plataforma de agregação de serviços. É possível haver uma instância da Plataforma ST agregando serviços de CRM, outra agregando serviços de ERP e outra para serviços de POS, cada uma dessas compondo um sistema distinto. Ainda assim, para cada uma delas, existe a possibilidade de se agregar novos serviços, incluindo alguns que sejam responsáveis exclusivamente pela interação entre esses diferentes sistemas.

Segundo as recomendações do DDD, módulos de um sistema, no nosso caso assemblies ou namespaces .NET, não devem conter no seu nome um nome de produto, mas sim a funcionalidade que ele provê, assim como devem conter como prefixo o nome da empresa que os desenvolveu. Assim, um módulo de gerenciamento de projetos ágeis desenvolvido pela empresa Contoso deveria ser nomeado com.contoso.agileprojectmanagement.applicationservice, de acordo com o que fora apresentado por Vaughn Vernon em Implementing Domain-Driven Design. No entanto, o padrão com.nomedaempresa se limita ao mundo Java, linguagem usada pelo autor para ilustrar o livro. Em projetos .NET, não há o costume de acrescentar o nome da empresa nos nomes dos módulos, e muito menos o prefixo com.

Ainda assim, poderíamos adaptar essa terminologia e nomear um dos nossos módulos de Contoso.AgileProjectManagement.ApplicationService, no entanto optei por usar ST.AgileProjectManagement.ApplicationService, e posso justificar essa decisão.

A Plataforma ST requer que os serviços desenvolvidos para executar sobre ela sigam um determinado padrão. Há uma classe abstrata ou no minimo uma interface que precisa ser implementada por todos os serviços, além disso eles precisam ser desenvolvidos levando em consideração o modo como a Plataforma ST irá gerir seu ciclo de vida. E mais, a Plataforma ST não é uma bala de prata, obviamente. Há cenários em que o mais interessante seja usar uma outra plataforma, ou desenvolver o sistema diretamente sobre o .NET Framework, já descartando os casos em que o próprio .NET Framework não seja a melhor opção.

Imagine por exemplo que seja desenvolvido na mesma empresa um sistema de colaboração, uma espécie de Wiki, que se adere aos padrões DDD mas não se encaixa na Plataforma ST. Esse sistema será desenvolvido de modo completamente independente dela, seus módulos serão totalmente incompatíveis. Agora seguindo a recomendação de usar o nome da empresa para determinar o nome dos módulos, teríamos algo como Contoso.Collaboration.ApplicationService, algo muito semelhante aos módulos dos sistemas desenvolvidos sobre a Plataforma ST, mas sem relação alguma com ela.

Por que não usar então Contoso.ST.AgileProjectManagement.ApplicationService? Ai vem um ponto em que discordo da recomendação do Vernon. Usar o nome da empresa, de qualquer modo que seja, na nomenclatura dos módulos, pode ser ruim e prefiro usar em seu lugar não o nome comercial de um serviço, o que concordo não ser recomendável, mas manter o módulo nomeado conforme sua função e prefixá-lo com um nome de projeto ao invés do nome da empresa. Seria algo que identifica todos os módulos que possuem algo em comum e cumpre a mesma função do nome da empresa na recomendação do livro.

Mas por que isso? Já trabalhei em uma empresa que mudou de nome, e via produtos legados com o nome antigo por todos os lados. Há casos de fusões e aquisições, em que o nome do proprietário do produto muda, e mesmo havendo motivações para manter o nome do desenvolvedor original mesmo que ele não exista mais, há o risco de novos módulos que integrem a mesma aplicação passarem a ser nomeados conforme o novo nome da empresa, o que geraria uma combinação de nomes de módulos não muito interessante.

Enfim, era isso que gostaria de compartilhar aqui e gostaria de ouvir a opinião de quem trabalha com DDD e já teve que passar por situações semelhantes às que descrevi. O que vocês tem a dizer?

Arquitetos de Software na Era da Agilidade

Atualmente tenho trabalhado como arquiteto de software e também como ScrumMaster em um time Scrum. Estamos desenvolvendo um projeto bastante complexo, onde temos na mesma equipe desenvolvedores de software, engenheiros, desenvolvedores de firmware e até mesmo desenvolvedores de hardware. Trata-se de uma única equipe de mais de 10 pessoas, e quem já tem experiência no assunto já pode imaginar que não deve ser nada fácil tocar um projeto como esse, principalmente se acrescentar que esta é a primeira experiência com Scrum para a maioria dos integrantes da equipe, e também meu primeiro projeto como ScrumMaster.

Estou escrevendo isso porque hoje tive contato com um artigo, escrito por Stravos Kontopoulos, que trás não apenas uma excelente definição das responsabilidades de um arquiteto de software como também destaca os principais desafios de um arquiteto de software em um projeto ágil. Achei fascinante, pois a realidade que vivo hoje é muito bem descrita por ele.

Segundo Stravos,

Arquitetos de software, para serem bem sucedidos, devem possuir diferentes habilidades: habilidades técnicas, habilidades gerenciais, habilidades de liderança.
A razão por trás disso é que eles são a interface para muitos grupos dentro da organização: desenvolvedores, interessados do negócio, engenheiros de operação, testadores, marketing, conselhos, etc. 

Habilidades técnicas são uma necessidade para uma arquitetura válida, servindo os propósitos do negócio de acordo com as necessidades atuais e futuras. Além disso, habilidades técnicas destacadas garantem que a tecnologia está sendo aplicada da maneira correta.

Um conjunto de habilidades gerenciais é essencial. Entregar um produto/projeto dentro do tempo/orçamento é de grande importância e um arquiteto de software é normalmente assistido por um gerente de projetos responsável por essa tarefa. O aspecto chave aqui é que o arquiteto de software sabe melhor como priorizar o trabalho, sabe melhor determinar riscos para o cumprimento dos requisitos do projeto/produto de acordo com sua perícia em software. A atual execução do gerenciamento pode ficar por conta do gerente de projetos, que também monitora os recursos/riscos em maior detalhe.

Acima de tudo, todo arquiteto de software deve ser um construtor de equipes. Frequentemente essa não é uma tarefa fácil. Pegar as pessoas certas, que frequentemente não são de sua escolha, manter o equilíbrio dentro do time, gerenciar as expectativas e a produtividade das pessoas, e eventualmente liderar o time é de vital importância. É como conduzir uma orquestra. Se você não fizer isso direito, o resultado será ruim, mesmo que tenha os melhores músicos.

Posso dizer que essa foi a melhor descrição para a função de um arquiteto de software que já encontrei. Reflete exatamente os desafios que encontramos no dia a dia, e as responsabilidades que temos que assumir. Quem pensa que ser um arquiteto de software é sentar a bunda na frente do Enterprise Architect e passar o dia desenhando diagramas (coisa que, como arquiteto ágil, raramente faço), está muito enganado.

Na sequência, Stravos fala sobre o papel do arquiteto de software em uma equipe ágil:

Na era da agilidade, em que não há tal coisa como uma arquitetura estável pré-definida, desenvolvedores devem trabalhar próximos ao arquiteto de software, monitorando a evolução da arquitetura.
Isso quer dizer que desenvolvedores também devem ter alguma habilidade com projeto arquitetural, de modo a fazer parte da evolução da arquitetura, sendo capazes de compreendê-la efetivamente. Um arquiteto de software não é capaz de estar ciente de todos os detalhes de um produto de software, mas deve estar ciente de cada decisão ou restrição que possa fazer a arquitetura se tornar inconsistente ou se desviar de sua tendência inicial.
O arquiteto de software, por sua vez, deve estar próximo de seu time, auxiliando-o durante as iterações de desenvolvimento, e por isso deve estar acostumado à codificação e codificar até um certo nível.

Muito frequentemente, um trabalho negligenciado é a documentação das arquiteturas. Isso pode ser parte de uma tarefa ágil em que a documentação é refatorada a cada iteração que também modifique a arquitetura.
Esta é a única maneira de se saber quais caminhos arquiteturais você está seguindo e ser capaz de apresentar aos interessados que você de fato sabe, e que eles possam ver através de seus olhos, o que você está construindo.

Confira o artigo completo neste link.

Conclusão do Curso de Especialista em Estratégias em Arquitetura de Software

Desenvolvo software desde 1998, profissionalmente desde 2002, mas apenas em 2008 identifiquei a área de Arquitetura de Software como aquela que mais me desperta interesse. Naquela época, ainda era uma área bastante marginalizada, ainda sendo um pouco ainda hoje. Afinal, quantas empresas possuem o cargo Arquiteto de Software? Quantas se quer sabem o que seria um Arquiteto de Software? Infelizmente ainda não parecem ser a maioria. Por conta disso, ainda é baixa a oferta de cursos de qualificação específica na área.

Ainda em 2008, soube da criação em Belo Horizonte do IGTI, uma instituição que passava a oferecer o primeiro curso de Estratégias em Arquitetura de Software do país, sendo uma das poucas a oferecer tal curso ainda hoje. Me interessei bastante, mas por inúmeros motivos não me matriculei. Até que, em 2012 soube que o mesmo curso passou a ser oferecido na modalidade de Ensino à Distância e com isso seria bem mais fácil conseguir o tempo necessário para me dedicar às aulas. Não havia mais desculpas. Fiz o curso e gostei bastante. Aprendi muito, ratifiquei boa parte do conhecimento que adquiri na prática ao longo dos anos, fiz bons contatos profissionais e bons amigos.

Desde os primeiros meses de curso, já falávamos a respeito do trabalho de conclusão, e aproveitei a oportunidade para estudar mais a fundo dois temas que muito me agradam, e que visivelmente contribuem para a melhoria da qualidade do meu trabalho e para o aumento de minha produtividade, que são as já bem conhecidas Boas Práticas para Desenvolvimento de Software e as nem tão conhecidas Especificações por Exemplo.

Desde meu primeiro contato com Especificação por Exemplo, então conhecidas por mim apenas como Behavior-Driven Development, já notei o quanto a técnica tornava mais simples a definição do que deve ser feito e como o trabalho deve ser divido, implementado e testado. Tendo uma boa técnica para verificar continuamente a qualidade do trabalho, fica bem mais fácil refatorar continuamente o código e aplicar continuamente as tão famosas Boas Práticas.

O resultado desse trabalho está disponível neste link. Confiram.

A sindrome do arquiteto astronauta

Desde que iniciei minhas aventuras com programação, na época que não fazia mais que encontrar novos meios de se usar a função SE no Excel 5, sempre gostei de pensar, inventar, descobrir e usar coisas novas. Cada novidade que eu podia experimentar, que podia tornar o código que eu escrevia mais agradável, me trazia satisfação. Não me bastava saber como criar uma tela de cadastro, isso já no Delphi, eu queria sempre buscar uma nova maneira, mais eficiente, de fazer isso, e ainda hoje tenho esse impeto pela inovação e pela maior eficiência. Arquitetura de Software sempre foi a minha praia dentre as várias que um desenvolvedor de software pode escolher. E claro, quem experimenta coisas novas erra muito mais que acerta. É necessário muita experimentação até se conseguir maturidade para identificar as chances de sucesso do próximo experimento, portanto coleciono muitas decisões equivocadas, das quais me orgulho pois cada uma delas contribuiu para os acertos seguintes.

Em meados de 2008, num período em que eu já me considerava capaz de criar soluções mais elaboradas, e já estudava com mais profundidade temas como padrões de projeto e boas práticas de desenvolvimento, me lembro estar construindo uma solução que, obviamente, tendia à perfeição. No entanto cada uma das imperfeições ainda existentes me incomoda absurdamente e cada dia eu gastava mais tempo tentando me livrar delas. Foi nesse período que alguém me disse: "você está sofrendo da síndrome do arquiteto astronauta, não deixe a busca pela perfeição te impedir de fazer um bom trabalho". Minha primeira reação foi pensar que aquilo simplesmente não fazia sentido, seja lá o que fosse a tal síndrome, já que buscando a perfeição, obviamente eu acabaria fazendo um bom trabalho. No entanto, na mesma época eu também passava por um processo de amadurecimento profissional forçado em que decidi aceitar toda crítica recebida independente de concordar ou não, buscando tirar algo positivo dela. Era mesmo possível que eu estivesse buscando algo desnecessário, ao menos para aquele contexto?

O arquiteto astronauta é aquele que vive no mundo da lua, fora da realidade, buscando soluções de outro mundo, vidrado demais em padrões e mais padrões, buscando sempre a solução mais perfeita possível sob o ponto de vista técnico. Para ele, se a solução pode ser melhorada, ela deve ser melhorada, e deve ser melhorada de imediato. Se uma tecnologia nova e interessante surge, ele vai querer usá-la, ainda que não tenha real necessidade. Se um novo padrão está bombando e se propõe a resolver o problema que ele enfrenta, ele irá querer usar tal padrão a qualquer custo. Assim cada vez mais novas tecnologias e padrões vão sendo agregadas a suas soluções, e dai começam a surgir as evidências de que sua super complexa, moderna e foda arquitetura, não é tão perfeita assim.

"Simples é melhor". "Mantenha isso simples, estúpido". "Você não vai precisar disso". São princípios listados entre as boas praticas que um bom arquiteto deve ter a obrigação de seguir, mas que normalmente são ignoradas pelo arquiteto astronauta. Hoje sei bem disso. Caso as ignore, suas soluções acabarão lotadas de tecnologias e padrões que tornarão seu código mais complicado de ser compreendido e modificado, a execução do software ficará mais lenta, dadas as camadas e mais camadas de abstração e linhas de execução, você mesmo ficará sobrecarregado em ter que gerenciar aquilo tudo.

Pra encerrar a história: Tenha sempre em mente a sua necessidade atual. Necessidades futuras mudarão, e suas soluções previamente implementadas podem se quer vir a atendê-las, quanto menos da melhor forma. "Você não vai precisar disso". Mantenha as suas soluções simples. Evite abstrações demais, que não se justifiquem na prática. E quanto aos princípios SOLID, lembre-se que eles existem para lhe orientar no processo de refatoração e melhoria de código, não no processo de construção. Evite otimizações antecipadas, antes de ter uma versão menos otimizada do código já funcionando, ou ainda, antes de identificar que tais otimizações são realmente necessárias. E o principal, evite criar situações apenas para lhe permitir usar um determinado padrão ou tecnologia. Não é por que programação distribuída lhe oferece diversas vantagens em diversos cenários que você deve executar cada procedimento em uma thread separada. Não é por que MongoDB é legal que você deve descartar o bom e velho Oracle sem pensar duas vezes.

Windows Azure e Nuvens Privadas

Não represento de nenhuma maneira a Microsoft, mas gostaria de falar um pouco aqui sobre Windows Azure e Nuvens Privadas.

As vezes quando converso com colegas sobre Windows Azure, ouço os clássicos questionamentos: Nuvem não é segura. Trabalhamos para governo, não podemos colocar software em servidores de uma empresa estadunidense. Para quê vou aprender algo que quase ninguém quer usar e só funciona na nuvem?

O fato é que aplicações implantadas em nuvem podem trazer vantagens que não podem ser ignoradas apenas com base em questionamentos como esses. A plataforma Windows Azure por exemplo tem crescido a cada dia, e cada vez novos recursos são acrescentados. Para um desenvolvedor, ou empresa, que tem o .NET Framework como sua principal plataforma de desenvolvimento, abdicar dessas vantagens pode significar abrir mão de uma grande vantagem competitiva.

Mas e os questionamentos acima? Como ter as vantagens da computação em nuvem sem ter que hospedar as aplicações num ambiente público e controlado por empresas de fora do país?

A alternativa são as nuvens privadas. No caso das plataformas Microsoft, ambientes baseados em Windows System Center 2012 ou Windows Server 2012, bastante semelhantes ao Windows Azure e que tem o modelo de desenvolver de aplicações bastante semelhante, se não idêntico, em muitos casos.

Na próxima vez que estiver considerando alternativas para aplicações robustas e escaláveis em plataforma Microsoft, não deixe de considerar essa opção.

E como desenvolvedor, não ignore o Windows Azure apenas por que a empresa onde trabalha se mostra resistente a ele. Conheça seus benefícios, as alternativas, e quem sabe até os convença a investir na plataforma.

Mais informações: http://msdn.microsoft.com/en-us/library/windowsazure/jj136831.aspx

Engenheiro de Software ou Arquiteto de Software?

Há alguns dias me perguntaram a diferença entre um Arquiteto de Software e um Engenheiro de Software.

Após uma definição do papel de cada um, para quem é do ramo, pode até não ser difícil entender, mas para quem não é, pode parecer que são apenas duas formas de descrever a mesma função.

À época pedi um tempo para pensar numa forma simples de explicar, e minha resposta veio através de uma analogia com um jogo bem conhecido, um quebra-cabeças, daqueles de encaixar peças para formar uma imagem.

Nessa analogia dizemos que o Engenheiro de Software é aquele que desenha a imagem a ser montada, o que será visto quando o jogo for concluído, enquanto o Arquiteto de Software é aquele que divide a imagem em peças pequenas e encaixáveis, que juntas formam a imagem desejada.

Um Engenheiro de Software tem como objetivo transformar um conjunto de processos de negócio em software; modelar o domínio do negócio de modo que um software possa ser produzido.

Já o Arquiteto de Software tem como objetivo organizar os artefatos modelados pelo Engenheiro de Software de modo a conseguir o melhor encaixe possível entre eles, dados os objetivos do negócio.

E ai? Será que consegui explicar? Ou complicar ainda mais? rs