Artigos Java WebLogic Multitenant: A nuvem dentro do servidor de aplicação

Entendendo Weblogic de vez

Hoje em dia a maioria das corporações sofre com a proliferação de ambientes, que ocorre por questões de insegurança (ao colocarmos novas aplicações em ambientes já existentes e funcionais) ou por diferença de criticidade. O grande problema dessa proliferação de ambientes é que ela custa caro em termos de mais infraestrutura e pessoal e também aumenta o risco, pois cresce a dificuldade de manter todos esses ambientes atualizados.

A solução para esse cenário é a consolidação das aplicações em um número menor de ambientes, reduzindo a complexidade, demanda sobre o time de operações, riscos, etc. No entanto, tal consolidação nos expõe aos problemas que levam à proliferação, como, por exemplo, a possibilidade de uma aplicação impactar sobre outra. A consolidação com controle sobre o comportamento de cada aplicação e também com isolamento entre elas é o cenário ideal para colocar mais aplicações em um mesmo ambiente e ainda garantir que uma não cause impacto na outra. Isso só pode ser obtido através de uma abordagem Multitenant. Mas, o que é mesmo Multitenant?

Para que seja possível entender o que é uma abordagem Multitenant, por que ela permite a consolidação com controle e, depois, assimilar como isso se aplica ao mundo Java EE, é preciso dar um passo atrás e compreender o significado desse termo. Multitenancy significa “múltiplos inquilinos” e, quando falamos sobre o assunto, estamos tratando de consolidação e compartilhamento de recursos com o objetivo de colocar mais ativos no mesmo ambiente e nos beneficiar dos recursos comuns disponíveis.

No mundo do software, podemos dizer que um software ou plataforma é Multitenant quando uma instância serve a múltiplos consumidores, também conhecidos como tenants. Essa abordagem permite compartilhar o ambiente e tirar proveito de uma série de fatores devido a esse compartilhamento, como veremos ao longo do artigo.

Java EE e o compartilhamento de recursos

Neste momento você pode estar pensando nos projetos Java EE que possui, onde provavelmente já compartilha recursos através da instalação de múltiplas aplicações no mesmo ambiente, não é mesmo? Então, o que de tão interessante tem esse tal de Multitenant que você já não esteja fazendo, visto que na maioria dos servidores de aplicação é possível instalar diversas aplicações na mesma instância e compartilhar os recursos e serviços providos pela plataforma Java EE?

Isso tudo é verdade, mas até certo ponto. O Java EE realmente é uma plataforma que permite o compartilhamento de recursos. Você pode instalar múltiplas aplicações na mesma JVM, fazendo com que todas elas compartilhem memória, poder de processamento, conexões com a base de dados, adaptadores JCA, recursos JMS (filas, tópicos, connection factories), entre outros.

Porém, nem tudo é perfeito nesse cenário. O problema começa quando você precisa compartilhar o ambiente e a infraestrutura, mas ao mesmo tempo necessita de um isolamento forte entre os ‘tenants’. Os tenants podem ser aplicações Java EE, ou conjuntos delas, que demandam isolamento umas das outras. A motivação desse isolamento pode ser, por exemplo, a criticidade ou o fato de ser uma aplicação nova, não madura e que não se tem confiança sobre o impacto que pode causar no ambiente.

Isolamento é importante quando o assunto é compartilhamento

Já que multitenancy significa multi-inquilinato, podemos fazer uma analogia com o mundo real para exemplificar a importância do isolamento em cenários de compartilhamento de recursos. Por exemplo, ao pensar em um edifício de apartamentos, fica mais clara a demanda por compartilhamento com controle. Nesse cenário, podemos assumir que os usuários irão compartilhar algumas das facilidades do edifício, como elevadores, áreas comuns, piscinas, garagens, entre outros. No entanto, vão demandar também políticas de isolamento. Os apartamentos deverão ser isolados fisicamente uns dos outros por questões de segurança e privacidade. Será necessário também um controle de acesso que garanta que usuários de um apartamento não possam acessar outro apartamento sem autorização, entre outros exemplos.

