“O medo não é introduzir a ferramenta. É não ter identidade”: a barreira na migração para arquitetura composable

A maior barreira na migração para arquitetura composable não é técnica. Dana Lawson, CTO da Netlify, partilha o que aprendeu sobre gerir a mudança, das decisões técnicas ao medo real das equipas

“O medo não é introduzir a ferramenta. É não ter identidade”: a barreira na migração para arquitetura composable

A conversa sobre arquitetura composable costuma vir carregada de buzzwords e promessas de transformação digital. No entanto, quando Dana Lawson, CTO da Netlify, fala sobre o tema a abordagem é diferente; é pragmática, direta e focada no que realmente importa para quem tem de tomar decisões.

Em entrevista à IT Insight durante o Web Summit 2025, Lawson partilhou a sua visão sobre como as organizações podem e devem pensar na transição de sistemas legados para arquiteturas mais ágeis, mas sem cair nas armadilhas que têm deixado muitos projetos pelo caminho.

Para a CTO da Netlify, a separação entre o front-end e o back-end não é revolucionária. “Trata-se mais de postura de segurança e de conseguir mudar rapidamente os componentes do sistema”, explica.

A arquitetura orientada a serviço já existe há vários anos; o que mudou foi o contexto. “Estes monólitos não foram construídos para uma força de trabalho de agentes ou para utilizadores sintéticos”, refere. A pressão para responder a agentes de Inteligência Artificial (IA) e as novas formas de interação está a acelerar a necessidade de sistemas mais flexíveis e composable, onde os componentes independentes podem ser combinados e recombinados conforme as necessidades do negócio.

Começar pequeno

A pergunta que um CIO coloca é por onde é que se deve começar sem reescrever décadas de investimento. A resposta de Dana Lawson é direta: não tentem ser heróis.

 

 “Uma vez que há um monólito, as probabilidades são de que nunca vá ser substituído por completo”

É preciso encontrar áreas onde é possível começar a deixar a equipa confortável com essas transições. Se estás num sistema ERP legado enorme, talvez não seja a melhor ideia; não se vai ter sucesso”, afirma, acrescentando que o conselho é começar por serviços de tier três e não pelos sistemas críticos. “Deve-se identificar as áreas que estão frágeis e começar a tirar essas peças de forma segura”.

Lawson deixa um aviso importante: “uma vez que há um monólito, as probabilidades são de que nunca vá ser substituído por completo”. A estratégia, diz, passa por decompor, não por destruir. “Se há algum greenfield ou nova tecnologia, constrói-se fora e é preciso ter essa disciplina de começar a construir fora”, explica.

A velocidade de mudança e a velocidade dos sistemas” em primeiro lugar “e depois o custo” são os dois principais fatores que levam as empresas estabelecidas a considerar seriamente uma mudança de arquitetura.

De acordo com Dana Lawson, muitas organizações ficaram presas a contratos com hyperscalers e, agora, querem flexibilidade. “As pessoas não querem toda a sua tecnologia num só fornecedor, especialmente com esta velocidade rápida de desenvolvimento que temos agora”. Outro fator, acrescenta, é a experiência do cliente, uma vez que “os sistemas se tornaram arcaicos e lentos e [as organizações] sabem que a experiência do cliente está a ser prejudicada”.

O que importa e onde corre mal

Questionada sobre como se mede o impacto, Lawson partilha que não é preciso reinventar a roda, até porque “as métricas DORA [DevOps Research and Assessment] existem há algum tempo. DevOps está em prática há mais de 15 anos”.

“Se o monólito funciona e vai continuar a funcionar, não o mudes. Foca a tua energia noutras coisas”

 

Assim, a CTO da Netlify foca-se em três indicadores clássicos: tempo de ciclo de revisão, tempo de deployment e mean time to recovery. No entanto, deixa um alerta: “podes fazer ship de uma série de mudanças o dia todo que não importam, mas começa a importar quando os concorrentes se movem mais rapidamente do que tu”. Para Lawson, a métrica mais importante é “impacto e valor para o cliente”.

Naturalmente, nem tudo corre sempre bem. Para Dana Lawson, “over-architecting” é onde as coisas podem correr mal; “tentar entrar e arrancar tudo o que existe. Acabas por criar uma teia de aranha de serviços”.

Neste sentido, se não existirem práticas estabelecidas de DevOps, o resultado é previsível. “Como é que consegues manter algo quando não tens telemetria ou não consegues rastreá-lo ou compreendê-lo? A fiabilidade desce”.

Outro erro comum é ficar parado. “Não podes simplesmente definir e esquecer, porque vais ficar para trás”. Mas, alerta, não se pode exagerar, porque “se o monólito funciona e vai continuar a funcionar, não o mudes. Foca a tua energia noutras coisas”.

