Conteúdo


Microsserviços em ação, Parte 2

Contêineres e microsserviços — um par perfeito

Por que componentes de aplicativos menores e mais rápidos podem ser entregues mais facilmente do que nunca

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Microsserviços em ação, Parte 2

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Microsserviços em ação, Parte 2

Fique ligado em conteúdos adicionais dessa série.

Na Parte 1 desta série, eu falei sobre o que são exatamente microsserviços e como eles diferem dos sistemas desenvolvidos tradicionalmente (monólitos). Esta segunda parte do artigo é sobre o poder dos contêineres Linux — como eles estão revolucionando o desenvolvimento de software e capacitando microsserviços para transformar um segmento de mercado inteiro. Mencionarei três conceitos que são fundamentais para serem focados ao se adotar infraestrutura baseada em contêiner para seus aplicativos baseados em microsserviço:

  • Criação de log e monitoramento
  • Entrega contínua sem interrupção
  • Registros de serviço dinâmicos

Eu iniciarei com uma visão geral de contêineres, gerentes de contêiner e como contêineres se relacionam com microsserviços.

Contêineres e microsserviços: Um par perfeito

A menos que a tecnologia de nuvem e o desenvolvimento de aplicativo nativo em nuvem sejam completamente novos para você, provavelmente terá ouvido falar sobre contêineres Linux e os projetos baseados em contêiner que foram um sucesso nos últimos anos. Mas, caso você não tenha, pense nos contêineres Linux como máquinas virtuais leves que podem ser usadas com mais flexibilidade, integradas mais rapidamente e distribuídas muito mais facilmente. Um dos projetos liderando este movimento é o Docker. Desde seu lançamento em 2012, a equipe do Docker (e agora a empresa) tem fornecido uma maneira muito simples de construir, empacotar e distribuir aplicativos nativos da nuvem via contêineres Linux.

Como contêineres diferem de máquinas virtuais? Cada máquina virtual (ilustrado no lado esquerdo da imagem a seguir) executa sua própria instância do sistema operacional guest e contém suas próprias bibliotecas e binários. Os contêineres (mostrados à direita) são isolados, compartilhando o S.O. e as bibliotecas do host subjacente, enquanto empacotam somente os binários de aplicativos necessários.

A conceptual view of the technical differences between virtual machines and Linux containers
A conceptual view of the technical differences between virtual machines and Linux containers

Muitos líderes de segmento de mercado estão mudando para uma infraestrutura baseada em contêiner, na nuvem e no local, para ganhos extremos.

Os contêineres são executados como um conjunto mínimo de recursos no topo de sistemas Linux, e geralmente o aplicativo empacotado não é maior do que algumas centenas de megabytes. Aplicativos baseados em máquina virtual ,geralmente, são pelo menos de três a quatro ordens de magnitude maiores (dezenas de gigabytes). É possível ver facilmente como os contêineres se ajustam no paradigma do microsserviço, sendo menores e mais rápidos— dois dos princípios do microsserviço da Parte 1.

Muitos líderes de segmento de mercado estão mudando para uma infraestrutura baseada em contêiner, na nuvem e no local, para ganhos extremos. Um dos principais ganhos é que o Docker e outras tecnologias de contêiner Linux semelhantes são fáceis de integrar nos pipelines de integração contínua e entrega contínua: Em média, os usuários do Docker enviam software sete vezes mais frequentemente, de acordo com um estudo recente do Docker com recursos próprios. Empresas como a Gilt Groupe aderiram aos microsserviços e infraestrutura em contêineres, enviando software mais de 100 vezes por dia, em algumas ocasiões. A capacidade de realizar o push do código muda rapidamente, reconstrua automaticamente as imagens do Docker que são de tamanho mínimo e gerencie um grande número dessas imagens implementadas a partir de resultados de base de código comum, em velocidade impressionante, por meio do pipeline de entrega de uma empresa.

