Infra e Dev : A união faz a força

Era uma vez, uma época em que os desenvolvedores conseguiam fazer seus trabalhos sozinhos. O malvado usuário fazia uma solicitação, o desenvolvedor ficava dias desenvolvendo o código para atender a solicitação do usuário até que entregava o produto (e o resultado vocês conhecem).

O malvado usuário, por sua vez, mantinha um grupo de escravos chamados de operadores de micro que solucionavam problemas rotineiros nos computadores do usuário, mantendo tudo funcionando.

As empresas dos usuários foram crescendo e suas necessidades se tornando cada vez mais complexas. O usuário começou a fazer pedidos a seus escravos que estes diziam "Só chamando o desenvolvedor".

Por sua vez o usuário também começou a fazer pedidos ao desenvolvedor que este dizia "Isso não dá para fazer!"

A tecnologia foi evoluindo, as empresas evoluindo, e o usuário... bem, é o usuário. Mas aos trancos e barrancos chegamos aonde estamos hoje e a questão é : Os desenvolvedores não são mais capazes de fazer seus softwares no estilo "eu sozinho", pois hoje dependem de conhecimentos que são característicos dos profissionais de TI.

Estes, por sua vez, precisam entender o ambiente de desenvolvimento para poderem gerenciar adequadamente as aplicações criadas pelos desenvolvedores.

Abaixo vou citar vários exemplos de como TI e desenvolvimento devem andar de forma casada e como este casamento tem tendência a aumentar cada vez mais, mostrando assim que já é hora de vocês (TI e Dev) sairem para tomar um choppinho e ver se rola um clima.

(Aos Trolls de plantão : Os exemplos são de tecnologia Microsoft pois trata-se da tecnologia com a qual trabalho, mas o objetivo do artigo é destacar a questão profissional da união e trabalho em conjunto entre TI e Dev. Caso queiram escrever exemplos citando outras tecnologias, sintam-se a vontade)

Distribuição de Aplicações

Instalar as aplicações produzidas nas máquinas dos usuários talvez seja um dos pontos que menos exige do casamento entre os dois, desenvolvedor e TI. O desenvolvedor cria a aplicação. O profissional de TI empacota a aplicação, interliga a aplicação com os grupos de usuários adequados (via GPO) e pronto, a distribuição é feita via Windows Installer, recurso que surgiu junto com o Windows 2000.

O Framework .NET trouxe a possibilidade de distribuição parcial sobre demanda (clickOnce), ou seja, determinado recurso da aplicação apenas seria instalado quando o usuário iniciasse sua utilização. Antes utilizava-se o UAB mas era muito complexo.

A segurança então se tornou o ponto de ligação entre o desenvolvedor e o administrador de TI. O .NET utiliza um recurso de segurança chamado Code Access Security que evita que uma aplicação .NET distribuida via rede se aproveite da máquina do usuário.

O Code Access Security, porém, exige que o administrador de TI comece a entender o funcionamento da segurança em desenvolvimento, para poder desenhar corretamente o CAS e fazer a configuração das máquinas a partir do servidor da rede (servidor de domínio).

Já o desenvolvedor começa a precisar entender conceitos básicos de segurança e os perfis de aplicação utilizados pelo Internet Explorer e que se tornaram também o padrão inicial do CAS.

Serviços de Servidor

Uma pergunta que ficou clássica em fóruns técnicos é "Como faço para minha aplicação rodar sem nenhum usuário logado ?"

Nesse ponto o desenvolvedor já estava sendo desafiado a criar aplicações para rodarem no servidor, onde normalmente ninguém fica logado. O desenvolvedor passa a precisar entender o conceito de um serviço rodando no servidor. O fato de que o serviço possui uma identidade sem permissão de administração do servidor e por isso precisa de permissões no Registry e no sistema de Arquivos (as famosas ACLs), entre muitas outras questões. É o desenvolvedor aprendendo TI.

Instrumentação é outro fato a parte, de tão importante. Trata-se da adição na aplicação da capacidade de ser facilmente gerenciada, notificando o administrador de TI sobre o que está acontecendo com ela. Event Viewer, Performance Counters e WMI são apenas o começo para isso.