O lado técnico: complexidade, segurança e agentes

Questiona se a arquitetura composable resolve a complexidade operacional dos microsserviços ou se apenas move o problema para outro lado, Lawson afirma que “depende”. O ponto importante está em separar áreas de preocupação. “A arquitetura composable não é sobre criar milhares de microsserviços; é sobre conseguir separar o front-end”. Muitas das mudanças rápidas, dependendo do negócio, acontecem na interface e não no back-end.

Mais API e pontos de integração significam, também, uma maior superfície de ataque. Lawson não dramatiza e explica que “é como dizer que os cintos de segurança tornam os carros mais seguros e podemos ir mais rápido. Não é assim. Tens de colocar barreiras”.

Para os agentes de IA a abordagem é a mesma. “Defines o contexto, que é o teu contrato para agentes e LLM, o que devem e não devem fazer”. Depois, diz, “não se deixa fazer o que querem. É preciso ser a pessoa a estar lá e a colocar essas barreiras”.


“Se tivesse entrado ali com um martelo e dito ‘tens de, deves’, eu e a minha equipa teríamos sido expulsos. Penso que tens de ser humano primeiro”


Pessoas, a barreira mais difícil

Adotar esta arquitetura implica não apenas uma mudança tecnológica, mas também organizacional. Por vezes, no entanto, alguma terá de ceder. Para Lawson, aquilo que muda primeiro é a tecnologia, porque “não tem sentimentos”.

Quando criaste a tua identidade e o teu propósito em seres uma pessoa que faz isto e agora há um exército de agentes sintéticos que, provavelmente, fazem isto melhor do que tu, é assustador. Perguntas ‘que propósito tenho eu na vida?’”, afirma.

Dana Lawson vê isto todos os dias, porque, historicamente, os profissionais de DevOps foram os responsáveis pela produção, mas agora têm de confiar em agentes. “Os workflows são a coisa mais difícil de mudar”, garante.

Neste ponto, os líderes têm uma responsabilidade vincada. “É nosso dever, enquanto líderes, preparar esta força de trabalho ou vão ficar para trás”. E, acrescenta, não vale a pena fingir. “Se nos sentarmos e dissermos [aos colaboradores] que os empregos não estão a mudar, isso não é verdade. Estão a mudar”.

No entanto, há esperança. “Ainda há muitas oportunidades para os humanos, mas somos os orquestradores”, até porque “os agentes não têm livre-arbítrio. Mesmo que digamos que têm, a verdade é que não têm”.

Conhecer a própria equipa

O exemplo da Netlify mostra como a abordagem de conhecer a própria equipa e o que resulta com cada pessoa é importante para o caminho que tem de ser feito. “Estamos ainda na nossa jornada agora na Netlify. Estamos a tentar ser muito pragmáticos sobre como introduzimos isto”, afirma.

Lawson fez um inquérito à equipa sobre o conforto com a inteligência artificial e os resultados foram díspares de umas pessoas para as outras. “Tivemos muitas respostas do género ‘tenho usado isto secretamente há meses e agora posso falar disto’ até ‘nunca vou tocar nisto’”.

Se tivesse entrado ali com um martelo e dito ‘tens de, deves’, eu e a minha equipa teríamos sido expulsos. Penso que tens de ser humano primeiro”, afirma. A falha, diz, acontece quando não se fala com as pessoas. “O medo é a substituição. Não é o medo de introduzir a ferramenta. É ‘não tenho identidade’”, partilha.

Assim, o conselho que Dana Lawson para um CIO que vai começar esta jornada é que “não façam editais nem digam o que devem ou não devem [fazer]. Também fazem parte disto. Estamos todos a aprender. Baixem o ego. Ninguém tem todas as respostas. Até as pessoas que estão no palco e nas notícias estão a inventar. Eu estou a inventar. Estamos todos a aprender juntos”.

Lawson lembra que o Model Context Protocol nem sequer era um conceito há um ano e que o Agent-to-Agent saiu apenas há seis meses. “A iteração rápida do que vemos, do que fazemos e de como interagimos está a mudar”, diz.

Por fim, deixa um aviso: “a IA não é uma bala mágica para nada. Pensem no que precisam de fazer, com quem precisam de o fazer, e sejam humanos sobre isso. Mantenham a mente aberta”.

Tags

NOTÍCIAS RELACIONADAS

RECOMENDADO PELOS LEITORES

REVISTA DIGITAL

IT INSIGHT Nº 58 Novembro 2025

IT INSIGHT Nº 58 Novembro 2025

NEWSLETTER

Receba todas as novidades na sua caixa de correio!

O nosso website usa cookies para garantir uma melhor experiência de utilização.