Notícias e tendências em DevOps para ficar de olho em 2021

As organizações de TI e fornecedores dos quais elas dependem não deixaram de se mover neste ano. O ritmo da mudança não diminuirá em 2021, portanto, os desenvolvedores e usuários DevOps precisam estar preparados.

Para entender o desenvolvimento de software e novidades do DevOps deste ano, os editores da SearchSoftwareQuality conversaram com a editora sênior de notícias do TechTarget, Beth Pariseau, e o diretor de notícias, Chris Kanaracus.

Essa discussão ampla abordou os seguintes tópicos:

• Trabalho remoto DevOps. O trabalho remoto tem destacado os aspectos de DevOps que os desenvolvedores não haviam destacado anteriormente.
• Tendências do “low code” (código baixo). A busca por histórias de sucesso de clientes continua, enquanto os grandes fornecedores de nuvem se apressam para entrar no espaço “low code”.
• Tendências das ferramentas de CI/CD. O mercado de CI/CD passou por muitas aquisições e consolidações; as cadeias de ferramentas de C/ CD estão cada vez mais fáceis de comprar.
• Mudanças nas ferramentas locais frente à nuvem. Em 2020 fornecedores como a Atlassian levaram a sério as ferramentas hospedadas na nuvem.
• Tendências de software empresarial de código aberto. As empresas de TI devem ser patrocinadoras responsáveis do código-fonte aberto e ainda assim maximizar seu controle sobre sua propriedade intelectual.

Nota do Editor: Para ver mais notícias e análises sobre nuvem, DevOps, low code e mais, visite as páginas dos autores Beth Pariseau e Chris Kanaracus. O áudio deste podcast está em inglês.

Bem-vindos Chris e Beth, obrigado por estar aqui conosco nesse episódio de Test & Release. E também um agradecimento especial a Meredith, que nos acompanha pela primeira vez.

Beth Pariseau : Obrigada!

Chris Kanaracus : É ótimo estar aqui, é um prazer.

Beth, um dos assuntos sobre os quais você escreveu este ano, e não acho que seja uma surpresa para as pessoas, é a mudança para o trabalho remoto nas equipes de DevOps [e] organizações de TI em geral. Então, você poderia falar sobre qual foi a mudança ao trabalho remoto e as implicações específicas para DevOps, e o que você ouviu em sua cobertura? 

Beth Pariseau.

Pariseau: O que tenho visto sobre a mudança para o trabalho remoto não é tanto seu efeito sobre DevOps, mas o efeito de DevOps sobre ele. Parece que quanto mais avançadas as empresas estavam em sua transformação digital - incluindo DevOps, entrega contínua, colaboração multifuncional, pequenas mudanças iterativas, documentação de mudanças, medição de resultados - melhor estiveram quando todos tiveram que ir para o trabalho remoto. Na verdade, isto reforçou algumas das melhores práticas de DevOps que talvez não fossem seguidas antes.

Em última instância, a ideia por trás de Agile e DevOps é documentar e medir seu trabalho. Mas quando as pessoas trabalhavam presencialmente, elas poderiam parar no corredor ou perto da mesa de alguém e ter essas conversas paralelas. Então, ainda havia muito “conhecimento tribal” do que estava acontecendo. Isso não iria funcionar com trabalho remoto. Então, em uma certa maneira, o trabalho de casa fez com que houvesse maior adesão às melhores práticas de DevOps. O que é realmente difícil é se não tivesse começado sua transformação digital, não houvesse migrado para a nuvem, não tivesse criado uma canalização de CI / CD centralizada para lançamentos de aplicações. [Então] a pandemia não só é muito mais difícil, ela faz com que seja muito mais difícil passar por essas coisas para tentar para sobreviver.

Mas no artigo que escrevi sobre isso, houve algumas apresentações interessantes de especialistas de ICS sobre como as abordagens de ECS e os objetivos de DevOps de melhora iterativa poderiam ser aplicados para se concentrar em uma melhoria incremental por vez... porque quase tudo é melhor do que a velha maneira de fazer as coisas enquanto todos estão a distância.

