Recentemente, liderei as frentes de Produto e UX no desenvolvimento de uma solução SaaS de IA para SEO, com um foco estratégico na adoção de tecnologias que acelerassem a busca pelo Product-Market-Fit (PMF) e pelo Minimum Viable Product (MVP). A abordagem escolhida também visava otimizar fatores cruciais, como a redução dos custos de desenvolvimento e a diminuição da curva de aprendizagem, garantindo um processo mais eficiente e acessível. Por isso, decidimos utilizar a seguinte stack de soluções para o desenvolvimento do software: Figma (prototipagem); Solução no-code para front-end web; A princípio íamos utilizar backend low-code, mas pivotamos e usamos tecnologia high code. Uma das principais vantagens dessa stack é que a velocidade de desenvolvimento do front-end seria muito maior por conta dos facilitadores, mas mantivemos o core da solução no backend em tecnologia high code, permitindo escala com melhor eficiência em cloud e flexibilidade. Posso explicar melhor o racional e quais opções nós cogitamos em um próximo post, mas vamos em frente aqui (comenta aqui se você gostaria de ler sobre isso). 5 lições aprendidas com no-code: 1. Velocidade maior: É indiscutível que uma solução no-code traz mais agilidade no desenvolvimento, acredito que reduzimos o tempo de desenvolvimento do front-end na ordem de 80%. Chega a ser bonito ver a facilidade que é criar as interfaces e os workflows, ainda mais quando você pode simplesmente utilizar um plugin e importar as telas diretamente do Figma. Se você é UX ou PM, imagine validar entregas e fazer ajustes de forma ágil. Melhor ainda: você mesmo pode criar as interfaces! Eu mesmo fiz isso diversas vezes ao longo do projeto. Muitas vezes, gastamos tempo documentando pequenos ajustes de usabilidade para que os desenvolvedores os corrijam, mas, nessa abordagem, bastava selecionar a camada e ajustar diretamente, sem intermediários. Tem um ponto positivo que vale destacar: O software no-code que usamos tem uma estrutura de auto-layout bem parecida com o Figma, se você domina Figma, vai tirar de letra. 2. Existirá uma curva de aprendizagem: Existem poucos profissionais com experiência prática na utilização de tecnologia low/no-code no país. Isso significa que você provavelmente vai ter que treinar o time a lidar com essa tecnologia, e naturalmente isso vai gerar alguns erros operacionais, bugs, e vai fritar alguns neurônios. A curva de aprendizagem é bem menor que uma tecnologia high-code, mas vai levar um tempinho para você construir um time maduro. 3. Você vai ter que repensar alguns processos: Gestão de equipes, branches, merges, servidores de homologação, deploys… Você vai ter que pensar nesses processos para garantir qualidade nas entregas e mitigar erros. Imagina alguém dar um “misclick” no software no-code e subir em produção uma branch errada… 4. Problemas novos surgem: Nem tudo são flores, ao utilizar uma plataforma para desenvolver um software, você pode acabar ficando dependente da empresa que fornece a plataforma (o famoso vendor lock-in), por isso é importante escolher de forma consciente qual tecnologia você vai utilizar. No caso do software que escolhemos, é possível exportar o projeto em código, então se no futuro você quiser tirar da plataforma, é possível, apesar que nunca fiz isso, você já exportou um projeto em produção? Conta aqui como foi. Além disso, você começa a se deparar com problemas diferentes, por exemplo, tinha uma tela que possuía um comportamento que com um simples “for” resolvia no código, mas no no-code foi um desafio… Print de uma call onde estávamos tentando resolver esse problema: 5. Vai haver quebras de paradigmas: Como em qualquer mudança, algumas pessoas poderão se sentir ameaçadas, com medo, ou resistentes. Você precisa encontrar pessoas dispostas a reaprender várias coisas, e a desbravar o novo. Não tivemos pessoas resistentes nesse projeto mencionado, mas já presenciei em outros ambientes pessoas que ainda acreditam que essas soluções não escalam e que não funcionam. Conclusão O uso de ferramentas low-code/no-code, como o WeWeb, tem nos ajudado significativamente a acelerar experimentações e o desenvolvimento de software. No entanto, nem tudo são flores: ao longo do caminho, tivemos que repensar diversos processos de DevOps, à medida que surgiam nuances específicas de se manter um software low-code em produção. O verdadeiro desafio de qualquer negócio está em entender profundamente as necessidades dos clientes e encontrar maneiras eficazes de aumentar o engajamento, o valor percebido, a aquisição e a retenção. Além disso, todo produto de software carrega um custo muitas vezes negligenciado: o custo de oportunidade. Esse custo representa o tempo e os recursos que decidimos investir em uma determinada iniciativa (tempo que poderia estar sendo direcionado a outras apostas potencialmente mais valiosas). Ao acelerar o desenvolvimento com low-code/no-code, conseguimos reduzir substancialmente esse custo, permitindo que o foco da equipe esteja onde realmente importa: gerar valor para o cliente, e não apenas escrever código.

