Construindo uma plataforma de Cloud Development Environment: Visão, Decisões e Lições Aprendidas

Fomos destaque no episódio #476 de um dos podcasts de tecnologia mais renomados do Brasil, o Hipsters.tech.

Os cofundadores do CPS1, Miguel Di Ciurcio Filho e Oscar Esgalha, participaram de uma conversa aprofundada sobre Cloud Development Environments, Developer Experience, Platform Engineering e práticas DevOps. Eles compartilharam histórias e aprendizados de suas experiências anteriores, revelando como nasceu o CPS1 e as principais decisões de arquitetura que moldaram a plataforma.

Aqui está a conversa em texto para quem prefere ler e o episódio também está disponível no Spotify.

Como vocês resumiriam de forma clara o que o CPS1 oferece aos desenvolvedores?

Miguel: A CPS1 é uma plataforma que você instala diretamente na sua própria infraestrutura, seja em nuvem pública ou privada, e que oferece, de maneira simples e rápida, a capacidade de criar ambientes de desenvolvimento sob demanda, seguindo os padrões do seu time.

No modelo tradicional, quando um desenvolvedor entra em uma nova empresa ou projeto, ele recebe um notebook e pode gastar dias ou até semanas instalando ferramentas, configurando o ambiente e aguardando aprovações de acesso. Já vi casos em que o onboarding levou mais de 30 dias antes da primeira contribuição de código.

Com o CPS1, a experiência é completamente diferente: o desenvolvedor acessa um portal pelo navegador, cria um workspace pré-configurado com todas as ferramentas definidas pelo time de desenvolvimento ou de plataforma e, em poucos minutos, já está pronto para trabalhar.

Quando desenhamos essa solução, pensamos também em diferentes cenários: tanto empresas com ciclos de DevOps maduros e bem estruturados, quanto aquelas ainda em estágios iniciais, com processos mais antigos. Queríamos algo que se integrasse a estruturas já estabelecidas, mas que também fosse um ponto de partida eficiente para quem ainda está construindo seu fluxo de desenvolvimento.

Oscar: Complementando o que o Miguel disse, desde o início concebemos o CPS1 como um componente que se encaixa facilmente na estratégia de Platform Engineering ou DevOps de uma empresa. Uma vez instalada na sua própria infraestrutura, seja pública ou privada, ela pode ser estendida e customizada para seguir os padrões e práticas já existentes.

Para empresas que estão começando ou que não contam com um time dedicado de DevOps, criamos o pacote comunitário chamado Contrib, que já vem com configurações prontas para linguagens populares como Python, JavaScript e Go. Isso permite que os times comecem a usar imediatamente.

Já para empresas com necessidades mais específicas, como um runtime de Java customizado ou um conjunto próprio de bibliotecas, o CPS1 permite adaptar o ambiente de forma simples e com o mínimo de esforço, alinhando tudo ao padrão da organização.

Esse foi um ponto-chave no design do produto: tornar a customização fácil e acessível, algo que não encontramos nas alternativas existentes no mercado quando começamos a desenvolver a plataforma.

Se você encontrar um CTO tradicional que prefere desenvolvimento local, como o convenceria a migrar para um ambiente de desenvolvimento em nuvem?

Miguel: Antes de responder diretamente, quero esclarecer uma coisa: no passado, ter um CDE (Cloud Development Environment) era quase sinônimo de programar direto no navegador. Hoje isso já não é mais uma obrigação embora ainda seja uma opção.

No nosso produto, por exemplo, a configuração padrão inclui uma IDE no navegador, mas também suportamos o uso da sua IDE local, como o VS Code, conectada ao workspace via SSH. Isso preserva a experiência de desenvolvimento que o profissional já está acostumado: atalhos, extensões, layout e fluxo de trabalho continuam exatamente os mesmos. Sabemos que os desenvolvedores valorizam esses detalhes, e o produto foi desenhado para respeitar isso.

Agora, quando se trata de apresentar a ideia a um CTO mais tradicional, eu destacaria alguns pontos importantes:

1. Flexibilidade e mais recursos: Os sistemas atuais são cada vez maiores e mais complexos, muitas vezes compostos por vários microsserviços. Num setup local, o desenvolvedor só consegue testar parte da aplicação, pois não tem acesso a todos os recursos e integrações necessários. Com o CPS1, esses serviços podem estar disponíveis dentro do workspace, permitindo testes de ponta a ponta, algo inviável até mesmo em um notebook potente.
2. Onboarding muito mais rápido: Num ambiente local, configurar tudo pode levar de 15 dias a um mês, seja para uma nova contratação ou para alguém que está apenas mudando de time. Com o CPS1, a pessoa começa a trabalhar em poucos minutos, eliminando semanas de espera.
3. Melhor coordenação de time: No modelo tradicional, back-end e front-end geralmente trabalham em paralelo e só integram no final, o que gera retrabalho. Com o CPS1, um desenvolvedor pode compartilhar seu workspace em execução com outro colega, permitindo feedback imediato e integração contínua, sem depender de deploys intermediários.

