Sete mitos que cercam o mundo mainframe

Li esta matéria no dia de hoje e acredito que muitos dos leitores tenham dúvidas do que cerca o mundo dos mainframes, como programá-los, onde estão as oportunidades, quem os usa e etc.

Estou repassando o conteúdo pelo blog e espero que o texto responda as dúvidas, ou a maioria delas. Retirado do site IT Web.

Calcula-se que o Brasil seja o quarto maior parque de mainframes em operação no mundo. Depois de uma “morte anunciada” há algumas décadas, esses gigantes seguem firmes sustentando operações do governo e instituições financeiras nacionais. Além disso, institutos de pesquisa apontam que essas máquinas processam 70% dos dados mundiais e encontram-se em 90% das mil maiores empresas listadas no ranking da Fortune.

Na avaliação de Idival Junior, diretor de vendas para mainframe da CA para a América Latina a “quase morte” da tecnologia nos anos 80 decorreu, em grande parte, da estagnação vivida por esse ambiente. “Quase não havia concorrência e isso inibia a inovação”, avalia. O que obrigou a “ressurreição” da plataforma alta foi a entrada de um concorrente de peso: a arquitetura distribuída (cliente-servidor).

Com mais de quarenta anos de vida, o mundo mainframe coleciona mitos. A provedora de tecnologia CA – que tem 65% de suas receitas globais atreladas a essas máquinas e lançou uma estratégia global batizada de Mainframe 2.0 – listou sete dessas lendas e apontou argumentos para tenta destruí-las com fatos. Acompanhe:

1) Só roda aplicações legadas: Segundo a CA, 60% dos MIPS (Milhões de Instruções Por Segundo) comprados desde o ano 2000 destinaram-se a novas aplicações. “Isso mostra que novas aplicações são disponibilizadas para esse ambiente”, comenta Junior.

2) É uma relíquia do passado: O barateamento da tecnologia faz a fabricante acreditar que se mantém viva a capacidade de inovar dos fabricantes que atuam nesse mercado. Graças a isso, inovações surgem para deixar o mainframe longe de se tornar um sistema legado.

3) É caro: realmente, investimento inicial é alto. Em compensação, as máquinas são altamente confiáveis. Segundo o executivo da CA, a longevidade dos mainframes é de cerca de 30 anos, contra menos de 2 anos de vida útil estimado para computadores comuns. Ainda de acordo com o diretor, o preço unitário dos MIPS caiu dois terços em um período de nove anos.

4) Não roda bem em conjunto com ambiente distribuído: Ainda existem separações nos times que cuidam de plataforma baixa e alta. Mas a CA acredita que, a medida que as interfaces para ambientes de mainframes ficarem mais intuitiva, não haverá mais distinção de quem cuidará de plataforma baixa ou alta nas empresas.

5) Trata-se de um monopólio da IBM: De fato, a Big Blue detém grande fatia do mercado, mas existem outros ambientes (Unisys e Fujitsu). A fabricante de software ressalta que há toda uma gama de soluções periféricas e canais especializados nesse ambiente surgindo, o que impulsiona inovação na plataforma alta, além de manter preços adequados.

6) Só pode ser operado por pessoas mais velhas: Calcula-se que 70% dos profissionais brasileiros especializados nesse tipo de ambiente se aposentarão nos próximos dez anos. “Isso é um grande risco para as empresas”, avalia Junior, contrapondo com o fato de que os provedores de tecnologia estão respondendo a esse desafio provendo soluções mais intuitivas para as novas gerações.

7) É energeticamente ineficiente: De acordo com a CA, um mainframe da linha z10, da IBM, consome por volta de 85% menos energia para processamentos iguais realizados em plataforma baixa – levando em conta o consumo de energia para processamento e refrigeração do hardware. Além disso, a plataforma alta ocupa menos espaço nos data centers.

A norma Ginga-J

