T1 | EP.12 | Porque estamos a apostar numa arquitetura multicloud? Com José Carlos

[embed]

Vê também no Spotify e Apple Podcasts.

Neste episódio da Caixa Central, o podcast da MC Digital conduzido por Rafael Pires, falamos sobre a estratégia que nos está a permitir dar mais autonomia às equipas de desenvolvimento através de uma arquitetura multicloud. Recebemos José Carlos Alves, Area Leader de Infrastructure Platform, para uma conversa sobre os desafios desta evolução e sobre a forma como estamos a simplificar o acesso à infraestrutura, reduzindo dependências e criando plataformas mais flexíveis para quem constrói tecnologia todos os dias.

O que vais ouvir neste episódio:

• O que é uma arquitetura multicloud e porque está a tornar-se cada vez mais relevante;
• Como estamos a criar plataformas mais simples e self-service para os developers;
• O desafio de dar mais autonomia sem perder consistência e controlo;
• O papel do Kubernetes na abstração da infraestrutura;
• Como a estratégia multicloud reduz dependências tecnológicas e aumenta a flexibilidade;
• O desafio de modernizar sistemas existentes enquanto continuamos a inovar;
• Como a inteligência artificial poderá transformar a forma como construímos e operamos plataformas tecnológicas.

Transcrição completa do episódio:

(Esta transcrição foi gerada automaticamente, a sua precisão pode variar)

Olá, sejam muito bem-vindos à Caixa Central, o podcast da MC Digital, onde exploramos a forma como construímos a tecnologia e as decisões que moldam o futuro do retalho. Eu sou Rafael Pires e hoje temos um assunto que acontece nos bastidores, mas que tem impacto direto naquilo que construímos.

Ao longo do tempo, fomos desenvolvendo cada vez mais aplicações, mas também são cada vez mais complexas. Com esta complexidade surge a necessidade de simplificar, criar bases mais consistentes e reduzir dependências técnicas. É precisamente sobre isto que vamos falar hoje através da exploração das nossas da nossa evolução para uma arquitetura multicloud. Tenho comigo José Carlos Alves, a área líder de Infrastructure Platform, que nos vai ajudar a perceber os drivers desta evolução, o que já foi feito e o que aí vem. José Carlos, muito bem-vindo.

Olá, Rafael. Viva! Vamos, vamos lá então explorar este tema. E como como sempre no nosso eh no nosso podcast, eu nunca me atrevo a apresentar o convidado, portanto é precisamente por aí que nós que nós vamos. Portanto, quem és, qual o teu percurso e qual é que é o foco da tua área neste momento?

Muito bem, então o meu nome é José Carlos Alves, sou natural de Viana do Castelo, eh licenciado na Universidade Minho, eh, em engenharia de sistemas informática, um curso que hoje já não existe ou foi rebrandit, mas acho que também não é evoluiu, diria como tudo na vida evolui, não é? Estou na Sonae há cerca de 25 anos, eh, sendo que comecei o meu percurso em funções mais técnicas, eh, sendo que desde 2006 estou na direção de sistemas de informação da MC.

Eh, sou uma pessoa que gosta muito de tecnologia e mas acredito que a tecnologia tem que estar cá ou tem que estar em qualquer área de negócio para servir um propósito muito claro. Eh, portanto, nós não podemos adotar tecnologia pela tecnologia, temos que trazer tecnologia para trazer valor eh para aquilo que é o o que importa para o negócio.

Ha, portanto, como disse, tenho vindo a fazer um percurso técnico, muito, muito técnico, mas entretanto a partir de 2006, fiz uma evolução para começar a agregar cada vez mais responsabilidades nestas áreas mais tecnológicas, sendo que alguros, em 2016 acabei por ficar com a liderança daquilo que são as áreas mais tecnológicas, já numa perspectiva mais de gestão e mais de eh influência naquilo que há de que tem vindo a ser a nossa tecnologia e que sustentou hoje grande parte dos nossos sistemas de informação.

Não. OK, boa. Eh, e eu tenho tenho tentado puxar pelos convidados de um bocadinho do lado B também. Aliás, o último o último podcast foi um foi um exemplo disto. Algumas surpresas do de alguns dos convidados. Não sei se queres dar aí um cheirinho de coisas que gostas de fazer. Eh, eu considero que sou uma pessoa relativamente tradicional. Reparem, eu gosto muito daquilo que faço enquanto profissional, naquilo que tem a ver na do ponto de vista mais pessoal, tenho tentar dedicar-me mais àquilo que a minha eh família e tenho dois filhos e um de 18 que fez 18 agora há muito pouco tempo, portanto maior de idade, portanto já maior de idade, maior que o pai também. Eh, e cuidado que o pai não é pequeno, não é? Hã, e tenho uma filha mais nova com 10 anos. E e acho que essa essa minha filha tem uma particularidade de se ter muito mais próxima do pai.

E é um prazer que me dá estar com ela sempre que é possível. Estarmos os dois, brincarmos os dois, tentarmos eh aproveitar o máximo de de possibilidade de tempo que temos os dois para interagirmos. também em certa medida acho que isto é uma culpa porque acho que no com o meu filho mais velho isso não aconteceu da mesma forma e portanto acho que agora estou a tentar redimir-me como uma filha mais nova diria era a evolução que falávamos há pouco, não aprendemos evolução. Aprendemos aprendemos e melhoramos e o segundo beneficia sempre exatamente do caminho do primeiro.

OK, o teu cargo é infrastructure platforms, não é? Eh conseguimos discar o que é que isto é quando dizemos infrastructure? O que é que é esta infraestrutura? Eh, eu tentando dizer de uma forma muito simples, eu diria que é tudo aquilo que são as eh stacks tecnológicas onde hoje executam as nossas aplicações. O que é isso? Estamos a falar de coisas tão basilares como capacidade de processamento, capacidade de armazenar os nossos dados, a rede que interliga as nossas aplicações.

Portanto, são todas essas peças que no fim do dia permitem que as aplicações quando são instaladas executam com com de acordo com aquilo que foram desenhadas para para e poderem fornecer em termos de de serviço.

Eh, portanto, nós quando estamos a falar de capacidade de computação, tipicamente as pessoas computadores pessoais. Aqui estamos a falar de sim, também estamos a falar de computadores, mas em escala em escala diferente e preparados para eh uma execução numa lógica de 24%, 365 dias por ano, portanto com eh preparados e desenhados para operar a um nível diferente de um utilizador convencional.