Um dos outros benefícios de contêineres do Docker é a portabilidade destes aplicativos empacotados, chamada de imagens do Docker. As imagens do Docker podem ser movidas facilmente entre ambientes e por meio de pipelines de construção. Por exemplo, a BBC News (uma divisão da British Broadcasting Corp.) afirma que suas tarefas de integração contínua ficaram mais de 60 por cento mais rápidas em uma infraestrutura baseada no Docker. A capacidade de mover o mesmo código por todo o pipeline de entrega — minimizando a necessidade de configuração de software em cada estágio e tendo requisitos de recurso de hardware previsíveis ao longo do caminho — acelera aplicativos por meio do desenvolvimento, teste e produção mais rápidos do que antes. Empresas estão aptas a ver estes ganhos em eficiência porque seus componentes do sistema são modularizados dentro de cada imagem do Docker. Você não precisa configurar o software toda vez que precisa dele. Você simplesmente inicia uma instância de contêiner e está pronto para começar.

Docker é um sistema de contêineres de remessa para código que torna o desenvolvimento e a entrega do software por meio de contêineres Linux fácil. O Docker age como um mecanismo que permite que qualquer carga útil seja encapsulada como um contêiner leve, móvel e autossuficiente. Tais contêineres podem ser manipulados usando operações padrão e executados de maneira consistente em praticamente qualquer plataforma de hardware.

An overview of how Docker simplifies software development and delivery through Linux containers.
An overview of how Docker simplifies software development and delivery through Linux containers.

Se você for iniciante em contêineres e Docker, consulte Recursos para obter links para um ótimo material introdutório sobre contêineres Docker e Linux em geral. Se você tiver experiência em Docker e desejar utilizar o Docker na nuvem, IBM Containers for Bluemix é um serviço de contêiner no nível corporativo que é possível começar a usar gratuitamente hoje. Você obtém seu próprio registro privado para armazenar todas as suas imagens, acessar o registro público da IBM de middleware suportado, integração de pipeline de entrega hospedado, e acesso a mais de 150 serviços do Bluemix™ . É possível ter seu aplicativo em execução em contêineres do Docker mais rápido do que nunca.

Mais rápido e menor: contêineres como os nanobots de desenvolvimento de software

Assim como você pode ver o motivo pelo qual contêineres são tão importantes para microsserviços — ,como uma das principais tecnologias de ativação para o estilo arquitetural, — você também pode começar a ver que o gerenciamento de contêineres é igualmente importante. Como você sabe da Parte 1, em vez de ampliar, dimensionamos os microsserviços. Em vez de incluir mais RAM em um tempo de execução de microsserviço, nós simplesmente obtemos um outro tempo de execução de microsserviço do mesmo tipo. Precisa de ainda mais RAM? Obtenha uma terceira instância. Esta abordagem é adequada somente para alguns serviços com uma instância de contêiner cada, mas como qualquer pessoa com habilidades em computador e uma família grande sabe, isto pode ficar fora de controle rapidamente quando você está gerenciando dúzias de servidores remotamente.

Pense no quão rapidamente você precisará gerenciar mais de 100 instâncias individuais. Se você iniciar com um punhado de microsserviços que constituem seu aplicativo — cinco ou seis, digamos — cada um deles deverá ter pelo menos três instâncias de contêiner suportando cada microsserviço. Portanto, de cara, você terá 18 instâncias de contêiner. Digamos que você inclua um outro microsserviço ou seu aplicativo seja realmente bem-sucedido e você precise escalar para cinco a 10 instâncias de contêiner para determinados serviços. Você está se aproximando facilmente de mais de 100 instâncias de contêiner para gerenciar — em um dia bom.

Felizmente, muitos projetos de software livre podem manipular esta necessidade exata. Por exemplo, Kubernetes, Apache Mesose fleet facilitam o gerenciamento de milhares de instâncias de contêiner a partir de um único console ou linha de comando, usando uma linguagem específica do domínio baseada em infraestrutura.

Este conceito de gerenciamento reforça firmemente o conceito de gado comparado com animais de estimação da Parte 1. A ideia é que todos os nossos contêineres que implementamos por meio de nossos processos de integração contínua/entrega contínua sejam imutáveis. Uma vez implementados, não é possível mudá-los. Em vez disso, se você precisa de uma mudança ou uma atualização, crie um novo cluster de contêineres com as atualizações corretas aplicadas e remova os antigos. É muito mais fácil gerenciar 1.000 cabeças de gado do que 1.000 animais de estimação. Não me leve a mal: todos nós amamos nossos animais de estimação mas, se desejar inovar em velocidade e entregar valor aos seus clientes, com receita para seus negócios, não pode dispor-se a gastar todo o tempo necessário para dar a cada animal de estimação todo cuidado de que ele precisa. Projetos como Kubernetes, Apache Mesos e fleet— e serviços de contêiner hospedados como Contêineres IBM, — tornam possível integrar seus pipelines de entrega e registros de imagem para gerenciar, de maneira rápida e fácil, todas as fases de sua infraestrutura como rebanho de gado hipereficiente.

