Por Que Você Deve Considerar O Uso De MicroProfile Em Seus Microsserviços?

Um Pouco de História

“Write once, run anywhere” (Escreva uma vez, execute em qualquer lugar) foi o slogan criado pela Sun Microsystems em 1995, quando a primeira versão do Java foi lançada. Uma das coisas que permitiu isso foi a criação de especificações para a linguagem Java e para a máquina virtual Java.

Com essas especificações, não precisamos nos preocupar sobre como um recurso foi implementado. Cada implementação deve executar um kit de compatibilidade de tecnologia (TCK – Technology Compatibility Kit), que consiste em um conjunto de testes que garantem que todas as especificações foram implementadas corretamente.

Quatro anos após o lançamento do Java, a comunidade criou a Edição Enterprise da plataforma Java (Java 2 Platform, Enterprise Edition ou J2EE).

Ela consistia em várias especificações que resolviam desafios que comumente eram enfrentados ao criar aplicações corporativas. Alguns anos depois, a plataforma foi renomeada para “Java Platform, Enterprise Edition” (ou Java EE) e depois a Oracle (a mantenedora do Java EE) passou a plataforma para a Eclipse Foundation, o que a fez ser renomeada para “Jakarta EE”.

A Tendência de Redução de Tamanho

As primeiras implementações das especificações corporativas eram grandes, pesadas e as aplicações demoravam vários minutos para iniciar. Alguns anos depois, a tendência era “quanto mais leve, melhor” e as implementações do Java EE começaram a persegui-la.

Uma das implementações mais conhecidas é o Apache TomEE, que consiste em Jakarta EE e MicroProfile no Apache Tomcat.

Como David Blevins (um nome muito importante no mundo open source, CEO da Tomitribe e um dos fundadores do Apache TomEE) declarou no blog da Tomitribe, a primeira versão do TomEE, anunciada em 2011, era uma distribuição de 30 MB que inicializava em um segundo, rodava por padrão com uma configuração de 64 MB de heap e passava no Java EE 6 Web Profile TCK em centenas de servidores t1.micro no Amazon EC2. Para David, isso foi um prenúncio do movimento dos microsserviços.

A Era dos Microsserviços

A arquitetura de microsserviços chegou, rapidamente se tornou um hype, e as empresas estavam resolvendo os mesmos problemas cada uma à sua maneira. Isso despertou a necessidade de um padrão.

Mas sabemos que em Engenharia de Software toda solução tem um ponto negativo e o uso de um padrão não é diferente. A sua criação pode levar muito tempo.

Foi então que, em 2016, com o apoio da Comunidade Java e de empresas como RedHat, IBM, Tomitribe, Payara e LJC, foi criado o MicroProfile, definido no site oficial como uma definição de plataforma básica que otimiza o Java Enterprise para a arquitetura de microsserviços e entrega portabilidade de aplicativos em vários runtimes de MicroProfile. Sua abordagem permite fornecedores, a comunidade, e projetos de código aberto inovarem enquanto colaboram onde há algo em comum. Isso ocorrerá em um ritmo muito mais rápido do que um padrão.

Especificações

No momento em que esta postagem é escrita, o MicroProfile 3.3 tem 12 especificações:

  1. MicroProfile Config
  2. Usada para injetar propriedades de configuração de fontes externas, como arquivos de propriedades e variáveis de sistema ou de ambiente
  3. Contexts and Dependency Injection (CDI)
  4. Usada para fornecer um mecanismo type-safe de injeção de dependência
  5. MicroProfile Fault Tolerance
  6. Usada para fornecer um conjunto de estratégias para construir serviços resilientes e tolerantes a falhas
  7. MicroProfile Health
  8. Usada para adicionar verificações de atividade e prontidão para determinar a integridade da aplicação
  9. Jakarta RESTful Web Services (JAX-RS)
  10. Usada para desenvolver web services seguindo o padrão REST
  11. JSON Binding (JSON-B)
  12. Usada para converter objetos Java de e para JSON
  13. JSON Processing (JSON-P)
  14. Usada para processar mensagens JSON (analisar, gerar, transformar e consultar)
  15. MicroProfile JWT Auth
  16. Usada para fornecer autenticação baseada em token JWT
  17. MicroProfile Metrics
  18. Usada para adicionar métricas personalizadas, como cronômetros ou contadores, à aplicação e expô-los via HTTP
  19. MicroProfile OpenAPI
  20. Usada para fornecer uma API Java unificada para a especificação OpenAPI v3 para expor a documentação da API
  21. MicroProfile OpenTracing
  22. Usada para fornecer rastreamento distribuído para uma aplicação JAX-RS usando o padrão OpenTracing
  23. MicroProfile Rest Client
  24. Usada para fornecer clientes type-safe para invocar RESTful Web Services

Runtimes Compatíveis

No momento desta postagem, o MicroProfile Starter lista 9 runtimes compatíveis com MicroProfile que você pode usar para executar suas aplicações e você é livre para escolher qualquer um deles.

  • Apache TomEE
  • Helidon
  • KumuluzEE
  • Open Liberty
  • Payara Micro
  • Quarkus
  • Thorntail
  • WildFly
  • WildFly Swarm

Conclusão

Quando usamos MicroProfile, somos livres para escolher qualquer implementação compatível e o slogan “Write once, run anywhere” torna-se relevante novamente. Ser capaz de migrar nossas aplicações para diferentes runtimes nos dá a liberdade de escolher o melhor fornecedor para nossas necessidades e, quando não estivermos mais satisfeitos, ou se surgir um melhor, podemos simplesmente trocá-lo, já que não estamos aprisionados a nenhum deles.

Além disso, o MicroProfile tem uma comunidade engajada que aprimora continuamente a plataforma e trabalha em problemas comuns que todos nós teríamos que resolver por nós mesmos, como configuração, métricas, verificação de integridade ou rastreamento. Dessa forma, podemos nos concentrar no que importa ao escrever uma aplicação: a lógica de negócio.

Para participar, você pode entrar na discussão e contribuir de várias maneiras, como por exemplo, dando feedback, compartilhando suas necessidades, propondo novos recursos ou especificações e até corrigindo bugs. A plataforma é feita pela e para a comunidade.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *