Containers: Entenda por que até 2025 essa tecnologia estará em 85% das empresas

Paulo de Godoy, country manager da Pure Storage no Brasil

  A TI está em meio a uma mudança profunda porque quase tudo que envolve a maneira como as empresas entregam e criam aplicações se tornou novidade. Essa transformação digital pode ser caracterizada por três elementos principais. Em primeiro lugar, vem a digitalização de processos dentro das empresas e para fora, aos clientes e parceiros. Segundo, é fortemente influenciada pelo uso dos recursos da nuvem ou de modelos operacionais semelhantes. Em terceiro lugar, a maneira como o desenvolvimento de aplicações ocorre também está mudando para um modelo de integração e implementação contínuas, que permitem mudanças frequentes nos processos interativos.

  No ápice desses três elementos está a conteinerização, que reúne a capacidade de construir aplicações em um modelo de desenvolvimento contínuo, independente, altamente escalável e portátil, ao mesmo tempo em que granular em relação aos componentes de serviços que são capazes de encapsular.

  As aplicações de contêineres, ou “containers” implementadas e gerenciadas por meio de uma plataforma de orquestração como o Kubernetes, desempenharão um papel fundamental na evolução da TI ao longo da próxima década. De acordo com o Gartner, 85% das empresas executarão “containers” na produção até 2025, acima da marca de 35% registrada em 2019.

  Os contêineres podem ser executados em uma densidade muito maior do que as tradicionais cargas de trabalho virtuais, o que significa que menos servidores são necessários. Isso tem o efeito indireto de reduzir os custos de licenciamento e, principalmente, os requisitos de energia. Por esses motivos, a conteinerização começa a sustentar iniciativas de redução de custos e business cases mais amplos, permitindo que as empresas visem 25% a 40% das aplicações como ponto comum de partida.

  Mas e o armazenamento, proteção de dados, backups, snapshots, replicação, alta disponibilidade e recuperação de desastres? São vitais para a infraestrutura de aplicações de uma empresa, mas podem ser um desafio em operações em “containers”. Antes de buscar maneiras de resolver isso, é preciso entender por que os “containers” são tão importantes e como eles funcionam.

 

Implementação ágil

 

  Digamos que o negócio principal de uma empresa esteja centrado em lançamentos frequentes de produtos com picos rápidos de demanda e requisitos de análise de acompanhamento. Pode ser uma operação de sistemas de ingressos, por exemplo, com picos repentinos e maciços nas vendas. As aplicações construídas tradicionalmente em uma arquitetura de três camadas (cliente-servidor-base de dados) seriam lentas para implementar, não escalariam bem e não suportariam altos níveis de demanda. Os “containers” surgiram justamente para lidar com essa situação.

  Isso ocorre porque eles encapsulam os inúmeros componentes de uma aplicação, o que significa que muitos desses microsserviços são reutilizáveis conforme novas aplicações são desenvolvidas, e podem se multiplicar rapidamente para atender às necessidades de dimensionamento. Além disso mantêm toda a conectividade da API e podem ser portados para vários ambientes operacionais. Assim, por exemplo, esse aumento repentino na demanda de ingressos pode ser acomodado pela reprodução rápida de instâncias de serviços em container interconectadas e se espalhar rapidamente em vários data centers, inclusive na nuvem pública.

  Em simples explicação, os fundamentos técnicos dos “containers” se resumem em uma forma de virtualização. Ao contrário dos servidores virtuais, são executados diretamente no sistema operacional do host e sem um hypervisor intermediário (monitor da máquina virtual). Isso significa que se tornam uma VM muito mais granular e leve que geralmente fornece componentes discretos de toda a aplicação, conectados por código, ou seja, APIs.

  Embora não haja hypervisor e sobrecarga consequente, os “containers” se beneficiam de uma camada de orquestração, fornecida por ferramentas como o Kubernetes, que organiza um ou mais “containers” em execução em pods, cada um com seu código, tempo de execução, dependências, chamadas de recursos. A inteligência para executar pods fica acima deles em um ou mais clusters do Kubernetes.

 