Eh, mas diria que são esses building blocos principais, portanto, que é aquilo que nos permite que as nossas aplicações no fim do dia cumpram o seu propósito. Portanto, eu tenho que ter algo onde as minhas aplicações executam.

Eh, ep, e muitas vezes hoje quando nós falamos nos conceitos de cloud, apesar de estarmos a falar nas nuvens, na realidade há sempre algo por trás das nuvens que permita que as aplicações executem. Não há há algo que efê, não é? Portanto, não é intangível físico está em algum lado a fornecer capacidade.

Exato. Apesar da cláudir, efetivamente por trás, efetivamente tem essas capacidades de de permitir que as aplicações executem.

OK. Boa. E então aqui a a tua área é responsável por assegurar que temos que temos tudo isso no sítio certo para as nossas aplicações e funcionarem.

Sim, sim, sem dúvida. Eu diria que é essa a sua principal missão. Diria que nos últimos anos essa missão tem vindo a focar-se cada vez mais em que a forma como essas tecnologias são consumidas, como essas plataformas de infraestrutura são consumidas, tendencialmente são mais self service para que quem constrói as aplicações preocupem desenvolver as suas aplicações e no momento em que precisa da tecnologia para suportar essas aplicações, essa essa tecnologia é democratizada, ou seja, é lhe dada essa acessibilidade para as pessoas poderem ter autonomia no consumo das mesmas.

É essa a principal missão hoje desta área. OK. Que é o que vamos explorar, que é o que vamos explorar hoje. Então, era já aí que eu ia que eu ia a seguir. E antes de irmos à de irmos à à evolução, não é? Nós hoje vamos explorar muito aqui eh o que nós estamos a fazer à volta da da arquitetura multicloud.

Portanto, nós tínhamos toda uma estratégia cloud que evoluiu para esta h para esta abordagem multicloud. O que é que diferencia? O que é que é este multicloud? Começaste já aí a abrir um bocadinho o o V sobre alguns dos benefícios, mas o que é que ganhamos nesta mudança de uma estratégia mais cloud, não tanto e diversificada, mas mas abrindo para um para um market.

Eu eu vou, se me permitires, vou vou usar aqui um pequeno paralelismo, embora eu acho que nós não estejamos emi, sei lá, eu acho que podemos dizer que a nossa ambição enquanto consumidores de serviços cloud deve ser quase, a ambição deve ser quase a cometer termos vários fornecores de energia elétrica.

Eu devia ter a flexibilidade de mudar o consumidor de energia elétrica de forma facilitada, nem que fosse pegar num telefone, dizer, olha, já não estou contente com este, vou mudar para aquele.

Obviamente que isto na energia elétrica a coisa é relativamente fácil. Isto já estamos num nível de maturidade, diria eu, que nos permite estar nesse patamar.

Quando estamos a falar da cloud, as coisas não são bem assim. Eh, nós temos vários players de cloud que oferecem os seus serviços, este serviços que eu falava há um bocadinho de computação, de armazenamento de dados, hh, de forma e facilitada para os consumidores, mas depois cada um desses players acaba por ter hh especificidades, especificidades de implementação.

Hum. E e nós o que queremos é que eh estejamos nós a consumir o o parceiro de serviço de cloud A ou B ou C, a forma como fazemos ser o mais consistente e uniforme para quem precisa de alojar as aplicações.

E e é um bocadinho isso que nós queremos. Nós teremos que ter uma estratégia multicloud, ou seja, isto nos permite em cada momento poder escolher qual é o melhor local para termos nossas aplicações e pode haver vários fatores que nos levem a escolher essas essas essa localização.

Hum, mas também ter a possibilidade de fazer isso sem grande esforço.

E o que nós queremos é precisamente pela ver especificidades de cada cloud provider, nós podermos h abstrair essa complexidade. Ao obstrirmos essa complexidade, queremos podê-lo fazer de maneira que quando eu estou a fazer deploy da aplicação A ou da aplicação B no provider A, fazer esse dessa mesma aplicação no provider B, a diferença seja muito to e, portanto, dar essa flexibilidade.

E e se nós e e estando nós a construirmos estas capacidades, estamos a dizer que se conseguimos fazer isto é porque eh a camada cloud que me dá o serviço deixa de ser tão relevante, passa a ser gnóstico quando eu faço deploy das minhas aplicações e, portanto, tenho esta flexibilidade para poder fazer deploy das aplicações e aquilo que está por baixo deixa de ser tão relevante.

Por isso é que eu vou fazer aquilo paralelo da energia elétrica. Não estamos lá, atenção, também parecer muito transparente, mas acho que é um é uma ambição que tendencialmente poderemos querer fazer no futuro, haja tecnologia que nos permita. Hoje ainda não é possível, mas eu sei que este era um bom paralelismo para fazer, certo?

Até não conhecendo eu muito bem as duas indústrias, não é? Na energia parece mais fácil porque a infraestrutura acaba por ser bastante partilhada de certa forma e na cloud tá um bocadinho mais senão totalmente segmentada.

Isso tá totalmente segmentada. Embora depois também devo dizer que muitos providers estão em espaços muito próximos uns dos outros também, não é?

Quando diz espaço, diz geografias. Geografias muito próximas, inclusive escolhem os mesmos espaços, as mesmas localizações, precisamente para para pronto, há de haver ali condições de eh geopolíticas também para essas escolhas.

Eh, mas efetivamente também quer dizer que eles estão próximos uns dos outros. Quer dizer que isto também não deveria ser o caminho até lá chegar. Há de ser sempre, há de ser um caminho também comum, como dizias, a forma como depois as aplicações transitam entre os cloud providers é que certo terá a sua as suas nuances, não é?

Certo, certo, certo. E depois também há toda a componente regulamentar que que que depois também acelera estes temas.

OK. Vamos concentrar aqui um no nosso a arquitetura multicloud que nos traz uma camada de a h autonomia adicional aos developers, alguma agnosticidade ao ho, fornecedor.

Nós não estávamos a fazer este caminho. O que é que estávamos a sentir? O que é que aconteceu que nos empurrou eh ou nos trouxe eh até aqui? Que dificuldade é que tínhamos?

