Red Hat Summit 2017 - Visão Geral

Red Hat Summit 2017

Visão Geral:

O evento frisa bastante que a prioridade é o desenvolvimento e também é bastante frequentado por desenvolvedores. Porém, assuntos relacionados a isso são poucos, sendo a grande maioria das novidades e conversas voltadas a infraestrutura.
A infraestrutura como conhecemos não é nem comentada mais. Virtualização parece um conceito ultrapassado pela novidade dos containers. No entanto, ela não se tornou menos importante, talvez seja até o contrário, pois com recursos pequenos, mas mais abundantes, a inteligência necessária para a administração é ainda maior e focada principalmente na prevenção de incidentes através da monitoração.
De forma geral, a participação no evento foi muito importante, porque os assuntos abordados ratificaram que, ao olharmos para micro serviços, desacoplamento, escalabilidade, entre outros, estamos olhando para a direção certa e esses assuntos foram embasados pelos engenheiros da Red Hat e pela comunidade como um todo.

Tecnologia:

A grande “estrela” do evento apresentada pela Red Hat foi o OpenShift.io.
Fica claro que todo o esforço e estratégia estão sendo direcionados a ele e as ferramentas que o incrementam ou complementam, como soluções de monitoramento, log, segurança, rastreabilidade, billing etc.
Entre os vários recursos apresentados da ferramenta, alguns chamaram mais atenção:
  • Desenvolvimento no browser – O Desenvolvedor tem no próprio OpenShift.io, tudo o que ele precisa para o seu desenvolvimento. (IDE, configuração de workspace, jars etc) e ele acessa tudo isso através do próprio browser, tornando a necessidade um notebook parrudo mais irrelevante e economizando boas horas com esse tipo de configuração que hoje deve ser feita a cada estação de trabalho.
  • Ambientes iguais. – O profissional desenvolve e publica em um ambiente exatamente igual aos de teste, homologação e produção. Esse cenário ajuda a mitigar problemas de diferenças de ambiente e erros humanos, além de diminuir as horas de teste.
  • Pipeline de publicação – Uma vez que o OpenShift trabalha com o Jenkins (ferramenta de publicação) por baixo, é possível, de forma bastante visual, criar pipelines de publicação específicos por aplicação, inclusive, incluindo aprovações de gestores ou responsáveis. Isso possibilita promover a aplicação de desenvolvimento para produção em segundos, já com testes integrados e rastreabilidade.
  • Integração com AWS – A Red Hat integrou o OpenShift.io com os serviços da Amazon. Dessa forma, agora é possível provisionar ambientes na própria AWS através de seu portal de administração de forma transparente. A “unificação” das clouds, facilita a administração e aumenta a flexibilidade no provisionamento, além do número de serviços provisionáveis.
Por enquanto, o ponto negativo, mas compreensível, é que a plataforma, por ser lançamento, só está disponível na versão SaaS. Ainda não há previsão para a versão on premisse, mas há a certeza que ela existirá.
Além do OpenShift.io, também foi apresentado o Atomic Host, que nada mais é do que o conceito de DevOps e micro serviços aplicado no próprio sistema operacional. Isso quer dizer que, diferentemente das versões tradicionalmente robustas de S.O., o Atomic Host possui apenas as libs e funcionalidades necessárias para um determinado contexto. Na prática, isso quer dizer que você pode possuir uma versão de S.O. sem nem mesmo os comandos básicos, como o ipconfig, caso ele não seja necessário.

Stands:

A grande maioria dos stands do evento, foi focada no conceito de containers, mas não mais na implementação deles e sim, na parte de monitoramento, mapeamento de dependências, logging, debbugging e todo o resto que os cerca para facilitar a sua administração.
Nesse sentido, ferramentas como o BlackDuck, Sysdig, e Dynatrace foram algumas das visitadas no evento.

Empresas:

A princípio, entendo que, por ser apenas na nuvem, o OpenShift.io ainda não seja implementável em algumas empresas, porém, é questão de tempo para que a solução tenha sua versão on premisse. Apesar de não ter data definida para isso, é bom deixarmos no radar.
No entanto, com relação ao Atomic Host, acredito que a adoção será natural, à medida que a utilização de containers começar a acontecer.
Hoje, imagino que o próximo, principal e desafiador passo, seja a definição de uma arquitetura de micro serviços. Mais do que a definição da linguagem ou do framework, que de certa forma se torna menos relevante, uma vez que qualquer serviço, independentemente da linguagem, retornará a mesma resposta, no mesmo formato, precisamos definir como funcionará o modelo de dados, versionamento das imagens dos containers (infra como código), ferramentas de publicação, segurança dos containers, ferramentas de centralização de logs.
Dentre os pontos citados acima, o mais abordado no evento e apontado como o mais desafiador foi a modelagem de dados.
Isso porque, conceitualmente, cada micro serviço deve ter seu próprio banco de dados, sendo esse banco todo definido pelo desenvolvedor. Isso faz com que você tenha o mesmo cliente, em diferentes bases, com id’s diferentes, por exemplo. Dessa forma, o mapeamento de dependências é extremamente importante para garantir a integridade dos dados de uma transação do início ao fim.

Conclusão:

O evento corroborou a nossa visão de futuro para a T.I. muito mais com a apresentação de conceitos, dificuldades em suas implementações e formas de facilitar a transação do modelo monolítico para o micro serviço do que propriamente com novidades tecnológicas.

Por Rodrigo Manfrini

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Como instalar Servidor Web Apache no Ubuntu e Debian