Um texto de referência para o entendimento do middleware Ginga, a ser usado no sistema de TV Digital. Texto escrito por Valdecir Becker, do IMasters.

Está em consulta pública na ABNT a norma Codificação de dados e especificações de transmissão para radiodifusão digital – Parte 4: Ginga-J – Ambiente para a execução de aplicações procedurais, que especifica o uso da linguagem Java para o desenvolvimento de aplicações para TV digital Interativa. Até o momento apenas a norma Ginga-NCL, discutida nos texto anteriores desta seção está oficializada, prevendo as linguagens NCL e Lua para o desenvolvimento das interatividades na TV digital brasileira.

A norma Ginga-J ficará em consulta pública até 17 de julho. Qualquer pessoa ou empresa pode se manifestar sobre a norma, aprovando-a integralmente, reprovando-a ou sugerindo alterações. Nos dois últimos casos é necessário anexar um documento com a justificativa ou as alterações sugeridas, respectivamente. Depois desse processo, a norma volta para o Fórum do SBTVD, responsável pela sua redação. O Fórum fará as análises dos votos, podendo aceitar ou não as alterações sugeridas. Depois disso, a norma é enviada para o Comitê Consultivo do governo federal, responsável pela homologação da mesma. Esse processo deverá levar cerca de 90 dias, talvez um pouco menos, dependendo das burocracias do Fórum e do governo. Dessa forma, é possível lançar oficialmente a interatividade antes do natal. As emissoras de TV estão apostando em um “natal interativo” para a TV digital.

O Ginga-J é composto por um conjunto de API (Application Programming Interface,  Interfaces de Programação de Aplicativos), usadas para desenvolver todas as funcionalidades para a implementação de aplicativos para televisão digital. Isso inclui desde a manipulação de dados multimídia até protocolos de acesso. O middleware Ginga é obrigatório para todos os receptores com interatividade, compreendendo set top boxes, TVs com recepção digital embutida, computadores multimídia e clusters locais de aparelhos conectados via redes domésticas (Home Area Networks , HAN).

Essa norma completa as normas anteriores, incluindo a Ginga-NCL. Para o desenvolvedor de aplicativos em NCL e Lua não muda nada, pois é possível escolher em quais linguagens programar as interatividades. Pode ser NCL sozinho, Java sozinho, NCL+Lua, NCL+Java ou NCL+Java+Lua.
Como já vimos em textos anteriores,  o Ginga-NCL (ou Máquina de Apresentação) é um subsistema lógico do middleware Ginga que processa documentos declarativos NCL. Outros módulos importantes são o usuário baseado em XHTML, que inclui uma linguagem de estilo (CSS) e intérprete ECMAScript, e o mecanismo LUA, que é responsável pela interpretação dos scripts  LUA.

A norma em consulta na ABNT também faz parte do middleware Ginga, porém processa aplicações procedurais desenvolvidas em Java, que recebem o nome de Xlets. Um componente-chave deste ambiente é o mecanismo de execução do conteúdo procedural, que tem por base uma Máquina Virtual Java.

A arquitetura completa do middleware Ginga é mostrada na figura abaixo. O Ginga é estruturado de forma a organizar as partes comuns, que independem da linguagem de programação dos aplicativos, como segurança e gerenciamento de mídias e fluxos de áudio e vídeo. A máquina de execução é responsável pela decodificação dos Xlets, enquanto a máquina de apresentação trata as aplicações declarativas. Em caso de a aplicação declarativa conter código procedural Java, há uma ponte entre as duas máquinas, que executam simultaneamente.

É preciso ressaltar que essa arquitetura se aplica apenas a receptores fixos e móveis. Receptores portáteis não possuem máquina de execução, nem máquina virtual Java.