Agora, imagine que para conseguir um isolamento físico mais forte ou um controle de acesso diferente por tenant, tenhamos que replicar os elevadores, a piscina, a garagem ou até mesmo o edifício para cada condômino. Imaginou? Pois é, muitas vezes é isso que acontece com as aplicações que precisam ser isoladas umas das outras, como veremos mais a frente.

A mesma demanda por um balanceamento entre o compartilhamento de recursos, o isolamento e o controle que temos em um condomínio se aplica a qualquer plataforma que se disponha a prover serviços compartilhados. É isso que o WebLogic Server Multitenant agrega ao que já existe na plataforma Java EE e o que veremos neste artigo.

A necessidade por isolamento e compartilhamento de recursos em Java EE

A necessidade do isolamento entre aplicações Java EE não é algo novo. Essa demanda ganha cada vez mais atenção à medida que as corporações tendem a consolidar mais aplicações no mesmo ambiente para reduzir a complexidade, consumo de recursos e simplificar a gestão e as operações.

Algumas abordagens para compartilhamento de recursos com isolamento já existem há bastante tempo. Essas soluções têm seu valor, e algumas podem ser utilizadas para complementar as funcionalidades providas pelo WebLogic Multitenant. Vamos analisar algumas delas para compreender quais problemas são possíveis de serem solucionados com o WebLogic Multitenant e que não eram antes.

Isolamento através da virtualização: múltiplas máquinas virtuais

A virtualização pode ser uma maneira de isolar aplicações e, ainda, tirar proveito do compartilhamento de recursos. Isso é possível uma vez que as VMs compartilham o mesmo hardware físico, mas há o isolamento entre as máquinas virtuais em termos de consumo de recursos, como CPU, memória, disco, etc.

Máquinas virtuais são uma boa opção para a consolidação e divisão de servidores grandes em máquinas virtuais menores e mais especializadas. Você provavelmente fará a instalação das instâncias do WebLogic Multitenant em máquinas virtuais. O problema é que configurar uma máquina virtual somente para isolar uma única aplicação das demais pode ser um exagero.

As máquinas virtuais levam consigo todo o footprint de uma nova instância do sistema operacional e, por isso, pode ser um exagero utilizá-las como uma forma de isolamento de aplicações. Tecnologias de containers, como o Docker (veja o BOX 1), são uma alternativa para esse cenário. Para adicionar mais overhead à nossa equação, em cada máquina virtual você terá uma máquina virtual Java (JVM) e outra instância do servidor de aplicação. Caso você precise instalar e isolar uma nova aplicação, o mesmo overhead será replicado: máquina virtual, sistema operacional, JVM e servidor de aplicação. Além disso, esse cenário agrega muita complexidade para a gestão dos ambientes, uma vez que, quanto mais aplicações demandam isolamento, maior é a demanda por mais máquinas virtuais, JVMs e instâncias de servidor de aplicação, o que leva a mais ambientes, mais recursos, mais tempo para aplicação de atualizações, etc.

BOX 1. Docker
É um projeto open-source que permite criar containers com tudo que sua aplicação precisa para executar. Através do uso de containers podemos ter um isolamento similar a uma máquina virtual, porém sem o overhead de executar um sistema operacional sobre outro. Isso ocorre porque o container não exige uma nova instância do sistema operacional, como no caso das máquinas virtuais, mas sim compartilha o kernel do sistema operacional onde está executando.

Isolamento com múltiplas JVMs

Outra forma bastante comum de isolar aplicações Java EE é executá-las em instâncias dedicadas do servidor de aplicação e JVM, mas na mesma infraestrutura base, que pode ser virtual ou física, ou seja, executando vários “nós” do servidor de aplicação na mesma máquina.

Dessa forma, as aplicações são completamente isoladas umas das outras sob o ponto de vista da JVM e servidor de aplicação, mas compartilham o mesmo sistema operacional. É mais uma abordagem para isolamento, mas que também vem com um preço a ser pago. Nesse caso, o overhead está relacionado à complexidade. Esse preço é um pouco menor do que o do cenário anterior, mas ainda é grande, pois temos a replicação da JVM e da instância de servidor de aplicação para cada aplicação que demande isolamento. Assim, à medida que ...

Quer ler esse conteúdo completo? Tenha acesso completo