É justamente na instrumentação que entra o trabalho do profissional de TI. Não basta para ele deixar a aplicação rodando lá e pronto. A aplicação é mais uma peça do cenário de TI e o profissional precisa aprender suas respostas para poder acompanhar o dia-a-dia da aplicação.

Analisar o Event viewer, system monitor e fazer a integração via WMI com aplicações de análise mais complexas quando necessário são algumas das tarefas que o profissional de TI terá.

Aplicações Web

As coisas começam a complicar neste ponto.

O desenvolvedor passa a precisar entender o impacto que os protocolos da web tem sobre sua aplicação. O desenvolvimento de uma aplicação web é drásticamente diferente do desenvolvimento de uma aplicação Windows e para entender estas diferenças o desenvolvedor começa a ter que estudar características da rede e do servidor.

O desenvolvedor precisará entender itens como : Precisa entender o impacto de trabalhar sem uma conexão constante com o servidor Precisa entender o impacto do scriptTimeout Precisa entender o impacto do Buffer Precisa entender o impacto dos headers de protocolo Precisa entender o impacto da sessão Precisa entender o impacto da comunicação sobre o tratamento de erro (isso está bem resumido) Veja mais detalhes no artigo sobre HTTP

Já o profissional de TI precisará entender o impacto que cada configuração do servidor terá sobre as aplicações em seu servidor, para poder orientar o desenvolvedor, administrar corretamente o servidor, controlar a segurança, entre outras coisas.

Veja alguns dos conhecimentos que o profissional de TI precisará ter : Precisa entender o impacto de tudo acima sobre os sistemas desenvolvidos para poder configurar corretamente o servidor Precisa entender como a aplicação acessa o banco para poder configurar a identidade integrada de acesso a banco Precisa entender como o servidor e os handlers lidam com extensões de arquivo para não fazer besteira Precisa entender os direitos de escrita e seus impactos de segurança devido ao trabalho realizado pela aplicação (mais uma vez, um resumo)

Sem dúvida as aplicações web foram o ponto onde o desenvolvedor e o profissional de TI começaram a se mesclar e surgiu a figura do arquiteto, que conhece ambas as áreas.

Aplicações Web em Load Balance

Quando uma aplicação web cresce muito, começa a ser necessário expandir o hardware para dar suporte a aplicação. Essa expansão as vezes acontece na forma de aquisição de novos servidores. Então passamos a ter vários servidores atuando como se fossem um servidor só, sendo que existem várias técnicas de gerenciamento de rede que permitem que isso ocorra.

Quer seja load balance ou DNS round robin ou outra técnica qualquer, o impacto disso sobre o funcionamento de uma aplicação é considerável.

Para o desenvolvedor :

Precisa entender que este impacto existe, estar ciente do ambiente em que a aplicação irá rodar e programar de acordo

Para o profissional de TI :

Não pode esperar que ao fazer um round robin ou load balance sem afinidade a aplicação vá funcionar da mesma forma que antes.

 

No ASP.NET, tal ambiente tem os seguintes impactos : A validationKey precisa ser definida explicitamente para a manutenção do ViewState A decryptionKey precisa ser definida explicitamente para a manutenção da autenticação A sessão precisa ser guardada em banco de dados a parte

 
Se por um lado isso pode aparentar estar gerando um excesso de trabalho de TI, na verdade se tudo isso fosse controlado em desenvolvimento o tempo de produção das aplicações seria muito maior

Internet Information Server 7.0

O novo IIS 7 é como a consagração do sucesso do IIS 6. Para quem não sabe, em toda sua vida, desde o ano de 2003, o IIS 6 teve apenas 2 falhas classificadas como importantes e nenhuma classificada como crítica e por isso provou ser um servidor web altamente estável, escalável e confiável.

O IIS 7 consolida o funcionamento interno do servidor web, unindo funcionalidades implementadas no servidor web com funcionalidades do framework .NET, melhorando ainda mais a forma de funcionamento do servidor.