O desafio de armazenamento e backup do Kubernetes

 

  Um dos maiores desafios a serem superados com o Kubernetes é o armazenamento e a proteção de dados. As raízes do problema remontam à origem dos “containers”, que originalmente deveriam ser executados em um laptop de desenvolvedores como uma instância efêmera e para os quais o armazenamento persistia apenas enquanto o container fosse executado.

  Conforme os “containers” se tornaram uma abordagem corporativa convencional para o desenvolvimento de aplicações, isso simplesmente não funcionaria. A maioria das aplicações corporativas são stateful, que criam, interagem e armazenam dados. Portanto, quem quer implementar “containers” com armazenamento de classe empresarial e proteção de dados precisa analisar um conjunto de soluções emergentes no mercado.

 

O que buscar ao adotar a tecnologia de “container”?

 

  Um ponto importante é que qualquer solução de armazenamento Kubernetes deve ser nativa de container. Isso significa que os próprios requisitos de armazenamento de uma aplicação são implementados como microsserviços em “containers” nos quais os requisitos de provisionamento, conectividade e desempenho são escritos como código, com todo o dinamismo e agilidade que isso implica. Isso contrasta com outros métodos – como CSI ou Container Storage Interface – que dependem de drivers codificados para armazenamento alocado em “containers”.

  Enquanto isso, uma plataforma de armazenamento Kubernetes nativa de “container” definida por software deve fornecer acesso ao armazenamento de blocos, files e objetos, além de usar o armazenamento em nuvem. Com isso, deve emular as principais características e benefícios da conteinerização e do Kubernetes. Isso significa que os dados devem ser tão portáteis quanto a aplicação em container, precisam ser dimensionados de forma autônoma e gerenciados por meio de um plano de controle comum.

  Quando se trata de proteção de dados, esse produto deve fornecer os principais métodos de proteção, incluindo backups e snapshots, replicação síncrona e assíncrona e funcionalidade de migração. Novamente, isso deve permitir a nuvem como origem ou destino nessas operações.

  Para lidar com a escalabilidade dos ambientes Kubernetes, a solução deve ser capaz de gerenciar clusters, nós e “containers” que são executados em centenas, milhares e centenas de milhares, respectivamente, com capacidade de armazenamento gerenciável em dezenas de petabytes.

  Por fim, deve ser inteligente, com gerenciamento automatizado baseado em regras que, por exemplo, cria, replica e exclui “containers”, conforme determinado por gatilhos de monitoramento predefinidos, além de provisionar e redimensionar o armazenamento conforme necessário. E então, depois de encontrar e implementar uma solução que atenda a todas essas caixas, fica claro por que 85% das empresas confiarão nessa tecnologia até 2025.

Orquestração de contêineres em nuvem

A popularidade das plataformas de conteinerização de aplicações segue crescendo ano após ano e vem se tornando um padrão para a entrega de aplicações distribuídas. A orquestração de contêineres traz muitos benefícios associados a alguns desafios interessantes para os times de operação.

Guilherme Belinelo, CTO da dataRain Consulting

  A popularidade das plataformas de conteinerização de aplicações segue crescendo ano após ano e vem se tornando um padrão para a entrega de aplicações distribuídas. A orquestração de contêineres, ou “containers” se você preferir a grafia em inglês como um neologismo, assim como usaremos neste breve artigo, tem trazido muitos benefícios associados a alguns desafios interessantes para os times de operação.

  Mas, para compreender o motivo desta popularização, vamos antes entender que, por ter um sistema operacional como base, compartilhado entre os diferentes containers, a plataforma de conteinerização consegue fazer melhor uso do hardware ao evitar o overhead do SO. Isso difere do caso tradicional de máquinas virtuais para as quais é necessário subir o sistema operacional inteiro sobre um hypervisor para só então poder rodar suas aplicações em cima.

  Outro aspecto bastante interessante é que o container já promove, nativamente, o conceito de microsserviço, no qual cada container executa uma tarefa especializada, reduzindo significativamente seu “footprint” e melhorando as características de alta disponibilidade e segurança do cluster como um todo.

  Porém, nem tudo traz consigo apenas os “prós” e precisamos levar em conta também alguns “contras” da abordagem de arquiteturas baseadas em containers. Um bastante importante é o “container sprawl” (espalhamento de containers) – sim, do mesmo jeito que acontecia com as VMs (máquinas virtuais) –, que, dado à facilidade com que é criado, permite que as áreas usuárias lancem diversos deles, levando quase sempre a um aumento muito rápido do número de containers a ser gerenciado.

  Isso traz dificuldade de como trabalhar com os containers em escalas corporativas. Nesse momento, as ferramentas de orquestração aparecem para resgatar os SysAdmins e colocam (alguma) ordem na bagunça, podendo ser separadas em basicamente em dois grupos:

