5 coisas que SREs e administradores de sistemas devem saber sobre o ROSA e serviços em nuvem

13 de maio de 2022Alex Handy7 minutos (tempo de leitura)

Kubernetes, containers e serviços em nuvem altamente escaláveis são os elementos modernos do sucesso do software comercial. Mas dar o salto para o Kubernetes requer treinamento, compreensão e muito trabalho de desenvolvedores, arquitetos e administradores de sistemas.

Para economizar tempo, acelerar os ciclos de desenvolvimento e limitar a agonia organizacional, geralmente faz sentido escolher uma oferta de Kubernetes gerenciada, em vez de operar a sua própria. Listamos cinco coisas que você deve saber se está considerando tomar esta decisão.

1. É a plataforma de aplicações que você não precisa gerenciar

O Kubernetes não é mais última novidade. Na verdade, é o mínimo que você precisa para operar. Assim como o Linux conquistou o mercado de servidores no início dos anos 2000, o Kubernetes domina a conversa sobre infraestrutura em nuvem já há algum tempo. A possibilidade de operar containers Linux em escala junto com serviços em nuvem, monitoramento e gerenciamento do ciclo de vida simplesmente é atraente demais para ser ignorada por desenvolvedores e administradores modernos que precisam de escala e confiabilidade.

No entanto, o Kubernetes é tão popular quanto complexo. Como o Kubernetes agora pode “fazer qualquer coisa”, pode ser complicado simplesmente colocá-lo em funcionamento e fazer alguma coisa. Existem muitas opções, configurações e hosts por aí, e todos eles vêm com seu próprio conjunto de necessidades e requisitos, assim como qualquer software.

Embora existam muitos motivos para executar seu próprio Kubernetes e até mesmo motivos para criar sua própria plataforma de aplicações, no final das contas, tudo nessa camada do stack é pura base. É possível inovar mais rápido com Kubernetes, mas esse é um benefício proporcionado pela plataforma como um todo, com todos os principais componentes em camadas trabalhando em harmonia com as necessidades dos usuários. Esses ambientes precisam estar disponíveis rapidamente e com maiores instâncias de segurança.

E quem já teve que configurar e manter ambientes de teste, construção e produção para hordas de desenvolvedores sabe que esta não é uma tarefa fácil. Pode ser necessária uma equipe inteira de pessoas para manter os sistemas funcionando e sincronizados com as necessidades dos desenvolvedores — e isso apenas no nível da aplicação.

Os departamentos de TI tradicionais normalmente levavam semanas, senão meses, para provisionar esses equipamentos. Mas o poder e a velocidade da nuvem automatizada podem reduzir esse processo para horas ou até minutos.

Para algumas empresas que não têm ciclos de TI extras a perder, o Red Hat OpenShift Service on Amazon Web Services (ROSA) fornece uma classe superior de serviço, suporte e hospedagem, juntamente com recursos de segurança aprimorados. Com os engenheiros em confiabilidade de site (SREs) da Red Hat operando a sua infraestrutura, sua equipe pode começar a trabalhar e se concentrar em suas aplicações, em vez de perder tempo instalando sistemas para começar a construir com base nesses clusters.

2. Os SREs da Red Hat gerenciam e automatizam tarefas usando o ROSA para você não ter que fazer isso

Reconhecemos um administrador de sistemas por sua carga de trabalho. Se eles estão fazendo muito trabalho manual, o tempo todo, talvez estejam perdendo o foco. Mesmo nos anos 90, um grande administrador de sistemas era medido pela força de seus scripts. Hoje, temos uma grande variedade de ferramentas para lidar melhor com essa automação, em vez de simplesmente recorrer ao antigo e confiável shell script.

Com ferramentas como Ansible, Argo CD e Git, praticamente qualquer fluxo de trabalho pode ser automatizado em um pipeline que faz o trabalho para desenvolvedores sem problemas e sem que o administrador precise se envolver. Mas leva tempo para construir e personalizar esse nível de automação, assim como qualquer infraestrutura.

Para equipes que ainda não são especializadas em criar software usando a nuvem e até mesmo para equipes que preferem passar seus ciclos longe da infraestrutura, o Red Hat OpenShift Service on AWS oferece ferramentas e processos de automação úteis para ajudar a acelerar o processo e, essencialmente, tornar a plataforma "chata".

