Participe do maior Hackathon da América Latina sobre Mudanças Climáticas | 23 a 25 de Julho Inscreva-se

Seis motivos pelos quais o Open Liberty é a escolha ideal para desenvolver e implementar microsserviços

Introdução

Ao pensar em microsserviços pela primeira vez, é natural achar que a única diferença está no tamanho do aplicativo. Afinal, são apenas pequenos aplicativos conversando entre si, certo? No entanto, ao se aprofundar um pouco mais e talvez colocar as mãos à obra, você começa a perceber que criar, conteinerizar, implementar e gerenciar muitos aplicativos interconectados é algo que apresenta um conjunto próprio e exclusivo de requisitos.

O IBM® WebSphere Liberty foi criado em 2012 em resposta ao aumento da demanda por um tempo de execução ágil e leve. Em 2017, por causa da crescente demanda por open-source, foi criado o Open Liberty: a distribuição open-source upstream, totalmente capaz, do Liberty. O WebSphere Liberty ainda existe, oferecendo recursos adicionais que facilitam a modernização dos aplicativos empresariais tradicionais. No entanto, para a maioria dos aplicativos, o Open Liberty fornece tudo o que você precisa.

O Liberty simplifica consideravelmente o desenvolvimento e a implementação de aplicativos em tempos de execução de servidor de aplicativos tradicional. Ele oferece a capacidade de criar implementações do tamanho certo, a partir de 24 MB até suporte completo para Jakarta EE/Java EE. A arquitetura de migração zero remove os desafios de migração de versão para versão; o ajuste automático proporciona o desempenho ideal sem ciclos de ajuste caros; é simples de configurar; e muito mais. Essas características são ideais para implementações em nuvem. Além disso, com a adição do suporte para contêineres de primeira classe e APIs nativas de nuvem, como MicroProfile, o Liberty é a escolha ideal para novos aplicativos com base em microsserviços.

Vamos explicar, em mais detalhes, os seis motivos principais pelos quais o Liberty é a escolha ideal para microsserviços nativos de nuvem.

Motivo 1. Imagens do tamanho certo, sem bagagem extra

Ao implementar microsserviços, o consumo de recursos (CPU, memória e assim por diante) é diretamente equivalente ao custo. Se você está implementando dezenas ou centenas de microsserviços onde antes tinha um aplicativo monolítico, agora tem dezenas ou centenas de instâncias do tempo de execução a mais. É importante, portanto, que seus microsserviços consumam recursos adequadamente. Se você está implementando centenas de pequenos microsserviços, não quer que cada microsserviço atraia centenas de megabytes de bibliotecas e tempo de execução do servidor.

O Liberty é um tempo de execução totalmente modular e permite que você escolha os recursos necessários para seu aplicativo. Com o Liberty, você tem um tempo de execução, uma abordagem, para desenvolver e implementar aplicativos que crescem desde pequenos microsserviços até monólitos empresariais modernos completos, e qualquer coisa entre eles.

A tabela a seguir mostra mensurações de disco e memória para três pacotes de tempo de execução de exemplo. A primeira linha contém todas as APIs mais recentes para Java EE/Jakarta EE e MicroProfile (tudo o que pode ser necessário para um monólito nativo de nuvem moderno); a segunda linha contém tempo de execução suficiente para dar suporte ao MicroProfile 3.3 (tudo o que pode ser necessário para um microsserviço típico); e a terceira linha contém tempo de execução suficiente para executar o Servlet 4.0 (o mínimo absoluto que pode ser necessário para executar um framework da web simples). É possível ver que, à medida que ajustamos o tamanho do Liberty para um conjunto reduzido de necessidades, os requisitos de disco e memória também diminuem. É exatamente isso que se espera de um tempo de execução.

Pacote Tamanho no disco Memória
Java EE 8/Jakarta EE 8 + MicroProfile 3.3 121 MB 165 MB
MicroProfile 3.3 59 MB 113 MB
Servlet 4.0 24 MB 72 MB

Motivo 2. Baixo custo operacional: menos memória e maior taxa de transferência são essenciais

A migração de aplicativos monolíticos para estilos arquiteturais que resultam na implementação de dezenas ou centenas de aplicativos menores provocou uma mudança na importância de diferentes características de desempenho do tempo de execução. Talvez você ouça falar muito em “inicialização a frio”, algo criticamente importante para funções de nuvem (o tempo do Liberty para a primeira resposta é de aproximadamente um segundo, ele não é lento). No entanto, para microsserviços, é provável que cada instância de execução atenda a milhares de solicitações antes de ser substituída. Dado o perfil de uso esperado de dezenas a centenas de serviços com milhares de solicitações, as métricas de desempenho mais importantes são consumo de memória e taxa de transferência. São elas que terão o maior impacto no custo.