• Ferramental de orquestração não gerenciado (ou “self hosted”).

• Ferramental de orquestração gerenciado.

  No caso das soluções não gerenciadas, você fica responsável por cuidar de todos os aspectos relacionados a subir e manter o cluster, com atividades de administração, atualizações de software, implementação de alta disponibilidade e escalabilidade, suporte técnico avançado (N2 e N3), gerenciamento da segurança e aderência a requisitos de conformidade.

  Por outro lado, se não é necessário acesso pleno ao control plane — máquinas “master” que gerenciam as cargas de trabalho em nós, “workers” — e você pode optar pelas soluções de orquestração mais comuns de mercado, por exemplo o Kubernetes, as soluções gerenciadas em cloud são geralmente o melhor o caminho a ser seguido.

  Com o provisionamento da infraestrutura em poucos minutos, guiados por “wizards” automáticos, você pode se preocupar mais com a arquitetura dos seus containers, microsserviços e comunicação entre eles, do que com a infraestrutura que fica por baixo.

  Por esta razão, o rápido desenvolvimento e adoção do Kubernetes resultaram em muitas implementações diferentes do aplicativo. A CNCF – Cloud Native Computing Foundation lista atualmente mais de 90 ofertas certificadas do Kubernetes. Para garantir alguma consistência entre as plataformas, a CNCF se concentra em três princípios fundamentais”

• Consistência: a capacidade de interagir de forma consistente com qualquer instalação do Kubernetes.

• Atualizações oportunas: os fornecedores devem manter as versões atualizadas, pelo menos anualmente.

• Confirmabilidade: Qualquer usuário final pode verificar a conformidade usando o Sonobuoy.

  Esses são os requisitos básicos para a CNCF quando se trata de Kubernetes, mas os provedores de nuvem têm ecossistemas tão ricos que provavelmente haverá discrepâncias mais significativas. Continuamos a examinar os muitos recursos e limitações atuais dos serviços Kubernetes gerenciados dos três maiores provedores de nuvem:

• Serviço EKS – Elastic Kubernetes da Amazon.

• Serviço AKS – Azure Kubernetes da Microsoft.

• GKE – Kubernetes Engine do Google.

  Os serviços de container da Amazon e do Azure são relativamente semelhantes. O ECR – Elastic Container Registry, da Amazon, é um serviço pago em camadas, que fornece um SLA com suporte financeiro e um serviço gratuito de digitalização de imagens e recursos como tags de imagem imutáveis. O ACR – Azure Container Registry, do Azure, também é um serviço pago em camadas, que fornece um SLA com suporte financeiro e serviço de digitalização de imagens pago, com o scanner Qualys e recursos como assinatura de imagem, marcas imutáveis ​​e bloqueio de imagens e repositórios.

  O ECR atualizou recentemente a capacidade de seu registro. Com a mudança de ECRs para suportar regiões e contas cruzadas, os usuários não precisam configurar e gerenciar a redundância entre zonas como faziam anteriormente. O preço do Azure é uma taxa de uso diário e com base na quantidade de armazenamento necessária, mas não cobra pela largura de banda da rede. A Microsoft também oferece redundância geográfica como parte de seu plano premium.

  Por fim, o Google concluiu sua mudança de seu registro de contêiner existente, o Google Container Registry, para um produto Artifact Registry completo. A empresa optou por se concentrar em mais formatos de imagem suportados, digitalização de imagem integrada e autorização binária para uma oferta mais segura.