Um design system bem construído pode acelerar produtos. Mas é a documentação que faz ele funcionar de verdade. O que é um design system Um design system não é apenas uma biblioteca de componentes, mas sim um conjunto de componentes reutilizáveis, diretrizes e boas práticas que orientam a criação de interfaces digitais de forma consistente e escalável. Ele combina design, código, padrões de interação, escrita e princípios de marca em um repositório vivo e colaborativo, geralmente mantido por times de design, desenvolvimento e produto. A documentação deve explicar o "porquê", o "quando" e o "como" de cada elemento. Sem ela, o design system vira apenas uma biblioteca técnica, difícil de adotar, manter e escalar. O papel da documentação A documentação é a fundação que sustenta o design system como uma ferramenta estratégica. Ela conecta elementos visuais e funcionais ao seu contexto de uso real, evitando dúvidas, decisões isoladas e retrabalho entre as áreas. Mais do que um manual técnico, a documentação atua como uma fonte única de verdade (single source of truth) para todos os times envolvidos na construção de um produto digital. Designers, desenvolvedores e PMs encontram ali um ponto de referência confiável sobre padrões de interface, diretrizes de uso, regras de comportamento e justificativas por trás das decisões de design. Com isso, a comunicação entre áreas se torna mais clara, o onboarding de novos profissionais fica mais rápido, esforços duplicados são evitados e o alinhamento com a identidade da marca e os objetivos do produto é mantido com muito mais consistência. A documentação permite que decisões sejam tomadas com mais segurança, pois todos trabalham com base nas mesmas informações, sem achismos, ruídos ou interpretações divergentes. Em resumo, ela garante que o design system seja compreendido, aplicado e evoluído da forma correta, tornando-se uma base sólida para colaboração e escala. Benefícios para todos Não estamos falando apenas de boas práticas teóricas. Os resultados são concretos e comprovados por algumas das empresas mais inovadoras e influentes do mercado. Organizações como IBM, Shopify, Atlassian e Adobe, grandes referências globais, há tempos entenderam que a documentação de um design system não é um detalhe, mas sim um dos pilares para garantir eficiência, qualidade e escala no desenvolvimento de produtos digitais. Essas empresas, reconhecidas mundialmente por sua excelência em design e tecnologia, obtiveram ganhos mensuráveis ao estruturar bem a documentação dos seus sistemas. Entre os benefícios estão a aceleração no tempo de entrega, a redução de bugs e a eliminação de esforço duplicado. Um experimento conduzido pela Figma comparou dois times de design de produto: um utilizando a documentação de um design system e outro sem esse suporte. O resultado foi expressivo. A equipe com documentação conseguiu atingir seus objetivos 34% mais rápido. A principal razão foi a agilidade obtida ao evitar tarefas repetitivas, como recriar componentes do zero, procurar elementos em arquivos antigos ou tomar decisões recorrentes sobre espaçamentos, tamanhos e estilos tipográficos. Os participantes também relataram um aumento significativo na confiança ao longo do processo, destacando que a reutilização de componentes bem documentados contribui diretamente para a consistência com o produto final. Esses benefícios se estendem para outras áreas da empresa. Desenvolvedores ganham eficiência ao reutilizar elementos confiáveis, o que reduz retrabalho e falhas. Equipes de produto aproveitam esse ganho de produtividade para acelerar as entregas e diminuir o time-to-market. Para os usuários, tudo isso se traduz em uma experiência mais consistente, estável e confiável, com entregas frequentes de valor. Como referências, gostaria de mencionar dois exemplos de documentação que considero excelentes. O primeiro é o Padrão Digital do Governo, o design system do governo federal. Seu propósito é fascinante: oferecer a milhões de brasileiros uma experiência padronizada em todos os produtos e serviços digitais do governo — esteja o cidadão declarando o imposto de renda, consultando o FGTS ou acessando o título de eleitor. Segundo a própria documentação, o objetivo é claro: "oferecer uma experiência única ao cidadão que se relaciona com o governo para acessar produtos e serviços." Em poucos anos, já é possível perceber avanços significativos na experiência digital, como o login unificado gov.br, que pode ser utilizado inclusive em serviços estaduais e municipais. Outro bom exemplo é o design system da Conta Azul, que se destaca por ir além do convencional. Sua documentação inclui, além de componentes e padrões visuais, conteúdos aprofundados como guias de onboarding, redação e pesquisa, oferecendo uma base completa para todas as áreas envolvidas na construção do produto. Para quem busca mais referências nacionais, recomendo visitar o site designsystemsbrasileiros.com, uma curadoria colaborativa com diversos exemplos de design systems utilizados por empresas e instituições brasileiras. A plataforma reúne iniciativas públicas e privadas, oferecendo uma visão ampla sobre como diferentes organizações têm estruturado e documentado seus sistemas para promover consistência, escala e eficiência no desenvolvimento de produtos digitais. Conclusão Um design system bem documentado não é apenas uma ferramenta de design. Ele se torna um ativo estratégico da empresa. Ele conecta pessoas, define padrões, acelera entregas, aumenta a autonomia do time e reduz custos com retrabalho. Para desenvolvedores, a documentação facilita a implementação, reduz dúvidas e acelera o uso de componentes reutilizáveis, promovendo código mais limpo e consistente. Para os times de produto, ela aumenta a previsibilidade dos projetos, melhora a colaboração com design e engenharia e ajuda a reduzir o time-to-market. Já para os usuários, tudo isso se traduz em uma experiência mais estável, intuitiva e coerente em cada ponto de contato com o produto.

