BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Cloud-native com Payara e Platform.sh

Cloud-native com Payara e Platform.sh

Lire ce contenu en français

Favoritos

A tecnologia está cada vez mais presente em nossas vidas e em todos os lugares, fazendo com que negócios estejam cada vez mais integrados entre os usuários e as aplicações. Em um mundo cada vez mais conectado, desafios como escalabilidade, produtividade e entrega rápida de qualidade, estão cada vez mais presentes em qualquer empresa, uma vez que, segundo a Forbes, todas as empresas são de software. Para tornar tudo isso possível, novos conceitos são criados, dentre eles, o cloud e o microservices, que vem se tornando expressões cada vez mais corriqueiras nas reuniões de arquitetura. Então, surge a seguinte pergunta: Será que o Java está preparado para lidar com esses diversos conceitos em um ambiente corporativo? A resposta é sim.

Nos últimos anos, a Eclipse Foundation vem conduzindo esse desafio em conjunto com outros membros da comunidade, além de diversas empresas do setor, para fazer o mundo Java cada vez mais atualizado e preparado, tanto para microservices, quanto para utilizar os recursos cloud. Dentre os esforços, podemos citar o Jakarta EE, que é o novo lar do Java EE, que tem como objetivo ser cloud native, além do Eclipse MicroProfile, que é uma plataforma otimizada para lidar com arquiteturas de microservices.

O que é a nuvem?

O software está em toda parte. Não importa para onde olhamos, há um software em execução. Na história humana, vimos o número de máquinas/software aumentar com o tempo, de uma máquina compartilhada por várias pessoas a uma única pessoa usando milhares de programas de software. Agora, podemos ver o software interagindo com outro, como quando compramos uma passagem aérea: Um sistema envia um email, outro lê e dispara um evento em nosso calendário. Essa nova abordagem abre mais perspectivas e oportunidades de negócios para todos, incluindo o aprendizado de máquina. Não se engane, a Skynet está chegando em breve.

O nascimento do Agile

Não é apenas a quantidade de software que aumentou, mas também o número de interações nos programas. Mais usuários, mais requisitos, mais feedback. Não faz sentido esperar anos para lançar um produto, o tempo de colocação no mercado e o feedback do usuário são vitais para conduzir o produto na direção certa. Por isso, em 2001, um pequeno grupo de pessoas, cansado da abordagem tradicional de gerenciar projetos de desenvolvimento de software, projetou o Manifesto Agile, que deu origem à metodologia Agile.

O Agile é um processo que ajuda as equipes a fornecer respostas rápidas e imprevisíveis usando o feedback que recebem do projeto. Cria oportunidades para avaliar a direção de um projeto durante o ciclo de desenvolvimento. As empresas avaliam o projeto em reuniões regulares chamadas sprints ou iterações. Em um aspecto mais técnico alinhado ao Agile, a abordagem DDD (Domain-Driven Design) ajuda a desenvolver softwares focados nas necessidades complexas que conectam profundamente a implementação a um modelo em evolução dos principais conceitos de negócios. Técnicas como a linguagem ubíqua são usadas para ter o código mais próximo do negócio, diminuindo a barreira entre o desenvolvedor e o usuário e, portanto, tendo mais interações do que com o desenvolvimento ágil.

Microservices

Cada vez mais empresas entendem que todas as empresas são empresas de software. Como resultado, dependem fortemente dos softwares, e frequentemente precisam contratar desenvolvedores de software. Surge então a questão de como lidar com várias pessoas que trabalham em apenas um projeto. Para resolver essa nova questão, podemos olhar para uma antiga estratégia militar romana: Dividir e conquistar. Sim, dívida uma questão altamente complexa em pequenos blocos de problemas, dívida a equipe em pequenos grupos e divida o projeto monolítico em vários pequenos projetos. O estilo arquitetural de microservice é uma abordagem para o desenvolvimento de uma única aplicação em um conjunto de pequenos serviços, para que, ao invés de uma empresa de comércio eletrônico trabalhar com apenas uma base de código e uma implementação, possa dividir as equipes/código em financeiro, estoque de produtos, marketing e assim por diante. Uma coisa a salientar, o contexto DDD ainda está lá. De fato, ele trabalha junto com a abordagem de como criar serviços úteis com base em alguns de seus conceitos limitados. Não estamos descartando ou deixando de lado essa noção, mas agregando-a em microservices.