Esses são apenas alguns exemplos. Existem outros benefícios, como melhorias no processo de revisão de código, redução de gargalos e aceleração do ritmo de entrega. Não se trata apenas de mudar o ambiente, mas de elevar todo o processo de desenvolvimento para um nível mais eficiente e colaborativo.

Como podemos incentivar iniciantes a praticar em um ambiente em nuvem para que já cheguem ao mercado de trabalho familiarizados com esse modelo?

Miguel: Do ponto de vista de quem está começando, a experiência muda muito pouco. Como mencionei antes, é possível acessar o workspace remotamente, até mesmo via SSH,e ter um shell disponível para fazer o que for necessário.

Hoje, muitas IDEs, como o VS Code, já oferecem suporte a desenvolvimento remoto, permitindo que você aponte a IDE para um servidor remoto e mantenha praticamente a mesma experiência local, só que rodando na nuvem. Para quem está aprendendo, o processo de instalar, configurar e resolver problemas continua fazendo parte da jornada.

A diferença fica mais clara em ambientes corporativos, principalmente no controle de acesso ao código-fonte. Em muitas empresas, especialmente quando trabalham com prestadores de serviço, o código acaba ficando na máquina do desenvolvedor — o que é um grande problema em setores regulados, como o financeiro. Com o CPS1, o código permanece na infraestrutura da empresa, e o acesso é feito de forma remota. Isso garante muito mais controle e segurança, sem prejudicar a experiência de desenvolvimento.

Normalmente, as empresas tentam resolver isso com VDI (Virtual Desktop Infrastructure), criando desktops virtuais para os desenvolvedores trabalharem remotamente. Mas quem já usou sabe: é lento, pouco prático e frustrante. Com um CDE como o CPS1, projetado para desenvolvimento, os workspaces são muito mais eficientes, eliminam esse gargalo e oferecem uma experiência fluida e agradável.

Oscar: Só para complementar: quando tínhamos nossa fábrica de software, organizamos alguns programas de contratação de desenvolvedores iniciantes. Em uma das edições, decidimos incluir o uso de um CDE no teste técnico, para que os candidatos passassem menos tempo configurando o ambiente e mais tempo escrevendo código.

Os resultados foram ótimos: recebemos mais candidaturas, mais código para revisar e conseguimos atrair mais talentos, sem aumentar significativamente a carga de trabalho. Então, para iniciantes, montar um CDE pode não ser a parte mais empolgante, mas receber um ambiente pronto para usar ajuda a focar no aprendizado de programação em vez de perder tempo com configuração.

Vocês têm uma estimativa dos recursos de máquina necessários para rodar o CPS1?

Miguel: Os recursos necessários dependem basicamente do número de pessoas usando ao mesmo tempo e do tamanho das aplicações em execução.

É preciso considerar também um pequeno overhead para suportar a IDE remota, que estimamos em cerca de 1 GB de memória e 1 vCPU por workspace.

Em termos de capacidade, é aquela resposta clássica: depende. Se suas aplicações exigem mais memória, você vai precisar de mais memória. O cálculo é simples: por exemplo, se você tem 20 desenvolvedores trabalhando simultaneamente em um certo tipo de projeto, basta multiplicar pelo consumo médio de cada um para estimar a necessidade.

Quanto ao próprio consumo do CPS1, ele roda como um operador no Kubernetes — algo totalmente transparente para o usuário. Se eu não contasse, você provavelmente nem perceberia. É extremamente eficiente, e o Oscar pode explicar melhor como conseguimos rodar com tão pouca memória.

Oscar: Esse foi justamente um dos principais motivos pelos quais decidimos construir nosso próprio produto do zero. Quando começamos a empresa, nossa ideia inicial era usar uma solução existente e oferecê-la como serviço.

O problema é que as opções disponíveis eram muito difíceis de instalar, consumiam uma quantidade absurda de recursos ou as duas coisas ao mesmo tempo. Para rodar praticamente nada, algumas soluções exigiam pelo menos duas ou três máquinas em um cluster Kubernetes, cada uma com 16 GB de RAM e mais de 8 vCPUs.

O nosso operador, desenvolvido em Rust, que já apresentamos em eventos como o Kubernetes Community Day Brazil e conferências de Rust, usa apenas alguns megabytes de memória e consegue atender a um grande número de usuários.

Nos testes que fizemos, o fator limitante foi a própria API do Kubernetes, não a nossa plataforma. Para começar, você só precisa ter um cluster Kubernetes configurado e recursos nos nós para rodar os ambientes de desenvolvimento — no mínimo 1 GB de RAM e 1 vCPU para a IDE, além do que sua aplicação demandar.

Nós mesmos usamos o CPS1 para desenvolver o CPS1 no dia a dia, e nossa conta de nuvem continua bem baixa.

A segurança do CPS1 depende de camadas próprias ou inteiramente do provedor de nuvem escolhido para hospedagem? Como essa responsabilidade é dividida?