A Internet Engineering Task Force (IETF) - organização internacional aberta que desenvolve e promove padrões técnicos para a internet, como os protocolos TCP/IP, HTTP e DNS - acaba de lançar a RFC 9745, que define uma forma padronizada de se informar a depreciação de recursos no contexto do HTTP, o que é especialmente relevante para APIs baseadas neste protocolo. Em resumo, a partir de agora, servidores podem informar seus clientes sobre o status de depreciação de determinados recursos utilizando o cabeçalho de resposta Deprecation, cujo valor é uma data, no passado ou futuro, indicando que o recurso já foi ou ainda será depreciado. Adicionalmente, é possível utilizar o cabeçalho link para apontar uma documentação e, também, o Sunset, trazendo a data na qual o recurso se tornará indisponível. Neste artigo iremos avaliar a viabilidade de se aplicar este padrão no mundo real. Utilizando as melhores práticas no desenvolvimento de APIs, partiremos de arquivos de definição que seguem a OpenAPI Specification e terminaremos no API gateway KrakenD. Impactos Como dito, este novo padrão é especialmente importante para as web APIs, ou seja, para as APIs que aderem ao protocolo HTTP, como as famosas REST. Neste contexto, a RFC oferece meios de se levar as políticas de depreciação — outrora restritas à documentação ou ao design time — ao tempo de execução. Portanto, a novidade tem o potencial de seriamente mitigar as quebras de integração, possibilitando aos desenvolvedores realizarem as adaptações necessárias com uma antecedência confortável. Aliás, vale lembrar que estamos entrando na era da A.I. (com seus agentes, servidores MCP e etc.), o que só faz aumentar o impacto deste novo padrão, já que eles podem aprender e se adaptar sozinhos diante da sinalização de depreciação. No contexto de governança, a RFC também torna possível aos fornecedores de gateways de API (como Kong, Tyk, KrakenD, Traefik, APISix e etc.) considerarem o novo padrão durante os processos automatizados de deploy de APIs, sobretudo quando pensamos em APIOps baseado em OpenAPI specification. Vejamos. A especificação OpenAPI prevê a indicação de depreciação de operações através do campo deprecated. Com esta nova RFC, é simplesmente natural pensarmos em linkar as coisas, ou seja, fazer com que a indicação de depreciação presente nos arquivos de definição encontre correspondência na configuração dos gateways, que, uma vez em execução, passem a injetar o novo cabeçalho de resposta nas operações apropriadas. Esta melhoria levaria a governança ao próximo nível de qualidade! Provando o conceito Utilizaremos o arquivo de definição aderentes à OpenAPI Specification (OAS) para descrever nossa API, construiremos um parser em Go utilizando a libopenapi, contaremos com o KrakenD como API gateway e um HttpBin como backend. Todos os detalhes do projeto podem ser encontrados neste repositório. Então, vou destacar apenas os pontos principais: O arquivo de definição (openapi.yaml) paths: (...) /users/{userId}: (...) delete: (...) deprecated: true Observe que a operação de deleção de usuário conta com o campo padrão da OAS deprecated com o valor true. Bem, é fácil perceber que estamos diante de uma incompatibilidade de impedância quando tentamos fazer esse booleano interagir com os novos cabeçalhos previstos na RFC 9745, já que estes são muito mais ricos em informação do que aquele. Por razões como esta, a OAS possui extensões, que, no nosso caso, serão utilizadas para descrever as propriedades esperadas pela RFC da seguinte forma: paths: (...) /users/{userId}: (...) delete: (...) deprecated: true x-deprecated-at: "2025-06-30T23:59:59Z" x-deprecated-sunset: "2026-01-01T00:00:00Z" x-deprecated-link: https://api.example.com/deprecation-policy O Parser A função do parser é ler e interpretar o arquivo de definição openapi.yaml, extrair as informações relevantes para o gateway, e criar o arquivo operations.json, que será embarcado na imagem do KrakenD e consumido durante a sua inicialização, numa abordagem denominada configuração flexível. Este é o resultado do operations.json: { "list": [ { "path": "/users", "method": "get", "backend": { "path": "/users", "host": "http://backend:8888" } }, { "path": "/users", "method": "post", "backend": { "path": "/users", "host": "http://backend:8888" } }, { "path": "/users/{userId}", "method": "get", "backend": { "path": "/users/{userId}", "host": "http://backend:8888" } }, { "path": "/users/{userId}", "method": "delete", "deprecated": { "at": "@1751327999", "link": "https://api.example.com/deprecation-policy", "sunset": "Thu, 01 Jan 2026 00:00:00 UTC" }, "backend": { "path": "/users/{userId}", "host": "http://backend:8888" } } ] } Observe que o parser projetou os elementos estendidos da OAS no arquivo de configuração do KrakenD, inclusive fazendo as devidas conversões de valores, da seguinte forma: OAS KrakenD x-deprecated-at: deprecated.at: x-deprecated-link: deprecated.link: x-deprecated-sunset: deprecated.sunset: O plugin Agora que a configuração do gateway foi devidamente gerada a partir do arquivo de definição, nosso plugin personalizado entra em cena. A sua função é identificar as operações de API depreciadas e inserir os cabeçalhos da RFC 9745 com os valores adequados. Mais detalhes podem ser encontrados no repositório do artigo. Mas, uma vez que o plugin foi embarcado no KrakenD, temos os seguintes resultados: GET /users/1 DELETE /users/1 Observe que apenas a segunda operação estava depreciada (vide operations.json) e o gateway adicionou corretamente os cabeçalhos na resposta. Conclusões O experimento mostrou a viabilidade do conceito, ou seja, que é possível levar as políticas de depreciação para além da definição e documentação, sendo facilmente comunicadas em tempo de execução. Desta forma, os sistemas podem adotar ações automatizadas para comunicar a obsolescência aos interessados e reduzir significativamente as chances de falhas nas integrações. Embora as extensões da OpenAPI Specification tenham tornado isso possível diante da insuficiência do booleano deprecated, imagino que a OpenAPI Initiative deve incluir uma melhoria nas próximas versões. Sobretudo quando penso que Eric Wilde, co-autor desta RFC, é bem atuante no mundo das APIs. Aos leitores que chegaram até aqui, meu muito obrigado. Espero que estas poucas palavras lhes tenham acrescentado algo e feito o seu tempo valer a pena. Referências RFC 9745: https://www.rfc-editor.org/rfc/rfc9745 OpenAPI Specification: https://spec.openapis.org/oas/latest.html Incompatibilidade de Impedância: https://devblogs.microsoft.com/oldnewthing/20180123-00/?p=97865 Repositório: https://github.com/MichelFortes/articles-RFC9745 HttpBin: https://hub.docker.com/r/michelfortes/httpbin KrakenD – flexible configuration: https://www.krakend.io/docs/configuration/flexible-config PB33F - libopenapi: https://pb33f.io/libopenapi/