Comparações de ocupação da memória

A figura a seguir mostra a comparação da ocupação de memória após a inicialização para servidores que executam a referência Acme Air Microservices. Nesse cenário, o Liberty usa de 2,5 a 10 vezes menos memória do que outros tempos de execução.

Gráfico de barras da comparação da ocupação de memória do Open Liberty, WildFly, TomEE, Payara e Helidon

Caso tenha escolhido o Spring Boot para seu aplicativo, há um benefício aproximadamente duas vezes maior na ocupação de memória com a execução no Liberty, como você perceberá na figura a seguir que mostra o uso relativo da memória ao executar o aplicativo Spring Boot Petclinic sob carga com uma pilha de 4 GB.

Gráfico de barras mostrando um benefício duas vezes maior na ocupação de memória ao executar o Spring Boot Petclinic no Liberty, em comparação com o Tomcat, sob carga

Comparações de taxa de transferência

O Liberty também tem benefícios significativos de taxa de transferência em comparação com outros tempos de execução. A figura a seguir mostra mensurações da taxa de transferência em relação à referência do Acme Air Microservices. O Liberty tem o melhor desempenho geral entre os tempos de execução testados e é significativamente melhor do que a maioria deles.

Gráfico de barras mostrando que a taxa de transferência do Liberty é melhor que a do WildFly, duas vezes melhor que a do TomEE e cinco vezes melhor que a do Payara e do Helidon

A figura a seguir mostra um benefício quase duas vezes maior na taxa de transferência ao executar o aplicativo Spring Boot Petclinic no Liberty, em vez de no Tomcat.

Gráfico de barras mostrando um benefício duas vezes maior na taxa de transferência ao executar o Spring Boot Petclinic no Liberty, em vez do Tomcat, sob carga

A combinação dos benefícios de memória e taxa de transferência equivale a uma economia mais de quatro vezes maior (taxa de transferência por MB) para este aplicativo Spring Boot no Liberty e um benefício 3,5 vezes maior em relação ao mais próximo dos outros tempos de execução comparados. Trata-se, potencialmente, de uma economia mais de três vezes maior em custos de nuvem e licença.

Motivo 3. Entrega contínua: baixa manutenção, dívida técnica zero

Muitas vezes, a migração para nativo de nuvem e microsserviços causa uma mudança na responsabilidade pela propriedade do tempo de execução. Uma única equipe multidisciplinar desenvolve, empacota e implementa um aplicativo (por exemplo, um microsserviço) como contêiner imutável incluindo o tempo de execução do servidor, até mesmo aplicativos Spring Boot incorporam um servidor (por exemplo, Tomcat, Jetty ou Liberty). A equipe de operações gerencia uma plataforma em nuvem baseada no Kubernetes, como o Red Hat OpenShift, em que as equipes de aplicativos implementam seus contêineres.

No novo mundo nativo de nuvem, o que frequentemente não se percebe (até que seja tarde demais) é que a equipe de desenvolvimento passou a ser responsável pela manutenção do tempo de execução, que agora faz parte do conteúdo do contêiner. Anteriormente, a equipe de operações gerenciava o menor número de instâncias de tempo de execução do servidor, lançando cuidadosamente os principais upgrades nas liberações de serviço ou versão e garantindo que as ‘correções provisórias’ críticas para a segurança fossem aplicadas. Agora, as equipes de desenvolvimento que entregam dezenas ou centenas de aplicativos (cada um incorporando um tempo de execução) são responsáveis por garantir que esses tempos de execução sejam mantidos atualizados e livres de vulnerabilidades. Como o Liberty ajuda com esse problema?

A primeira parte da resposta é liberar com frequência. O Liberty tem um ciclo de liberações de ‘entrega contínua’, enviando uma nova liberação a cada quatro semanas. As correções enviadas para a liberação anterior são automaticamente transferidas para a próxima. Com a entrega contínua, não é necessário aplicar o serviço. Você o recebe automaticamente. Cada liberação do Liberty é disponibilizada na Maven Central e na Docker Hub, tornando muito mais simples a escolha da automação de desenvolvimento mais recente. As equipes de desenvolvimento podem simplesmente recriar os contêineres para atrair a liberação mais recente, estando confiantes de que ela contém correções para a versão anterior. A segunda parte da resposta é ‘migração zero’, que é discutida na próxima seção.

Evidentemente, se não estiver mudando a forma de entregar seus aplicativos, mas ainda quiser os benefícios do Liberty, o ciclo de liberações do Liberty e as opções de suporte também possibilitam isso. Cada liberação do Liberty vem com cinco anos de suporte. Cada terceira liberação em um ano (as versões que terminam em 3, 6, 9 e 12) vem com dois anos de suporte para ‘correção provisória’, possibilitando um ciclo de atualização mais tradicional. Além disso, não há necessidade de extensões de suporte, porque cada nova liberação de quatro semanas reinicia o relógio de suporte de cinco anos. Para saber mais, consulte a Política de Suporte do Liberty.

Motivo 4. Migração zero: mantenha-se atualizado, sem esforço

O Liberty é o único tempo de execução Java que fornece ‘migração zero.’ A migração zero significa que, em questão de minutos, é possível avançar para o Liberty mais recente sem precisar alterar o código ou a configuração do aplicativo. Historicamente, esses tipos de migrações enchiam as equipes de medo, pois precisavam ser planejadas com meses de antecedência e levavam mais de um ano para serem concluídas. É muito investimento apenas para se manter atualizado.

O Liberty permite a migração zero por meio do uso de “recursos” com versões. No Liberty, as APIs são fornecidas por recursos. Por exemplo, há um recurso para o servlet-3.1. Quando são introduzidos novos recursos que travariam aplicativos existentes ou sai uma nova versão de especificação, o Liberty fornece um novo recurso. Portanto, quando saiu o Java EE 8 e houve mudanças que causaram avarias, criou-se um recurso servlet-4.0 ao lado do recurso servlet-3.1. Um aplicativo pode decidir se usará um ou o outro. Migrar seus aplicativos é, portanto, uma decisão separada de atualizar o nível do Liberty. Se você quiser avançar para o nível mais recente do Liberty, mas não migrar o aplicativo e a configuração, poderá continuar usando os mesmos recursos (por exemplo, o servlet-3.1). Isso significa que será possível pegar as correções de tempo de execução mais recentes sem precisar passar por uma migração dolorosa. Quando estiver pronto para tirar proveito das APIs mais recentes (por exemplo, servlet-4.0), poderá atualizar a configuração do servidor e o aplicativo para usá-las.

A combinação de entrega contínua e migração zero significa que é possível se manter em dia com as correções, com o mínimo de investimento, e optar por investir em mudanças nos aplicativos quando houver uma necessidade de negócios e um benefício em fazer isso.

Motivo 5. Otimização para Kubernetes: ajuste automático, integração nativa

No momento, a maioria das grandes empresas está executando o Kubernetes na produção. Os contêineres e o Kubernetes são considerados integrais para a entrega de microsserviços nativos de nuvem. A entrega contínua de microsserviços baseados em contêiner precisa de um tempo de execução que ofereça suporte a melhores práticas de contêiner e orquestração de contêineres (Kubernetes). Precisa ser fácil:

  • Alcançar o melhor desempenho sem saber onde o contêiner será implementado.
  • Criar e manter imagens seguras e compatíveis.
  • Integrar o tempo de execução e o aplicativo com o ambiente de orquestração de contêineres.

Sem essas qualidades, os microsserviços serão ineficientes e difíceis de manter, proteger e gerenciar. As seções a seguir explicam como o Liberty ajuda a proporcionar a experiência ideal do Kubernetes.

Tempo de execução de ajuste automático

Ao implementar em ambientes em contêiner em nuvem pública ou privada, é importante ser capaz de obter o melhor desempenho do aplicativo. Isso não é exclusividade dos contêineres; no entanto, eles tornam o ajuste mais desafiador. Para lidar com isso, o Liberty faz duas coisas:

A figura a seguir mostra a taxa de transferência do Liberty com base em diferentes latências de solicitações. É possível ver que o ajuste automático rapidamente alcança o desempenho ideal. Se a latência mudasse com o tempo, o Liberty se ajustaria de acordo.

Gráfico de linhas mostrando que a taxa de transferência do Liberty alcança o máximo desempenho por meio de ajuste automático do pool de threads

Imagens prontas para a produção

Para cada nova liberação do Liberty, novas imagens do contêiner Universal Base Image são transferidas por upload para o Docker Hub. As imagens são de distribuição gratuita, compatíveis com a OCI (Open Container Initiative) e com suporte disponível, se você desejar. As imagens para o Open Liberty e o WebSphere Liberty são transferidas por upload e mantidas com base na política de suporte do Liberty. As correções para vulnerabilidades críticas de segurança são automaticamente aplicadas, e as imagens, atualizadas, para que você não precise fazer isso.