Os microservices, além de tornar a equipe mais ágil, também trazem várias vantagens, como expansão independente e liberação de serviços discretos. No entanto, ele carrega algumas desvantagens no lado das operações. O código finalizado não é suficiente se não for para produção. Portanto, as operações devem seguir a equipe de desenvolvimento para liberar o que o sistema precisa implantar todos os dias. É por isso que: O DevOps é um conjunto de práticas de desenvolvimento de software que combinam operações de desenvolvimento de software (Dev) e operações de tecnologia da informação (Ops) para reduzir o ciclo de vida de desenvolvimento de sistemas, ao mesmo tempo em que fornecem recursos, correções e atualizações com frequência em alinhamento com os objetivos dos negócios.

Com as equipes de desenvolvimento e operações integradas e trabalhando em conjunto com a metodologia DevOps, estamos prontos para lidar com software e suas operações. Mas e o hardware? Integrar a equipe significa que o equipamento não existe. O que acontece quando uma equipe precisa de mais processamento do computador? Faz sentido alguém comprar um novo servidor? Não é rápido o suficiente. No mercado global e com a batalha de milissegundos para obter menos tempo de resposta, um servidor mais próximo do cliente significa menos tempo de produção, mas como compramos/mantemos os servidores em vários continentes?

Com a computação em nuvem disponível sob demanda para recursos de sistema de computador, especialmente armazenamento de dados e poder de computação, sem gerenciamento ativo direto do usuário, a computação em nuvem significa: Não nos importamos com o próprio hardware. Esses serviços são amplamente divididos em três categorias: Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS) e Software como Serviço (SaaS).

Essas categorias trazem um novo conceito de negócio ao mercado. Além disso, cada serviço traz novas instalações, principalmente de entrega rápida.

Há um artigo fantástico que explica os benefícios da computação em nuvem com a comida mais popular e deliciosa do mundo, isso mesmo, a pizza!

Benefícios do IaaS

  • Não há necessidade de investir em próprio hardware;
  • Escala de infraestrutura sob demanda para suportar cargas de trabalho dinâmicas.

Benefícios do PaaS:

  • Desenvolva aplicações e chegue ao mercado mais rapidamente;
  • Reduza a complexidade com o middleware como serviço.

Benefícios do SaaS:

  • Aplicações e dados são acessíveis a partir de qualquer computador conectado;
  • Nenhum dado será perdido se o laptop quebrar porque as informações estão na nuvem.

Um projeto de software precisa possuir entrega rápida como a melhor abordagem estratégica. Uma entrega rápida traz vários benefícios, como receber feedback, corrigir bugs e principalmente conduzir o produto na direção certa, com base nas necessidades do usuário. É por isso que várias metodologias e tecnologias como Agile, microservices, DevOps e a nuvem, nasceram. Hoje em dia, é difícil pensar em esperar um ano para lançar um projeto, correndo o risco de perder o timing do mercado. A comunidade Java decidiu lançar um release a cada seis meses, e o Jakarta EE busca o mesmo caminho. O Platform.sh tem o objetivo de facilitar a transferência do projeto para a computação em nuvem, permitindo a implantação em qualquer lugar e a qualquer hora, inclusive em uma sexta-feira ensolarada.

O que é o Cloud Native?