Sabemos que com o surgimento de diversas tecnologias, há um grande aumento do número de termos que ouvimos falar, embeddings é um deles, mas o que são?Embeddings, que em inglês significa "incorporar", é um termo utilizado em IA e Processamento de Linguagem Natural (PLN). Refere-se ao processo de "incorporar" ou "embutir" informações complexas (como palavras, frases ou documentos) em um espaço vetorial. Isso significa que dados que seriam difíceis de processar diretamente são transformados em uma forma numérica (vetores), que os modelos de Machine Learning podem entender e usar para tarefas como classificação e análise semântica. Quando combinados com bancos de dados vetoriais, possibilitam que sistemas analisem grandes volumes de dados não estruturados. Isso permite a extração de informações relevantes e consultas complexas de forma rápida e eficaz. Essa técnica de transformação de dados é essencial na construção de soluções escaláveis, pois a representação vetorial facilita a busca e recuperação de informações além de comprimir suas informações e ainda assim manter a relação com o seu conteúdo original. Como funciona Sabemos que Embeddings são vetores para entendimento de máquina baseados em textos, fases, documentos. Mas como transformamos essas informações em vetores?Os vetores são formados a partir da utilização de modelos de IA treinados para identificar contextos, classificando-os com base na aproximação do contexto em números, que normalmente variam de -1 a 1. O valor 1 indica a maior proximidade, com milhares de parâmetros de comparação. Esses modelos são geralmente treinados com grandes volumes de texto, identificando padrões de concorrência entre palavras que aparecem frequentemente em contextos semelhantes, como "gato" e "animal". Durante o treinamento, o modelo aprende a mapear essas palavras para vetores numéricos em um espaço multidimensional, de forma que palavras com significados relacionados ou contextos similares fiquem posicionadas mais próximas entre si nesse espaço vetorial. O objetivo é fazer com que palavras ou frases com significados semelhantes fiquem mais próximas no "espaço" dos vetores. Por exemplo, "gato" e "cachorro" devem ser representados por vetores próximos, enquanto "gato" e "carro" estarão mais distantes. Exemplo de embedding | Imagem: https://arize.com/blog-course/embeddings-meaning-examples-and-how-to-compute/ De que forma é calculada a semelhança entre dois vetores, comparando, por exemplo, um texto com diversos vetores do modelo treinado?Matematicamente se utiliza normalmente a técnica de similaridade por cosseno para realizar a comparação entre dois vetores A similaridade do cosseno fornece um valor no intervalo [-1,1], tendo 1 como o valor de contexto mais próximo e -1 o mais distante [1] Equação de similaridade por cosseno | Imagem: Wikipedia Dois vetores com 98% de similaridade com base no cosseno do ângulo entre os vetores | Imagem: Richmond Alake Embeddings, na prática Análise de PDF com QA (Question Answering): Embeddings são usados em sistemas de análise de documentos, como PDFs, para realizar tarefas de Pergunta e Resposta (QA). Empresas que lidam com grandes volumes de documentos, como contratos ou relatórios, podem utilizar embeddings para localizar automaticamente trechos relevantes em um texto. Por exemplo, ao analisar um contrato em PDF, os embeddings permitem mapear semanticamente o conteúdo e identificar passagens relacionadas a perguntas como "Qual é o prazo de validade deste contrato?" ou "Quais são as obrigações de pagamento do cliente?". Em seguida, um modelo de IA generativa pode utilizar esses trechos para interpretar o contexto e gerar respostas em linguagem natural com maior precisão. Recomendação de Produtos (E-commerce): Plataformas como Amazon e Netflix utilizam embeddings para recomendar produtos ou filmes baseados nas preferências e comportamentos passados dos usuários. Por exemplo, ao recomendar filmes, embeddings são usados para capturar o estilo, gênero e características dos filmes que o usuário assistiu, sugerindo novos conteúdos com base na similaridade vetorial. Análise de Sentimentos (Atendimento ao Cliente): Empresas utilizam embeddings para analisar sentimentos em feedbacks ou mensagens de clientes. Por exemplo, ao analisar um conjunto de comentários em redes sociais ou e-mails de clientes, embeddings ajudam a identificar automaticamente se o sentimento é positivo, negativo ou neutro, permitindo uma resposta rápida e apropriada. Conclusão Embeddings têm se mostrado uma ferramenta poderosa e crescente em diversas indústrias, transformando a forma como interagimos com dados não estruturados. Sua capacidade de representar informações complexas de maneira numérica tem levado a melhorias em sistemas de análise de documentos, recomendações e até no atendimento ao cliente. Sendo uma tecnologia em constante evolução, é esperado que, com o tempo, ela seja cada vez mais integrada em soluções inteligentes e escaláveis. Além disso, com a tendência de redução dos custos computacionais e o avanço das infraestruturas de processamento e armazenamento, torna-se cada vez mais viável escalar essas soluções com eficiência e baixo custo. Referências https://builtin.com/machine-learning/cosine-similarity#:~:text=Cosine%20similarity%20is%20a%20measurement,within%20an%20inner%20product%20space https://arize.com/blog-course/embeddings-meaning-examples-and-how-to-compute