Apenas para atualizar o panorama da implantação da TV digital no Brasil, o processo está adiantado em quase dois anos. Vinte cidades já dispõem de sinal digital, sendo 16 capitais, compreendendo mais da metade da população brasileira. Os receptores, cujo preço abusivo foi muito criticado no lançamento da TV digital em 2007, custam menos de R$ 400,00. O único problema é que a maioria dos fornecedores está sem estoque, segurando as vendas para incluir a interatividade nos próximos lotes. Até empresas desenvolvedoras de aplicações têm tido problemas para adquirir quantidades maiores de set top boxes. As 20 cidades com sinal digital são: São Paulo (SP), Belo Horizonte (MG), Rio de Janeiro (RJ), Goiânia (GO), Porto Alegre (RS), Curitiba (PR), Campinas (SP), Cuiabá (MT), Salvador (BA), Florianópolis (SC), Vitória (ES), Uberlândia (MG), São José do Rio Preto (SP), Teresina (PI), Santos (SP), Brasília (DF), Campo Grande (MS), Fortaleza (CE) e Recife (PE).

Desenvolvimento responde por 96% das falhas em sites de negócios

Notícia retirada do site CIO-Uol.

De acordo com o consórcio que reúne especialistas na área de segurança das aplicações, os problemas que mais se repetem são o Cross-site Scripting e o SQL Injection

Problemas no desenvolvimento de aplicativos web são responsáveis por mais de 96% das falhas críticas em sites de negócios. O dado faz parte de uma pesquisa divulgada pelo Web Application Security Consortium (WASC), um consórcio internacional que reúne especialistas na área de segurança de aplicações.

Os testes realizados pelo WASC mostraram que as falhas que mais se repetem podem ser divididas em duas categorias: os problemas derivados de Cross-site Scripting (XSS) e SQL Injection. No primeiro caso, trata-se de uma vulnerabilidade explorada pelos criminosos que enganam os usuários ao inserir links maliciosos no código de um site. Enquanto que, no segundo, ele ocorre quando o cracker insere um comando indesejado para ser executado quando o usuário acessar determinado site.

Em um site de comércio eletrônico, por exemplo, uma vulnerabilidade no SQL Injection pode ser explorada por criminosos para o roubo de informações, como dados pessoais ou de cartão de crédito.

A empresa de segurança Cipher alerta que a maioria das falhas dos sites está na validação de entrada de dados, ou seja, nos campos onde o usuário pode preencher login e senha ou preencher o valor que será transferido da conta bancária em um internet banking. Os sites precisariam prever a inserção de dados incorretos ou inesperados – o que pode representar um golpe online.

Para corrigir tais problemas, afirma a Cipher, os principais responsáveis seriam os desenvolvedores, que precisariam usar técnicas de desenvolvimento seguro. Adicionalmente, as organizações podem utilizar firewalls de aplicação para bloquear ataques nos aplicativos e manter os programas sempre atualizados com as correções oferecidas pelos fabricantes, além de realizar testes de vulnerabilidades e de invasão regularmente.

A Diferença de EA e Arquitetura de Software

Mais um post voltado a arquitetura de software. Retirado do site do Diego Pacheco.

Neste posta venho falar de arquitetura, falando de software existem vários níveis de arquitetura, hoje venho escrever um pouco mais sobre isso. Vou ficar com dois níveis ou tipos de arquiteturas que são a Arquitetura de Sistema e a Arquitetura Corporativa. Ainda pretendo traçar uma pequena relação do tema como SOA.

A Arquitetura de software é uma prática muito saudável, framework de desnevolvimento de software como o RUP e OpenUP são baseados na Arquitetura como suporte ao desenvolvimento. Mas existe um grande diferença da Arquitetura de Sistema e da Arquitetura corporativa.

A Complexidade

A Arquitetura de sistemas além de servir como suporte para o desenvolvimento, isso não significa fazer tudo para o desenvolvedor, mas significa pegar as maiores pedras, ou seja, as coisas mais complexas.

Investir na arquitetura de um sistema é sempre um bom negócio, a arquitetura não será a solução para todos os problemas e nem será feita de uma solução única, soluções homogêneas são cada vez mais difíceis. Principalmente falando de grandes empresas com a necessidade de ter cada vez mais flexibilidade e reaproveitamento, este é um cenário para a utilização de SOA, logo prepare-se para ter que lidar com sistemas legados, diversos tipos de tecnologias e vendors, e tudo isso só aumenta mais e mais a complexidade.

A Arquitetura de um sistema já pode ter a sua parcela de complexidade mas quando falamos no envolvimento de vários sistemas a complexidade aumenta e muito, sendo SOA ou não você irá precisar investir na arquitetura corporativa.

Enterprise Architecture

Também conhecida como Arquitetura Corporativa, de facto esta a um nível superior da arquitetura de sistemas. Quando você mais de um sistemas em uma empresa e o funcionamento do seu negócio precisa usar esses sistemas em conjunto você precisará de um outro nível de arquitetura, que seria a Arquitetura Corporativa ou Arquitetura das Arquiteturas.

A Arquitetura Corporativa é considerada também como uma forma de representação e padronização dos sistemas que servem ao negócio da empresa em questão. Falando de SOA, que são princípios para a construção de uma arquitetura voltada a serviços que por natureza vai ter que ser aplicada a mais de um sistema, está mais para EA do que para arquitetura de um sistema.

SOA é EA ?

Existem vários discursos e pontos divergentes nessa questão. Mas SOA são princípios, não existe nada mais especifico que ficam mais ao nível do “O Que fazer” do que especificamente “Como Fazer”. Alguns acham que isso é apénas uma questão de maturidade e que logo SOA iria evoluir ao ponto de chegar a se tornar algo mais completo perto até de um certo nível de governança.

Se isso vai acontecer eu já não sei. Mas o que afirmo é que existe muita pressão dos grandes vendors em cima disso, com certeza SOA está no Hype, apesar do ciclo ter caido muito. Os grandes players estão vendendo SOA como se fosse uma tecnologia ou um ferramental, por isso que a adoção de SOA vem caido e o pessoal de TI não está conseguindo provar o valor de SOA para o negocio.

SOA deve ser implementado com bons conhecimentos de engenharia e desenvolvimento, um excelente expertise de processo e de Design, o ferramental e a tecnologia são menos importantes, mas ao mesmo tempo que as empresas ficarem focando mais em tecnologia e ferramentas do que no expertise na construção de sistemas distribuídos nada vai evoluir.

O Troca Troca de Tecnologia

Você que está na TI pode ver um fenômeno que a cada ano que passa fica maior. Cada vez mais é mais difícil construir um sistema do Zero, cada vez mais é comum a construção de um sistema para migrar de tecnologia, algo que foi feito em clipper que será migrado para Java ou .NET.

Independente da linguagem tem sistemas que devem ter sido migrados de tecnologia umas 3 vezes, tudo isso por que? É por que a tecnologia ficou obsoleta, não é só por isso. Eu não tenho dúvidas que Java é melhor que clipper, mas qual é o problema?

O problema é que são estamos trocando de tecnologia e mudando o problema de lugar, ainda cometemos erros básicos de acoplamento e coesão, erro básicos de design, erros de análise de requisitos e de gestão, logo ao trocar de tecnologia não estamos resolvendo esses problemas.

Quando falo de fazer Arquitetura de Sistemas e Arquitetura Corporativa, não falo de tecnologia, falo de padrões, falo de boas práticas, falo de design, falo de baixo acoplamento e alta coesão, isso pode ser feito com qualquer linguagem de programação.

Soluções de Arquiteturas Corporativas

Existem algumas soluções de arquitetura corporativa(EA), uma delas é o framework do Zachman que prove um meio formal para definir a sua arquitetura corporativa. O Framework é muito completo e cobre quase tudo o problema é o alto grau de formalismo e o preço da solução.