Quando você diz 'ECS', você quer dizer os engenheiros de confiabilidade do site (SRE, em inglês)?

Pariseau: Sim. É um termo que está se tornando mais popular. Mas ainda há, como DevOps, desacordo sobre o que ele realmente significa. Mas, em geral, a ideia do DevOps é que os desenvolvedores operem suas próprias aplicações e as resolvam. Então, isso faz a maioria das pessoas de operações de TI se converter em... alguns chamam a si mesmos ECS (SRE, na sigla em Inglês), outros se chamam de engenheiros de plataformas; eles criam a infraestrutura onde os desenvolvedores implementam suas aplicações, dão suporte, tentam torná-las mais confiáveis. E se houver problemas sistêmicos com essa plataforma, eles corrigem.

Passando para um tópico um pouco diferente, também quero trazer à mente o baixo código (low code), porque ele continua sendo uma tendência neste ano. Lembro que no início do ano o Google se aventurou no código baixo, acho que eles compraram a AppSheet em janeiro. E creio que o objetivo declarado, nos comunicados, foi fortalecer a sua oferta na nuvem.

Então, essa pode ser uma boa pergunta para conhecer a visão de Chris. [Tenho] curiosidade em relação às notícias sobre baixo código que você viu durante todo o ano: É um fenômeno que tem se repetido quando os fornecedores de cloud combinam suas ofertas de baixo código e na nuvem em conjunto? Ou, se não for esse o caso, tenho curiosidade em saber que outras observações a respeito do baixo código foram vistas em ambos.

Kanaracus: O que podemos dizer sobre a aquisição do AppSheet pelo Google é que a empresa já tinha algo chamado App Maker que foi descontinuado após a compra do App Sheet. Porque o App Maker foi um fracasso. Ele saiu em 2016 e ninguém o usou. E a ideia de baixo código existe há décadas, talvez três décadas, se considerarmos o Microsoft Visual Basic como um tipo de ambiente de baixo código. Ainda assim ele existe e as pessoas têm escrito milhares e milhares, se não milhões, de aplicações corporativas com ele ao longo dos anos que ainda estão em execução em empresas hoje.

Chris Kanaracus.

Em termos de fornecedores de nuvem: Sim, logo o AWS lançou o Honeycode em meados do ano, usando um tipo de interface de planilha de cálculo para fornecer um editor de código baixo. Eu acho que a conclusão é que estas coisas vêm dando voltas há décadas. Existem alguns fornecedores independentes maiores como o Mendix que estão ganhando muito dinheiro. Mas isso vem de BPM [gestão de processos de negócios], que é uma geração anterior de tecnologia muito mais complexa. E ninguém realmente resolveu o enigma. Eu acho que muitas das coisas temos visto dos grandes fornecedores de nuvem são apenas para obter um tipo de produto protótipo para que possam dizer: “Temos baixo código, fincamos uma bandeira no solo”.

Se parece que sou cético, eu sou; simplesmente não vejo isso como algo sustentável a longo prazo... Todas essas coisas são jardins cercados... Não é como uma aplicação de negócios tradicional, que foi escrito em linguagens comuns e escrita em um IDE (ambiente de desenvolvimento integrado) e que podem ser atualizados por outras pessoas depois seus criadores deixam a empresa e podem ser transferidas para diferentes tipos de hardware. E especialmente com os fornecedores de nuvem, tudo está em seus próprios locais, é muito cercado. Eu diria que há muita propaganda, mas... o verdadeiro sucesso tem aludido a este espaço há décadas. Então, eu não sei, veremos. O ano que vem será interessante.

Chris, eu posso te perguntar sobre o que você espera que o próximo ano trará para o low code? Será mais destes grandes fornecedores adquirindo IP (Intellectual Property, Propriedade Intelectual) de código baixo? Ou você vê fornecedores que desenvolverão produtos de código baixo internamente? Será que os grandes jogadores na nuvem irão se mover para o código baixo?