Foto crédito: bangoland

Guia rápido para desbravar o universo do Kubernetes

Paulo de Godoy, country manager da Pure Storage no Brasil

Cloud edge computing: Além do data center

Lenildo Morais – Mestre em ciência da computação pelo Centro de Informática da UFPE – Universidade Federal de Pernambuco

Uma exploração mais profunda das considerações sobre a cloud edge

 

  A “borda” da computação de borda se refere à periferia de um domínio administrativo, o mais próximo possível de fontes de dados ou usuários finais. Este conceito se aplica a redes de telecomunicações, a grandes empresas com pontos de presença distribuídos, como o retalho, ou a outras aplicações, em particular no contexto da IoT.

  Uma das características da computação de borda é que o aplicativo é fortemente associado à localização da borda. Para as telecomunicações, “a borda” se referiria a um ponto próximo ao usuário final, mas controlado pelo provedor, potencialmente tendo alguns elementos de cargas de trabalho em execução nos dispositivos do usuário final. Para grandes empresas, “o limite” é o ponto em que o aplicativo, serviço ou carga de trabalho é usado (por exemplo, uma loja de varejo ou uma fábrica). Para os propósitos desta definição, a borda não é um dispositivo final com capacidade extremamente limitada para suportar até mesmo uma arquitetura de nuvem mínima, como um dispositivo IoT ou de sensor. Esta é uma consideração importante, porque muitas discussões sobre computação de borda não fazem essa distinção.

   A computação de borda é semelhante à computação de data center onde:

• Inclui recursos de computação, armazenamento e rede.
• Seus recursos podem ser compartilhados por muitos usuários e muitos aplicativos.
• Beneficia da virtualização e abstração do pool de recursos.
• Beneficia da capacidade de alavancar hardware de commodity.
• Utiliza APIs para suportar a interoperabilidade.

   A computação de borda difere da computação em grandes data centers onde:

• Os sites de borda são o mais próximo possível dos usuários finais. Eles melhoram a experiência em alta latência e conexões não confiáveis.
• Pode exigir hardware especializado, como plataformas GPU / FPGA para funcionalidades de realidade aumentada/realidade virtual.
• O edge pode ser dimensionado para um grande número de sites, distribuídos em locais distintos.
• A localização de um site de borda e a identidade dos links de acesso que ele encerra são significativas. Um aplicativo que precisa ser executado perto de seus usuários precisa estar na parte certa da borda. É comum que o local do aplicativo seja importante na computação de borda.
• Todo o pool de sites pode ser considerado dinâmico. Devido a sua separação física, os sites de borda serão, em alguns casos, conectados entre si e o núcleo com conexões WAN. Os sites de borda ingressarão e sairão do pool de infraestrutura ao longo do tempo.
• Os sites de borda são remotos e potencialmente não-tripulados e, portanto, devem ser administrados remotamente. As ferramentas precisam suportar o acesso intermitente da rede ao site.
• O edge suporta grandes diferenças no tamanho e na escala do site, desde a escala do data center até um único dispositivo.
• Sites de borda podem ter recursos limitado. A adição de capacidade a um site existente é restrita devido a requisitos de espaço ou energia.
• Multi-tenancy em escala maciça é necessária para alguns dos casos de uso.
• O isolamento da computação de borda das nuvens do data center pode ser necessário para garantir que os comprometimentos no domínio “nuvem externa” não afetem os serviços.

  O conceito de computação de borda deve cobrir o site de borda (por exemplo, a infraestrutura de computação, rede e armazenamento), mas também os aplicativos (cargas de trabalho) executados nele. Vale notar que qualquer aplicativo em um ambiente de computação de borda pode potencializar qualquer um ou todos os recursos fornecidos por uma nuvem – computação, armazenamento em bloco, armazenamento de objetos, rede virtual, bare metal ou contêineres.