Miguel: Quando desenhamos o produto, optamos por um modelo self-hosted, ou seja, ele roda 100% dentro da sua infraestrutura. Não somos um SaaS, e o CPS1 pode inclusive operar em ambientes air-gapped (totalmente isolados da internet), justamente para aproveitar e estar em conformidade com as políticas de segurança já existentes na sua organização.

Se a sua empresa exige governança rígida, auditoria ou regras de retenção de logs, o CPS1 segue esses padrões de forma transparente, pois funciona dentro da sua própria rede e sob seu controle operacional.

Além disso, o CPS1 possui controles internos: por exemplo, para acessar o workspace compartilhado de um colega é necessário autenticar, e todas as conexões usam TLS por padrão.

Tudo foi implementado seguindo práticas de segurança de ponta, combinando a proteção da sua infraestrutura com os mecanismos nativos da plataforma.

Como vocês planejam fomentar a comunidade do CPS1, engajando usuários atuais e incentivando novas contribuições?

Miguel: Quando definimos a separação entre as edições Community e Enterprise, estabelecemos como princípio que a versão Community não teria limitações de funcionalidades — ao contrário do que muitas empresas fazem.

Ela oferece todos os recursos do CPS1, com a única restrição no número de usuários simultâneos, atualmente limitado a cinco desenvolvedores. Escolhemos esse número porque já atende bem a equipes pequenas, enquanto times maiores normalmente têm necessidades mais complexas.

Outro ponto é que não exigimos licença de teste, cadastro ou qualquer barreira de entrada: basta acessar a documentação, rodar um único comando no terminal e o CPS1 estará funcionando localmente para avaliação.

Também temos o repositório Contrib, onde é possível adicionar linguagens, ferramentas e integrações, ampliando as capacidades da .

Oscar: O CPS1 é instalado via um Helm Chart público, disponível para qualquer pessoa consultar e entender sua configuração — incluindo CRDs, pacotes e recursos.

• Pacotes são componentes instalados no workspace, como compiladores, interpretadores ou ferramentas de desenvolvimento.
• Recursos são serviços gerenciados, como bancos de dados ou filas de mensagens.

Dentro do Helm Chart, mantemos um pacote chamado Contrib com exemplos padrão. A ideia é estimular que mais pessoas proponham novos pacotes para dar suporte a outras linguagens e serviços, construindo um ecossistema colaborativo.

Também criamos um servidor no Discord e usamos o GitHubcom issues e discussões para reunir sugestões de novas funcionalidades, reportar bugs e trocar ideias.

Além disso, participamos ativamente de eventos da comunidade DevOps — já estivemos em edições do DevOpsDays e temos presença confirmada em várias outras neste ano, incluindo Rio de Janeiro e Brasília.

Qual foi o maior desafio técnico que vocês enfrentaram no desenvolvimento do CPS1 e como o superaram?

Oscar: Lançamos a primeira versão pública do CPS1 em julho, mas internamente esta já é a quarta ou quinta reescrita completa do projeto. Muitas vezes testamos hipóteses de implementação, validamos com um pequeno grupo de usuários e percebemos que não funcionavam como esperado — então voltávamos à prancheta e começávamos de novo.

Um dos principais obstáculos foi tentar adotar o Devfile, um padrão da CNCF para definição de ambientes de desenvolvimento. No início acreditávamos que seria uma boa base para a plataforma. Porém, ao analisar como outras empresas e projetos usavam o padrão, percebemos que a maioria ignorava grande parte das especificações e colocava tudo em campos customizados para suas próprias implementações. Ao tentar seguir o padrão à risca, nosso produto ficou mais limitado e confuso. Decidimos abandoná-lo, o que simplificou bastante o desenvolvimento e acelerou o progresso.

Outro desafio foi experimentar o uso do Nix/Nix Packages para gerenciamento de ambientes. Apesar de tecnicamente interessante e cada vez mais popular, enfrentamos problemas práticos — especialmente em ambientes de nuvem, onde o sistema de volumes sofria com a enorme quantidade de arquivos gerados pelo Nix. Além disso, para os desenvolvedores que testaram, a curva de aprendizado inicial era muito íngreme, o que prejudicava a adoção.

Essas experiências nos ensinaram a importância de manter o produto fácil de instalar, simples de usar e compatível com qualquer nuvem. Chegar a esse ponto exigiu múltiplas iterações, ajustes e simplificações.

Encerrando

Foi um prazer compartilhar nossa jornada no Hipsters.tech — desde as primeiras ideias até as lições aprendidas e as decisões técnicas que moldaram o CPS1.

Mas essa história só avança de verdade quando mais pessoas se juntam a nós.

Se quiser ver o que o CPS1 pode fazer, não espere:

• Coloque para rodar agora → Guia de Início Rápido — um comando, sem cadastro, sem chave de teste.
• Explore os detalhes → Documentação Completa — tudo, da arquitetura à customização.
• Dê sua opinião → Participe no GitHub — ideias, dúvidas, pedidos de funcionalidades ou até críticas do tipo “isso podia ser melhor” são todas bem-vindas.

Criamos o CPS1 para facilitar a vida dos desenvolvedores, e o seu feedback é a maneira mais rápida de nos ajudar a deixá-lo ainda melhor.