Floci: o emulador local da AWS que nos vai poupar uma fortuna em subscrições de desenvolvimento (e ainda nos prepara para sair da cloud quando quiserem)

Higgs

Olá a todos!

Nota do autor antes de começar: este post foi escrito para incomodar quem ainda acha que “developer environment” é sinónimo de “conta AWS com cartão de crédito da empresa associado”. Vai incomodar as equipas de DevOps que normalizaram pagar €2.000 por mês em ambientes de desenvolvimento que ninguém usa ao fim de semana. Vai incomodar os CFOs que olham para a factura da AWS e assumem que “é o normal”. E vai incomodar quem investiu emocionalmente no LocalStack durante anos e ainda não percebeu que o cobertor foi puxado em Março deste ano. Se cabes nalguma destas categorias, respira fundo. Posso estar a falar contigo.

Disclaimer habitual: uso a AWS. Tenho clientes em AWS. Não estou aqui a dizer para abandonarem a AWS amanhã :smirk:. Estou a dizer que a maneira como a maioria das equipas de desenvolvimento usa a AWS hoje é, do ponto de vista financeiro e operacional, uma escolha questionável. E hoje quero apresentar-vos uma ferramenta que continua a mudar a forma como olho para isto: o Floci.

O cenário que toda a gente conhece.

Vamos ao que interessa. Imaginem uma equipa de desenvolvimento com dez engenheiros a trabalhar num produto SaaS construído em cima da AWS. S3 para storage, DynamoDB para a base de dados principal, Lambda para a lógica serverless, SQS para filas de mensagens, SNS para notificações, Cognito para autenticação, API Gateway à frente, EventBridge a orquestrar eventos. O típico stack moderno da cloud.

Cada engenheiro precisa do seu próprio ambiente para testar. Não dá para partilhar uma única conta de development porque os testes destroem-se uns aos outros. Não dá para usar a conta de staging porque isso polui dados de QA. Então o que se faz? Cria-se uma conta AWS por developer, ou um sub-account isolado, ou um set de recursos com prefixos por developer. E paga-se.

E paga-se mesmo quando ninguém está a trabalhar. Paga-se ao fim de semana. Paga-se ao Natal. Paga-se em Agosto quando metade da equipa está de férias. Paga-se quando o developer está num call de quatro horas e não tocou no ambiente uma única vez nesse dia. Paga-se sempre, todos os dias, todas as horas, porque a AWS não cobra pelo uso real, cobra pela existência do recurso.

Já vi facturas de €3.000 a €5.000 mensais só em ambientes de desenvolvimento numa startup de quinze pessoas. Já vi empresas a gastar €30.000 por ano em DynamoDB que servia exclusivamente para testes locais de developers. Já vi auditorias internas em que ninguém da equipa conseguia explicar para que servia metade dos recursos que estavam a ser facturados.

E aqui está o detalhe que me deixa o cabelo em pé: a maioria deste dinheiro é completamente desnecessário. Estamos a pagar à AWS para nos fornecer S3 quando o que realmente precisamos é de um endpoint que aceite chamadas S3 e devolva respostas válidas. Estamos a pagar pelo Cognito de produção quando precisamos apenas de um JWT válido com claims previsíveis. Estamos a pagar pelo SQS quando o que queremos testar é a lógica do nosso consumer, não a fiabilidade do broker da Amazon.

LocalStack já não é resposta (e foi por uma boa razão)

Aqui é onde muitos vão dizer “mas Nuno, isto resolve-se com o LocalStack, toda a gente sabe disso”. E têm razão. Durante anos, o LocalStack foi a resposta de facto para emular AWS localmente. Tinha edição comunitária gratuita, suportava os serviços principais, integrava bem com testcontainers, e estava na maioria das pipelines de CI/CD do mundo Java e Python.

Tinha. Passado. Em Março de 2026 a LocalStack anunciou oficialmente o sunset da edição comunitária. A community edition deixou de receber updates de segurança, passou a exigir auth tokens para funcionar a partir de uma certa altura, e o ecossistema viu-se forçado a olhar para alternativas ou pagar pela versão enterprise. E a versão enterprise não é barata. Para uma equipa média, a factura mensal facilmente ultrapassa o que vocês estavam a poupar em AWS quando começaram a usar a ferramenta. É o clássico bait and switch: dão a versão grátis durante anos até toda a gente estar dependente, depois fecham a torneira.