Kanaracus: Eu acho que você verá ambos, mas o que eu gostaria de ver mais são exemplos de sucesso de cliente no mundo real, não apenas 'Oi, meu usuário avançado de Excel pode escrever um widget com isso'. Caso contrário, como traduzo isso em valor comercial? E para a empresa: Como a fizeram ganhar dinheiro? Como ele ajudou uma empresa a entrar em um novo mercado? Como ajudou a empresa a otimizar sua força de trabalho? E coisas assim. Quero ver isso dos grandes fornecedores nas feiras comerciais no próximo ano: os clientes neste cenário realmente contando suas histórias. Aí serei menos cético.

Vou aproveitar esta ideia de extrapolação e mudança de fornecedores e usuários reais para falar sobre uma tendência que acho que é mais generalizada, mas que certamente tem passado pelas mesmas lutas, que são as ferramentas de CI/CD. Beth, eu sei que você escreveu inúmeros artigos sobre as várias atualizações, aquisições, recursos e integrações entre todas as diferentes ferramentas que você usaria para uma canalização de DevOps ou CI/CD. Houve algo que te chamou a atenção em 2020 e algo a verá continuar em 2021? 

 Pariseau : Eu acho que a tendência principal não foi surpreendente, mas sim bastante consistente, e que as sequências de CI/CD tenham deixado de ser estas criações artesanais sob medida, improvisadas a partir do código-fonte aberto, sem processamento por ninjas e estrelas do rock, e se tornado algo que as principais empresas querem usar, mas não querem construir do zero. Eles querem suporte, querem a integração ... não estão no negócio de construção de canalizações de CI/CD. Estão no negócio de entrega de qualquer lógica comercial em suas aplicações.

Então, você está começando a ver os fornecedores, especialmente grandes fornecedores de TI tradicionais, tais como Red Hat, CloudBees, que é o patrocinador comercial de Jenkins (de código aberto) - que ainda é uma ferramenta amplamente utilizada no espaço - e Atlassian colocando juntos coisas que são mais de ponta a ponta, para usar um termo de marketing nojento. E Red Hat também tem começado a integrar CI/CD maneira mais profunda, incluindo CI/CD impulsionado por eventos, com OpenShift. Portanto, eles estão tentando conectar a canalização da CI/CD com a plataforma na qual os desenvolvedores estão implementando e os ICS ou engenheiros de plataforma estão apoiando. Então, quando você vê as coisas como CI/CD neste conjunto de produtos pré-compilados e empacotados, já está generalizando. Basicamente, isso já não é algo de vanguarda, onde você tem que ser um OG ou programador de código aberto para construir um.

Portanto, tampouco é a tendência mais empolgante, mas há [uma] maioria. Tenho acompanhado o tema desde 2016, isso se superpõe muito bem com a integração de coisas como DevOps e CI/CD. Então, quando comecei, se falou muito sobre ' Quais são as melhores ferramentas para construir?' e 'como colocá-las juntas?' Agora, se fala de maneira mais pragmática: 'com qual de seus fornecedores tradicionais você irá comprar todo este pacote?'. E... competitivamente há consolidação na indústria e desgaste. Ou será porque, em última instância, há uma batalha bastante acalorada entre fornecedores que haviam sido os governantes de diferentes domínios. Agora tudo é tão transversal que todos procuram fazer tudo por todos. E os usuários acabam tendo que escolher quem será seu principal fornecedor de software DevOps.

