Não há dúvida de que agora estamos vivendo em uma era híbrida de várias nuvens. As empresas estão usando os principais provedores de nuvem, como AWS, Azure e GCP, com provedores de computação em nuvem de nicho surgindo no mercado. Simultaneamente, muitas organizações ainda retêm cargas de trabalho em data centers locais ou adotam colocação. Independentemente do padrão de implantação, as equipes de DevOps desejam a mesma elasticidade da nuvem, mas está se tornando cada vez mais difícil gerenciar consistentemente as nuances de cada provedor de serviços.
Para dar suporte às arquiteturas poliglotas distribuídas de hoje, uma camada comum pode facilitar os problemas ao implantar aplicativos e provisionar vários servidores. Ao desacoplar o plano de controle de infraestrutura de provedores de nuvem específicos, um console de gerenciamento unificado pode trazer visibilidade de custo e desempenho, capacitando o CloudOps com conhecimento antes da eles cometem. Mas a engenharia desse resultado dependeria de plug-ins para cada ambiente e de um conjunto robusto de APIs para permitir o controle programático.
Recentemente me encontrei com Jake Warner, Cycle.io, para explorar como o aumento da abstração da infraestrutura pode resolver os problemas acima. De acordo com Warner, uma camada padrão para gerenciamento de computação é necessária para permitir um controle consistente sobre ambientes multinuvem e sob medida no local. A seguir, definiremos esse conceito e consideraremos os benefícios que a abstração de infraestrutura pode trazer para o desenvolvimento de software empresarial moderno.
Os problemas enfrentados pelo gerenciamento de infraestrutura
Gostamos de pensar que a nuvem é abrangente e que todos estão a bordo com um estilo de computação semelhante. No entanto, isso está longe de ser verdade. A multinuvem está crescendo e 95% das empresas estão tornando a multinuvem uma prioridade estratégica em 2022, um Estudo Valtix encontrado. No entanto, apenas cerca de metade dos entrevistados achava que tinha as ferramentas e habilidades adequadas necessárias para executar uma estratégia multinuvem.
“Há muito valor em multinuvem, incluindo redução de riscos, garantia de melhor tempo de atividade e flexibilidade para selecionar o melhor hardware para o caso de uso”, disse Warner. “Mas a multinuvem é extremamente complexa.” Usar múltiplas nuvens significa suportar processos operacionais cada vez mais variáveis para cada ambiente. Seja AWS, GCP, Azure, Equinix ou Vultr, os operadores também exigem um nível profundo de visibilidade dos dados de telemetria. Isso se torna complicado de rastrear, pois o software é cada vez mais modular e distribuídos em várias regiões de computação.
Além disso, os data centers locais estão longe de morrer – surpreendentemente, um Estudo da Spiceworks descobriu que 98% das empresas ainda usavam servidores locais. Servidores tradicionais são frequentemente preferidos devido a restrições corporativas ou para atender mandatos de conformidade de segurança. Também pode ser um caso cultural de “se funcionar, não conserte”. O dilema é que você não pode obter facilmente recursos de nuvem comuns, como dimensionamento automático e balanceamento de carga, enquanto estiver em sua própria infraestrutura.
Outro problema que Warner descreveu é que as empresas tradicionais de plataforma como serviço (PaaS) apresentam limitações inerentes se você pretende criar aplicativos e serviços substantivos. “Muitas dessas ofertas de PaaS tornam realmente fácil começar, mas, na maioria das vezes, os desenvolvedores são rapidamente forçados a fazer concessões com sua abordagem. Esses compromissos podem criar problemas técnicos de longo prazo, especialmente quando é hora de escalar”, disse ele. “Precisa de um servidor com uma configuração de hardware específica em uma região de destino? Boa sorte. Para a maioria das empresas de PaaS, a rampa de saída é tão definida quanto a rampa de acesso.”
Movimentos em direção à abstração de infraestrutura
Já estamos vendo movimento no mercado para gerenciar os encargos operacionais de várias nuvens. Um exemplo é o Infrastructure Abstraction Layer (IAL), de código aberto da Cycle.io, que Warner explicou que pode atuar como um sistema padronizado para implantações. Com a especificação, um provedor de infraestrutura pode gerar um endpoint de API para permitir o provisionamento de infraestrutura sem exigir uma integração profunda entre os dois serviços. Com esse endpoint ativo, uma plataforma de desenvolvimento de aplicativos ou orquestrador ganha a capacidade de enviar cargas JSON padronizadas para provisionar servidores, alocar IPs, configurar regiões e várias outras solicitações. A resposta, outro payload JSON, confirma que a solicitação desejada foi concluída e inclui um ID exclusivo.
Com mais controle programático sobre a infraestrutura, um engenheiro pode interagir com uma lista padronizada de todos os servidores, em vários provedores, para implantar e agir com base nessas informações em um console unificado. Essa camada é um local oportuno para ajudar a comparar custos e configurações de servidor para diferentes regiões também. Também é um local vantajoso para filtrar por proximidade para mostrar os servidores disponíveis mais próximos para otimizar a entrega.
Benefícios de unificar a implantação de várias nuvens
A separação da camada de gerenciamento de infraestrutura dos provedores de serviços pode trazer benefícios potenciais para o DevOps, disse Warner. Por um lado, permite que as operadoras estendam a automação da infraestrutura em seus data centers privados, ajudando-as a obter a mesma capacidade de programação que teriam na nuvem. Um certo grau de padronização também pode remover muitos dos contras da multinuvem: “Os desenvolvedores podem mudar de um provedor para outro sem grandes mudanças ao longo do caminho”, disse ele.
Claro, a TI não quer um fardo adicional. É por isso que uma solução baseada em API é necessária para permitir a programação, disse Warner. Ao adotar uma abordagem de API RESTful para gerenciar uma infraestrutura híbrida, os operadores podem criar fluxos personalizados com base em características ambientais refinadas que mudam com o tempo, como latência, despesas ou localização. “Uma das coisas interessantes é que permite que os provedores de infraestrutura façam ajustes e melhorias constantemente sem ter que reenviar sua integração com uma plataforma subjacente”, disse Warner.
A flexibilidade do LowOps
A implantação de software atual é cada vez mais ampla e variada – uma relatório recente da HashiCorp descobriu que 76% das organizações já são multinuvem. A multinuvem traz muitas vantagens, mas também multiplica o número de tarefas operacionais necessárias. Ao mesmo tempo, as organizações desejam aproveitar os investimentos em data centers locais enquanto forem economicamente viáveis. Automatizar o DevOps para uma infraestrutura tão variada pode ser difícil sem uma camada unificada desacoplada de cada nicho de área de computação.
Segundo Warner, as empresas exigem uma plataforma LowOps e flexibilidade para abstrair essa automação em sua própria infraestrutura quando apropriado, o que pode variar muito. Por exemplo, as operadoras podem estar trabalhando com uma frota de dezenas de milhares de dispositivos IoT. Além disso, como abordamos anteriormente, um método LowOps pode ser benéfico para empresas de pequeno a médio porte que podem não ter recursos para dar suporte a infraestruturas complexas como Kubernetes.
Poderia algo como IAL se tornar um padrão aberto? Bem, no momento em que escrevo, a especificação IAL foi implementada apenas pela Cycle.io e alguns de seus parceiros de infraestrutura, mas não há razão para que não possa ser extrapolada para uma especificação comum no futuro, disse Warner. Ele ainda prevê um mercado comunitário ou registro compartilhado para abstrações de infraestrutura, permitindo que as plataformas suportem centenas de provedores de nuvem.
Em conclusão, a necessidade de LowOps, combinada com a ascensão de várias nuvens e o poder de permanência dos data centers locais, está alimentando a necessidade de um centro de gerenciamento desacoplado. A abstração de infraestrutura pode permitir a conveniência de uma PaaS enquanto capacita as operadoras com opções de infraestrutura personalizadas.