Como uma exceção, deve ser observado que, embora determinados serviços de contêiner ainda usem máquinas virtuais como hosts do Docker, eles ainda devem ser considerados como rebanho de gado. Estas VMs são um pouco mais robustas em recursos e capacidades de gerenciamento integrado, mas ainda são, em geral, consideradas como gado pois elas são gerenciadas dinamicamente pelas necessidades das cargas de trabalho baseadas em contêiner.

Uma malha de microsserviços: sua melhor desculpa contra jogar Acerte a marmota

Até agora, falei sobre o motivo pelo qual mais contêineres é melhor e como manipular a infraestrutura genérica em escala. Agora que você está confortável com o conceito de desenvolvimento para contêineres e disse adeus aos seus animais de estimação, é necessário começar a pensar no desenvolvimento de seus aplicativos e colocá-los em produção.

Isto me leva aos três elementos-chave que são cruciais para o desenvolvimento de aplicativo baseado em microsserviço:

  • Criação de log e monitoramento
  • Entrega contínua sem interrupção
  • Registros de serviço dinâmicos

Deve-se pensar sobre cada um desses recursos desde o primeiro dia, mas sem necessariamente resolvê-los imediatamente.

Conforme eu examinar estes recursos, você também verá o motivo pelo qual uma malha de microsserviços integrada — tal como o Bluemix e seus serviços relevantes — torna o gerenciamento de suas arquiteturas de microsserviços muito mais fácil.

Criação de log e monitoramento

Se fornecer suporte no nível de produção para aplicativos e serviços, sua primeira questão deverá sempre ser, "O que fazer quando algo dá errado?" Observe que não há nem mesmo uma sugestão de um "se" nessa pergunta. Componentes falharão, versões mudarão, serviços de terceiros terão indisponibilidades. Como você pode manter um nível de sanidade, juntamente com um nível desejado de tempo de atividade para seus usuários? Essa é a pergunta um.

Como eu disse anteriormente, você deseja que seus contêineres sejam imutáveis. Por esta razão, a maioria das organizações de TI não fornece acesso no nível do sistema às instâncias de contêiner — nenhum SSH, nenhum console, nem nada. Portanto, como saber o que está acontecendo dentro de uma caixa preta que você não pode mudar? Essa é a pergunta dois.

Felizmente, esta pergunta foi resolvida com o conceito de uma pilha de ELKElasticsearch, LogStashe Kibana.

Visual representation of what the ELK stack looks like, with data flowing through LogStash to Elasticsearch to Kibana.
Visual representation of what the ELK stack looks like, with data flowing through LogStash to Elasticsearch to Kibana.

Estes três componentes separados fornecem a capacidade de agregar logs, procura de forma livre por meio de logs agregados e criar e compartilhar painéis baseados em logs e atividade monitorada na plataforma. Este é um grande recurso — muito melhor do que efetuar login em computadores individuais e executar uma caixa de ferramentas sysadmin de sed, grep e awk. Você tem acesso com recursos completos a um armazenador central de todos os seus logs. É possível correlacionar eventos entre sistemas e microsserviços porque você geralmente verá eventos e IDs viajando através de seu sistema e encontrando problemas semelhantes.

É possível integrar com pilhas de ELK de várias maneiras, esteja você executando na nuvem ou no local: via variantes de serviços hospedados, software livre e opções frequentes criadas para ofertas de plataforma como serviço —Contêineres IBM, por exemplo. Dentro do tempo de execução do contêiner no Bluemix, você tem acesso a uma pilha de ELK de vários locatários, com todos os recursos, que recebe automaticamente seus logs dos tempos de execução baseados em contêiner do Docker, fornecendo visibilidade e capacidade de pesquisa para aqueles eventos de tempo de execução enquanto também fornece um painel baseado em Kibana pré-configurado pronto para uso. Se pretende se iniciar no uso de contêineres, este é um recurso-chave que torna os Contêineres IBM uma opção preeminente para seus microsserviços baseados em contêiner.