Parece que esta consolidação pode ser útil se está nos primeiros estágios da CI/CD e está à procura de pacotes de canalização mais completos. Muitos de nossos leitores e ouvintes, acredito, tem algum estágio de maturidade de CI/CD e poderiam já ter de 10 a 15 ferramentas, talvez incluindo diferentes canais em diferentes partes de seus negócios. Portanto, podem ser confrontados com uma decisão mais difícil sobre apostar em uma empresa ou continuar reunindo essas sequências que têm construído.

 Pariseau: Bem, parece que o custo/benefício é um debate consagrado. E quanto ao que está na moda, o pêndulo oscila de um lado para o outro. Uma coisa que eu acho que é boa sobre esta atual onda de mudança na TI é que, no fundo, a maior parte é baseada em código aberto. Então, pelo menos em teoria, o código central de algo como Kubernetes ou Jenkins, ou mesmo ferramentas de observabilidade, como Prometheus e Grafana, não pertencem ao seu provedor. Não é exatamente o nível de dependência que as pessoas costumavam ter com os fornecedores de software proprietários há 10, 15 ou 20 anos. Mas ninguém realmente quer, no fim do dia, administrar de 10 a 15 ferramentas. E no final do dia, a maioria das empresas não estão realmente no negócio de montar uma plataforma de CI/CD. Eles querem enviar seu código mais rapidamente, é disso que se trata. E querem vincular mais estreitamente seus negócios ao que seus técnicos estão fazendo. Estes são os objetivos reais em que as pessoas estão começando a se concentrar, com CI/CD mais como um meio para um fim.

Então, para nos mantermos na linha de opções de ferramentas disponíveis para desenvolvedores, e o que mudou no último ano... Chris, pode dar-nos uma breve descrição geral das ferramentas locais contra as ferramentas do lado da nuvem?

Kanaracus:  Algo importante é que em 2020, na verdade, a partir do final de 2019 em diante, vimos uma mudança para os editores de código baseados na nuvem dos principais fornecedores: grandes nomes como Google e Microsoft. Na conferência [Microsoft] Build 2019, no final de 2019, eles fizeram uma demonstração de algumas dessas novidades. E você sabe que algo ressoa com uma multidão de desenvolvedores quando as pessoas se levantam e aplaudem de pé. Não digo que eles estavam jogando confete, mas as pessoas ficaram empolgadas com o que viram. Você pode fazer coisas como a programação em pares (pair programming) em tempo real na nuvem, com um outro desenvolvedor. Isso em 2020. Poder fazer isso de modo remoto foi algo realmente grande.

Google também tem liderado o caminho com o Google Cloud, muitas extensões para IDEs existente, Visual Studio e outros, porque estão tentando manter um pé em um mundo onde 80% da programação é feita em estações de trabalho a nível local, mas tentando levar mais funcionalidade à nuvem. Então, acho que isso será bastante quente em 2021. Muitas pessoas começaram com estes novos editores de código, e vamos ver muito mais disso em 2021.

Obrigado Chris. E você mencionou fornecedores como Google e Microsoft. Mas se meu entendimento estiver correto, a Atlassian é outro provedor que exemplifica essa tensão entre as instalações locais e a nuvem. E, Beth, você escreveu um pouco sobre a Atlassian. Eu estava pensando, você poderia falar um pouco sobre eles e o que está acontecendo com eles?

Pariseau: Apenas como pano de fundo, relacionando-o à pandemia e ao trabalho remoto como mencionou Chris: as empresas que ainda dependiam do acesso VPN aos centros de dados locais durante a pandemia também tiveram muitas mais dificuldades do que as empresas que já tinham mudado para serviços baseados na nuvem ou SaaS. Porque do que todas as pessoas precisam quando trabalhando de casa, se estiverem usando um produto de software baseado na nuvem, é de sua conexão à Internet, e idealmente algum tipo de autenticação ou sistema de gerenciamento de acesso e identidade do usuário. Novamente, se você tivesse avançado muito em sua transição para a nuvem e transformação digital, e tivesse [esses sistemas na nuvem] instalados. E isso também separou “os que tem” dos “que não tem” quando a pandemia chegou.

