Transforme os negócios com microsserviços e contêineres.

Microsserviços – A história da computação é pontuada por um conjunto de mudanças sísmicas nas arquiteturas de TI da empresa.

Aplicativos monolíticos e altamente integrados movidos para pilhas de software integradas e arquiteturas de “N” camadas.

A computação distribuída também passou por várias encarnações. Houve várias tentativas de padronizar as comunicações entre aplicativos, como chamadas de procedimento remoto no Unix, modelo de objeto distribuído, arquitetura de agente de solicitação de objeto comum e serviços da web.

Todos tentaram promover a reutilização de código, publicar e compartilhar interfaces de programação de aplicativos (APIs) em uma tentativa de evitar que os programadores tenham que “reinventar a roda”.

Desde meados dos anos 2000, graças ao crescimento do JavaScript em servidores e servidores de aplicativos Java, a arquitetura orientada a serviços (SOA) surgiu como a nova campeã de integração corporativa.

Como seus antecessores, esse modelo de computação distribuída foi projetado antes da era da computação nativa em nuvem. As empresas construídas na nuvem adotaram uma abordagem muito diferente, baseada na ideia de contêineres e microsserviços pouco acoplados.

Agora, graças ao sucesso do Docker e do Kubernetes, mais empresas estão procurando implementar contêineres. A razão para a popularidade dessa abordagem é que ela ajuda as empresas a desenvolver aplicativos nativos da nuvem, que podem ser entregues rapidamente para impulsionar iniciativas de transformação digital.

Plataformas de contêineres corporativos da Forrester, Agora, Q2 2018 : “Tecnologias centradas em contêiner, orientadas a microsserviço e nativas em nuvem orquestradas dinamicamente ajudam as empresas a criar aplicativos e serviços altamente diferenciados que criam experiências atraentes para os clientes. Eles rapidamente se tornaram elementos importantes da transformação dos negócios digitais, já que prometem acelerar a entrega de software e melhorar a escala, flexibilidade, flexibilidade e implementação”.

Movendo-se para uma abordagem ágil com contêineres.

O Red Hat OpenShift é uma das principais plataformas de contêineres corporativas identificadas no relatório da Forrester. Negócio global de análise de informações A Elsevier está entre as empresas que usam o produto Red Hat enquanto ele digitaliza seus negócios.

Como muitas organizações, a Elsevier começou com uma SOA e usou contêineres como uma forma de tornar o desenvolvimento de software mais ágil.

Tom Perry, diretor de engenharia de software da Elsevier, diz que a empresa começou com uma SOA tradicional, que não suportava muito bem o negócio. “Quando ingressei em 2015, estávamos usando uma arquitetura SOA parcialmente preparada. Não era muito estruturado e era proprietário”, diz ele.

Isso significava que era difícil para as equipes de software da Elsevier criar componentes reutilizáveis, o que reduziu o ritmo das mudanças. “Tivemos uma aplicação monolítica – um grande negócio – e foi uma grande jogada quando você quis adaptá-la”, acrescenta Perry.

Na época, a empresa estava mudando de vender conteúdo para vender serviços além do conteúdo. Além da mudança nos negócios, a Elsevier também estava mudando sua abordagem para a TI, fechando seu datacenter e passando para a nuvem da Amazon Web Services (AWS).

Perry diz que queria uma arquitetura que funcionasse com a evolução do negócio. “Em vez de observar como os aplicativos interagem, queríamos ter acesso a dados nos processos de negócios de ponta a ponta”, diz ele. Para conseguir isso, a Elsevier precisava de um acoplamento flexível entre sistemas internos e de software como serviço (SaaS), como o Salesforce.

Como as plataformas de contêineres estão em constante evolução, Perry diz que a Elsevier inicialmente tentou o Red Hat Fuse para migrar da SOA para uma arquitetura de contêiner híbrida. No entanto, ele diz: “Nós poderíamos ver onde as coisas estavam indo, mas a tecnologia não estava madura o suficiente para a empresa“.

Além da tecnologia em constante evolução, a Elsevier também teve que passar por uma curva de aprendizado. Uma das lições aprendidas das tentativas iniciais da empresa de implantar contêineres era que as APIs e os serviços expostos exigiam muita segurança. “Deveríamos ter segurança dissociada”, acrescenta Perry.

Se o Red Hat Fuse não estivesse funcionando, o que mais? Embora seja possível construir plataformas de nuvem empresariais completas a partir de componentes de código aberto, como o Kubernetes, Perry ressalta que o Kubernetes é apenas o bit no meio. “Você precisa construir serviços em torno de Kubernetes“, diz ele. A Elsevier queria um único produto, por isso selecionou a Red Hat OpenShift Container Platform. “Temos uma plataforma all-in-one, que nos permite pegar nosso código e implantá-lo em outra plataforma”, acrescenta Perry.

O primeiro sistema a usar a nova plataforma foi o sistema de marketing e publicidade da empresa, que usava software no local e SaaS. Descrevendo a configuração, Perry diz: “Procuramos fornecer acesso a dados corporativos e expor um conjunto de APIs corporativas para reutilização futura“.

Ao contrário da tentativa da empresa com a Red Hat Fuse, ele diz que a arquitetura é baseada em microsserviços sendo executados em contêineres. Estes executam apenas funções lógicas, portanto, não há sobrecarga de segurança adicional para se preocupar. “Usamos um gateway de API para gerenciar a segurança, para que os serviços não precisem se preocupar com a segurança“, acrescenta Perry.

Lições aprendidas

Além de sua experiência com a integração de segurança nas APIs, Perry acredita que os contêineres não são adequados para todos os tipos de aplicativos e cargas de trabalho. “Nem sempre é a escolha certa para usar recipientes“, diz ele.

Um exemplo de quando não usar contêineres inclui ao tentar executar um servidor de aplicativos ou um servidor de banco de dados em um contêiner, o que envolverá código monolítico. De acordo com Perry, não há grandes benefícios obtidos ao tentar conter esses aplicativos monolíticos como serviços pesados.

Outra vantagem do uso de contêineres na Elsevier é que nem todas as partes da empresa estão prontas para computação nativa na nuvem. As metodologias de desenvolvimento ágil são frequentemente associadas a uma abordagem nativa em nuvem para o desenvolvimento de aplicativos.

Embora a Elsevier tenha começado a usar abordagens ágeis em alguns de seus projetos de desenvolvimento, Perry acrescenta: “Existem velocidades diferentes em toda a organização. Alguns serviços podem funcionar de maneira ágil, mas outros, como nosso Oracle eBusiness Suite, não podem.”

Alocar custo é outra área problemática para TI, na experiência de Perry. “Ainda não descobrimos como distribuir o custo na área de integração em uma função compartilhada”, diz ele.

Desafios da conformidade

O DevOps geralmente anda de mãos dadas com metodologias ágeis de desenvolvimento de software, dando liberdade às equipes para desenvolver e implantar código rapidamente.

Mas, em uma arquitetura nativa da nuvem construída de contêineres que executam microsserviços, a velocidade e a agilidade não estão isentas de riscos, de acordo com Jonathan Hotchkiss, chefe de engenharia de confiabilidade de serviços em nuvem do serviço de empréstimo de dinheiro, WorldRemit .

Como a empresa construiu seu sistema de pagamento sem servidor usando microsserviços, a capacidade de entender tudo o que estava acontecendo tornou-se cada vez mais difícil, diz Hotchkiss. “A menos que seja feito corretamente, o dinheiro é desperdiçado fazendo DevOps porque os sistemas são construídos e esquecidos, ou o código é ampliado além de sua capacidade usando a nuvem“, diz ele, significando que, na verdade, esse código não é escrito para dimensionar com eficiência.

Ele diz que a plataforma original da empresa começou como uma arquitetura clássica de web e-commerce usando um banco de dados monolítico. “Não era a melhor arquitetura para escalabilidade, então começamos a extrair partes e desenvolvê-las como microsserviços, usando a PaaS do Azure [plataforma como um serviço]”, acrescenta.

Infelizmente, o WorldRemit não conseguiu documentar completamente todos os microservices que estão sendo desenvolvidos. Isso foi parcialmente devido à cultura do time.

As equipes de desenvolvimento de software da empresa foram transitórias, com equipes com duração entre 18 e 24 meses. “Nenhuma equipe teve uma ideia completa de todos os microsserviços. Nós não sabíamos como tudo funcionava”, acrescenta Hotchkiss.

O WorldRemit selecionou o Dynatrace para fornecer um painel, que forneceu uma visão topológica de todos os componentes do sistema. “Quando algo é quebrado, a Dynatrace destaca o que é e o que não é bom e nos dá uma resposta inteligente do motivo de uma falha“, diz Hotchkiss.

Equilibrar a conformidade ao dar às equipes de DevOps a liberdade de trabalhar com eficiência é sempre um desafio. Como a WorldRemit descobriu, sem algum nível de controle – a como a necessidade de as equipes documentarem seu trabalho completamente – a arquitetura nativa da nuvem pode se tornar rapidamente incontrolável.

A aplicação rigorosa de regras, procedimentos e políticas corporativas pode limitar a flexibilidade, mas às vezes pode ser melhor incentivar o uso de ferramentas e estruturas preferenciais usando as comunidades de melhores práticas.

Por exemplo, a Porsche Informatik estabeleceu comunidades de engenheiros que promovem as melhores práticas que são então enviadas de volta às equipes de DevOps.

A Porsche Informatik tenta fazer com que suas ferramentas e estruturas sejam tão fáceis de usar quanto possível, para que elas se tornem a primeira escolha para as equipes de DevOps.

Falando no evento NewStealth FutureStack em Londres, James Governor, co-fundador do analista RedMonk , discutiu como as arquiteturas nativas da nuvem mudaram a forma como os aplicativos são depurados. Na época, ele disse: “[Precisamos] construir aplicativos de uma maneira que possam ser gerenciados com eficácia. Estamos mudando para um ambiente quando temos que depurar a produção, o que exige observabilidade.”

De acordo com o Governador, o rastreamento, o registro e o monitoramento do desempenho de aplicativos (APM) estão sendo aproveitados para lidar com problemas no código de produção.

Dos negócios que a Computer Weekly falou, parece que eles estão aprendendo como se desenvolver em um mundo de computação sem servidor, microsserviços, containers e DevOps.

Se o Governador estiver certo, mais empresas precisarão se adaptar para começar a testar o código em seus ambientes de produção ao vivo.

Como o WorldRemit descobriu, é necessário entender como os microsserviços estão evoluindo nos negócios. E embora as ferramentas e as linguagens de programação e estruturas que os desenvolvedores adotem possam se resumir a escolhas pessoais, ter membros-chave da equipe de DevOps envolvidos nas melhores práticas – como é o caso da Porsche Informatik – pode ajudar a consolidar padrões e ferramentas preferenciais em projetos.

Tem algo a dizer sobre este artigo? Comente abaixo ou compartilhe conosco no Facebook, Twitter ou no nosso LinkedIn.

Leia também:
– A replicação não protegerá as VMs contra o ransomware.
– Novo bug do Kernel do Linux afeta as distribuições Red Hat, CentOS e Debian.
– Pesquisa revela a adoção lenta da computação na nuvem nas empresas entre executivos de TI.