Empresas enfrentam desafios diários na gestão de infraestrutura Kubernetes, especialmente para manter eficiência e reduzir custos. Aqui na Softplan, descobrimos uma solução que transforma a maneira de gerenciar nossos clusters EKS na AWS: o Karpenter. Desafios na gestão de instâncias Antes de falar de Karpenter é preciso dar alguns passos atrás e explicar um pouco do que se trata um auto escalonamento de nodes. Suponha que temos nosso cluster com algumas máquinas (instâncias) disponíveis executando nossos workloads. O que acontece se por acaso houver um pico de uso em nossas aplicações e seja necessário subir mais instâncias (réplicas) de nossos pods? Sem um autoscaling precisaríamos provisionar um node, orientá-lo a juntar-se ao nosso cluster para aí sim nossos pods estarem aptos a serem iniciados nessa nova instância. Lembrando que o provisionamento de uma instância não é instantâneo, há todo um bootstrapping da máquina, configurações de rede e muitas outras coisas antes dela ficar totalmente disponível. Certo, falamos sobre pico de usuários em nossas aplicações, mas e quando houver ociosidade? Queremos mesmo deixar esses nodes em pé com poder computacional subutilizado? Para resolver essa e outras questões, entra em cena o conceito de auto scalers. Auto Scalers As implementações de auto scalers são responsáveis basicamente pelo provisionamento e consolidação de nodes. Aqui estamos falando de escalonamento horizontal, ou seja, adicionando mais máquinas em nosso cluster. Há diversas implementações de node autoscaling, mas neste artigo o foco será na implementação da AWS e por que decidimos migrar para uma outra solução. Abaixo uma figura exemplificando o funcionamento do node autoscaling: Figura 01: autoscaling AWS - Auto Scaling Groups Ao definir um grupo de escalonamento na AWS precisamos definir diversas propriedades, como o número mínimo/máximo de instâncias de nodes permitidas para este grupo, recursos utilizados, tipo de disco, configurações de rede (subnets, etc) e muitos outros detalhes. Por exemplo, para um determinado tipo de aplicação que utilize mais CPU vamos configurar um grupo que contenha tipos de instância com mais CPU do que memória. No fim possivelmente teremos alguns grupos distintos para certos tipos de aplicações. Juntando as peças – Cluster Auto Scaler Para que meu cluster consiga “conversar” com meu cloud provider (neste exemplo AWS), precisamos de um componente chamado Cluster Auto Scaler, ou CAS.Este componente foi criado pela própria comunidade que mantém o Kubernetes, e está disponível aqui. Uma configuração padrão do CAS pode ser vista abaixo, utilizando o helm para instalação: nameOverride: cluster-autoscaler awsRegion: us-east-1 autoDiscovery: clusterName: meu-cluster image: repository: registry.k8s.io/autoscaling/cluster-autoscaler tag: v1.30.1 tolerations: - key: infra operator: Exists effect: NoSchedule nodeSelector: environment: "infra" rbac: create: true serviceAccount: name: cluster-autoscaler annotations: eks.amazonaws.com/role-arn: "role-aws" extraArgs: v: 1 stderrthreshold: info Com isso configurado e instalado e nossos autoscaling groups criados acabamos de habilitar o gerenciamento automático de nossos nodes! Por que decidimos migrar para o Karpenter Nosso caso de uso aqui na Projuris é o seguinte: temos um cluster de desenvolvimento e outro de produção. Depois da migração para o Gitlab SaaS tínhamos um desafio de como provisionar os runners para a execução de nossas pipelines. Ficou decidido que usaríamos o cluster de desenvolvimento para provisionamento desses runners. Na “primeira versão” optamos pelo cluster auto scaler por ser uma configuração mais simples e que já atendia nosso setup em produção. Mas aí começamos a enfrentar alguns problemas com esta escolha: Tempo de provisionamento: ao iniciar uma pipeline o tempo de provisionamento da máquina era um pouco lento. O grande ponto é que o cluster auto scaler paga um “pedágio” no cloud provider para provisionamento de um novo node. Dificuldade na configuração de grupos: como temos alguns “perfis” de pipeline essa gestão ficou um pouco complicada, porque para cada novo perfil um novo node group precisa ser criado. Custo: para mitigar o problema de lentidão no startup de um novo node tínhamos um perfil de máquina “online” que ficava o tempo todo de pé, mesmo sem executar nenhuma pipeline. O que é o Karpenter? É uma solução de cluster autoscaling criada pela AWS, que promete o provisionamento e consolidação de nodes sempre com o menor custo possível. Ele é inteligente o suficiente para saber que por exemplo, ao comprar uma máquina na AWS do tipo on-demand, dependendo da situação, é mais em conta do que se fosse uma máquina spot. E essa é apenas uma das características dessa ferramenta. O Karpenter também trabalha com a ideia de “grupos” de máquinas (que no mundo do Karpenter chamamos de NodePools), só que a diferença é que fazemos isso através de CRDs (custom resource definitions) do próprio Karpenter, ou seja, temos manifestos dentro de nosso cluster com todas essas configurações, eliminando a necessidade de qualquer node group criado na AWS. Exemplo de um NodePool no Karpenter: apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: karpenter-gitlab-runner-small-online spec: template: metadata: labels: workload: gitlab-runners environment: karpenter-nodes-gitlab-runner-build-small-online spec: requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot", “on-demand”] - key: "node.kubernetes.io/instance-type" operator: In values: ["m5d.large", "m5n.large", "m6id.large", "m6in.large"] nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: my-node-class taints: - key: "gitlab-runner-karpenter" value: "true" effect: NoSchedule expireAfter: Never disruption: consolidationPolicy: WhenEmpty consolidateAfter: 5m budgets: - nodes: "20%" limits: cpu: "500" memory: 500Gi Além do NodePool precisamos criar um NodeClass para definir detalhes específicos de instâncias AWS: apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: my-node-class spec: amiFamily: AL2 role: "aws-role" tags: Name: nodes-k8s-nodes-gitlab-runner-small-online subnetSelectorTerms: - tags: karpenter.sh/subnet: "my-subnet" securityGroupSelectorTerms: - id: "sg-123" - id: "sg-456" - id: "sg-789" amiSelectorTerms: - id: "imagem ami" kubelet: clusterDNS: ["111.222.333.44"] blockDeviceMappings: - deviceName: /dev/xvda ebs: volumeSize: 40Gi volumeType: gp3 encrypted: true OBS: perceba que o nome “my-node-class” precisa bater com o node class configurado no node pool. Como o Karpenter nos ajudou a superar os desafios apresentados? Tempo de provisionamento: como o Karpenter conversa diretamente com as APIs do cloud provider não é necessário pagar o pedágio do cluster auto scaler. Tínhamos muitos problemas de timeout no provisionamento de novos nodes, após a troca pelo Karpenter esse problema simplesmente desapareceu justamente porque o provisionamento é mais eficiente. Dificuldade na configuração de grupos: com a solução de NodePools e NodeClass do Karpenter essa configuração ficou trivial, e o mais importante, versionada em nosso controle de versões no Gitlab. Ou seja, precisa incluir um perfil de máquina novo no NodePool? Sem problemas, basta um commit e o Karpenter já irá considerar isso nos novos provisionamentos. Custo: Conseguimos utilizar a utilização de máquinas, pois agora runners com características semelhantes são alocados em nodes que suportem os requisitos de memória e CPU exigidos. Ou seja, estamos realmente usando todo o poder computacional que aquele node proporciona. Isso vale também para a consolidação de nodes. Com o cluster auto scaler haviam scripts complexos para fazer o drain dos nodes antes da consolidação. Com o Karpenter isso é configurado no NodePool de maneira muito simplificada. Um ótimo argumento para a gestão que justifique o investimento nesse tipo de mudança é custo. Abaixo temos um comparativo do custo utilizando o Cluster AutoScaler e o Karpenter em Janeiro/25, onde conseguimos uma economia de 16% no total: Figura 02: Período de 01/01 à 15/01 com ClusterAutoScaler Figura 03: Período de 16/01 à 31/01 com o Karpenter Considerações finais A migração para o Karpenter foi uma escolha acertada. Conseguimos simplificar a gestão de nossos nodes com diferentes perfis de forma bastante simplificada. Ainda há espaço para algumas melhorias, como por exemplo a utilização de um único NodePool para simplificar ainda mais, e deixar que os runners configurem labels específicas para o perfil de máquina que deve ser provisionado para o runner (mais em https://kubernetes.io/docs/reference/labels-annotations-taints/). Referências Karpenter (doc oficial): https://karpenter.sh/ Node Auto Scaling (doc oficial k8s): https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/