Caso as imagens não sejam exatamente do seu gosto, os Dockerfiles e scripts do Open Liberty e do WebSphere Liberty usados para criá-las são open-source e estão disponíveis para customização própria. Todos os artefatos necessários estão disponíveis em repositórios públicos como Maven Central e Docker Hub.

Integração do Kubernetes

O Kubernetes rapidamente se tornou a principal tecnologia de orquestração ao migrar para contêineres. Plataformas baseadas no Kubernetes, como o OpenShift, permitem que você implemente contêineres, os aumente ou diminua e até mesmo deixe-os zerados.

Os operadores são a abordagem de gerenciamento preferencial do Kubernetes. O Open Liberty Operator possibilita o gerenciamento de primeira classe do Liberty dentro do Kubernetes e do OpenShift. Ele simplifica consideravelmente a implementação e a configuração de aplicativos, armazenamento em cluster, integração de persistência, ligação de serviços, determinação de problemas e muito mais.

Alguns aspectos do ciclo de vida do contêiner e do gerenciamento de tráfego precisam de ajuda do tempo de execução no interior do contêiner. Por exemplo, o Kubernetes reiniciará um contêiner se acreditar que ele está inativo e não enviará solicitações a um contêiner se acreditar que ele não está pronto. As sondagens Liveness e Readiness do Kubernetes fornecidas pelo contêiner são usadas para indicar o status do contêiner/aplicativo. O suporte MicroProfile Health no Liberty foi criado para tornar incrivelmente simples a oferta desse nível de integração da orquestração de contêineres.

Motivo 6. Ferramentas para desenvolvedores que ajudam, não atrapalham, cientes do contêiner e concentradas em CD

Uma experiência do desenvolvedor de primeira classe é fundamental para fornecer novas funções e correções com eficiência. Por muitos anos, o Liberty se concentrou principalmente em ajudar os desenvolvedores a serem produtivos com suas ferramentas preferidas. O Liberty se integra com as ferramentas de desenvolvimento mais populares (Maven e Gradle), incluindo a liberação de todos os binários de tempo de execução para o Maven Central. O suporte para Maven e Gradle do Liberty também fornece o ‘modo de desenvolvimento‘, o que significa que os desenvolvedores podem fazer alterações no código e na configuração para que entrem em vigor imediatamente em um servidor em execução local, até mesmo em um servidor em execução em um contêiner local. Isso remove a necessidade de recriação e reimplementação completas, reduzindo consideravelmente o tempo necessário para desenvolver e testar atualizações. O suporte para contêiner significa que é possível desenvolver e testar em um ambiente mais próximo da produção.

O teste de aplicativos nativos de nuvem introduz a necessidade de fazer testes no contêiner. A realização de testes de integração fiéis à produção dentro de um contêiner reduz consideravelmente as chances de que problemas cheguem à produção. Os testes do ‘MicroShed‘ permitem exatamente isso, com a capacidade de executar testes de integração do JUnit em relação a um aplicativo Liberty em execução em um contêiner, incluindo a integração com contêineres que executam bancos de dados e Kafka.

O modo de desenvolvimento permite implementação a quente, testes a quente, depuração a quente e muito mais nos editores de código mais populares: IntelliJ, Eclipse, VS Code, até mesmo vi. A combinação do modo de desenvolvimento com APIs MicroProfile e testes MicroShed proporciona uma experiência do desenvolvedor nativa de nuvem integral. Estamos continuamente oferecendo novos recursos para deixar incrível sua experiência do desenvolvedor!

Assista ao vídeo a seguir para ver como a extensão Open Liberty Tools for IntelliJ facilita ainda mais o desenvolvimento com o modo de desenvolvimento do Open Liberty no IntelliJ:

Conclusão

A migração para implementações mais refinadas de microsserviços nativos de nuvem gera novos desafios para as equipes de desenvolvimento e operações: a necessidade de tempos de execução com alta taxa de transferência e baixo uso de recursos; a necessidade de integração com Kubernetes e contêineres de primeira classe; a necessidade de ser capaz de manter a segurança com upgrades simples e frequentes; e muito mais.

Este artigo destacou seis recursos do Liberty que lidam com esses novos desafios:

  • Tempo de execução do tamanho certo
  • Baixo custo operacional
  • Entrega contínua
  • Migração zero
  • Otimização para Kube
  • Ótima experiência do desenvolvedor

Esses recursos tornam o Liberty a escolha ideal para o desenvolvimento e a implementação de microsserviços.

Próximas etapas

Caso queira experimentar o Liberty, confira os guias práticas do Open Liberty.