A primeira coisa que será observada é que configurações que antes eram "controladas pelo desenvolvedor" (entre aspas mesmo, porque muitas não deveriam), passaram a constar explicitamente na interface de configuração do IIS, ficando claro que precisam ser, no mínimo, de conhecimento do profissional de TI que gerencia o servidor web (suporte : aprendei a desenvolver).

Por outro lado, para manter o ambiente versátil, o IIS criou o mecanismo de delegação (que na verdade é baseado internamente no mecanismo de delegação de configurações já existente no Framework .NET).

O mecanismo de delegação permite que o profissional de TI delegue ao desenvolvedor algumas configurações do servidor, quaisquer configurações a sua escolha. O desenvolvedor pode utilizar uma ferramenta para se conectar ao IIS e irá visualizar apenas o nível do servidor que lhe foi delegado, tendo permissão de alterar apenas as configurações que lhe foram delegadas naquele nível.

Assim sendo, na hora do chopps entre o pessoal de dev e TI, não deixem de conversar sobre o que será delegado, antes que acabem delegando coisas demais ou de menos.

Aplicações Distribuidas

No final de 2006 (isso mesmo, crianças, há um ano), a Microsoft fez algo que há muito estava devendo : Uniu suas tecnologias de distribuição de dados em uma única (Gostam de sopa de letrinhas ? ASMX, WS*, WSE, COM+, MSMQ, Remoting = WCF).

O resultado ficou realmente muito bom, muitos acham até que é magia o fato de tarefas que antes eram feitas em mais de 50.000 linhas de código hoje serem feitas com 3 ou 4 linhas.

Com isso, tarefas que já deveriam ser do profissional de TI há muito tempo, tal como escolha de protocolos de comunicação, criptografia, compactação, autenticação, entre outros, finalmente podem passar para as mãos deste, pois não ficam mais agregadas ao código da aplicação.

É fato que ainda estamos no meio termo : O IIS 7 não possui ferramentas de configuração para serviços WCF (mas uma extensão poderia ser criada, porém ai já é trabalho do desenvolvedor), por isso muitos profissionais de TI ignoram a existência do WCF e acabarão por tentar afirmar ser de responsabilidade do desenvolvedor. É a briga na hora de pagar a conta do chopp, conta cara, alias, porque a enorme simplicidade trazida pelo WCF tem consequencias : uma simples mudança de configuração de true para false ou vice-versa consegue mudar todo o protocolo de comunicação utilizado por uma aplicação, então fica muito fácil fazer m... f... a p... toda causar sérios prejuizos para a empresa.

Active Directory & CIA

O sistema operacional foi produzido de forma muito extensível e pode-se tirar muitas vantagens disso. Por exemplo, quantas pessoas será que sabem que o Active Directory permite a personalização seu conjunto de dados para poder guardar informações personalizadas sobre cada usuário da rede, tal como informações do departamento de RH ? Provavelmente apenas um pouco mais de pessoas do que as que sabem que o sistema de busca do Windows Vista é extensível a ponto de você poder programa-lo para reconhecer a digitação do nome de um cliente no menu iniciar, procura-lo em sua base de dados e abrir sua aplicação com seu cliente na tela.

A integração necessária entre desenvolvimento e infraestrutura para soluções deste tipo é sem dúvida muito grande.

PowerShell

O Windows Server 2008 traz este novo recurso, chamado PowerShell. O PowerShell é um recurso de gerenciamento programável do sistema operacional. Algo como um ambiente de scripts, porém o PowerShell foi interligado ao .NET Framework, portanto a programação utilizada para o gerenciamento do sistema operacional envolve a manipulação de objetos.

Acrescente a isso o fato de termos agora uma edição Server Core, sem interface gráfica, totalmente controlada via prompt, e temos profissionais de TI aprendendo desenvolvimento para gerenciar seus servidores.

Edit : Dia 13/12 haverá uma apresentação do Windows Server 2008 no Rio, vejam em https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=PT-BR&EventID=1032361417 ou mais detalhes aqui

Conclusão

Tecnologicamente Infraestrutura e Desenvolvimento de software encontram-se cada vez mais integrados, exigindo cada vez mais um do outro para atingirem seus objetivos. Resta saber como os profissionais e o mercado de trabalho irá reagir a isso.