Esqueça as crianças. Precisamos disso para automação de TI.

Nosso filho mais novo tem nove (NOVE) (E MEIO! NÃO ESQUEÇA DA METADE!) e atualmente ele está fascinado por robôs. Não apenas brincando com eles, mas programando-os. Como ambos os pais possuem diplomas avançados em ciência da computação, você pode imaginar que estamos entusiasmados e encorajadores com essa tendência em particular.

Então, é claro que robôs que oferecem modelos de programação fáceis de aprender são uma coisa comum em nossa casa atualmente. Um dos brinquedos deste verão foi da Wonder Workshop , cujos robôs podem ser programados por meio de uma linguagem do tipo “bloco”.

Essa é a norma para as crianças de hoje. Esta criança brinca com vários "jogos" em seus vários dispositivos, todos os quais usam o mesmo modelo de "bloco" para construir programas. Até mesmo seu robô Lego Mindstorms Ev3 usa um mecanismo semelhante, onde as construções de programação são blocos que você conecta. Variáveis e condições são definidas ao selecioná-las, e não há nenhum “código” real exibido na tela.

Mas você sabe que está lá.

Na época em que eu estava avaliando soluções de BPM (Business Process Management), eles usavam um paradigma semelhante para permitir que as partes interessadas do negócio definissem processos. Sua interface refletia a natureza dos processos, ou seja, você construía um fluxograma usando um modelo de arrastar e soltar, mas grande parte da construção da orquestração era realizada por meio de uma interface mais fácil de aprender. Como os que meu filho mais novo usa hoje, só que mais parecido com o Visio. Agora que penso nisso, acho que é muito mais parecido com o Visio.

Esqueça as crianças. É nessa direção que a automação de TI precisa seguir. Não há razão para a complexidade inerente à automação de TI hoje, além do fato de que ninguém ainda reconheceu que, se quisermos incentivar mais isso — e por pessoas que não são programadoras naturais — precisamos encontrar uma maneira melhor de construir os fluxos de trabalho que representam os processos de TI usados para implantar, gerenciar e configurar a infraestrutura de TI.

A primeira coisa que precisamos concordar é que programática não significa necessariamente "você pode fazer o que quiser, porque codifica". Isso é verdade, no sentido mais liberal da palavra, mas também significa a capacidade de mudar ou definir comportamento programaticamente. Há um conjunto limitado de ações necessárias para executar um fluxo de trabalho em TI, e a maioria é habilitada hoje pela (outra) economia de API. Ao fornecer uma interface que encapsula esse conjunto limitado de ações e fornece construções lógicas claras e fáceis de entender (se/então, enquanto, funções iterativas), poderíamos aparentemente eliminar a tendência aos mecanismos de script não estruturados que introduzem muito mais dívida técnica nas operações de TI do que a maioria dos softwares desenvolvidos em empresas no passado. Esse nível de abstração restrita também permitiria que codificadores não nativos (engenheiros e arquitetos de rede e armazenamento) produzissem fluxos de trabalho bem construídos e altamente sustentáveis (um importante impulsionador da padronização). Quando combinado com um backbone sem servidor para executar fluxos de trabalho , esse modelo reduz o investimento necessário para criar, manter e executar fluxos de trabalho apropriados para operações de TI.

Isso é importante porque precisamos abordar a automação de TI com um olhar voltado para a sustentabilidade. Um script hoje funciona muito bem, mas ele pode ser adaptado às pessoas e aos processos no futuro?

Agora, talvez não precisemos de uma solução tão simples (ou colorida), mas a premissa na qual a interface é projetada é importante, eu acho, para se adaptar à medida que olhamos para o futuro da automação de TI e como construímos (e mantemos) o código que eventualmente fará a TI funcionar. Infelizmente, tendemos a transferir a complexidade dos sistemas subjacentes para o design dos sistemas (e, portanto, das interfaces) que interagem e os controlam. Queremos expor todos os botões e maçanetas possíveis. No mínimo, um corretor de API que fornece uma maneira de agregar a complexidade natural das CLIs transformadas em APIs em tarefas operacionais mais compreensíveis seria uma bênção para aqueles encarregados de automatizar redes de TI e serviços de aplicativos. O login pode ser um processo complexo que envolve várias etapas que se repetem sempre. Compô-los em um único “serviço” os torna repetíveis e infinitamente mais auditáveis, além de consistentes. Combine isso com uma interface (mais) intuitiva e temos um vencedor em automação de TI.

As interfaces para aplicativos de “codificação” para crianças hoje provam que é possível fazer isso sem que os usuários sintam que estão olhando para um ENIAC sem um manual para orientá-los. Podemos fazer melhor e, se quisermos escalar a transformação digital interna para acompanhar o ritmo dos negócios, precisamos fazer isso.