Casos de uso

 

  Existem muitas maneiras de caracterizar casos de uso e este artigo é muito curto para fornecer uma lista exaustiva. Mas aqui estão alguns exemplos para ajudar a esclarecer o pensamento e destacar oportunidades de colaboração.

 

Coleta de dados e análise

  IoT, onde os dados são frequentemente coletados de uma grande rede de microssites, é um exemplo de um aplicativo que se beneficia do modelo de computação de borda. Enviar massas de dados em conexões de rede geralmente limitadas a um mecanismo de análise localizado em um data center centralizado é contraproducente; pode não ser responsivo o suficiente, contribuir para latência excessiva e desperdiçar largura de banda preciosa.

  Como os dispositivos edge também podem produzir Terabytes de dados, a análise mais próxima da fonte dos dados na borda pode ser mais econômica, analisando os dados próximos à fonte e enviando apenas pequenos lotes de informações condensadas de volta aos sistemas centralizados. Há uma compensação aqui – equilibrar o custo de transportar dados para o núcleo contra a perda de algumas informações.

 

Segurança

  Infelizmente, à medida que os dispositivos de borda se proliferam – incluindo telefones celulares e sensores IoT – novos vetores de ataque estão surgindo, aproveitando a proliferação de endpoints. A computação de borda oferece a capacidade de mover os elementos de segurança para mais perto da origem de ataque, permite aplicativos de segurança de desempenho mais alto e aumenta o número de camadas que ajudam a defender o núcleo contra violações e riscos.

 

Requisitos de conformidade

  Conformidade abrange uma ampla gama de requisitos, passando por soberania de dados e aplicação de direitos autorais. Restringir o acesso a dados com base em limites geográficos e políticos, limitar fluxos de dados, dependendo das limitações de direitos autorais, e armazenar dados em locais com regulamentações específicas é possível e executável com infraestrutura de computação de ponta.

 

NFV – Virtualização da função de rede

  A NFV é a essência do aplicativo de computação de borda, pois fornece funcionalidade de infraestrutura. As operadoras de telecomunicações buscam transformar os seus modelos de entrega de serviços executando funções de rede virtual, como parte ou em camadas de uma infraestrutura de computação de ponta. Para maximizar a eficiência e minimizar o custo/complexidade, a execução de NFV na infraestrutura de computação de ponta faz sentido.

 

Tempo real

  Aplicativos em tempo real, carros conectados, telemedicina, Internet tátil indústria 4.0 e cidades inteligentes são incapazes de tolerar mais que alguns milissegundos de latência e podem ser extremamente sensíveis a jitter ou variação de latência. Como exemplo, os carros conectados precisarão de baixa latência e alta largura de banda e dependerão de computação e cache de conteúdo perto do usuário, tornando a capacidade de borda uma necessidade. Em muitos cenários, particularmente quando a automação de circuito fechado, ela é usada para manter a alta disponibilidade. Os tempos de resposta em dezenas de milissegundos são necessários e não podem ser atendidos sem a infraestrutura de computação de borda.

 

Imersivo

  A computação de borda expande os recursos de largura de banda, desbloqueando o potencial de novos aplicativos imersivos. Alguns deles incluem imagens em 360° para verticais como cuidados de saúde. Colocar em cache e otimizar o conteúdo na borda já está se tornando uma necessidade, já que protocolos como o TCP não respondem bem a mudanças repentinas no tráfego da rede de rádio. A infraestrutura de computação de ponta, vinculada ao acesso em tempo real a informações de rádio/rede, pode reduzir os atrasos em vídeo em até 20% durante as horas de pico e também variar a taxa de transmissão de vídeo com base nas condições de rádio.

 

