Este é o quarto artigo de uma série sobre os desafios decorrentes da transformação digital.
- A verdade surpreendente sobre a transformação digital
- A verdade surpreendente sobre a transformação digital: o caos da nuvem
- A verdade surpreendente sobre a transformação digital: negligenciar a segurança
Deseconomia de escala.
Ao expandir uma empresa, especialmente ao longo do tempo, você tende a acumular uma bagagem que precisa ser administrada. Raramente diminui o número de aplicações às quais precisa dar suporte. Normalmente, esse número aumenta — às vezes, de forma exponencial no intervalo de poucos anos. Em períodos sem grandes mudanças, a quantidade de aplicações tende a dobrar a cada quatro anos. Quando uma nova tecnologia se impõe, esse número aumenta ainda mais.
Cada aplicativo exige mais suporte de operações (isto é, rede, computação, armazenamento e segurança, para quem não está familiarizado). Mas, assim como sabemos que a escalabilidade vertical tem seus limites (só é possível adicionar uma quantidade limitada de hardware para resolver o problema), também sabemos que o mesmo vale para os recursos humanos. Não podemos simplesmente continuar ampliando a equipe de operações para acompanhar o crescimento dos aplicativos. Isso aumenta a carga de gestão (overhead) e torna a comunicação mais lenta, pois temos dificuldade até para descobrir quem é responsável pelo quê, quanto mais para de fato conversar com essa pessoa.
É isso que a Lei dos Deployments Decrescentes nos mostra. Chega um ponto em que a quantidade de profissionais de operações acaba dificultando o deployment, e começamos a perceber que é preciso fazer concessões. Como Fausto negociando com o diabo, optamos pela velocidade em detrimento da segurança e pela escalabilidade em detrimento da estabilidade. Por fim, chegamos a um ponto de inflexão em que atingimos nosso limite teórico, e as equipes de desenvolvimento e operações, assim como a empresa, começam a buscar soluções em outros lugares.
Em resumo, há um limite para a quantidade de profissionais de operações que você pode contratar para lidar com o número crescente de aplicativos antes de esbarrar na Lei dos Deploys Decrescentes.
É por isso que a automação é fundamental para que as operações acompanhem o aumento do número de aplicações e a demanda por implantações mais rápidas. Afinal, não importa o quão rápido você digite: o processamento computacional é mais rápido.
Mas lembre-se de que automação vai além da criação de scripts.
Já usamos muitos scripts, e isso certamente tem sido um fator que nos mantém, pelo menos, competitivos nas implantações. Para que a automação seja realmente bem-sucedida, ela não deve ser executada individualmente para cada dispositivo ou aplicativo. Simplesmente não deve. Isso não é escalável. Se você está escrevendo um script para cada dispositivo ou aplicativo, não está fazendo automação da maneira certa.
A automação precisa estar centrada no processo (portanto, na verdade, trata-se de orquestração, mas esse é um moinho de vento contra o qual continuo investindo e que se recusa a cair) e na execução consistente. Isso significa que você precisa adotar a automação — e não apenas criar scripts para implementar mudanças. E isso exige uma nova abordagem que incorpore princípios de DevOps, como infraestrutura como código.
Infraestrutura como código
Infraestrutura como código é uma analogia. Isso significa que a infraestrutura propriamente dita pode ser composta por software ou hardware e estar na nuvem ou no local. A implementação é irrelevante para fins de implantação, pois usaremos APIs e artefatos de implantação para reproduzir o comportamento da infraestrutura como código. Ao desacoplar a configuração do dispositivo, podemos tratá-lo como se fosse uma caixa-preta.
O que importa são os artefatos de implantação — os modelos, scripts e políticas usados para provisionar e configurar o dispositivo para o serviço desejado. Eles são armazenados em um repositório (LOCAL). Esses artefatos descrevem completamente um determinado serviço — seja de rede, segurança, armazenamento ou infraestrutura de aplicações — e podem ser usados para recriá-lo quando necessário. Eles também podem ser usados para automatizar tarefas individuais — adicionar uma regra de firewall, implantar um balanceador de carga, configurar o WAF — e, em seguida, ser combinados em um processo orquestrado para viabilizar a implantação contínua.
A razão pela qual isso é importante para enfrentar a deseconomia de escala é que o uso exclusivo de scripts ainda exige uma tarefa por dispositivo. Um script transforma uma tarefa de cinco minutos em uma tarefa de cinco segundos. No entanto, ele ainda precisa ser acionado manualmente e requer a intervenção de pessoas para conduzir o processo. Isso não atende à necessidade mais ampla de automatizar todo o *processo* — e é disso que você precisa para alcançar a economia de escala necessária para competir em uma economia digital.
Fique de olho no último post desta série, no qual vamos explorar como disponibilizar, com segurança, o número cada vez maior de aplicativos implantados em ambientes conteinerizados.
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...