Em vez de criar seus pipelines de desenvolvimento do zero, o ROSA pode vincular seus sistemas e ferramentas existentes, como GitHub e Ansible. Melhor ainda, nossos SREs construíram padrões para seus desenvolvedores usarem, com versões pré-configuradas de infraestrutura essencial prontas para serem usadas em um piscar de olhos.

Isso vai além do Red Hat OpenShift on AWS, pois o modelo aberto de nuvem híbrida oferecido pelo Red Hat OpenShift oferece flexibilidade para construir em outros provedores de nuvem, bem como no local. Por exemplo, você pode executar backups automaticamente em vários locais e provedores de nuvem, em todo o mundo, usando os serviços e sistemas que você já usa em maior escala.

Adicione serverless e Quarkus para Java e Kubernetes Operators e você terá um espaço com abrangência global, que opera em diversas nuvens e é totalmente automatizado para seus desenvolvedores acessarem e usarem, tudo com estruturas de proteção e provisionamento de segurança reforçada integrados.

Com menos trabalho manual a fazer, os administradores podem focar em tarefas inovadoras que desejem fazer, em vez de fazerem triagem de sistemas legados e arbitragem de déficits técnicos que provavelmente não gostam de fazer.

3. Suporte integrado da Red Hat e do AWS com acesso aos desenvolvedores open source que criaram essas ferramentas

Você já encontrou um bug que não estava documentado online, tinha um número infinito de prováveis causas e estava bloqueando o trabalho completamente? Até mesmo uma única característica destas já é suficiente para fazer com que toda uma equipe de TI fique frustrada e atrasada.

Quando ocorrem bugs e erros críticos, é essencial tratá-los com algo semelhante ao Caminho do Samurai: uma abordagem focada e disciplinada baseada no imediatismo, precisão e na preservação dos interesses do empregador. Também é melhor ter um exército do que um esquadrão.

E a Red Hat é um dos maiores exércitos de esmagamento de bugs que existe. É muito, muito difícil para os bugs se esconderem do olhar atento de nossa equipe de serviço e suporte. Aqui está um exemplo de um momento em que entramos em ação em um bug open source.

Isso acontece porque quando você nos pede ajuda com um bug, vamos começar a avaliar seu problema, replicá-lo e descartar grandes porções do stack. Geralmente, contribuímos com cerca de 5% do código em qualquer versão kernel do Linux.

Pode não parecer muito, mas os principais contribuidores podem variar ao longo do tempo, à medida que novos aspectos são adicionados ao kernel em torno de sistemas embarcados e dispositivos móveis. A Red Hat está muito focada no núcleo do Linux e, como tal, somos um dos maiores mantenedores e signatários de código contribuído para o kernel do Linux. Quando contribuímos com código para o kernel do Linux, nós o revisamos e testamos, mesmo quando não o escrevemos. Fazemos parte do trabalho duro, o dia-a-dia dos ciclos de cluster de gastos para testar e proteger esses projetos open source. E nós enviamos essas descobertas para o upstream.

O mesmo vale para o Kubernetes, onde somos o segundo maior colaborador de código corporativo do projeto. Ajudamos a conduzir muitos dos planos futuros para a comunidade do Kubernetes e, quando esses planos se estendem por alguns anos, tentamos tapar os buracos com soluções temporárias de código open source enquanto conduzimos as mudanças arquitetônicas de longo prazo que geralmente são necessárias para resolver questões sistêmicas.

Demos várias explicações simplesmente para dizer que o ROSA vem com suporte integrado da Red Hat e do AWS. Se você encontrar um bug realmente intrigante, vai trabalhar com colaboradores do kernel do Linux, colaboradores do Kubernetes e SREs especializados, que usam esses sistemas em escala todos os dias. Eles conhecem o software e, quando você precisar de ajuda, eles estarão lá, desde a base do stack até onde a aplicação é inicializada.

4. É mais do que Kubernetes, é uma plataforma de aplicações completa

Seus desenvolvedores precisam de todo tipo de... coisas. Bancos de dados, registros, repositórios, balanceadores de carga, firewalls, máquinas virtuais, filas de mensagens e pizza. Embora o ROSA não venha com pizza, ele tem os demais blocos de construção básicos. Com o apertar de um botão, você pode implantar ambientes de aplicações inteiros direcionados às necessidades de seus desenvolvedores.