Por outro lado, existem algumas organizações empresariais muito grandes que ainda têm requisitos de segurança que não permitem colocar certas aplicações ou dados na nuvem. A nuvem tem se tornado muito mais convencional, e sequer precisamos dizer que já é algo generalizado. As grandes empresas, inclusive os bancos, contam com sua infraestrutura de nuvem e serviços de aplicações. A Amazon tem o GovCloud [AWS] que é usado pela CIA e pelo Departamento de Defesa. É possível, mas existem algumas instituições, especialmente financeiras, que simplesmente não querem mover certos aplicativos para a nuvem. Então, é aí que as pessoas começam a falar sobre a nuvem híbrida. E você tem uma combinação de recursos locais e baseados na nuvem.

E a Atlassian é interessante, porque eles começaram como um provedor de software licenciado localmente. E inicialmente suas ofertas na nuvem não eram muito fortes em termos de confiabilidade. Mas há uns dois anos migraram seus back-end para o AWS no lugar de seus próprios centros de dados autogeridos e começaram a oferecer versões de seus produtos na nuvem. Aos poucos, essas versões começaram a tornar-se uma clara preferência em termos de para as quais desenvolveriam características primeiro, quais seriam entregues em primeiro lugar, quais seriam mais promovidas. E eles começaram a tentar empurrar e incentivar suavemente seus usuários a mudar seus produtos locais para versões na nuvem [com] coisas como descontos e assistência para migração e ferramentas gratuitas de avaliação de migração e esse tipo de coisas. E no início do ano as pessoas podiam ver o que estava por vir, mas ainda houve alguma surpresa e consternação quando finalmente passaram da cenoura, por assim dizer, ao bastão e no fim de outubro e interromperam a sua linha de servidores, que era sua licença de entrada para produtos locais.

[Atlassian também] aumentou drasticamente as licenças para versões de centros de dados de seus produtos, as versões empresariais com todas as funções de seu software. E [a empresa] até mesmo disse que agora está focada na nuvem, e assim continuará. Eles administraram essa transição tão cuidadosamente quanto qualquer um poderia e foram muito receptivos às preocupações dos clientes. Mas ao final do dia, as empresas são suficientemente grandes, com dados altamente regulados para tratar, como os bancos, pagaram o que era necessário para comprar essas licenças para centros de dados. Mas foi a primeira vez que vi uma empresa na minha área fazer cumprir com toda crueza essa transição. Tal vez porque muitos [fornecedores neste segmento] não começaram a partir das instalações em primeiro lugar. Mas acho que está muito claro que as pessoas com investimentos locais são uma minoria. À medida que as aplicações vão se modernizando, ocorre a transformação digital e a maioria das principais preocupações sobre a segurança e confiabilidade da nuvem já desapareceram para a maioria das empresas. Creio que podemos dizer que finalmente chegamos.

Kanaracus : Beth, nos anos de SaaS, e no período anterior à SaaS, o discurso sempre foi que '[a nuvem] é melhor do que as instalações locais, porque podemos atualizá-la quatro vezes ao ano, nós vamos cuidar de tudo, obviamente. Você terá uma iteração rápida do software, não apenas [inaudível], mas também uma série de funções em cascata em vez de ter que instalar uma nova versão uma vez ao ano, uma vez a cada dois anos'.

É o mesmo caso? Na Atlassian, com Jira, as pessoas querem aquela iteração rápida que a nuvem pode fornecer?

Pariseau: Bem, a  [Atlassian] também revisou recentemente o Jira Service Desk dessa forma. E é necessário ser cuidadoso, porque há algumas empresas que têm um grande apetite pela mudança, mas há outras que vão enlouquecer se mudam muito frequentemente, muito rápido ou de maneira muito drástica. Então no caso da Atlassian, pelo menos com Jira Service Desk, agora é Jira Service Management. Quando fizeram esta transição, automaticamente deram a todos os novos recursos, mas não removeram nenhum dos existentes. E eu acho que isso é atraente para algumas empresas, mas quando se vende a empresas convencionais, isso não se aplica a todo o mundo.