Que é é assim como como eu como eu disse é assim nós queremos ter hh a capacidade de dar autonomia aos developers. Por outro lado, também queremos ter a flexibilidade de que hoje eu estou na cloud A e amanhã, seja por razões técnicas, seja por razões comerciais, seja outros motivos, nós podemos querer pegar nas nossas aplicações e movê-las para outros para um outro parceiro.

A isto são são duas dimensões, se quisermos. Aquilo que tem que ver com a o aprovisionamento das soluções, o modelo que nós tínhamos até então até há bem pouco tempo, é muito na lógica de que há uma equipa central que faz o aprovisionamento das capacidades tecnológicas e que depois as aplicações são instaladas lá por cima.

O objetivo que se pretende agora, não é esse, ou que se o que se pretendeu com esta mudança é garantir que os developers têm a capacidade de construir suas aplicações, mas ao mesmo tempo passam a ter acesso a um catálogo de serviços que podem consumir para aprovisionarem eles próprios de forma autónoma aquilo que são as capacidades tecnológicas.

E isto ser feito estando eu na cloud A, na cloud B ou na cloud C. Portanto, a forma como eles fazem, a ideia é que seja consistente, independentemente do local onde eu estiver.

Esteja hoje eu nos meus data centers, onde nós temos hoje uma parte das nossas aplicações, esteja eu na cloud A ou B, porque a ideia é que o processo seja sempre o mesmo para fazer deploy das soluções, OK? Independentemente depois de onde as aplicações acabam por aterrar.

Mas então do do do que eu entendo é que nós tínhamos um um bottleneck no aprovisionamento das aplicações porque havia uma centralização dessa dessa atividade e este movimento, criando aqui uma camada, a tal camada de abstração que estamos e que estamos a dizer que dá autonomia ao developer, tira-vos da equação. Não vos tira totalmente, que têm que manter e e garantir que tudo isso está a funcionar, mas dá esse espaço ao developer para parecer ele mais autónomo na na…

Totalmente verdade. Na realidade, o que acontece é nós quando estamos a criar estas abstrações, estamos a dizer assim: “Olha, tu ao developer este este serviço tecnológico, aquilo que é complexidade inerente ao processo de aprovisionamento e configuração, as equipas especializadas que estão nas minhas equipas já o trabalharam, já sabem como é que o devem fazer, portanto, já estabeleceram um caminho h com as configurações otimizadas para aquele tipo de recurso.”

E eu sei que quando o developer fizer o aprovisionamento daquele tipo de recurso, ele vai aprovisionar segundo as minhas regras. E, portanto, se eu de alguma forma estou também habilitado a garantir que se aquilo foi feito daquela forma, eu estou habilitado para suportar também daquela forma.

Portanto, é é garantir aqui esta consistência não só no processo de aprovisionamento, mas também depois no processo de manutenção e operação.

OK. Eh, portanto, em certa medida, né? Nós estamos a delegar autonomia. A equipa central fica focada, por um lado, em desenvolver estas abstrações, tornando-as cada vez mais robustas, e ao mesmo tempo também focar na capacidade de manter aquilo que é a operação destas soluções tecnológicas.

OK. OK. Sim. Esta abstração, estamos sempre a dizer, no fundo, é aqui quase um middleware intermédio que expõe um conjunto de serviços que depois faz a cola com os providers nossos, outros outros providers.

Na realidade é como se tivéssemos nós no meio entre os developers e os sítios onde estamos a alojar das nossas aplicações e tal infraestrutura que falávamos há pouco, tal infraestrutura que está por baixo.

E na realidade este middleware acaba por criar e faz a cola entre as duas partes, por dizer isso. Isso no fundo recebe de forma eh standard as necessidades e depois traduz para a linguagem de cada uma das das infraestruturas que depois temos temos em baixo.

OK. Isto isto faz-me pensar num processo de gestão de mudança que certamente foi preciso fazer com os developers, porque eles estavam habituados de uma forma de trabalhar, um conjunto de, se calhar, eh tomava-se logo uma decisão à cabeça de para onde é que isto vai e fazemos o aprovisionamento para aí, e de repente esse processo muda.

Como é que como é que está a correr essa?

É assim, não há caminhos perfeitos, sendo assim muito transparente. É pá, nunca há, não é?

Portanto, é preciso nós termos aqui um um caminho de adaptação.

Hum, nós temos vindo a fazer um caminho de onboarding, h, ou seja, garantir que as equipas de desenvolvimento vão ter contacto com estas novas, com estas abstrações, com esta forma de ter acesso de consumo da tecnologia, eh, para eles próprios saberem como é que podem ter essa autonomia.

E nós estamos com eles para lhes dar esse guidance e, portanto, garantir que eh eles sabem como é que isto se faz.

E reparem, nas primeiras soluções houve mais um assisted, não é? Houve uma maior assistência daquilo que é com a nossa ajuda.

Sim. Portanto, nós tivemos a apoiar esse onboarding, inclusive temos pessoas que estão focadas em apoiar as streams de desenvolvimento nesse nesse papel. Portanto, garantir que as pessoas estão capacitadas, os developers estão capacitados para usarem estas abstrações da forma mais simples possível e, independentemente das dúvidas que possam haver, nós estamos sempre lá com eles para assegurar que isso acontece da forma mais eh suave possível.

Isto vai ser um trabalho contínuo, porque nós estas abstrações hoje vamos dizer que estamos na versão 1.0 ou 1.01 ou algo do género.

E é natural que nós vamos evoluindo estas estas capacidades para colocar novas funcionalidades, para colocar eh maior simplicidade no processo, eh, que vise continuamente esconder a complexidade por um lado e por outro lado facilitar sempre a vida de quem adota.

Portanto, isto vai ser sempre um caminho iterativo.

É por isso que eu eh em certa medida isto é um caminho de engenharia contínua, portanto isto é como se fosse um produto.

É, não. Na realidade é como se fosse um produto.

Estas abstrações são um produto que tem que ser continuamente evoluído.

Eh, e mediante as evoluções que acontecem, será sempre necessário fazer reajustes neste processo de onboarding com as equipas de desenvolvimento.

Sim. Extensão do portfólio de serviços, não é? Porque como como dizíamos no início, as aplicações são cada vez mais complexas, há necessidades adicionais, provavelmente necessidades não previstas.

Aí vocês vão ter que criar ali mais um mais um tradutor, digamos assim, para manter a arquitetura e a estratégia multicloud.