Suas equipes estão criando APIs diretamente relacionadas aos resultados da sua empresa? O Red Hat OpenShift API Management oferece gerenciamento de API de nível empresarial projetado com base em open source, para que seus desenvolvedores possam começar a trabalhar e criar mais APIs geradoras de receita com mais rapidez.

Suas equipes estão tentando ingerir grandes quantidades de dados de forma assíncrona? O Red Hat OpenShift Streams for Apache Kafka oferece uma fila de mensagens gerenciadas, executada por nossos SREs, mas contendo seus dados e fornecendo a seus desenvolvedores um pipeline constante de dados para processamento.

Ou talvez seus desenvolvedores estejam tentando construir um cérebro. Para treinar algoritmos de AI/ML é preciso ter grandes conjuntos de dados, grandes quantidades de processamento para treinamento e sistemas facilmente acessíveis para que os cientistas de dados gerenciem ambos. Para eles, temos o Red Hat OpenShift Data Science.

E, é claro, o ROSA é totalmente integrado a todos os serviços da AWS nos quais você confia. Com mais de 170 integrações de serviço, os administradores podem aproveitar muitas coisas para simplificar sua carga de trabalho diária e fornecer aos desenvolvedores uma experiência de Kubernetes mais rápida e fácil de usar.

5. Permite que você foque em suas aplicações em vez de em Kubernetes

Os quatro primeiros motivos para a adotar o ROSA podem ser resumidos neste último. Como administrador, o dia a dia de montar sistemas e serviços, apagar incêndios e planejar o futuro certamente se tornou mais desafiador nos últimos anos. Como as empresas dependem mais fortemente de seus desenvolvedores de software para inovar e obter receitas, os facilitadores desses desenvolvedores que tiveram que correr na frente do trem de carga construindo os trilhos.

O Kubernetes foi um grande avanço para o gerenciamento de sistemas, permitindo que os administradores concentrassem sua atenção em grupos de sistemas, em vez de servidores únicos. Isso causou, no entanto, um crescimento exponencial na complexidade do gerenciamento, que é abordado por meio das milhares de ferramentas e serviços disponíveis para acrescentar sobre o Kubernetes.

Assim como um administrador moderno não gastaria tempo mexendo em um único container, ele também não deveria perder tempo mexendo em um único serviço. Esse container exigente deve ser eliminado e reiniciado a partir do repositório. E esse serviço complicado deve, talvez, simplesmente ser executado por especialistas que fornecem o próprio cluster como um serviço. Assim, os administradores podem se concentrar em capacitar seus desenvolvedores em vez de aprender um pequeno aspecto do Kubernetes.

Os desenvolvedores podem fazer coisas incríveis com um cluster totalmente automatizado, se tiverem a chance. Eles podem criar um novo banco de dados sem aterrorizar os administradores, que já definiram diretrizes inquebráveis para essas implantações por meio dos Kubernetes Operators. Os desenvolvedores podem criar ambientes inteiros sob demanda para testar teorias e novos softwares, todos isolados do resto do mundo com segurança. E o mais importante, eles podem inovar sem abrir um ticket de suporte.

Saiba mais

Sobre o autor

Alex Handy

Principal Product Marketing Manager

Red Hatter since 2018, technology historian and founder of The Museum of Art and Digital Entertainment. Two decades of journalism mixed with technology expertise, storytelling and oodles of computing experience from inception to ewaste recycling. I have taught or had my work used in classes at USF, SFSU, AAU, UC Law Hastings and Harvard Law.

I have worked with the EFF, Stanford, MIT, and Archive.org to brief the US Copyright Office and change US copyright law. We won multiple exemptions to the DMCA, accepted and implemented by the Librarian of Congress. My writings have appeared in Wired, Bloomberg, Make Magazine, SD Times, The Austin American Statesman, The Atlanta Journal Constitution and many other outlets.

I have been written about by the Wall Street Journal, The Washington Post, Wired and The Atlantic. I have been called "The Gertrude Stein of Video Games," an honor I accept, as I live less than a mile from her childhood home in Oakland, CA. I was project lead on the first successful institutional preservation and rebooting of the first massively multiplayer game, Habitat, for the C64, from 1986: https://neohabitat.org . I've consulted and collaborated with the NY MOMA, the Oakland Museum of California, Cisco, Semtech, Twilio, Game Developers Conference, NGNX, the Anti-Defamation League, the Library of Congress and the Oakland Public Library System on projects, contracts, and exhibitions.