Outra coisa que acho que pode ser fonte de estresse para algumas empresas de TI [é] um tema sobre o qual você, Beth, escreveu este ano: relacionamento das empresas e, às vezes, relacionamento tenso com contribuições de código aberto. E uso a palavra carregada, porque acredito que uma abordagem dos seus artigos... fale de departamentos jurídicos conservadores [que] têm problemas com, como eu disse, as contribuições de código aberto. É possível explicar essencialmente o panorama das relações das empresas com as contribuições de código aberto e qual é a natureza atual?

Pariseau: Claro. O código aberto... passou de marginal ao principal, para ser apenas um requisito agora. Acho que o apelo inicial era: ' Ei, é grátis'. Mas como se costuma dizer nos círculos de código aberto: 'Há grátis como na cerveja e grátis como em um filhote de cachorro'. E o código aberto é definitivamente grátis como em um cachorro. Você o recebe de graça, mas você tem que cuidar dele, você tem que criar e treinar, e precisa de um lugar a qual recorrer em busca de apoio. E não é tão simples como 'Ei, instale esta licença, é grátis'.

Portanto, um dos atrativos do software de código aberto é que você pode modificá-lo conforme for necessário. Mas ele não só exige habilidade, mas isso também requer uma nova abordagem à propriedade intelectual corporativa, e o que possuímos. Qual é o nosso valor agregado como empresa? O que é único para nós e devemos manter internamente? E o que podemos contribuir para a comunidade? E isso colide primeiro com a cultura corporativa. Então você tem desenvolvedores, e tudo o mundo quer contratar desenvolvedores que são crianças-prodígio, mas a coisa é que esses desenvolvedores tendem a ser fortes defensores de abertura do código que eles estão criando. E se você quiser recrutar os melhores desenvolvedores no mundo, você terá que lhes permitir utilizar software de código aberto e desenvlvê-lo dentro de sua empresa. A reputação de código aberto de uma empresa é mais valiosa para ela como uma ferramenta de recrutamento para a equipe de TI em meio de uma escassez de habilidades.

Então, as empresas agora têm que enfrentar esse problema. E lá estão ainda algumas coisas que são não resolvidas... não há nenhum precedente legal, realmente. Google versus Oracle, em termos de API e Java, é o mais perto de um possível precedente, mas isso não poderia se aplicar necessariamente em todos os casos. É um território inexplorado do ponto de vista jurídico. E também é um problema bastante generalizado no qual há uma diretoria e equipes como as de gestão de riscos e equipamentos legais que não são profundamente técnicas, enfrentando os desenvolvedores que estão profundamente técnicos, mas não especialistas versados na legislação. E você tem que juntar esses dois lados. Não se trata apenas da colaboração entre diferentes facções de TI, também se trata de integrar as diferentes funções do negócio ao redor ao que você está fazendo tecnicamente. Então, isso é um grande desafio para as pessoas, culturalmente. As pessoas achavam que fazer os desenvolvedores e operadores trabalharem juntos era difícil. Tente colocar um advogado corporativo em uma sala com um desenvolvedor de código aberto - eles falam línguas diferentes.

Logo, outra coisa que é sua própria toca são as licenças. E empresas como, por exemplo, a Bloomberg, que se encontra na rara posição de ter um executivo na posição de gestão: O que nós licenciamos [e] como nós licenciamos as coisas de código aberto que criamos dentro de nossa empresa? E tomar essa decisão coordenada sobre o que manter em casa e o que não, como trabalhar com essas bases de código aberto. Há certas coisas: práticas em torno de um contrato legal, documentos, acordos de direitos autorais, [que] não foram colocados em dia com o software moderno. Basicamente, as empresas estão começando a se interessar em ser donas do código com o objetivo de abri-lo no lugar do desenvolvedor individual. Em parte, isso está ligado esta ferramenta de recrutamento, que está ligada à visibilidade (elas querem ser vistas como bons cidadãos corporativos) e, francamente, não querem que o trabalho deste desenvolvedor pertença aos seus empregados; eles querem que pertença à empresa, se ele é feito usando os recursos e tempo da empresa. Então esse é todo o seu problema. Por exemplo, Kevin Fleming, que é a pessoa com quem falei na Bloomberg, teve que trabalhar com várias empresas de software para que a Bloomberg, a pessoa jurídica, fosse a detentora dos direitos autorais para fins de código aberto no final do ano passado/início do presente ano, e essas empresas nunca antes tinham feito esse processo desta maneira.