Sim. Na realidade é assim, nós hoje estamos a endereçar estas abstrações para a nossa tech stack, ou seja, para aquilo que são as nossas peças tecnológicas que nós definimos dentro da nossa tech stack.

E é para aquilo que são novos desenvolvimentos, aquilo que estamos a direcionar, é que a tech stack que deve ser usada esteja relativamente balizada.

Não queremos condicionar totalmente porque mais uma vez a tecnologia evolui, não é? Mas naquilo que é hoje as diria 80, 90% das necessidades deveria estar circunscrita àquilo que é a nossa tech stack e isso também nos permite circunscrever àquilo que é…

Isso é um bom ponto porque acaba por ser aqui um caminho paralelo que depois nos ajuda a consolidar este trabalho que está aqui a ser feito, não é?

Nós estamos a trabalhar numa evolução da da nossa tech stack, mas não podemos ignorar todo o legado.

Eh, e eu queria puxar para aqui o tema do legado também, que é como é que faz esta modernização, como é que faz esta atualização, esta arquitetura, mas ao mesmo tempo tens que manter o legado ou evoluir o legado de forma a manter essa compatibilidade.

Como é que foi lidar com com essa realidade que é natural em empresas da nossa dimensão?

Eu diria que é assim, sendo uma empresa com 40 anos, eh nós não podemos dizer que estamos numa fase muito madura, portanto claramente uma empresa que já tem alguma coisa para ensinar a muita gente ou a muitas organizações.

Eh, temos soluções que pela sua natureza já estão aqui há alguns anos e, portanto, foram construídas com tech stacks diferentes das que estamos a fazer hoje.

E, portanto, eu nem gosto muito de posicionar a palavra legacy como algo negativo. É aquilo que fez sentido em cada momento. Eu diria que se calhar, se estamos a falar daqui a alguns anos, aquilo que estamos a falar hoje vai ser o legado.

Portanto, na realidade temos hoje o que se pode ser qualificado como legacy, que suporta hoje muitos dos nossos processos críticos da organização. Estamos a falar de um ERP, de soluções como um WMS. Portanto, são soluções que, pela sua natureza, foram construídas sobre uma tech stack diferente da que temos hoje.

Hum, e isso, como disse, é normal numa organização como a nossa termos uma diversidade de tech stacks tecnológicas. Nós queremos, obviamente, fazer aqui um narrow down dessa diversidade.

Hum. Mas isto não se faz da noite para o dia, não é?

E, portanto, o que é importante para nós é, por um lado, termos efetivamente soluções com tech stacks diferentes e que não permitem beneficiar deste tipo de abstrações. Temos aqui esta dualidade de soluções e de realidades.

Sim.

Hum, mas também é importante dizer que a tech stack que nós usamos está perfeitamente atualizada e perfeitamente adequada àquilo que são as necessidades dessas soluções, tal como elas estão desenhadas hoje.

Eh, o que é importante é também nós termos consciência que aquilo que estamos a construir hoje está perfeitamente adequado para aquilo que for a modernização destas soluções quando o momento surgir para isso acontecer.

E é isso que nós devemos procurar: mais uma vez uniformizar aquilo que é a stack tecnológica de todas as soluções, sejam elas as novas que nós construímos, sejam elas as que nós vamos modernizando.

Uhum. Ok. Mas para essas soluções legado, potencialmente não compatíveis, tomou-se uma decisão de vamos modernizá-las logo que possível ou vamos deixar essas e focar só nas novas? Que estratégia é que seguimos aqui neste momento?

A estratégia está muito focada naquilo que são soluções que estão desenvolvidas dentro de casa. OK?

Eh, porque temos controlo sobre todo o desenvolvimento, sobre todo o código.

Eh, outras soluções, também pela sua criticidade em termos de importância para o core de retalho, uma transformação dessas não é uma coisa que se faz rapidamente. Portanto, tem que ser pensado um processo de modernização que não vai ser feito em meses, vai demorar algum tempo, não é?

Mas eu diria que nós temos que estar preparados para conviver com estas duas realidades.

Vai ser sempre a forma como nós vamos ter de gerir os nossos sistemas de informação. Vai haver peças que nós seremos capazes de modernizar e ter capacidade de mexer mais rapidamente porque também têm uma dinâmica diferente.

Haverá outras que, pelo seu posicionamento no nosso sistema de informação, teremos que perceber qual o momento em que o fazemos.

Mas o importante, mais uma vez, é quando chegar esse momento, nós termos um caminho bem definido para fazer esta modernização. Temos os pré-requisitos e as condições para o fazer.

Sim, mas no fundo é vamos assegurar tudo o que é novo. O que está para trás é, no fundo, quase caso a caso, com diferentes critérios de risco, momento…

É, é assim.

O que está… E também para ser muito claro, eu quando disse que eram novas soluções, não há dúvida que nós estamos a fazer um processo de refactoring em bastantes soluções que são, diria, mais fáceis de modernizar.

E estamos a fazer isto porque também estamos no processo de transição de uma cloud para outra.

Portanto, nós estamos a transitar aqui um conjunto de soluções de uma cloud para a outra e estamos a aproveitar para, nesta transição, garantir que aquilo que mexemos já nasce com isso mesmo.

Isso mesmo.

Portanto, é um bocadinho isso aqui. Estamos a aproveitar este momento de transição para o fazer.

Certo. Nunca acontece isolado no vácuo. Há sempre fatores externos que depois também aceleram ou atrasam a transição.

OK. Boa.

Vamos tentar aprofundar aqui um bocadinho mais na implementação.

Há pouco falavas num conjunto de serviços que os developers têm acesso para acelerar, para dar autonomia.

Conseguimos instanciar exemplos? Que serviços é que são estes?

Sim.

E, portanto, nós quando decidimos que íamos ter uma arquitetura hybrid multicloud, definimos aqui um conjunto de peças fundacionais que iríamos ter em qualquer cloud onde estivéssemos.

E porquê?

Precisamente para dar aquela consistência que falávamos há bocadinho.

Portanto, nós queremos ter a certeza que a forma como nós vamos instalar as aplicações vai ser usando determinadas tecnologias.

Como por exemplo, vamos usar — e agora espero bem não usar aqui muitos jargões técnicos…

Mas há espaço para isso.

