Existe uma implantação mínima viável para o NetOps?
É realmente tudo ou nada para automação de rede?
A automação de rede – a prática de DevOps no pipeline de produção – já está em uso por uma porcentagem significativa de organizações. Embora muito poucos estejam totalmente envolvidos, a maioria (77% de acordo com nosso último State of Application Delivery ) está pilotando ou usando parcialmente a automação na produção.
Um dos conceitos intimamente associados ao DevOps – e, portanto, frequentemente vinculado ao NetOps – é a noção de um produto mínimo viável (MVP).
Faz parte da metodologia Agile e é usada como uma forma de acelerar os ciclos de desenvolvimento e levar soluções ao mercado mais rapidamente. Isso é algo que precisamos desesperadamente na “rede”. Você deve se lembrar da pesquisa da Appian mencionada em um blog anterior , que nos surpreendeu com uma pesquisa que dizia que 72% dos entrevistados não tinham confiança na capacidade de TI de atender às necessidades do negócio.
Ai. Apesar do uso bastante extensivo da automação em TI, desenvolvedores e partes interessadas do negócio ainda não confiam em nossa capacidade de fazer as coisas.
Portanto, adotar ferramentas, tecnologia e metodologias do DevOps para acelerar as coisas (por meio de uma escala mais inteligente) não é tão louco assim. Mas antes de descobrirmos como aplicar o MVP à rede, precisamos entender o que ele é. Então, para aqueles que não estão familiarizados com DevOps, Agile ou MVP, aqui está uma definição direta da Agile Alliance:
Um produto mínimo viável (MVP) é um conceito do Lean Startup que enfatiza o impacto do aprendizado no desenvolvimento de novos produtos. Eric Ries definiu um MVP como a versão de um novo produto que permite que uma equipe colete a quantidade máxima de aprendizado validado sobre os clientes com o mínimo de esforço . Esse aprendizado validado se dá na forma de saber se seus clientes realmente comprarão seu produto.
Uma premissa fundamental por trás da ideia de MVP é que você produza um produto real (que pode ser nada mais do que uma landing page ou um serviço com aparência de automação, mas que é totalmente manual nos bastidores) que você pode oferecer aos clientes e observar seu comportamento real com o produto ou serviço. Ver o que as pessoas realmente fazem em relação a um produto é muito mais confiável do que perguntar às pessoas o que elas fariam.
Uma equipe usa efetivamente o MVP como a peça central de uma estratégia de experimentação. Eles levantam a hipótese de que seus clientes têm uma necessidade e que o produto no qual a equipe está trabalhando satisfaz essa necessidade. A equipe então entrega algo a esses clientes para descobrir se de fato eles usarão o produto para satisfazer essas necessidades. Com base nas informações obtidas neste experimento, a equipe continua, altera ou cancela o trabalho no produto.
Este é o ponto neste tratado onde observo que muitos dos conceitos associados ao DevOps (e suas tecnologias e metodologias relacionadas) nem sempre são bem traduzidos quando aplicados a uma iniciativa NetOps. Experimentação não é um termo usado por engenheiros, arquitetos ou executivos de TI ao discutir mudanças na rede.
O raio da explosão, veja bem. É grande e responsável. A maioria das organizações não tem alta tolerância ao risco operacional, e por um bom motivo. As interrupções custam dinheiro de verdade – e, às vezes, empregos. A rede não é realmente um bom lugar para experimentação.
Mas isso não significa que não haja uma implantação mínima viável (MVD) para NetOps.
Definindo um MVD para NetOps
O pipeline de produção hoje é composto por recursos compartilhados, como switches, roteadores, DNS e roteamento multinuvem (GSLB), bem como serviços de aplicativos por aplicativo, como balanceadores de carga, WAF e controle de acesso a aplicativos.
Curiosamente, se observarmos a taxa de mudança associada aos recursos compartilhados, descobriremos que eles são bastante nominais. Ou seja, eles têm uma baixa taxa de mudança. Isso é bom, porque eles também têm baixa tolerância a interrupções. Vá para os recursos por aplicativo e você encontrará uma taxa de mudança maior com uma tolerância maior para interrupções.
Afinal, esse é um dos benefícios de uma arquitetura por aplicativo: isolamento do caminho de dados que protege outros aplicativos de interrupções quando algo dá errado.
Ao longo desse caminho de dados estão, em média, os dezesseis serviços de aplicativos diferentes que, segundo nossa pesquisa, as organizações usam para entregar e proteger seus aplicativos. Alguns deles – como um firewall de rede e DNS – são recursos compartilhados . Outros não, ou pelo menos não precisam ser. Hoje, eles podem ser implantados em uma plataforma compartilhada, mas podem ser arquitetados em seu próprio caminho de dados se você tiver um bom motivo para isso.
O que, claro, é o que vou lhe dar.
O bom motivo é que você pode desenvolver efetivamente um MVD para um aplicativo se adotar uma arquitetura por aplicativo para os serviços de aplicativo que estão fortemente acoplados ao aplicativo em primeiro lugar.
Como nossa definição de MVP nos diz, o “produto” (no nosso caso, uma implantação de aplicativo) não precisa ser totalmente automatizado. Se operarmos com a premissa de que os recursos mais arriscados e menos tolerantes devem continuar a ser configurados (e verificados) manualmente, ainda ganharemos terreno. Firewalls e serviços principais como DNS têm uma taxa de alteração muito baixa, então podemos supor que métodos manuais não afetarão significativamente o cronograma de implantação. Isso é ainda mais verdadeiro se automatizarmos a maior parte dos serviços de aplicativos por aplicativo, porque então estaremos liberando tempo para operadores e engenheiros fazerem alterações manuais, se necessário.
Supondo que a proporção de serviços principais (compartilhados) para serviços de aplicativos por aplicativo seja de cerca de um para três*, isso significa que nossa organização média tem pelo menos quatro recursos compartilhados para gerenciar manualmente e doze recursos por aplicativo para automatizar.
Olhando para a extensa lista de serviços de aplicativos ( atualmente estamos monitorando trinta serviços distintos ), notaremos que alguns deles são necessários para entregar ou proteger um aplicativo (DDoS, WAF, balanceamento de carga para escala, acesso ao aplicativo), enquanto outros são mais, digamos, aprimoramentos . Seriam serviços de aplicativos como opções de aceleração para melhorar o desempenho ou logon único (SSO) para aumentar a produtividade.
Então, se considerássemos a implementação de um MVD, poderíamos adotar uma abordagem ágil e focar nos serviços de aplicativos que são essenciais para a entrega e segurança no primeiro dia. Isso não significa que estamos ignorando as melhorias, significa apenas que vamos focar inicialmente nas críticas e automatizá-las primeiro. Ainda podemos gerenciar manualmente os serviços que melhoram a produtividade ou o desempenho, mas para um MVD queremos nos concentrar nos serviços que impactam o lucro.
Uma abordagem MVD para a rede ágil
Abordar a automação com a intenção de definir e entregar um MVD significa que estamos nos movendo mais rápido (somos mais ágeis) e nos dá a oportunidade de iterar na automação para melhorá-la e expandi-la a cada sprint (medido em semanas, não em trimestres) até que tenhamos um produto sólido e sustentável (implantação automatizada).
Adotar uma estratégia de automação baseada em MVD exige comprometimento não apenas com uma arquitetura, mas também com uma abordagem e atitude focadas em aplicativos. Isso ocorre porque esse tipo de abordagem exige uma compreensão do aplicativo e de suas necessidades, tanto de uma perspectiva operacional quanto de um ponto de vista comercial. O MVD de um aplicativo pode não corresponder ao MVD de outro. Essa é uma das razões pelas quais a arquitetura por aplicativo é um componente tão crítico na transição de uma rede fixa e manual para um pipeline ágil (automatizado).
Então, verifica-se que existe uma implantação mínima viável para NetOps. O que significa que você pode adotar uma abordagem ágil para automação de rede – uma que será infinitamente mais rápida (e segura) se você fizer a transição para uma arquitetura por aplicativo como parte de suas iniciativas de rede ágil.
Automatize (quase) todas as coisas da rede.
*isso é totalmente um SWAG baseado na lista, na minha experiência e na minha (forte) opinião. Sua quilometragem e definição podem variar.