Então, tudo isso ainda é uma fronteira, mas vai começar a aparecer para mais e mais empresas, porque você precisa apenas usar e contribuir para o código aberto. E também reflete a maturidade do mercado, onde dizem ' OK, vamos usar essas coisas; está bem, estamos ficando muito bons no uso de estas coisas, mas há um problema, precisamos que ela faça algo que não faz, assim que estiver certo, faremos'; para: 'Bem, realmente precisamos compartilhar isto com a comunidade, porque conseguimos tudo isso com base no trabalho de outras pessoas e das doações à comunidade. E se quisermos ser parte de todo este movimento, realmente precisamos retribuir. De outra forma, teremos uma má reputação. E logo se tornará mais difícil para você obter o apoio da comunidade sobre o uso do software. Mas você logo se depara com todas estas questões legais que, em alguns casos, tem séculos de idade e ainda precisam ser atualizadas.

Você mencionou DevOps em termos de reunir desenvolvedores [e] operações. E, é claro, a tática que sempre tomamos para falar com DevOps é descobrir como colaborar. Mas parece que com a dinâmica que você está descrevendo, poderiam ser necessárias concessões de um lado ou outro, em vez de haver uma colaboração.

Pariseau: Em alguns casos.

 Sim. Mas [também] me lembro que para as pessoas nos campos técnicos, sejam engenheiros de DevOps, desenvolvedores ou profissionais de controle de qualidade, nunca é uma má ideia rever as habilidades sociais, [para] ser capaz de se comunicar [e] trabalhar com pessoas de fora de seu departamento.

Pariseau : Simplesmente não há uma maneira de contornar isso. Já não é possível deixar de lidar com as pessoas. Você está fazendo um trabalho técnico? [Então] você tem que colaborar com o pessoal de segurança e de operações, um desenvolvedor e vice-versa. Ou está se comunicando com todo mundo, desde a alta gestão da sua empresa até as equipes jurídica e de riscos. Até os sistemas que as pessoas usam estão convergindo. Por exemplo, está surgindo uma categoria de software chamada gerenciamento de serviços empresariais, diferentes empresas como a ServiceNow e a  Atlassian estão entrando mais neste campo. Estão começando a expandir seus produtos como Jira Service Desk para adequar-se aos equipamentos legais e de recursos humanos. E eles têm interfaces de baixo código ou nenhum código para esses setores em produtos como o Jira Service Desk, para que possam oferecer coisas como tipos de serviços de intranet corporativa, porque não se trata mais apenas do helpdesk de TI. [Digamos] que você precisa incorporar o processo de dar baixa a um novo funcionário, não só em termos de configuração de seu notebook, mas em termos de seu status em nosso sistema de recursos humanos, e você vai usar algo como Jira para isso.

É fácil se esquecer disto com todas as ervas daninhas técnicas, mas o objetivo inicial do Agile e do DevOps era melhorar o negócio; era entregue o a lógica empresarial de forma mais rápida e competente. À medida que o mundo é governado pelo software, agora todas as empresas precisam ter pelo menos um aplicativo para celular e um site. Assim, cada empresa agora tem de ter uma certa quantidade de entregas de software, qualquer que seja o seu produto. E isso significa que ja não há essa separação entre os técnicos na “masmorra” fazendo a mágica que fazem e as pessoas de negócios à frente fazendo o que fazem. Você realmente tem que juntar essas coisas. Não é apenas bom ter isso, não é apenas uma ideia. É necessário se você quiser sobreviver no século XXI.

Beth, Chris, quero agradecer a vocês dois novamente por se juntarem a nós. E também pela cobertura de notícias que ambos escreveram no ano passado, [e que] informou muito desta nossa conversa.