Consistência. No mundo da tecnologia, usamos esse termo para descrever a característica de equivalência. Algo é consistente quando se comporta da mesma maneira ao longo do tempo ou sob diferentes condições. A consistência continua sendo um problema para as empresas que operam em um mundo multinuvem. De acordo com o nosso relatório State of Application Services de 2019, esse é o caso da maioria (87%) de vocês.
Certamente, a variação nas taxas de implantação de serviços de aplicações entre data centers e a nuvem aponta para uma causa simples: a falta de consistência na implantação desses serviços.
Mas essa não é a única causa da inconsistência. Segundo a mesma pesquisa, muitas pessoas estão implantando serviços de aplicações localmente e na nuvem pública, mas ainda enfrentam dificuldades para manter a consistência, especialmente no que diz respeito à segurança.
Isso exige uma análise mais aprofundada do que significa "consistência", pois suspeito que parte do problema esteja na incapacidade de reconhecer que existem duas camadas distintas de consistência e que ambas são importantes.
Serviços de Aplicação não são Controladores de Entrega de Aplicações
No cerne desta discussão sobre consistência está a diferença entre um controlador de entrega de aplicações (ADC) e um serviço de aplicação.
O ADC é uma plataforma que fornece serviços de aplicação. Esse ADC é um sistema independente, assim como o Kubernetes. O Kubernetes é uma plataforma para implantar e operar contêineres. Um ADC é uma plataforma para implantar e operar serviços de aplicação.
Isso é importante porque as plataformas (ou sistemas, se preferir) têm uma noção de consistência distinta daquela dos "elementos" que implantam e operam. A consistência está na camada operacional, ou seja, no gerenciamento e na operação da plataforma e dos serviços de aplicativos que ela fornece.
Consistência funcional
Isso é claramente diferente da consistência funcional oferecida por cada serviço de aplicação. A consistência funcional abrange os recursos do serviço de aplicação. Geralmente, é a isso que as pessoas se referem quando apontam um desafio de consistência em ambientes multicloud, pois esse é o aspecto mais visível.
É particularmente difícil alcançar a consistência funcional ao implantar serviços de aplicações de diferentes provedores. Um serviço de WAF ou antibot de um fornecedor não é necessariamente equivalente, em termos funcionais, a um serviço de WAF ou antibot de outro fornecedor.
Um dos motivos pelos quais as organizações têm dificuldade para manter a consistência em ambientes multinuvem não é a falta de implantação de serviços de aplicações na nuvem, mas sim a implantação de diferentes serviços de aplicações com recursos funcionais inconsistentes. A padronização com base na equivalência funcional ajudará as organizações a alcançar a consistência que têm dificuldade de obter.
Consistência operacional
A segunda fonte de inconsistência, mencionada com menos frequência, está na camada de plataforma. Para um número significativo de organizações empresariais, trata-se do ADC. Ao migrar para a nuvem pública, muitas organizações optam (intencionalmente ou não) por usar opções nativas da nuvem para os serviços de aplicações.
Isso introduz imediatamente uma inconsistência operacional na camada de plataforma. A forma como você provisiona, integra e opera esses serviços de aplicação é uma questão operacional e gera dívida operacional assim que você se conecta à primeira API.
Provavelmente, você não está usando serviços de aplicações nativos da nuvem no ambiente local. Isso significa que agora você precisa lidar com duas plataformas diferentes de serviços de aplicações. Elas têm métodos distintos de gerenciamento, análise, monitoramento, enfim, tudo.
É como usar dois ADCs diferentes no ambiente local. Embora algumas organizações muito grandes consigam fazer isso funcionar, ao longo dos anos percebemos que a maioria das organizações padroniza uma única plataforma de ADC. A consistência operacional e a capacidade de replicar políticas de serviços de aplicações em todas as aplicações têm sido fatores determinantes para essa decisão.
Mas, ao migrar para a nuvem, alguns se esqueceram do motivo pelo qual padronizaram uma plataforma de ADC: consistência operacional e suporte. A introdução de plataformas adicionais inevitavelmente aumenta a carga sobre as operações e prejudica a busca por consistência.
A consistência exige padronização
Padronização pode ser um termo assustador para algumas pessoas que acreditam que ela inibe a inovação. Mas ainda mais assustadora é a falta de regras, que pode até incentivar a inovação, mas, a longo prazo, é insustentável e cria um ambiente operacional caótico.
Com a TI sob pressão para gerar valor para a empresa, aumentar a equipe de operações para manter várias plataformas e uma profusão de serviços de aplicativos parece ir na contramão do objetivo de alcançar consistência em ambientes multicloud.
A padronização — especialmente na camada operacional — é um componente essencial para a inovação, pois reduz a necessidade de a equipe se concentrar na operação das plataformas e, em vez disso, incentiva a colaboração em políticas e arquitetura.
Ao garantir a consistência operacional e funcional em todos os ambientes, as organizações podem alcançar a uniformidade de políticas desejada sem comprometer seus orçamentos.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...