Não estou aqui a julgar a LocalStack pela decisão. É uma empresa, tem direito a fazer dinheiro com o produto. Estou a dizer que esta jogada é exactamente a razão pela qual nunca devemos basear infraestrutura crítica em produtos comerciais com edição community que pode desaparecer a qualquer momento. Já escrevi aqui sobre isto noutros contextos: o postmortem da Anthropic, a Element.io, o problema do token subsidiado. O padrão repete-se sempre. Hoje é grátis, amanhã é caro, depois de amanhã está extinto.

A boa notícia é que do vazio deixado pela LocalStack nasceu uma alternativa séria, completamente open source, sob licença MIT, sem auth tokens, sem feature gates, sem rate limits artificiais. Chama-se Floci.

O que é o Floci

O Floci é um emulador local da AWS escrito em Java sobre o framework Quarkus, com imagem nativa via GraalVM. O nome vem de “floccus”, uma formação de nuvens que se parece com pipocas. O slogan oficial é “light, fluffy, and always free”. E o “always free” não é marketing, está garantido pela licença MIT no repositório.

Os números técnicos são genuinamente impressionantes. A imagem Docker tem cerca de 90 MB contra os 1.0 GB do LocalStack. O startup time é de aproximadamente 24 milissegundos contra os 3.3 segundos do LocalStack. A memória idle anda nos 13 MiB contra os 143 MiB da alternativa. Isto não é optimização cosmética, é uma diferença qualitativa que muda o que se pode fazer com a ferramenta. Com 24 ms de startup, podem estar a subir um Floci limpo em cada teste unitário sem perceberem o impacto na duração da suite. Tentem fazer isto com o LocalStack e a vossa pipeline de CI passa de cinco minutos para quarenta.

O Floci hoje suporta 26 serviços da AWS, com mais de 1.873 testes automatizados de compatibilidade. A lista inclui o essencial e mais um pouco: S3 com versionamento, multipart upload, pre-signed URLs, Object Lock nas modalidades COMPLIANCE e GOVERNANCE, notificações de eventos. DynamoDB com GSI, LSI, Query, Scan, TTL, transactions, batch operations. Lambda em containers Docker reais, com warm pool, aliases, Function URLs, e Event Source Mappings para SQS, Kinesis e DynamoDB Streams. IAM com mais de 65 operações suportadas. STS com as 7 operações principais. KMS com encrypt, decrypt, sign, verify, data keys, aliases. SQS standard e FIFO com DLQ, visibility timeout, batch operations. Cognito com user pools, app clients, auth flows, endpoints JWKS e OpenID well-known. ElastiCache real com Redis e Valkey, RDS real com PostgreSQL e MySQL, ECS real com clusters, services, tasks. SES, EventBridge, Step Functions, CloudFormation, CloudWatch Logs e Metrics, API Gateway REST e HTTP, OpenSearch.

E o detalhe que faz a diferença: os serviços que precisam de ser “reais” para serem úteis (Lambda, ElastiCache, RDS, ECS) correm em containers Docker reais com SigV4 e autenticação IAM válida. Não é simulação superficial. É o mesmo fluxo de autenticação que se usa em produção. Se a vossa aplicação assina pedidos correctamente para a AWS de produção, vai assinar correctamente para o Floci. Se não assina, o Floci diz-vos isso antes de chegarem a produção. Que é o ponto.

A matemática que ninguém faz na vossa empresa

Vamos a números concretos, porque é isso que convence quem tem o cordão à bolsa. Imaginem uma equipa de dez developers. Cada um tem o seu ambiente AWS de desenvolvimento isolado. Olhando para facturas reais de clientes meus, um ambiente de desenvolvimento sério (com DynamoDB com algumas tabelas, S3 com alguns buckets, Lambda com algumas funções, SQS com filas, Cognito, API Gateway, EventBridge, CloudWatch Logs com retenção razoável) anda entre €80 e €250 por developer por mês, dependendo do volume de testes que correm.

Vamos ser conservadores e dizer €150 por developer por mês. Para dez developers, isto são €1.500 mensais, €18.000 anuais. Acrescentem-se ambientes de CI/CD que sobem e descem recursos AWS para correr testes de integração, e facilmente se chega a €25.000 a €30.000 por ano só em desenvolvimento. Isto sem tocar nos custos de produção, que são outra conversa.

Agora façamos a conta com Floci. Cada developer corre uma instância de Floci na sua máquina local, gratuita. Os pipelines de CI/CD correm Floci em containers Docker, gratuito. O custo de infraestrutura passa a ser zero. Os €25.000 a €30.000 anuais ficam disponíveis para outras coisas. Tipo, sei lá, salários. Ou hardware. Ou um servidor dedicado a sério para hospedar serviços críticos que não querem na cloud (já lá vamos a isto).

E aqui é onde alguém vai levantar a mão e dizer: “mas Nuno, há diferenças entre o Floci e a AWS real, vamos ter bugs em produção que não víamos em desenvolvimento”. E a resposta é: claro que sim. Mas estes bugs existem hoje exactamente da mesma maneira, porque o vosso ambiente de desenvolvimento na AWS já não é igual à produção. Tem versões diferentes, configurações diferentes, dados diferentes, escalas diferentes. A noção de que “se passa em dev, passa em prod” é uma ilusão confortável que custa muito dinheiro manter.

O que o Floci vos dá é uma camada de validação muito barata e muito rápida onde se podem apanhar 80% dos problemas antes de eles chegarem à AWS real. Os outros 20% apanham-se em ambientes de staging partilhados que existem na AWS verdadeira, mas que servem dez developers em vez de um. A poupança real está em reconhecer que a maioria do trabalho de desenvolvimento não precisa da AWS verdadeira, apenas precisa de algo que se comporte como ela.

Como o Floci muda o vosso workflow

Setup é trivial. Um docker compose up com uma imagem de 90 MB. Os serviços ficam disponíveis em http://localhost:4566, e qualquer SDK da AWS aponta para esse endpoint com credenciais arbitrárias. Funciona em Java, Python, Node.js, Go, Rust, AWS CLI, Terraform, OpenTofu, AWS CDK. Todos suportados, todos testados.

Onde isto ganha verdadeiramente é em integração com testes. Cada teste unitário sobe um Floci limpo em milissegundos, faz as suas assertions, deita fora. Não há contaminação entre testes, não há limpeza manual de buckets ou tabelas, não há flakiness por timeouts da rede. Testes de integração reais que antes demoravam meia hora a correr porque dependiam de latências de rede para us-east-1 passam a correr em segundos contra a instância local.

Em CI/CD a história é ainda melhor. Em vez de ter pipelines que provisionam recursos AWS reais (com tudo o que isso implica em termos de credenciais, IAM, networking, e custos), as pipelines correm tudo localmente dentro dos runners. Mais rápido, mais barato, sem dependências externas. Se o GitHub Actions falhar a meio do build, não ficam com 17 instâncias EC2 esquecidas a sangrar dinheiro durante o fim de semana.

E há um benefício que demora algum tempo a apreciar: o desenvolvimento offline. Posso programar para a AWS num avião, num comboio, num café com WiFi miserável, ou na casa de família onde a Internet é fibra mas só funciona quando lhe apetece. Para quem como eu vive a meio caminho entre clientes, isto é literalmente uma melhoria de qualidade de vida. O ambiente de desenvolvimento deixa de estar refém da ligação à Internet.

The long game: preparar a saída da cloud

E agora chegamos ao ponto que é, para mim, o mais importante de todos, e que justifica o título deste post. Quem lê este blog há tempo já me ouviu falar várias vezes sobre soberania, sobre controlo, sobre o risco existencial de termos infraestruturas críticas em mãos de terceiros. A AWS, a Azure, e a Google Cloud são extraordinárias do ponto de vista técnico, mas são pontos únicos de falha geopolítica, regulatória, e financeira para qualquer empresa europeia que dependa delas.

A discussão sobre migração off the cloud (ou multi cloud, ou hybrid cloud, ou seja qual for o nome que queiram dar) tende a esbarrar sempre no mesmo argumento: “estamos demasiado dependentes da AWS para mudar agora”. E é verdade. Mas a dependência cresce todos os dias que passa sem fazermos nada. Cada novo serviço que se constrói usando APIs proprietárias da AWS aumenta o custo de saída.

O Floci muda este cálculo de uma forma subtil mas importante. Quando a vossa equipa desenvolve contra Floci em vez de contra AWS directa, está implicitamente a construir software que assume um endpoint compatível com a AWS. Não está acoplado à infraestrutura da Amazon, está acoplado à interface AWS. Isto é uma distinção crucial.

Porque o Floci, na essência, prova que a interface AWS é replicável. E se é replicável num emulador local de 90 MB que cabe num portátil, é também replicável numa infraestrutura on premise séria, com hardware vosso, em datacenter vosso, com SLAs vossos. O Floci não foi desenhado para isto (oficialmente é uma ferramenta de desenvolvimento), mas a lógica é a mesma. Se conseguem correr o vosso software contra Floci e ele funciona, a porta para o correrem contra alternativas como MinIO para S3, Postgres puro para DynamoDB equivalentes, NATS para SQS, e assim sucessivamente, fica muito mais perto.

A migração off the cloud, na prática, faz se em três fases. Primeira fase: desacoplar o vosso código da AWS específica usando emuladores e testes contra esses emuladores. O Floci serve esta fase. Segunda fase: implementar uma camada de abstracção fina sobre as chamadas AWS, de forma a poder trocar implementações. Terceira fase: começar a substituir serviços AWS por equivalentes self hosted, um de cada vez, começando pelos mais caros ou mais críticos.

A maioria das empresas hoje nem sequer começou a fase um. Estão a usar AWS em desenvolvimento da mesma forma que usam em produção, e isto torna cada migração futura em projecto de seis meses com risco enorme. Adoptar o Floci é uma forma quase indolor de começar a fase um sem precisarem de declarar publicamente que estão a sair da AWS. Não estão. Estão só a tornar o vosso desenvolvimento mais rápido e mais barato. O facto de isto também vos preparar para uma eventual saída é um bónus que nenhum decisor financeiro vai recusar.

Os trade offs honestos

Não quero pintar isto como uma solução perfeita. Há limitações reais.

O Floci é jovem. A versão actual é a 1.2.0, o projecto tem cerca de um ano de existência pública. Há serviços que não suporta, há comportamentos da AWS que ainda não emula com perfeição, e há casos de uso muito específicos onde a única solução é testar contra a AWS real. Para serviços como Athena, Glue, ou os mais exóticos do catálogo da Amazon, o Floci não vos vai ajudar hoje.

A comunidade está a crescer, mas ainda não tem a massa crítica do LocalStack na sua era de ouro. Issues podem demorar mais a ser respondidas, features novas podem demorar mais a chegar. Por outro lado, é open source MIT, o que significa que podem contribuir directamente para resolver os vossos casos de uso. Ou podem forkar e adaptar. Nenhuma destas opções existe com a LocalStack enterprise.

E há sempre a possibilidade de o Floci, no futuro, decidir comercializar também. É um risco real com qualquer projecto open source. A diferença é que a licença MIT garante que o que existe hoje continuará a existir gratuitamente para sempre. Se daqui a três anos a equipa do Floci decidir lançar uma versão comercial, a versão actual continua disponível, forkável, modificável. Ao contrário da LocalStack, onde a community edition foi efectivamente abandonada e congelada.

O que devem fazer esta semana

Vou ser prático:

Façam o download da imagem do Floci. docker pull hectorvent/floci:latest. São 90 MB, não vos vai estragar o disco. Subam uma instância e configurem o AWS CLI para apontar para http://localhost:4566. Criem um bucket, ponham um objecto, listem o bucket. Vejam que funciona.

Identifiquem na vossa equipa um pequeno projecto ou módulo que use a AWS de forma intensiva em desenvolvimento. Não precisa de ser o vosso sistema core. Pode ser uma ferramenta interna, um proof of concept, ou um módulo isolado. Configurem esse projecto para correr contra Floci em vez de AWS de desenvolvimento durante uma semana e meçam o impacto na produtividade.

Calculem honestamente quanto a vossa empresa gasta hoje em AWS exclusivamente para desenvolvimento e CI/CD. Vão ficar surpreendidos com o número. Apresentem este número à liderança junto com uma estimativa de quanto poderia ser eliminado adoptando Floci em pelo menos parte dos workflows. Mesmo que cortem só metade, é dinheiro real que pode ser realocado.

Comecem a pensar no vosso código como tendo um contrato com a interface AWS, não com a infraestrutura da Amazon. Esta mudança mental é mais importante do que a ferramenta em si. É o que vos permite, no futuro, ter opcionalidade real sobre onde a vossa infraestrutura vive.

Nota final

A dependência da cloud não é, em si, um problema. O problema é a dependência sem alternativa, sem plano B, sem caminho de saída. Quando a única forma da vossa equipa testar código é pagando à Amazon, vocês não têm leverage nenhum nas vossas próprias decisões técnicas. Cada subida de preços, cada mudança de política, cada nova restrição, é algo que sofrem sem terem nada a dizer.

Ferramentas como o Floci devolvem leverage. Não porque vos forçam a sair da AWS, mas porque tornam a saída tecnicamente possível se um dia precisarem dela. E ter essa possibilidade muda completamente a conversa com a Amazon, com a vossa direcção financeira, e com a vossa própria postura estratégica.

Hoje o Floci é uma ferramenta de desenvolvimento que vos poupa dinheiro. Amanhã pode ser o primeiro passo concreto de uma estratégia de soberania tecnológica séria. Em qualquer dos cenários, vale a pena ter na caixa de ferramentas.

E o melhor de tudo: é grátis, é MIT, está num container Docker que cabe numa mensagem de email. Não há desculpa para não experimentar esta semana.

Mantende-se vigilantes com os vossos custos operacionais.

Um abraço,
Nuno Higgs

Fontes:

 

Related Posts