Eficiência de rede

  Muitos aplicativos não são sensíveis à latência e não exigem grandes volumes de computação ou capacidade de armazenamento, para, teoricamente, rodar em uma nuvem centralizada, mas os requisitos de largura de banda e/ou computação ainda podem tornar a computação de borda mais eficiente. Algumas dessas cargas de trabalho são comuns, incluindo vigilância por vídeo e gateways de IoT, enquanto outras, como reconhecimento facial e reconhecimento de matrículas de veículos, são recursos emergentes. Com muitos deles, a infraestrutura de computação de borda não apenas reduz os requisitos de largura de banda, mas também fornece uma plataforma para funções que permitem o valor do aplicativo – por exemplo, detecção de movimento de vigilância por vídeo e reconhecimento de ameaças.

  Em muitos desses aplicativos, 90% dos dados são rotineiros e irrelevantes, portanto, enviá-los para uma nuvem centralizada é proibitivamente caro e desperdiça a largura de banda da rede, que costuma ser escassa. Faz mais sentido classificar os dados na borda para anomalias e alterações e apenas relatar os dados acionáveis.

VMWare lança soluções para ambientes multi-cloud

Redação, Infra News Telecom

  A adoção de multi-cloud, contratação de múltiplos provedores de nuvem, é cada vez mais comuns nas empresas. Segundo a Forrester, 89% das companhias em todo o mundo usam ao menos duas nuvens e 74% delas já têm três ou mais clouds públicas.

  Pensando em ajudar as companhias a reduzirem custos e a complexidade de operar esses ambientes, a VMware, especializada em software corporativos, apresentou novidades em seus serviços de cloud, permitindo que os times de CloudOps, DevOps, segurança e compliance gerenciem os custos e análises entre as nuvens.

  “Nossas plataformas ajudam os clientes a aproveitarem as nuvens nativas para responder a novas oportunidades e ameaças, além de entregarem qualquer aplicativo, em qualquer dispositivo. É possível visualizar, gerenciar, proteger e operar com mais eficiência as cargas de trabalho na nuvem. Estamos dividindo os silos de nuvem e ajudando às empresas a atenderem as necessidades de seus aplicativos com os melhores recursos possíveis”, diz Raghu Raghuram, COO de produtos e serviços em nuvem da VMware.

Automação de nuvem

  Os novos serviços de automação na nuvem da companhia suportam a escolha de clouds sem interromper as operações das equipes de desenvolvimento. Além disso, fornecem e gerenciam aplicações e infraestrutura, intermediam serviços com grades de proteção flexíveis e automatizam e solucionam problemas no pipelines de liberação de código em múltiplas nuvens.

  O portfólio é composto pelo VMware Cloud Assembly (orquestra e acelera a entrega de infraestrutura e aplicações, de acordo com os princípios do DevOps); VMware Service Broker (agrega conteúdo nativo de várias nuvens e plataformas em um único catálogo com políticas baseadas em função); e VMware Code Stream (acelera a entrega de software e a solução de problemas com pipelines e análises de liberação).

Reduzindo o risco em ambientes multi-cloud 

  Um outro serviço é o VMware Secure State, projetado para atender às necessidades e desafios mais urgentes das equipes de segurança na nuvem, oferecendo uma oferta de SaaS – software como serviço, que automatiza a configuração da segurança e o monitoramento de conformidade em ambientes com múltiplas nuvens.

   Já o Wavefront by VMware é uma plataforma de análise e monitoramento nativa na nuvem que oferece aos DevOps uma visão instantânea do desempenho dos aplicativos web distribuídos.

  A solução ganhou atualizações como escalabilidade massiva de contêineres (pode ingerir, analisar e visualizar dados de métricas de um ambiente que executa 100 mil contêineres); integração com PKS – Expanded Pivotal Container Service (garante que a visão de Kubernetes e dos aplicativos em contêiner sejam aplicadas desde o início, impondo o dimensionamento correto do contêiner), instrumentação e análise sem servidor (aprimora o suporte sem servidor com novos painéis pré-desenvolvidos e SDKs sem servidor), novos controles de segurança (para o gerenciamento de aplicações nativas na nuvem com facilidade, seja por usuário ou grupos de usuários, e o gerenciamento de painéis de acesso em tempo real) e novas visualizações e aprimoramentos do AWS UX (fornece visibilidade em tempo real das aplicações nativas na nuvem usando topologias de nuvem pública, conteinerizada e microsserviços).

Orquestração e automação

Mario Pires de Almeida Filho, da GDN Tecnologia