Eu me lembro que há pouco tempo os gerentes dos CPDs descreviam a arquitetura em N camadas de seus ambientes como se estivessem transbordando de orgulho. A arquitetura em N camadas pode ser descrita como uma separação em três camadas, a de apresentação, a de lógica de negócios e a de dados. Para muitos, isto continua sendo o jeito mais conveniente de conceituar os componentes funcionais de qualquer sistema de software. Como muitos usuários, processos e dados foram adicionados, mais espaço de armazenamento foi adicionado também. O desempenho da rede adicionou uma dimensão de rendimento, e analistas de TI muitas vezes se veem calculando usuários x dados x transações por hora para determinar requisitos. Estes ainda são exercícios fundamentais e bons.
Mas o que acontece quando seus sistemas escalam rapidamente, quase exponencialmente além das expectativas ou limites já conhecidos? A solução mais comum no passado foi balanceamento de carga. Processadores e armazenamento foram compartilhados ou virtualizados. Isto funciona bem até um ponto, mas os problemas tomam forma quando se torna difícil de compartilhar a memória. Quando chega o momento de aumentar além de umas dezenas de processos paralelos, a abordagem do balanceamento de carga fica, assim, sobrecarregada. A escalabilidade se torna o foco central. É mais bem compreendida como a habilidade de uma aplicação crescer para satisfazer maiores volumes e velocidades de usuários, transações e dados sem alterar o código, o que sacrificaria a integridade dos dados ou reduziria os níveis de serviço dos usuários.
Os sistemas de gerenciamento de bancos de dados relacionais, ou RDBMS, são bons em durabilidade e em potência da informação. Mas bancos de dados relacionais dependem de infra-estrutura localizada, que é lenta e se torna um gargalo. Quando a escalabilidade entra em foco, o I/O de disco se torna a questão número um. A fim de manter a consistência, os bancos de dados muitas vezes precisam ser bloqueados em cada tabela, página ou registro. Para superar os desafios de desempenho do banco de dados, computadores mais robustos e de alto desempenho são implantados. Pense em adicionar capacidade de processamento em um sistema em escala vertical – nós estabelecemos uma elevação na plataforma de banco de dados.
Superar as barreiras de arquiteturas tradicionais exige novas abordagens. Uma Grade de Dados Em Memória (IMDG em inglês – In Memory Data Grid) é uma camada de software composta de “múltiplos processos de servidor, sendo executados em vários servidores físicos, todos trabalhando juntos para armazenar e processar grandes quantidades de dados na memória.” O objetivo do IMDG é obter alta disponibilidade, alto desempenho e flexibilidade de dados na memória, e em paralelo. A necessidade de acesso ao disco é reduzida por um IMDG, pois o I/O e o gerenciamento de dados são operações de memória e não requerem acesso ao disco físico. O foco da escalabilidade em um IMDG muda de uma otimização do disco I/O para uma otimização do gerenciamento de dados em memória através de uma rede.
O Oracle Fusion Middleware é um exemplo de uma arquitetura de integração tradicional ERP que não usa as técnicas da computação in-memory. O guia de alta disponibilidade da Oracle para o fusion middleware identifica claramente sua dependência em armazenamento físico compartilhado: “Apesar de cada nó em um cluster ser um servidor independente que executa seu próprio conjunto de processos, há alguns dados baseados em sistemas de arquivos e elementos de configuração que precisam de acesso constante em todos os nós de um cluster. O armazenamento compartilhado se refere a habilidade de um cluster acessar o mesmo armazenamento, geralmente discos, de qualquer nó em um cluster.” A IBM WebSphere Middleware não é diferente, e também sofre em alguns aspectos de armazenamento físico compartilhado. Com todo o barulho ao redor do SAP HANA seria de se esperar que o SAP Netweaver utilize as abordagens da computação in-memory. Mas isto também não é verdade. Somente o SAP Netweaver com a marca Data Warehouse é baseado no HANA, não a própria plataforma de integração ERP SAP.
No mundo da integração, conheço apenas uma plataforma de integração de ERPs que realmente utiliza as mais avançadas técnicas de computação in-memory para todas suas mensagens: Plataforma de Integração Magic xpi. Com o Magic xpi, uma abordagem conhecida como arquitetura baseada em espaço (space-based architecture) alavanca memórias co-localizadas e grupos de processamento chamados de “espaços”. Cada “espaço” contém um subconjunto da lógica de negócios, dos dados e das mensagens necessárias para executar um subconjunto da aplicação. Cada espaço é independente de todos os outros e, portanto, a escala pode ser alcançada em condições paralelas ilimitadas ou em grades de dados mais apuradas. Um espaço pode, na realidade, ser particionado entre diferentes unidades de processamento físico e memórias de espaço. Com reproduções, a alta disponibilidade é alcançada na designação primária e nas partições de backup para cada espaço. Tais aproximações usam o método cluster para alcançar a auto-recuperação e zero pausas.
A escalabilidade da integração de ERPs realmente importa? Apenas se o desempenho dos processos de negócios subjacentes importar. Mas lembre-se que a integração pode ocorrer em pontos múltiplos sem um fluxo de processo de integração de negócios. Para a maioria das empresas, hoje em dia devem ser levados em conta múltiplos touchpoints como parte de cada processo de negócios.