Portanto, estamos a falar de usar Kubernetes, que é um orquestrador de aplicações, porque existe em todos os major cloud providers. Portanto, é algo que acaba por ser um standard comum.

Estamos a falar de usar motores de base de dados open source, portanto PostgreSQL para bases de dados relacionais e Mongo para bases de dados não relacionais.

Portanto, são peças que existem nos vários cloud providers.

As nossas componentes de integração aplicacional, também estamos a aproveitar a modernização destas plataformas para introduzir novas capacidades, como API Gateways.

Nós estamos hoje a usar uma solução muito baseada numa solução da Google, que é o Apigee, e vamos agora transitar para Gravity.

A parte de mensagens entre aplicações também estamos a implementar uma solução que é o Solace.

Portanto, estamos a colocar aqui um conjunto de peças que nos dá a mesma fundação em qualquer cloud onde estejamos.

E, para além destas peças, estamos a dar guias de implementação aos developers de como usar estas peças.

Portanto, quando eu falava naquele onboarding que estamos a fazer às equipas, estamos a fazê-lo nas várias plataformas que estamos a introduzir.

Estamos a falar muito nas plataformas de infraestrutura, plataformas de integração.

Também temos equipas que estão a trabalhar com as equipas de desenvolvimento para dizer: “Olha, vocês para usarem isto neste contexto devem seguir estes padrões e, portanto, é com esses padrões que devem construir as vossas soluções.”

Portanto, todo este guiar das equipas acaba por trazer, acreditamos nós, a consistência que queremos na forma de construir as soluções neste novo contexto.

OK. Portanto, para alguns géneros, isto limita-nos também um bocadinho, não é?

Porque para podermos ter então esta abordagem multicloud, vamos ter que encontrar aqui quase como um mínimo múltiplo comum de peças comuns entre todos para depois conseguirmos fazer essa ligação, ou não necessariamente?

Não necessariamente.

É assim, uma boa parte destas tecnologias existem em qualquer cloud provider.

Eh, as outras peças que eu falei, como por exemplo Gravity e afins, não são naturais de nenhum cloud provider. São soluções third party face ao cloud provider, mas que nós podemos instanciar onde quisermos.

Portanto, na realidade, nós estamos a falar de peças que conseguimos instanciar de forma autónoma em qualquer cloud.

OK?

Portanto, não temos que fazer quase uma interseção das funcionalidades porque senão isso provavelmente ia dar asneira.

Porque depois, e repare precisamente por aquilo que eu disse no início, cada cloud provider tem a sua forma de fazer, de implementar os seus serviços.

Isto é uma coisa muito importante quando nós queremos ser agnósticos ao cloud provider. Nós temos que usar peças que não sejam específicas daquele cloud provider, porque efetivamente depois, se quisermos sair, temos que fazer um refactoring total daquilo e, portanto, isso tira-nos parte da flexibilidade.

Tira-nos parte da flexibilidade, não é?

Portanto, não é esse o objetivo.

OK?

Portanto, aqui um dos drivers fundamentais foi mesmo essa preocupação em escolher peças não necessariamente exclusivas, mas standards no fundo, partilhados entre as várias clouds.

Ok. Ok.

Hum. Eu ouço falar muito em Kubernetes e parece ser uma das peças basilar. Podes, consegues especificar um bocadinho mais o porquê? Porque é que é tão importante? E houve uma altura em que só se falava disto.

Eu diria que assim como houve uma altura em que só se falava disto, ou ainda agora se fala muito disto, eu acho que a tendência é que essa tecnologia vá estar embebida na plataforma. Dada altura nós vamos usar aquilo e já não é natural.

Deixa-me fazer este paralelo.

Mas o que é que isto faz? O que é que Kubernetes nos traz que nós antes não tínhamos?

Deixa-me só fazer este paralelo antes.

Nós ao longo dos anos temos vindo a fazer evoluções no sentido de abstrair a tecnologia que está por baixo, não é? Estamos a fazer aquilo que se chama o shift down.

Portanto, esconder.

Fazer o shift down é esconder a complexidade que está por baixo, não é?

Eh, quando veio o conceito de virtualização do hardware, na realidade, o que ele fez foi esconder aquilo que era o hardware e, portanto, podermos partir o hardware em pequenas peças para podermos rentabilizar melhor o hardware.

O Kubernetes foi uma peça que surgiu para dar um salto acima ainda, que foi para podermos orquestrar um conjunto de recursos, desde computação, desde aquilo que eram componentes de rede, desde o próprio storage, e fazê-lo de forma agnóstica do cloud provider.

Portanto, garantir que eu estou a instalar algo que fica por cima de uma camada de abstração adicional àquela que as VMs nos trouxeram.

Exatamente.

É uma camada de abstração adicional.

Obviamente que isto é a versão simples.

Há uma versão se calhar um bocadinho mais sofisticada da coisa.

Sim.

É isto tudo, mas isto permite fazer orquestração daquilo que são processos de deployment.

Permite automaticamente ter processos que dão a possibilidade de escalar.

Consegue fazer testes se a aplicação está a responder de forma efetiva e, com esses probes, perceber se a aplicação deve levar um restart, por exemplo.

Ou seja, acaba por embebar aqui um conjunto de capacidades para além daquilo que é fazer o scheduling dos recursos, ou seja, de escalonar os recursos necessários para executar as aplicações.

Também consegue fazer testes de que as aplicações estão a funcionar devidamente e, face a isso, tomar ações sobre elas.

Ou seja, acaba por embebar uma perspetiva de deployment, mas também uma perspetiva operacional.

Ou seja, também é capaz de perceber se a aplicação não estiver a funcionar e forçar-lhe um restart.

E este restart é feito de uma forma escondida para o utilizador final.

Ou seja, ele consegue tirar uma parte do serviço do ar sem ninguém se aperceber que caiu nada, não é?

Portanto, acaba por ter ali capacidades de self-healing.

Uhum.

Que acabam por dar também um nível de resiliência diferente dos mecanismos tradicionais de deployment em VMs.

Quando uma VM cai, cai tudo.

O Kubernetes, como tipicamente faz correr aplicações mais modulares e temos várias cópias da aplicação a executar, é mais resiliente.

Porque na realidade temos múltiplas cópias da aplicação a executar e, por cima, temos algo que está a fazer balanceamento de tráfego.

Se por acaso uma cair, ele em cima tem uma inteligência para dizer que atira o tráfego só para aquilo que está a funcionar.

