O ritmo digital ganhou força no ano passado, levando os responsáveis pela rede e infraestrutura que entregam aplicativos para consumidores e usuários corporativos a buscar a automação e a perspectiva mais ágil e colaborativa trazida pelo DevOps. Mas mesmo que as organizações adotem a automação e reconheçam a importância da programabilidade (APIs e modelos), elas ainda não estão prontas para se estabelecer em uma única pilha para governar todas elas.
Com mais de 2.100 entrevistados abrangendo todas as funções de TI – de desenvolvedores de aplicativos a CEOs e engenheiros de segurança e rede – nossa pesquisa State of Application Delivery de 2017 descobriu que, à medida que o DevOps avança para a produção, seus motivadores e percepções também mudam.
A transformação digital requer mais do que apenas uma API corporativa e um grupo de desenvolvedores. Estamos vendo tanto (se não mais) foco nas mudanças internas necessárias para permitir que o negócio cresça de forma eficiente, proporcional ao seu crescimento. Colocar mais pessoas em tarefas não é mais um meio viável de escalar as operações comerciais porque não se trata apenas de fazer as coisas, mas também de fazê-las de forma rápida e eficiente.
Isso significa mais sistemas, mais coisas, mais aplicativos, mais ameaças e mais identidades para gerenciar. Na TI, a mesma luta para escalar e atender a essa demanda é contínua e cada vez mais respondida com automação e orquestração.
Em 2016, apenas 21% dos entrevistados em nossa pesquisa State of Application Delivery estavam usando uma ou mais estruturas de automação. Um ano depois, esse número saltou para 52% dos entrevistados, com mais da metade usando dois ou mais sistemas ao mesmo tempo. Todos os sistemas apresentaram crescimento, com Cisco, OpenStack e VMware apresentando os maiores ganhos, com 19%, 14% e 22%, respectivamente. Como prova de que a automação de serviços de rede e aplicativos é importante, o Cisco ACI é usado por 35% dos entrevistados. Considerando que é relativamente novo em comparação a empresas tradicionais como VMware e até mesmo OpenStack, esse é um salto considerável em apenas dois anos de monitoramento.
Enquanto 39% dos entrevistados usam apenas um sistema para automatizar serviços de infraestrutura e aplicativos, a maioria (61%) usa dois ou mais. Observamos que quanto maior a organização (e talvez não seja surpresa quanto mais aplicativos forem gerenciados), maior será esse número. O número médio de sistemas de automação em uso é 1,8, mas se você gerencia 3.000 ou mais aplicativos, pode esperar uma média de 2,43.
É fascinante notar que o número médio de modelos de nuvem em uso também é de 1,8. É bem possível que a automação em algumas organizações esteja vinculada exclusivamente à adoção e ao uso da computação em nuvem.
Isso faz muito sentido para empresas que há muito tempo dependem da VMware para virtualizar sua infraestrutura de computação. Praticamente (desculpas, na verdade) não há razão para uma organização eliminar a automação existente que alimenta seu provisionamento e gerenciamento de computação. A resposta geralmente está em sistemas adicionais, como o Cisco ACI, que expande o provisionamento e a automação do gerenciamento para a infraestrutura de serviços de rede e aplicativo.
Quase metade (47%) dos que dependiam de uma única estrutura de automação optaram pela VMware. A Cisco obteve 26% dos entrevistados com apenas uma estrutura, enquanto o OpenStack obteve 9%.
7% dependem exclusivamente de scripts Python para realizar automação e orquestração, o que justifica uma comunidade forte e bem suportada voltada para o cliente em torno de APIs de plataforma de serviços de rede e aplicativos.
O benefício mais citado do DevOps é a velocidade. As métricas associadas à medição de seu sucesso giram em torno da frequência de implantação e do tempo de colocação no mercado. No entanto, quando se trata de infraestrutura de serviços de rede e aplicativos, a escala se torna a força motriz por trás da automação e orquestração. Apenas 14% dos entrevistados citaram o Time to Market como o motivador por trás do uso de estruturas de automação, estabelecendo escala (37%) e redução de opex (37%) como o motivo por trás de sua adoção.
Suspeitamos que a redução do OpEx é um código para “manter o quo orçamentário”. Com os orçamentos de TI praticamente inalterados ou estagnados, de acordo com a última pesquisa da Computer Economics, otimizar orçamentos é, sem dúvida, uma preocupação significativa. Escalar sem adicionar mais funcionários é difícil, dadas as proporções já significativas de dispositivos para engenheiros, então automação e orquestração são uma maneira de escalar sem aumentar drasticamente o orçamento operacional.
É interessante notar que a automação geralmente tem o impacto de melhorar a velocidade de uma implantação. Ao mapear fluxos de valor como primeiro passo para orquestrar processos de implantação, geralmente é fácil encontrar os “tempos de espera” que causam atrasos na implantação. Esses tempos de espera geralmente são transferências entre equipes ou "tempo na fila" esperando um engenheiro ficar livre para executar uma tarefa específica. A automação pode reduzir esses tempos de espera e o tempo em filas, o que tem o benefício de acelerar todo o processo, melhorando assim o tempo de colocação no mercado.
Uma olhada nos drivers SDN conta uma história semelhante, com 62% adotando SDN para controlar despesas operacionais.
Muito antes de tudo definido por software se tornar o status quo, a programabilidade possibilitou ecossistemas intrafornecedores ao fornecer os meios para integrar produtos e oferecer recursos mais abrangentes aos clientes. Essas mesmas APIs agora floresceram na economia de Outras APIs e permitem uma ampla variedade de funções e recursos, tanto diretamente para os clientes quanto incentivando uma integração mais ampla com sistemas de código aberto.
Seja relacionado à infraestrutura de nuvem ou de data center, a programabilidade é como as redes e a infraestrutura de aplicativos são automatizadas, os processos se tornam orquestração e a escala é finalmente alcançada. A programabilidade é mais frequentemente associada a APIs e cada vez mais à noção de modelos. Ambas apresentaram picos dramáticos na importância percebida em nossa pesquisa, com maiorias claras designando ambas como características “mais importantes” para a infraestrutura.
Menos bem compreendida e discutida é a programabilidade do caminho de dados; isto é, a capacidade de interceptar, inspecionar e modificar dados em andamento. Isso permite funções da camada de aplicação, como reescrever URLs, proteger cookies e adicionar/remover cabeçalhos HTTP, bem como uma inspeção mais profunda de protocolos que se prestam bem à segurança (principalmente diante de uma nova exploração).
Surpreendentemente, esse recurso é considerado “mais importante” do que APIs ou modelos. Enquanto 52% dos entrevistados consideram as APIs “mais importantes” e 53% dizem que os modelos são “mais importantes”, 57% marcam a programabilidade do caminho de dados como sendo “mais importante”.
Os benefícios comerciais da programabilidade do caminho de dados em termos de agilidade, particularmente no campo da segurança, fornecem amplo ímpeto para que os entrevistados adotem tais recursos.
Programabilidade, automação e orquestração não vão desaparecer, e é animador ver a porcentagem significativa de funções fora do desenvolvimento de aplicativos adotando esses conceitos. Embora eles possam ver a automação, a orquestração e conceitos relacionados como respostas táticas para enfrentar desafios como orçamentos e escala, eles certamente estão participando do buffet que é o DevOps para fornecer a cobertura aérea necessária para permitir a transformação digital do negócio, por dentro e por fora.
Sinta-se à vontade para ler os dados em formato de slide no SlideShare .