Uma solução mais barata é o TOGAF. É um padrão da Open Group que foi desenvolvido no meio dos anos 90. Essa solução ajuda a você lidar com sistemas complexos que por natureza temo seu nível de independência e em certo ponto acabam se sobrepondo.

Toda solução de arquitetura corporativa tem indiferentemente de sua abordagem o principio de aproximar a TI do negócio através do planejamento estratégico. A Arquitetura corporativa tem que ser dinâmica e flexível. Muitas vezes a arquitetura corporativa se completa quando adicionamos a governança de TI. Mais ai já é assunto para outro post. Em outros posts pretendo falar mais sobre o TOGAF.

8 Boas Práticas Para Melhorar a Escalabilidade

Artigo traduzido, e retirado do InfoQ, voltado a análise de arquitetura, performance e escalabilidade de soluções, com ênfase em banco de dados. .

Wille Faler propõe 8 boas práticas para melhorar desempenho e escalabilidade como diminuir a carga no banco de dados, usar cache, minimizar tráfego na rede, entre outros.

1. Diminua a carga do banco de dados – fique longe do banco de dados o máximo que puder. Isso significa não abrir conexões ou iniciar transações a menos que seja realmente necessário.

2. A diferença que o uso de cache faz – cache diminui significativamente a carga em banco de dados, especialmente em aplicações que somente lêem desse banco. Cache em memória é melhor que cache em disco, que é melhor que um banco de dados relacional ou remoto.

3. Use cache em objetos de baixa granularidade – usar cache em objetos pouco granulares “economiza ciclos de CPU e tempo necessário para consultar n zonas de cache, ao invés de uma somente. Além disso, retornando o grafo do objeto completo economiza tempo ao montar o grafo do objeto.

4. Não armazene estado temporário em memória permanente – evite armazenar dados temporários como dados de sessão para um login em um banco de dados.

O “monstro do estado temporário” é uma besta perigosa. Como regra geral, somente dados de negócio reais, necessários, críticos e prontos para processamento devem ser armazenados de forma permanente (banco de dados, disco); nada mais.

5. Localização, Localização – deixe as coisas perto de onde elas devem ser fornecidas. Em vez de utilizar um balanceador de carga, um servidor web, um servidor de aplicação e um banco de dados, lembre-se que é melhor utilizar um balanceador de carga e um servidor web; e obter parte do conteúdo de uma Rede de Fornecimento de Conteúdo (CDN).

6. Restrinja acesso simultâneo a recursos – se mais de uma requisição acessa o mesmo recurso e executa o mesmo cálculo, é melhor que somente a primeira requisição faça o cálculo até o fim, e as demais requisições somente utilizem o resultado final. Permitir que todas as threads acessem o recurso somente tornará o processo mais lento.

7. Processamento assíncrono e em etapas

Algo que costuma fazer maravilhas para escalabilidade e desempenho é separar um processo de forma que seja assíncrono, dividido em etapas separadas por filas e executadas por um número limitado de threads em cada etapa.

8. Diminua a comunicação na rede – tente fazer com que sua aplicação se comunique o mínimo possível através da rede, pois é um processo muito mais lento do que comunicação em memória.

Steve M. Ciske, comentando sobre o post do Faler, é cauteloso em relação a reduzir a carga do banco de dados:

Eu tomaria cuidado ao diminuir a carga do banco de dados. Já vi pessoas no outro extremo que colocam tudo na camada de aplicação.

Pawel Stradomski considera cache remoto em memória mais rápido do que cache local em disco e Faler concorda com ele:

O uso de cache em um host remoto (via rede) pode ser mais rápido que o uso de cache em um disco local. A leitura dados sequenciais em um disco é por volta de três vezes mais lenta que a leitura na memória de hosts remotos; isso desconsiderando o tempo de busca.

Fonte relacionada: Simon Brown escreveu um artigo sobre princípios de escalabilidade.