A computação em nuvem trouxe muitas metodologias e técnicas que revolucionaram os mundos comercial e técnico. Entre os termos que surgiram, nasceu o cloud native. Para atender e cobrir essas expectativas no universo Java, nasceu o Jakarta EE.

Como qualquer novo conceito, existem vários conceitos com o mesmo nome. Se lermos os livros ou artigos sobre cloud native, poderemos não encontrar consenso sobre o termo. Por exemplo:

"Cloud-native é uma abordagem para criar e executar aplicações que explora as vantagens do modelo de computação em nuvem". -Pivotal

"Cloud-native é uma maneira diferente de pensar e raciocinar sobre sistemas de software. Ele incorpora os seguintes conceitos: Alimentado por infraestrutura descartável, composta por limites, escalas globalmente, adota a arquitetura descartável". - Architecting Cloud Native Applications

"De maneira geral, "cloud-native" é uma abordagem para criar e executar aplicações que explora as vantagens do modelo de entrega de computação em nuvem. "Cloud-native" é sobre como os aplicações são criados e implantados, não onde." - InfoWorld

"As tecnologias cloud-native capacitam as empresas a criar e executar aplicações escaláveis em ambientes modernos e dinâmicos, como públicos, privados, e nuvens híbridas. Containers, service meshes, microservices, infraestrutura imutável e APIs declarativas exemplificam essa abordagem"

Cloud-Native Computing Foundation

Uma abordagem que gosto é que uso com base nesses livros e artigos é:

Um conjunto de boas práticas para otimizar uma aplicação na nuvem por meio de:

  • Containerização;
  • Orquestração;
  • Automação.

Em um consenso mútuo em torno das definições de vários artigos, podemos dizer que o cloud native é um termo usado para descrever ambientes baseados em containers. Portanto, o cloud native não está relacionado a linguagens ou estruturas de programação específicas ou mesmo a uma empresa provedora de nuvem, mas a containers, porém, não limitado a isso.

O que são as melhores práticas do cloud native?

Quando começamos a aprender um novo conceito, geralmente corremos para ler sobre as práticas recomendadas para evitar erros e qualquer code smell. Com a Programação Orientada a Objetos (POO), temos os padrões do gang of four, e no Java, temos o Effective Java e, ao falar sobre arquitetura, temos o Código Limpo e a Arquitetura Limpa. Portanto, a pergunta é: Quais são as melhores práticas para o cloud native?

Até onde sabemos, não existem práticas recomendadas relacionadas especificamente ao cloud native. Mas como a nuvem está próxima da metodologia Agile, há várias práticas que podemos aproveitar para ter uma aplicação saudável e indolor:

As práticas mais conhecidas relacionadas a qualquer aplicação que inclua computação em nuvem são inspiradas nos padrões de arquitetura e refatoração de aplicações corporativas de Martin Fowler.

The Twelve-Factor App

I. Base de Código

II. Dependências

III. Configurações

IV. Serviços de Apoio

V. Construa, lance, execute

VI. Processos

VII. Vínculo de porta

VIII. Concorrência

IX. Descartabilidade

X. Dev/prod semelhantes

XI. Logs

XII. Processos de Admin

Em resumo, ainda não existem práticas específicas recomendadas para o cloud native, mas existem padrões do Agile, microservices e a aplicação dos doze fatores que são úteis para seguirmos.

Olá mundo com Payara Micro e Platform.sh

Nesta seção, mostraremos como criar o nosso primeiro projeto REST com o Payara Micro e, em seguida, como mover esse projeto para o Platform.sh usando o Maven Archetype, que é um kit de ferramentas de modelagem de projeto Maven. Um arquétipo é definido como um padrão ou modelo original a partir do qual todas as outras coisas do mesmo tipo são feitas. Podemos gerá-lo com o seguinte comando:

mvn archetype:generate -DarchetypeGroupId=sh.platform.archetype   -DarchetypeArtifactId=payara  -DarchetypeVersion=0.0.1  -DgroupId=my.company  -DartifactId=hello -Dversion=0.0.1 -DinteractiveMode=false