No Grupo Softplan, a evolução dos produtos é um esforço contínuo que envolve a colaboração entre times e um compromisso profundo com o cliente. Em minha função como Product Growth, troco constantemente ideias com outras equipes e recebo feedbacks valiosos dos clientes, seja pela análise de como utilizam o produto ou através de canais específicos de comunicação, como e-mail. Essas interações me proporcionam uma visão clara do impacto que a evolução contínua dos produtos tem no sucesso da empresa e no valor entregue aos clientes. Este artigo explora como a colaboração entre times e o foco no cliente impulsionam a evolução dos nossos produtos, promovendo o crescimento do Grupo Softplan e o sucesso daqueles que utilizam nossas soluções. Colaboração entre times: o motor da inovação O desenvolvimento e a melhoria de produtos no Grupo Softplan exigem uma integração contínua entre diversos times. As soluções de software precisam ser eficazes e alinhadas às demandas do mercado. Embora não faça parte diretamente da definição do roadmap, minha função permite trazer insights valiosos com base em interações com clientes e dados de performance. Isso contribui diretamente para a priorização de iniciativas de desenvolvimento. Estudos da Forbes indicam que empresas que incentivam a colaboração interna têm 4,5 vezes mais chances de reter os melhores talentos e inovar com mais eficiência (Forbes on Collaboration). No Grupo Softplan, a colaboração eficaz é um dos pilares para garantir que as necessidades dos clientes sejam atendidas com agilidade e eficiência. As áreas de produto, marketing, growth e comercial trabalham juntas continuamente, sempre buscando alinhar as iniciativas com as demandas do mercado. Esse trabalho colaborativo, aliado ao apoio da equipe de Growth na priorização das iniciativas, integra diferentes perspectivas e áreas da empresa, permitindo ajustes constantes nos produtos e impulsionando a criação de inovações a partir dessas interações entre departamentos. Cliente como protagonista: o guia das nossas decisões No Grupo Softplan, o cliente está no centro de todas as decisões, especialmente na Unidade de Indústria e Construção, onde o valor de "cliente como protagonista" orienta nossa forma de trabalho. Utilizamos canais específicos para coletar feedbacks contínuos, e esses insights moldam as iniciativas de produto. Conforme apontado pela Salesforce, 80% dos clientes consideram a experiência oferecida por uma empresa tão importante quanto seus produtos e serviços (Salesforce State of the Connected Customer). Na prática, isso significa que, ao ouvir os usuários e ajustar nossos produtos com base em suas demandas, fortalecemos o relacionamento e aumentamos a lealdade à nossa marca. Um exemplo disso foi a recente atualização de funcionalidades, baseada no feedback dos clientes, que trouxe comunicações mais diversificadas em módulos do produto, alinhando-se às necessidades identificadas. Essa abordagem orientada pelo cliente não apenas atende às necessidades atuais, mas também nos permite antecipar demandas futuras. Esse processo contínuo solidifica nosso papel como parceiro estratégico para os clientes. Impacto no mercado: inovação e crescimento O Grupo Softplan se destaca no mercado por seu compromisso com a inovação e foco em resultados concretos. Ajustar nossos produtos com base no feedback direto dos clientes tem um impacto direto no crescimento da empresa e na satisfação dos usuários. Como mencionado, a atualização das comunicações mais diversificadas em módulos do produto foi uma resposta direta a esses feedbacks, destacando como a comunicação contínua com o cliente guia a evolução das nossas soluções. De acordo com a PwC, empresas que priorizam a experiência do cliente podem ver um aumento de 16% na receita e uma maior retenção de clientes (PwC Future of Customer Experience Survey). Essa realidade também se aplica ao Grupo Softplan, onde o ajuste contínuo e o foco nas necessidades dos clientes nos ajudam a entregar soluções relevantes que se destacam no mercado. O uso estratégico do feedback do cliente não só melhora a experiência do usuário, como também garante que estamos sempre um passo à frente em termos de inovação e competitividade. Venha crescer com a gente O Grupo Softplan se destaca por escutar seus clientes e unir seus times para criar soluções que impulsionam os negócios. O valor de "cliente como protagonista" é um guia prático e presente em nossa jornada de evolução de produtos. Colaboramos, inovamos e nos adaptamos, sempre garantindo que as necessidades dos clientes estejam no centro das nossas decisões. Se você valoriza um ambiente que fomenta colaboração e inovação, com oportunidades de aprendizado contínuo e crescimento, o Grupo Softplan é o lugar certo para você. Aqui, nossos valores e objetivos estratégicos são reforçados por treinamentos e pela oportunidade de trabalhar em projetos desafiadores que transformam o mercado de software. Junte-se a nós e faça parte de uma equipe que transforma a vida dos clientes e inova o mercado. Acesse nossa página de carreira.