Portanto, isto é uma resiliência nativa completamente diferente do que é o standard, diria eu.

Portanto, temos não só o benefício que Kubernetes nos traz, como a compatibilidade com as diferentes clouds, que também nos ajuda.

Ou seja, mais uma vez, isto traz para aquele tema que falávamos de trazer consistência e trazer processos comuns para os developers poderem disponibilizar as suas aplicações.

Porque o Kubernetes acaba por ser o control plane, ou seja, é sempre o ponto de entrada para os deployments acontecerem.

E, portanto, seja na cloud A, na cloud B ou na cloud C, para o developer isso é transparente.

Ou seja, não tem que se preocupar para onde é que isto vai parar. Eu tenho que me preocupar com esta abordagem.

Depois esta abordagem há de lidar com o sítio onde vai parar no final.

Há pouco, eu já te perguntei, José, sobre a gestão da mudança e queria voltar a este tema porque o impacto disto é algo que não se faz sem esforço e não é tão rápido quanto nós desejaríamos.

E o que é que foi mais desafiante ao longo desta transformação?

E é uma transformação que ainda estamos a fazer, portanto ainda há muito para fazer.

Mas o que é que tem sido mais desafiante?

Eu diria que a nossa vida é feita de desafios, não é?

Mas este primeiro…

Isto é uma transformação que vai estar sempre a acontecer. Como eu disse, isto é um conceito de produto, de evolução contínua.

Hum.

Mas, para ser muito concreto à tua pergunta, fazer esta transformação implica trazer aqui um conjunto novo de skills na forma como se trabalha este tipo de tecnologias.

Skills que não abundam muito no mercado, infelizmente.

E não é uma coisa que apareça facilmente.

Mas também não é uma prática comum.

É algo novo e emergente.

Eh, não é expectável que exista muito conhecimento ainda à volta disto, não é?

É, sim.

E eu diria que é uma prática que algumas organizações têm tentado fazer através da adoção de ferramentas de mercado.

OK. OK.

Mas depois existem sempre especificidades, não é?

E quando nós adotamos ferramentas de mercado também criamos ali alguma dependência.

E, portanto, aquilo que tentámos foi construir algo que fosse mesmo nosso. Uma plataforma nossa, algo que nós conseguíssemos gerir e evoluir ao longo do tempo.

Mas como estava a dizer, introduzir tecnologias como Kubernetes, na realidade, nós de repente estamos a trazer um conjunto de skills muito diferenciados.

Estamos a falar de pessoas que têm que perceber de coisas como — agora vou entrar em modo jargão — têm que conhecer Linux, têm que conhecer conceitos de rede, têm que conhecer conceitos de balanceamento, têm que conhecer um conjunto de coisas.

Dizes isso das pessoas da tua equipa que estão a montar estas peças. Portanto, acabam por ser um conjunto de valências que é difícil concentrar.

Difícil concentrar.

Exatamente.

E pressupõe que as pessoas tenham vontade de fazer isso.

Tipicamente, tu vias as pessoas que faziam gestão de sistemas Linux como um perfil muito específico.

Quem geria uma rede era outro perfil.

Era tudo muito verticalizado.

E agora nós aqui precisamos de pessoas que sejam quase multifacetadas, não é?

Porque é quase um full stack mesmo no fim do dia.

É isso.

Porque depois, quando nós estamos a usar tecnologias como Kubernetes, acabamos por tocar nestas valências todas.

E não ter estas valências acaba por trazer menos destreza no momento em que estamos a construir ou no momento em que há temas mais de operação.

Portanto, eu diria que o tema do conhecimento é uma dificuldade.

Não é fácil trazer pessoas para estas áreas.

Para além de que temos alguma rotatividade também, como noutras áreas da indústria.

Hum. Mas temos vindo a fazer um caminho de nos capacitar.

Hum, mas é algo que temos que continuamente evoluir porque a dinâmica de mercado também nos traz desafios.

É verdade, é verdade.

A atualização constante, mas sim, fica a nota. Portanto, a possibilidade ou a capacidade de conseguirmos atualizar e dotar as pessoas da equipa com o conhecimento necessário.

OK.

Um dos drivers para esta mudança foi servir melhor os developers. Portanto, à partida isto é uma boa notícia para eles.

Por outro lado, temos que pensar que há sempre aquela natural resistência à mudança, que é: “mas eu já estava habituado”, seja melhor ou pior, “eu já estava habituado à forma anterior”.

Como é que foi gerir esta alteração na forma como os developers trabalham? Foi bem recebido, não foi recebido?

Depende.

E dizer depende é sempre uma boa…

É, é a resposta típica de consultor.

Exato. Exato.

Mas é assim, eu diria que no início, e nós começámos isto primeiro com uma stream em que começámos a fazer este processo de gestão de mudança, e no início foi mais difícil.

OK?

E as pessoas, diria que, estranharam um bocadinho.

Hum, mas posso dizer que essa stream, passados uns meses, tudo aquilo que construíam em termos de novas soluções passou a ser usando esta nova filosofia.

Portanto, começaram a ver o benefício de terem autonomia naquilo que eram os processos de aprovisionamento de tecnologia.

Portanto, eu acho que nós tivemos, mais uma vez, também pelo estágio de maturidade das várias equipas — porque não estamos todos iguais, ninguém está, acho eu, ninguém pode dizer que está.

Hum, mas as equipas que começaram primeiro diria que hoje estão num estágio completamente diferente.

Ou seja, já não conhecem, se calhar, como é que era dantes.

Como é que era dantes, não é?

Exatamente.

Como é que eu acho que as pessoas… Um problema hoje seria: como é que se fazia isto antes?

Diria que é mais isso.

Há arestas a limar.

Reparem, nós tivemos a fazer um conjunto de capacidades para, mais uma vez, esconder cada vez mais a complexidade.

E eu diria que, à medida que vão vendo os serviços a ficarem disponíveis, a tendência é quererem ver mais.

“Mas isto ainda não está”, “isto ainda não está”.

E nós dizemos: “Isso vai estar mais à frente. Essa parte ainda não dá. Ainda não és autónomo aí. Ainda depende de uma equipa central.”

Portanto, nós…

Há motivação para puxar.

É, é verdade.