O próximo passo é convertê-lo em um projeto Git, portanto:

cd hello
git init
git add .
git commit -m "hello world with Payara"

Finalmente, vamos criar um novo projeto no Platform.sh, pegue o endereço do repositório git e envie o código para o mestre. Assim que fizemos o push do código para o domínio, será gerará os containers necessários para disponibilizar a nossa aplicação.

git remote add cloud <platform.sh-git-address>
git push cloud master

Assim que fizermos o push do código para removê-lo, o mesmo criará a compilação do Maven e implantará a aplicação. No final, será gerado o endereço IP, que será pego por esse endereço e será feito uma solicitação no servidor.

curl <ip_server>
 hello from Platform.sh

O arquétipo do Maven que geraremos inclui as dependências do Maven e os três arquivos que o Platform.sh requer para mover essa aplicação para a nuvem. Agora, vamos aprofundar este arquivo e falar sobre os componentes, um por um. Para explicar melhor, esses arquivos representam o conceito de infraestrutura como código, ou seja, o processo de gerenciar e provisionar data centers de computadores por meio de arquivos de definição legíveis por máquina.

name: app
type: "java:8"
disk: 1024
hooks:
    build:  mvn -DskipTests clean package payara-micro:bundle
web:
    commands:
        start: java -jar -Xmx512m target/microprofile-microbundle.jar --port $PORT

O arquivo da aplicação possui a configuração para criar o container da aplicação. A construção é definida por um comando Maven que cria um uberjar. Para criar o container da aplicação, o arquivo possui os seguintes atributos:

  • nome (obrigatório) - define o nome exclusivo do container da aplicação;
  • tipo (obrigatório) - define a imagem base do container a ser utilizada, incluindo o idioma da aplicação e sua versão;
  • disco e montagens (obrigatório) - Define os diretórios de arquivos graváveis para a aplicação;
  • Construção e dependências- Controla como a aplicação é compilada. Precisamos observar que essas compilações ocorrem antes que a aplicação seja copiada em diferentes instâncias. Portanto, todas as etapas aqui serão aplicadas a todas as instâncias da web e local;
  • web - Controla como a aplicação da web é servida.

Muito mais!

Platform.sh e Payara criaram um guia útil para falar sobre Jakarta EE e cloud native.

Nesse guia teremos;

  • Definições de cloud-native
  • Hello World com Payara Micro e Platform.sh
  • Payara Platform com JPA
  • Payara Platform com NoSQL
  • Payara Micro, Platform.sh e Microservices

Clique no link para saber mais: https://www.payara.fish/page/payara-platform-and-paas-with-platform-sh/

Com isso foi possível criar uma aplicação Jakarta EE e movê la para nuvem de uma maneira bastante simples e sem se preocupar com toda a complexidade de infraestrutura. Como já mencionamos, apesar de existirem diversos artigos, livros e uma fundação, ainda não existe uma versão "final" definindo o cloud-native, porém, muitas empresas, comunidades e indivíduos estão trabalhando e focando em criar aplicações que tiram cada vez mais proveito da aplicação em nuvem. Um ponto muito interessante desse livro que reúne vários conceitos e práticas para confirmar que é possível criar uma aplicação cloud-native através to Payara e com Platform.sh.

Sobre o autor

Otávio Santana é engenheiro de software, com grande experiência em desenvolvimento opensource, com diversas contribuições ao JBoss Weld, Hibernate, Apache Commons e outros projetos. Focado em desenvolvimento poliglota e aplicações de alto desempenho, Otávio trabalhou em grandes projetos nas áreas de finanças, governo, mídias sociais e e-commerce. Membro do comitê executivo do JCP e de vários Expert Groups de JSRs, é também Java Champion e recebeu os prêmios JCP Outstanding Award e Duke's Choice Award.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT