O DevOps vai roubar meu trabalho?
É um medo comum: o DevOps significará o fim do meu trabalho? Afinal, o DevOps significa que os desenvolvedores realizam operações, certo? O DevOps é uma automação. E se eu me automatizar fora do meu emprego atual? Entrega contínua e os containers significam que o pessoal de operações está obsoleto? O DevOps é tudo como código: infraestrutura-como-código, teste-como-código e mais isto ou aquilo “as a code”. Mas, e se eu não tiver habilidades definidas para fazer parte de tudo isso?
Na medida em que mais e mais devs gerenciam todo o ciclo de vida de um aplicativo, é muito fácil ficar preso na ideia do DevOps. Os containers, provavelmente, acabam contribuindo muito para essa linha de pensamento. Quando os containers surgiram na cena, eles foram promovidos como uma forma dos desenvolvedores um medo comum: o DevOps significará o fim do meu trabalho? Afinal, o DevOps significa que os desenvolvedores realizam operações, certo? O DevOps é uma automação. E se eu me automatizar fora do meu emprego atual? Entrega contínua e os containers significam que o pessoal de operações está obsoleto? O DevOps é tudo como código: infraestrutura-como-código, teste-como-código e mais isto ou aquilo “as a code”. Mas, e se eu não tiver habilidades definidas para fazer parte de tudo isso?
#1. Eu não sou mais necessário na equipe
Na medida em que mais e mais devs gerenciam todo o ciclo de vida de um aplicativo, é muito fácil ficar preso na ideia do DevOps. Os containers, provavelmente, acabam contribuindo muito para essa linha de pensamento. Quando os containers surgiram na cena, eles foram promovidos como uma forma dos desenvolvedores construírem, testarem e implemetarem seu código, “tudo-em-um”. Sendo assim, qual papel o DevOps desempenha na equipe de operações, ou testes, ou mesmo QA?
Isso decorre de um mal entendido dos princípios do DevOps. O primeiro princípio do DevOps, ou o “First Way”, é o Systems Thinking, qual seja, enstruírem, testarem e implemetarem seu código, “tudo-em-um”. Sendo assim, qual papel o DevOps desempenha na equipe de operações, ou testes, ou mesmo QA?
Isso decorre de um mal entendido dos princípios do DevOps. O primeiro princípio do DevOps, ou o “First Way”, é o Systems Thinking, qual seja, enfatizar uma abordagem holística para gerenciar e entender todo o ciclo de vida de um aplicativo ou serviço. Isso não significa que os desenvolvedores do app aprendam e gerenciem todo o processo. Em vez disso, é a colaboração de pessoas talentosas e qualificadas para garantir o sucesso como um todo. Tornar os desenvolvedores exclusivamente responsáveis pelo processo é praticamente o oposto extremo dessa premissa – essencialmente a consagração de um único silo em detrimento de todo o ciclo de vida da aplicação.
Existe um lugar para a especialização em DevOps. Assim como o engenheiro de software com educação clássica em conhecimento de regressão linear e pesquisa binária é desperdiçado escrevendo playbooks Ansible e arquivos Docker, o sysadmin altamente qualificado com o conhecimento de como proteger um sistema e otimizar o desempenho do banco de dados é desperdiçado escrevendo CSS e projetando fluxos de usuário. O grupo mais eficaz para escrever, testar e manter uma aplicação é uma equipe de pessoas com diferentes conjuntos de habilidades e backgrounds.
#2. Meu trabalho será automatizado
Preciso ou não, o DevOps às vezes pode ser visto como um sinônimo de automação. Qual trabalho é deixado para a equipe de operações e de testes quando builds automatizados, testes, deploys, monitoramento e notificações representam grande parte do ciclo de vida da aplicação? Este foco na automação pode estar parcialmente relacionado ao Second Way: Amplify Feedback Loops. Esta segunda premissa do DevOps de priorizar o feedback rápido entre as equipes em oposição à aplicação leva ao deploy – desde o monitoramento e manutenção até o deploy, teste, desenvolvimento etc., e a ênfase para tornar o feedback importante e acionável.
Embora o Second Way não esteja especificamente relacionado com a automação, muitas das equipes lidando com ferramentas de automação em seus pipelines de implementação facilitam notificações rápidas e ações rápidas, ou correção de curso com base em feedback no suporte a essa premissa. Tradicionalmente idealizado por humanos, é fácil entender por que um foco na automação pode levar à ansiedade sobre o futuro do trabalho.
A automação é apenas uma ferramenta, não uma substituição de pessoas. Pessoas inteligentes presas fazendo as mesmas coisas indefinidamente, apertando o grande botão vermelho dos Jetsons é um enorme desperdício de inteligência e criatividade inexploradas.
A automação do trabalho árduo diário significa mais tempo para resolver problemas reais e criar soluções criativas. Os seres humanos são necessários para descobrir o “como e por quê”; Os computadores podem lidar com “copiar e colar”.
#3. Eu não tenho o conjunto de habilidades necessárias para isso
“Como vou fazer isso? Não sei como automatizar. Tudo é código agora – eu tenho que ser um desenvolvedor e escrever código para trabalhar com DevOps?” O terceiro medo é, em última instância, um medo da autoconfiança. À medida que a cultura muda, sim, as equipes serão convidadas a mudar junto, e alguns podem temer não possuir as habilidades necessárias para seguir realizando seus trabalhos.
A maioria das pessoas, no entanto, provavelmente já estão mais próximas disso do que imaginam. Senão, vejamos: o que é o Dockerfile, ou ferramentas de gerenciamento de configuração como Puppet ou Ansible, senão o “ambiente-como-código”? Os administradores de sistema já escrevem scripts shell e programas Python para lidar com tarefas repetitivas para eles. Não é dificil aprender um pouco mais e começar a usar algumas das ferramentas que já estão à disposição para resolver mais problemas – orquestração, implementação, manutenção de código – especialmente quando liberado do trabalho pesado das tarefas manuais para se concentrar no crescimento da aplicação propriamente dita.
A resposta a este medo reside na terceira premissa DevOps, qual seja: “The Third Way: A Culture of Continuous Experimentation and Learning”. A capacidade de tentar, falhar e aprender com erros sem culpa é um fator importante na criação de soluções cada vez mais criativas. O Third Way é embasado pelas duas primeiras premissas – permitindo a rápida detecção e reparação de problemas, e, assim como o desenvolvedor é livre para tentar aprender, outras equipes também o são.
As equipes de operações que nunca usaram gerenciamento de configuração ou programas escritos para automatizar o provisionamento de infraestrutura são livres para tentar/testar e aprender. As equipes de testes e QA são livres para implementar novos pipelines de teste e automatizar os processos de aprovação e de lançamento das aplicações. Em uma cultura onde é valorizado o aprendizado e o crescimento, todos têm a liberdade de adquirir as habilidades de que precisam para ter sucesso e aproveitar seu trabalho.
Qualquer prática ou mudança disruptiva em uma indústria pode criar medo ou incerteza, e o DevOps não é uma exceção. A preocupação com o trabalho de alguém é uma resposta razoável às centenas de artigos e apresentações que enumeram as inúmeras práticas e tecnologias aparentemente dedicadas a capacitar os desenvolvedores a assumir a responsabilidade por todos os aspectos da indústria.
Aa verdade, no entanto, é que o DevOps é “uma comunidade interdisciplinar de prática dedicada ao estudo da construção, evolução e operação de sistemas resilientes que mudam rapidamente e em escala“. DevOps significa o fim dos silos, mas não a especialização. É a uma forma de delegar o trabalho pesado aos sistemas automatizados, libertando o desenvolvedor para fazer o que as pessoas fazem melhor: pensar e imaginar. E se você está motivado para aprender e crescer, não haverá fim nas oportunidades que encontrar pela frente para resolver novos e desafiadores problemas na tecnologia.
O DevOps vai roubar o seu trabalho? Sim, mas em troca lhe dará um melhor.
Fonte: Opensource.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.