E repara, nós fazemos, precisamente relacionado com o processo de change, grupos trimestrais para termos uma sessão com os principais stakeholders das várias streams e percebermos onde é que eles estão a ter mais dificuldades, onde é que estão a ter mais dores.

Coisas que nós achamos que até estão a funcionar, mas que na realidade podem não estar.

Portanto, nós queremos que isto, sendo um produto, também tenha feedback contínuo para nós podermos evoluir.

Eles são os nossos consumidores. Portanto, nós queremos consumidores satisfeitos.

E, querendo consumidores satisfeitos, temos que fazer por isso.

Claro, claro. Tem que prestar um bom serviço e ouvi-los.

Hum. Boa.

Em relação ao impacto que isto está a ter, já se consegue medir? Já se consegue sentir em alguma dimensão os benefícios?

Seja em reduzir complexidade, dar autonomia aos developers, entregar mais rápido?

Sei que isto também é um processo que começou há relativamente pouco tempo e aí também podes usar um bocadinho de quando é que definimos a estratégia, quando é que começámos a implementar e em que fase é que estamos.

Mas, se sim, que tipo de impacto é que já estamos a sentir? Que benefícios é que já estamos a sentir de forma direta pela organização e pelos developers em particular?

É assim, nós começámos a trabalhar com estas tecnologias de Kubernetes e todo este conjunto de outras peças há cerca de um ano, um ano e meio atrás.

Em 2025 acabámos por estar a definir aquilo que devia ser a nossa abordagem para a nossa estratégia hybrid multicloud.

Portanto, garantir que tínhamos aqui todas as peças necessárias para darmos esta consistência.

Mas, em paralelo com esta definição, nós estávamos já a trabalhar com as equipas no sentido de começarmos a dar estas abstrações.

Quando nós fechámos a nossa estratégia para a arquitetura multicloud e começámos a implementar estas peças fundacionais que referi há bocadinho, agora no início de 2026, trazendo estas capacidades para a nossa cloud primária, que passou a ser Google, acabámos por fazer algum refactoring daquilo que eram as nossas abstrações.

OK?

Portanto, tivemos de robustecer essas abstrações para também incorporar mais funcionalidade.

Ou seja, para aquilo que os developers já conseguiam fazer durante o ano de 2025 com relativa autonomia, havia ainda coisas que não conseguiam fazer.

O que acabámos por fazer durante o primeiro trimestre de 2026 foi dar passos adicionais para que essa autonomia aumentasse.

Só para dar um exemplo: nós até bem pouco tempo dávamos a capacidade de aprovisionarem uma aplicação, mas depois, quando essa aplicação tinha de estar pública para a internet, havia necessidade de envolver outras equipas que faziam configurações noutros equipamentos.

Entretanto, o que estamos a fazer foi dar um passo adicional para que essa configuração passasse a ser feita de forma autónoma pelo developer.

Ou seja, quando ele diz “eu quero publicar um serviço para a internet”, esta abstração faz as configurações todas necessárias, inclusive as configurações nos equipamentos que publicam os serviços para a internet.

Portanto, faz tudo no mesmo pipeline.

Mas o developer tem conhecimento para conseguir fazer essas especificações depois?

Não.

Simplesmente ele faz uma especificação. Só diz: “Eu quero este serviço público na internet.”

E undercover a coisa acontece.

OK?

É esse o objetivo.

Aliás, o objetivo é que eu possa mudar as peças por baixo e o developer não tenha que saber isso.

É esse o grande desígnio desta mudança.

OK.

Gostava de explorar agora, antes de começarmos a fugir para a parte final do nosso podcast, olhar um bocadinho para o futuro nesta área.

Que mudanças é que antecipas? O que é que achas que vai marcar os próximos anos?

Nós estamos a fazer esta evolução. Tudo anda muito rápido, ainda por cima agora num mundo em que a inteligência artificial vem acelerar aquilo que nós já achávamos que era rápido demais.

O que é que tu antecipas aqui para esta área?

Eu diria que nós, enquanto tech digital, tudo o que for novas tecnologias para dar serviço às nossas aplicações, cada vez mais tem que estar embebido neste contexto de ser dado de forma transparente para o developer consumir.

O desígnio tem que ser: se eu escolher a tecnologia X, ela tem que ser usada pelo developer de forma transparente e fácil, completamente sem ter que pensar no que está por baixo.

É esse o objetivo.

Eu não tenho que saber que para publicar um serviço para a internet tenho que fazer 50 coisas num equipamento.

Isso tem que acontecer undercover.

É esse o desígnio em tudo aquilo que fazemos e queremos manter.

Sim, sim.

Mas pensando no futuro, seja a forma como os developers vão lidar com estes serviços ou se estes serviços vão ser ainda mais abstraídos com uma nova camada, mas também para o vosso trabalho, a forma como vocês constroem, mantêm e evoluem estes serviços, o que é que antecipas que possa vir a mudar?

Olha, sem promessas de futurologia, porque hoje a futurologia tem que ser feita para seis meses ou um ano.

Mais do que isso começa a ser difícil.

Mas claramente a IA vai ter que ser um enabler para nós.

Não só na velocidade com que fazemos, mas também na forma como operamos.

Nós hoje começamos a ver a IA a ajudar-nos a fazer coisas que antes demoravam imenso tempo e exigiam muita investigação.

Hoje vemos o — e eu gosto deste nome, embora ache que não foi por acaso — Copilot.

Não o produto Copilot, mas o conceito de um copiloto.

Exatamente.

Eu gosto disso porque acho que efetivamente é assim que devemos ver.

Acredito que a IA vai determinar muito a forma como vamos construir estas plataformas e estas abstrações.

Vai ter que estar embebida em tudo aquilo que fazemos.

Não há outra forma.

Acredito que aquilo que hoje são os developers a fazerem as suas especificações, nós possamos começar a dar agentes para poderem fazer isso.

Portanto, serem agentes a interagir com essas abstrações.

Era aí que eu queria chegar.

E até mais pela evolução que nós estamos a fazer na MC Digital, da atualização do nosso ciclo de desenvolvimento de software, alavancado cada vez mais em agentic engineering.

Nós temos estado a dizer que são serviços que os developers vão consumir, mas na verdade o developer do futuro vai ser um orquestrador de agentes.

Portanto, são serviços que os agentes vão consumir.

Até que ponto isso muda ou não a figura e aquilo que temos que evoluir nesta exposição de serviços?