Entrega contínua sem interrupção

Agora que você está tranquilo de que terá uma noção do que fazer quando o céu começar a cair (é claro que espera que isso nunca aconteça), você pode seguir em frente implementando rapidamente todas as suas incríveis atualizações de aplicativos. Pensando em algumas das maiores empresas que estão implementando aplicativos dezenas, centenas ou milhares de vezes por semana, você precisa pensar sobre tempo de inatividade. Certamente essas empresas não estão tendo indisponibilidades dos aplicativos toda vez que lançam uma nova versão — se tivessem, elas nunca estariam ativas.

Essas empresas tornaram-se peritas em implementação com indisponibilidade zero. Isto pode ser conhecido como várias coisas, geralmente com variantes coloridas, que variam de Vermelho-Preto a Azul-Verde e assim por diante, mas todos eles seguem o mesmo princípio: seu aplicativo está sempre disponível, não importa o que aconteça, mesmo passando por atualizações abundantes, porque indisponibilidades do website causadas por tempo planejado de inatividade planejado não são boas para você ou para seus usuários.

An example notification of a website outage caused by planned system downtime
An example notification of a website outage caused by planned system downtime

Agora com o monólito descrito na Parte 1, evitar tempo planejado de inatividade era perigoso, demorado, caro e exaustivo para todos os envolvidos. A necessidade de várias imagens espelhadas de um enorme conjunto de recursos era um tanto difícil de gerenciar e levava a noites de trabalho, em uma janela "fora do expediente", onde era feito muito esforço para ativar a nova versão e desativar a antiga — sem falar em ter que imaginar o que fazer com a versão antiga se um retrocesso fosse necessário ou se algo fugisse do controle da equipe imediatamente responsável.

Com microsserviços e aplicativos baseados em contêiner, essas preocupações foram minimizadas, se não completamente removidas, especialmente com alguns serviços chave disponíveis no Bluemix hoje. Dividindo seus componentes em partes muito menores, você pode implementá-los com impacto mínimo no sistema geral, enquanto mantém muitos deles ativos em determinados momentos para evitar indisponibilidades. Um novo serviço disponível no Bluemix, Active Deploy, fornece este recurso e é pré-integrado no Pipeline de Entrega. Equipes menores podem gerenciar mais aplicativos de maneira mais eficiente porque cada versão implementada possui supervisão automática da manutenção de seu tempo de atividade, o que tem menos custo em atenção humana e recursos de cálculo.

Registros de serviço dinâmicos

O último tópico para esta parte do artigo é a noção de registros de serviço dinâmicos. Este tópico inclui conceitos que você já deve conhecer como descoberta de serviço ou proxy de serviço. Estes dois conceitos não são os mesmos de forma alguma, mas eles são semelhantes o suficiente para serem considerados nesta abordagem.

Agora que você estará criando milhares de instâncias de contêiner que suportam seus microsserviços em todos os seus aplicativos, como os outros componentes em seu aplicativo entenderão o que está se passando? Como eles saberão quais outros microsserviços estão disponíveis para fazer chamadas de serviço? Como eles responderão às chamadas de serviço que estão sendo feitas para eles?

A diferença entre descoberta de serviço e proxy de serviço considera se você deseja executar a procura você mesmo ou se deseja permitir que outra pessoa a manipule para você. Como uma analogia, suponha que você precisa de um serviço de envio. Você deseja consultar serviços a partir de um único provedor (o US Postal Service (USPS), por exemplo) ou a partir de uma clearing house multisserviço (como a Staples).

A visual metaphor showing shipping service lookups from a single provider or a multi-service clearing house.
A visual metaphor showing shipping service lookups from a single provider or a multi-service clearing house.

