O que é a tão comentada modernização de aplicações para Cloud?

Compartilhe:

Acabou de acontecer a quarta edição do IBM Talk’ n’ Labs, um encontro de especialistas que apresenta à comunidade técnica as novidades da IBM. Aproveitamos este espaço para falar um pouco sobre um dos temas apresentados no evento…

Quando se utiliza o termo “modernização para Cloud” normalmente podemos explorá-lo sob diversas óticas, analisando os impactos de infraestrutura ou mesmo de desenvolvimento. Neste artigo em especial, iremos focar em aspectos mais relacionados ao desenvolvimento.

A primeira coisa que vem à mente pode ser: “ahhh, vou mover a minha aplicação monolítica do jeito que ela está para o ambiente de Cloud!“. E, na verdade, muitas empresas estão fazendo isso como uma primeira estratégia, pomposamente chamada de “lift-and-shift”. Sobre este assunto, algo precisa ser discutido com mais afinco…

As aplicações monolíticas de hoje e do passado usam uma premissa de que o hardware está sempre disponível e é imutável. E mais, quando o hardware for desligado, tudo desaparece, inclusive a aplicação, então não precisaríamos nos preocupar com qualquer assunto no momento da parada. O mesmo é válido para um ambiente virtualizado com VMWare, por exemplo, já que as premissas são as mesmas, ou seja: desligou a VM, nada mais importa.

Em um ambiente de Cloud e de containers, utilizando Kubernetes ou OpenShift, a dinâmica funciona de outra forma. Primeiro, os containers são gerenciados de forma “viva”, e existe uma entidade chamada “gerenciador de containers” que cuida do seu ciclo de vida. Como containers são menores e mais fáceis de mover (de fato, são sempre recriados), o gerenciador vai organizando os workloads em função da memória e CPU disponíveis sob seu controle. Se ele percebe que alguma máquina está chegando a um limite crítico, pode, deliberadamente, mover ou mesmo criar um novo container em outro local. Em resumo, o que antes era uma decisão humana de parar uma máquina ou VM, agora é uma decisão sistêmica e que pode acontecer a qualquer hora do dia.

Mas o que isso tem a ver com a minha aplicação?

Bem, se antes não precisávamos nos preocupar com nada, agora é necessário, ao menos, se preocupar em guardar o contexto quando sair, e retomar o contexto de onde parou quando voltar. Mas talvez não seja tão simples, porque existe a possibilidade de parar de executar em uma máquina e começar a executar em outra. Os processos de inicialização e finalização precisam ser ao menos revisitados no lift-and-shift.

É claro que este é só o primeiro cuidado. Outro aspecto importante é que não podemos mais gravar informações em qualquer lugar. Os ambientes virtualizados funcionam como um sistema operacional e disco juntos, em um arquivo só. Também por causa disso, são gigantes! A decisão nos containers foi estabelecer determinadas áreas de storage externas ao container, e que podem ser utilizadas para armazenar de forma mais permanente. Claro que vale lembrar que outros containers podem acessar as mesmas áreas e dados, e precisamos ter cuidado com conflitos nos acessos aos arquivos. Ao menos ter a preocupação de que os dados não são mais exclusivamente nossos.

O que acontece é que o pessoal se empolgou transformando VMs de 40Gb em containers de 400Mb, e foram um pouco além. Aplicações monolíticas têm sido transformadas em blocos menores de processamento chamados de microsserviços. Estes se comunicam normalmente com protocolos leves, como REST, e cada um roda em seu container. Aqui, já existem complicadores maiores. Ao invés de uma aplicação monolítica, agora existem grupos de containers rodando de forma relativamente independente, mas se comunicando através de REST que usa HTTP como se estivessem dentro da mesma aplicação.

Um dos objetivos desta abordagem é facilitar a manutenção e diminuir o downtime geral da aplicação. A ideia é a de que podemos utilizar DevOps para publicar cada “pedaço” do programa de forma independente, o que é fantástico – mas não tão simples assim! O que acontece se um pedaço, carinhosamente chamado de microsserviço, estiver em manutenção ou sendo atualizado, e outros códigos tentarem se comunicar com ele?

Esse é um dos problemas comuns que vêm sendo endereçados com tecnologias que facilitam o desacoplamento, como o Kafka, Event Streams e Confluent. Todos eles trabalham com eventos que tornam os sistemas mais desacoplados, porque os eventos são enviados e ficam disponíveis para serem consumidos pelo microsserviço quando retornar à execução. Desta forma, a esteira DevOps finaliza o container, atualiza a imagem e o gerenciador de containers cria a nova instância quando disponível. Quando este código estiver operacional, ele passa a consumir os eventos ou mensagens que não tratou enquanto estava fora do ar.

Essa é uma das mudanças de arquitetura necessárias para que ambientes monolíticos possam se beneficiar de ambientes de containers, quando migramos para arquiteturas de microsserviços. Existem outros fatores a serem considerados, e um local interessante para explorar outros aspectos e recomendações é o 12Factor. Nele existem algumas boas práticas que auxiliam a tornar as aplicações mais preparadas para executar em ambientes de Cloud pública ou privada.

Sabemos que existem outras preocupações importantes, como endereços IP e portas não serem mais confiáveis, e pelo fato de os containers serem imutáveis, tudo deve ser armazenado fora ou enviado para um serviço externo. Containers não devem ter estado (devem ser stateless), porque muitos estarão executando em paralelo e não há a garantia de que o container que processou antes irá processar a segunda requisição agora.

Quando se migra para uma arquitetura de microsserviços rodando em ambientes de containers (tomando cuidado com todos os aspectos) fazemos o que se chama “modernizar a aplicação”, ou aplicar práticas que tornam a aplicação mais adequada para a sua execução em containers e, consequentemente, em Cloud. Existem ferramentas que ajudam a identificar possíveis pontos de mudança, e até ferramentas que apoiam na migração de forma automática, utilizando IA, para uma arquitetura de microsserviços.

Neste artigo, abordamos um dos vários temas que foram foco no Talk’ n’ Labs, o evento da IBM especialmente criado para a comunidade técnica sobre os principais tópicos em alta no contexto da transformação digital nas empresas. O evento é apresentado por um time muito especializado da IBM e conduzido de uma forma didática e fácil de entender – mas nem por isso deixando de ser aprofundada!

Saiba mais

Confira o replay do IBM Talk’ n’ Labs no IBM Play e aprofunde seu conhecimento técnico para alavancar seu diferencial competitivo.

Vamos conversar

Entre em contato com um representante da IBM.

Texto original: https://www.linkedin.com/pulse/o-que-%25C3%25A9-esta-comentada-moderniza%25C3%25A7%25C3%25A3o-de-aplica%25C3%25A7%25C3%25B5es-para-glauco-reis/