Eu diria que será a evolução natural.

Teremos agentes a consumir estas abstrações.

É a única forma de ser sustentável.

Se desenvolvemos mais rápido, mas depois temos alguém a fazer especificações manualmente, deixa de fazer sentido.

Portanto, isto tem que encaixar no pipeline como um todo.

No pipeline de desenvolvimento até ao momento em que há o deployment.

Isso também tem que alimentar um agente.

Tem que ser integrado.

Não vejo que não possa ser assim.

Tem que ser mesmo assim.

Ainda vamos descobrir.

E em breve, até porque estamos a fazer esse caminho na MC Digital.

Ainda não chegámos a essa parte final do deployment, mas não vai demorar.

E aí teremos que ter respostas.

Uma última pergunta.

Tu há pouco levantaste um tema que eu não estava sequer a considerar e queria explorar.

Disseste que algumas empresas estão a fazer este caminho de uma forma alternativa.

Em vez de montarem esta plataforma, estão a ir para soluções de terceiros.

Vamos bater na tecla típica do build or buy.

Que critérios é que nós usamos para irmos pelo caminho do build e não tanto do buy?

Eu até vou antecipar — e diz-me se estou correto — que se estamos a tentar fugir ao lock-in de um determinado fornecedor, iria um bocadinho contra o princípio.

Mas às vezes há trade-offs que temos que fazer.

Qual foi o racional da decisão?

Essas soluções que existem no mercado são apenas parte da solução.

Ou seja, a parte de instanciar a nossa realidade tem que ser construída na mesma.

Aquilo que pensámos foi: porque é que eu vou criar mais uma dependência quando posso fazer isto com uma interface relativamente simples?

As pessoas ficam dependentes de fazer um pull request no Git e a coisa acontece a partir daí.

Ou então temos uma interface gráfica onde se fazem alguns cliques.

O ganho não justificava.

Eu julgo que não.

E repara, também não estávamos num estágio de maturidade para comprar algo e achar que um mês depois estava tudo a funcionar.

Não.

Na realidade, o que dá mais trabalho é a implementação deste trabalho todo.

Criar a abstração da tecnologia que está por baixo.

Exatamente.

E depois, se quisermos, com o advento da IA, as interfaces tornam-se menos relevantes.

Hoje em dia isso não é o mais difícil.

Não que estivéssemos a pensar nisso quando começámos, mas efetivamente a evolução foi tão rápida que se calhar foi uma boa decisão.

Sim, sim.

Olha, e já agora, também acabámos por não falar nas timelines.

Quando é que começámos a pensar nisto? Quanto tempo demorámos a desenhar a estratégia e o que é que tem sido a implementação?

É assim, nós em termos de estratégia hybrid multicloud começámos.

E deixa-me pôr aqui uma nota.

Quando digo hybrid tem a ver com o facto de nós também termos os nossos data centers.

Temos cloud pública e privada.

Exatamente.

E portanto temos aqui muitos serviços que, apesar de nascerem na cloud pública, têm dependências com serviços privados nos nossos data centers.

Daí chamar-lhe hybrid multicloud.

Mas estava eu a dizer que a nossa estratégia foi definida durante o ano de 2025.

Tivemos a fechar um conjunto de soluções, como o caso da API Gateway e do Solace, durante 2026.

E depois acabámos por aproveitar um momento em que tomámos a decisão de fazer a nossa mudança para GCP.

Como no final do ano acabámos por tomar a decisão de ir para a Google Cloud Platform, aproveitámos esta transição para montar as peças nesta nova cloud.

Garantindo que juntávamos o útil ao agradável.

Houve um bom casamento de timings.

Ou, na verdade, um iria implicar o outro ou gerar retrabalho.

E aproveitou-se para fazer o trabalho conjunto.

Faz-me sentido.

Como eu dizia no início, estas coisas não acontecem de forma isolada.

Há sempre um contexto e outras alavancas e variáveis externas que temos que ter em consideração.

Boa.

Reta final.

Temos aqui o nosso último desafio, que é a clássica Caixa de Favoritos.

Agora fora do teu mundo profissional, mas também se quiseres ir por aí, como consumidor, que tecnologias ou soluções te chamaram mais a atenção recentemente ou que gostas de usar ou não conseguias viver sem?

E porquê?

Olha, estávamos a falar um bocadinho sobre isso.

Uma solução sem a qual eu não consigo viver, enquanto consumidor nas lojas Continente, é o Continente Pay.

Porquê?

Eu já não uso cartões há não sei quanto tempo.

Estou totalmente digital.

A única coisa que levo quando vou às compras é o meu telemóvel.

E, portanto, sinto que é uma solução altamente cómoda para quem vai fazer compras.

Não temos que andar com cartões nem complicações.

Ajuda muito à desmaterialização e é algo que, enquanto consumidor, me facilita muito a vida.

Tenho até tentado convencer a minha mulher a fazer o mesmo, porque ela ainda é um bocadinho mais tradicional do que eu nesse aspeto.

As pessoas vão vendo que estas soluções de desmaterialização trazem benefícios enquanto consumidores.

Eu pelo menos já não me lembro da última vez que usei um cartão multibanco.

Então és um consumidor sem carteira.

Sem carteira, exatamente.

E então também tens a desmaterialização dos cartões todos? Cartão de cidadão e assim? Usas a aplicação do Governo?

Eu não ando com carteira.

Não andas com carteira?

Boa.

Eu por acaso também tenho isso tudo, mas tenho sempre um backup na carteira.

É sim. Repara, já me aconteceu chegar lá e a app gov não estar a funcionar por algum motivo.

Fiquei um bocado nervoso, mas depois a coisa recuperou.

Claro.

Isso nunca aconteceu no Continente Pay.

No Continente Pay funciona sempre.

Boa.

José, muito obrigado por esta conversa.

Acho que fica claro que estamos a preparar tecnologia para o futuro, fundações mais consistentes para os nossos developers e para as nossas aplicações.

Menos dependência, mais autonomia.

E esta estratégia vem reforçar estes princípios.

Muito obrigado por nos mostrares um bocadinho mais sobre como estamos a fazer este caminho.

Para quem nos está a ver lá em casa, muito obrigado por nos acompanharem.

Não se esqueçam, temos mais conteúdo no blog, podem acompanhar-nos por lá.

E voltamos em breve para mais um episódio da Caixa Central.

Até já.