Por exemplo, se eu desejo enviar um pacote, posso ir ao website da USPS, inserir alguns parâmetros para o tipo de agência de correio que estou procurando, obter uma lista de opções, escolher uma e ir até lá para enviar meu pacote. Este é o conceito de descoberta de serviço: eu uso um registro conhecido de terminais de serviço disponíveis que é atualizado quando os serviços ficam on-line e off-line. Por meio de APIs REST, aplicativos de chamada podem consultar serviços de descoberta de serviço para determinar quais e quantos tipos de serviços estão disponíveis para uma chamada de serviço específica, até uma versão específica desse serviço solicitado.

An example microservice architecture using client-side service discovery patterns, more commonly known as Service Discovery.
An example microservice architecture using client-side service discovery patterns, more commonly known as Service Discovery.

Se eu não desejo escolher onde ir para enviar meu pacote, — eu apenas quero dizer "entregue este pacote no endereço indicado na etiqueta" — eu posso optar pela Staples. A Staples então escolhe a opção de envio com custo mais reduzido para meu pacote com base em todas as informações fornecidas por mim. Estou entregando o pacote para um provedor de serviços reconhecido e deixando ele tratar do roteamento do pacote para mim. Este é o conceito de proxy de serviço: você faz uma chamada para um terminal conhecido, e essa chamada é encaminhada automaticamente, com base em regras ou metadados pré-estabelecidos, para um serviço de suporte que fornece a resposta real à solicitação de serviço.

An example microservice architecture using server-side service discovery patterns, more commonly known as Service Proxy.
An example microservice architecture using server-side service discovery patterns, more commonly known as Service Proxy.

Existem bons argumentos para preferir a descoberta de serviço ao proxy de serviço e vice-versa, mas isto na verdade está relacionado à preferência ou experiência/requisitos de implementação. Várias ofertas de descoberta de serviço de software livre, tais como etcd e Consul, fornecem registros de serviço distribuídos com os quais você pode registrar, identificar e pulsar todas as suas instâncias de serviço disponíveis. Existem projetos ainda mais legais como Registrator que registrará seus serviços automaticamente em um desses terminais assim que o contêiner do Docker é criado.

Alguns dos projetos de proxy de serviço mais populares suportam o argumento-chave de que, na execução longa, o método de proxy de serviço requer menos hops de rede para obter seu serviço de suporte eventual. Um dos maiores e mais populares projetos de proxy de serviço é o projeto Hystrix da Netflix. Hystrix é uma biblioteca baseada em tecnologia™ Java que vai muito além de um simples proxy de serviço, mas fornece inúmeras melhorias de qualidade de serviço em uma biblioteca de proxy de serviço.

Obviamente, ambos os padrões são importantes no gerenciamento automático de suas instâncias de serviço e para torná-las parte de sua infraestrutura de microsserviços disponível. O Bluemix terá sua própria oferta de descoberta de serviço de vários proprietários em breve (se é que já não o terá quando você estiver lendo isto) — removendo a necessidade de você gerenciar o serviço de descoberta de serviço, o que pode ser difícil. Imagine registrar todas as suas instâncias de contêiner automaticamente, esteja você acelerando-as manualmente, realizando o push por meio do Bluemix Delivery Pipeline ou integrando com um pipeline no local como o IBM UrbanCode Deploy ou Jenkins.

Conclusão

Você viu como contêineres estão acelerando o desenvolvimento de aplicativo nativo da nuvem. Componentes de aplicativos menores e mais rápidos podem ser entregues mais rápido e mais facilmente do que nunca, com recurso de gerenciamento mais integrado do que nunca. A implementação de contêineres em um serviço gerenciado, tais como Contêineres IBM, juntamente com todos os recursos de microsserviço de apoio — incluindo criação de log e monitoramento, Active Deploy, e descoberta de serviço — torna mais fácil dar aquele próximo passo a partir de seus monólitos existentes em direção à nuvem.

Estamos movendo em direção a sistemas modulares mais inteligentes, que são mais automatizados e mais integrados desde o início até a conclusão. Eles se desenvolverão em seu próprio ritmo, cientes do que está disponível na infraestrutura, reconhecendo o que não está, e reconhecendo quando algo precisa mudar. Todos esses recursos, e outros mais, serão abordados em alguns dos próximos artigos desta série.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing, Linux, Software livre
ArticleID=1026237
ArticleTitle=Microsserviços em ação, Parte 2: Contêineres e microsserviços — um par perfeito
publish-date=01262016