Cameleering

New Headroom: what is left when servers drop out, on the Microsoft 365 outage of 12–13 November

Cameleering · make software need less, then prove it against the original

Shrink what your software needs, not just the instances.

Cameleering is a practice, not a product: make software carry the same load on less memory, CPU and start-up time, then prove each gain against the original on the same machines. The results below come from two open-source projects built this way, Cameleer and simoom. Further down are the steps to get the same on your own software.

Looking for a project? Cameleer, the integration engine · simoom, the HTTP engine · the steps

Results from projects built with the practice · each number names its project and its baseline

450xfaster start-up1,106 ms to 2.45 ms for a started context (451x, shown rounded down; Apache Camel 4.23 on Java 21; on Quarkus native, 30 ms).Cameleer vs Apache Camel 23xsmaller Lambda compute bill$0.06 instead of $1.50 for a month of 10 million requests: execution time 3 ms instead of 7 ms, memory 128 MB instead of 512 MB, and cold starts that cost 300 times less.Cameleer vs Apache Camel · arithmetic on measured time and memory 51xmore integrations per node20 to 1,024 per 8 GiB on a direct route; 24 to 122 for HTTP into Kafka.Cameleer · arithmetic on measured peak memory 54xless memory, at bestPeak 214–440 MB to 7–67 MB: 4.8 to 54 times less across 11 scenarios.Cameleer vs Apache Camel 8.7xthe throughput, at best1.7 to 8.7 times Apache Camel’s messages per second, in all 11 scenarios, on the same machines.Cameleer vs Apache Camel 43%less CPU per requestAbout 23 µs to 13 µs, with 1.7–1.8x the requests per second.simoom vs the server it replaced
Run it on your softwareSee every result in the ledger

It works on software people run every day

Two projects have run every step in public.

Cameleer Cameleered 2026-11-06

An integration engine in the style of Apache Camel, and the first Cameleering project.

  • Baseline: Apache Camel 4.23.0 on Java 21 and 4.22.1 on Quarkus native, on identical DigitalOcean c-4 machines.
  • Cut: one std-only binary that keeps Camel’s routes, YAML and endpoint URIs, with component families as build options.
  • Proved: start-up 450x faster (10x against Quarkus native), 4.8–54x less memory, 1.7–8.7x the throughput.

Full comparison · every scenario and the raw data

simoom Cameleered 2026-11-12

An HTTP engine in std-only Rust, built to replace Cameleer’s original server.

  • Against the server it replaced: 1.7–1.8x the throughput, 43% less CPU per request, 65% less memory with 1,000 idle connections.
  • Against 20 other servers on the same droplets: first of 21 on start-up (0.94 ms) and first of 19 on CPU per request.

simoom benchmarks · all projects, including the ones not yet measured

What less machine buys you

Software decides how much memory and CPU every instance needs. Flexera’s 2026 survey puts cloud waste at 29% of infrastructure spend.

A smaller bill

Lambda bills execution time times memory, and since August 2025 the cold start too. Each request runs 3 ms in 128 MB instead of 7 ms in 512 MB, about 9 times less per request, and a million cold starts cost $0.03 instead of $9.17. For a month of 10 million requests the compute bill is $0.06 against $1.50.

Arithmetic on measured numbers and AWS list prices. The arithmetic, with its limits

Less waiting

A started context in 3 ms instead of 1.1 s. A REST API with JSON has a p99 of 2.6 ms instead of 6.3 ms. Behind simoom, p99 fell from 0.87–0.91 ms to 0.32–0.44 ms while serving 1.7–1.8x the requests.

Cameleer · simoom

Fewer machines

1,024 integrations fit in 8 GiB by peak memory instead of 20. At 1.7–8.7x the throughput on the same CPUs, the same load needs fewer vCPUs, and each costs about $29.55 a month on Fargate at list price.

Arithmetic; real density is lower on both sides. Density and vCPU examples

Simpler operations

One binary with no JVM to install: 8 MB of memory at start-up instead of 114 MB. simoom has no crates.io dependencies at all and holds 1,000 idle connections in 2.7 MB instead of 7.7 MB.

Both rows in the ledger

Do it on your own software

Seven steps, in any language, on the service you already run. You need one service, two identical machines and a load generator on a third machine.

  1. 1 Pick the service that costs the most

    Do
    Rank your services by spend in your cost reports and take the top one.
    Record
    Its monthly cost, instance count and the unit you are billed in.
    Use
    Step 1 of the FinOps practice.
    Done when
    One service is named, with its cost on one line.

  2. 2 Baseline it on fixed hardware

    Do
    Measure start-up, idle and peak memory, throughput, p99, CPU per request, size and dependencies. Report the median of many runs.
    Record
    The exact version, runtime, flags and machine type.
    Use
    “What to measure” and the fair-baseline rules in the method.
    Done when
    A teammate can rerun the baseline with one script and get the same figures.

  3. 3 Translate and budget

    Do
    Turn each number into what you pay for: GB-seconds, vCPU-hours, instances per node. Set a target for each, labelled as a target.
    Record
    The arithmetic, and what it leaves out.
    Use
    The worked examples on the FinOps page.
    Done when
    Every target has a number, a unit and a price.

  4. 4 Cut, starting with the smallest step

    Do
    Climb the ladder one rung at a time: tune, remove, replace one component, rewrite the hot path; rewrite it all only when the design is the limit. Keep the behaviour users rely on.
    Record
    One change per measurement, and why you made it.
    Use
    The ladder and the rewrite checklist.
    Done when
    The behaviour tests still pass and the change moved a number.

  5. 5 Prove it on the same machines

    Do
    Rerun the same harness on the same hardware, swapping the roles of the two machines. Round against yourself: your times and memory up, your ratios down.
    Record
    Both ends of every range, and every scenario you lose.
    Use
    The “Don’t” list in the method.
    Done when
    You have a before-and-after table with the losses in it.

  6. 6 Rightsize, then guard

    Do
    Lower requests, limits and memory settings to match, or the software shrinks and the bill does not. Then make CI fail on size, memory, start-up and p99 regressions.
    Record
    The answers to the ten-question water check before each release.
    Use
    The water check in the method.
    Done when
    A regression fails the build before it reaches the bill.

  7. 7 Write the crossing report

    Do
    One page per result: Load (the workload), Baseline (exact versions), Terrain (hardware and OS), Water (start-up, memory, size, CPU), Distance (throughput and latency), Losses, Repeat it (scripts and raw results) and Date.
    Record
    The report, next to the raw results.
    Done when
    Someone outside the team could check your numbers.

When a result can be called Cameleered

All five must hold: a named, current baseline version; both sides on the same hardware; a script anyone can rerun, and the raw results; the losses disclosed; measured within the last 12 months. Work in progress is Cameleering and shows targets only; work not started is planned.

Need a second pair of eyes?

Stuck on a baseline, or not sure a number is fair? Ask in GitHub Discussions. Cameleering sells nothing; the maintainer is open to consulting.

Open the methodIs a rewrite worth it?

We call this cameleering

Cameleering is the practice of making software carry the same load on less (less time, memory, size and dependencies) and proving every gain against the original, on the same hardware, with the method published.

Carry more on less. No claim without a number.

  1. Measure before you claim. Targets are labelled as targets until they are measured.
  2. Baselines over boasts. The version people run today, on the same machine, with both sides published.
  3. Same job, same contract. Keep the names, options and behaviour people rely on.
  4. Pack only what the journey needs. Every feature, dependency and idle thread pays its way, or ships as an option.
  5. Real waiting over felt waiting. A loader changes how a wait feels; only engineering changes how long it is.
  6. Budgets in the build. Size, memory, startup and latency regressions fail CI.
  7. Rewrite when the numbers say so. A rewrite is a tool, not a creed (when it pays off).
  8. Publish the losses. A ledger with no red rows is not trusted.
approachwhat it doeshow cameleering relates
FinOpsmanages cloud spend, mostly by rightsizing infrastructure [8]cameleering changes how much the software needs, so the next rightsizing goes further
Green software and the SCI standardmeasures and reports the carbon of software [7]complementary: cameleering changes the software and reports resources; SCI can turn those into carbon
Performance engineeringtunes a system, usually privately and step by stepthe same craft, done in public against the incumbent, losses included

The idea is old: in 1995 Niklaus Wirth wrote “A Plea for Lean Software” [1]. Cameleering adds shipped improvements to widely used software, proven against the original in public.

Why now: using less is a responsibility

We spent faster chips and cheaper memory on features and layers, often for good reasons. Now code is cheap to produce: in one benchmark, GPT-4’s code took 3.12 times as long to run as human solutions [3] (the evidence). The thing to fight is waste, not the people who build features.

To the people who pay for the machines

Every idle gigabyte is paid for, every month, by someone.

To the people who wait

A slow start or a slow p99 is a person waiting, or a function billed while it warms up.

To the power we all share

The IEA projects data-centre electricity use to reach about 945 TWh by 2030 [2]. One project cannot change that; every team that removes waste does its share. Cameleering reports milliseconds and megabytes and makes no carbon claims of its own.

Code efficiency as a FinOps lever

Milliseconds and megabytes turned into instances and dollars.

When a rewrite pays off

The ladder from a setting to a full rewrite, and a checklist.

Headroom: what is left when servers drop out

The same traffic on fewer servers: why per-request cost decides the margin.

All articles

AI code performance, Wirth’s law and more, with sources; also as a feed.

Common questions

Is this “rewrite it in Rust”?

No. The gains come from how software uses its language: what goes into the build, which defaults ship, and how many threads and allocations a request costs. A rewrite is the top step of the ladder, used only when the design is the limit. Each claim is a measured result, never the language.

Will I get the same savings?

Not necessarily. The FinOps figures are arithmetic on measured numbers and list prices, and each says what it leaves out. Yours depend on your workload, your discounts and whether you rightsize afterwards. That is why step 2 is your own baseline.

Why should I trust these numbers?

Check them. Every result names its baseline version and hardware, and links to the scripts and raw results. Ratios are rounded down, and the losses are in the same table as the wins.

Can we do this on closed-source software?

Yes. The steps work the same in private, and the crossing report goes to your team instead of the web. The public ledger lists only results whose scripts and raw data are published.

How is this different from FinOps?

FinOps rightsizes the infrastructure to fit the software. Cameleering changes how much the software needs, so the next rightsizing goes further. The two fit together.

What does Cameleering sell?

Nothing. The projects are open source under the Apache License 2.0, with no paid edition. The maintainer is open to consulting; ask in GitHub Discussions.

Is Cameleering affiliated with the Apache Software Foundation?

No. Cameleer follows Apache Camel's names and semantics but contains no Camel source code and is not affiliated with or endorsed by the ASF.

Pick one service. Measure it this week.

Start with the baseline. Everything after it is a number you can show.

Open the methodSee the ledgerAsk in GitHub Discussions

Everything is open source under the Apache License 2.0: the code, the benchmark harness and the raw results. Security reports go privately through GitHub’s vulnerability reporting (security and supply chain).

Sources

  1. Niklaus Wirth, “A Plea for Lean Software”, IEEE Computer 28(2), February 1995, doi:10.1109/2.348001.
  2. International Energy Agency, “AI is set to drive surging electricity demand from data centres”, 2025 (Energy and AI report).
  3. Huang et al., “EffiBench: Benchmarking the Efficiency of Automatically Generated Code”, NeurIPS 2024.
  4. Green Software Foundation, Software Carbon Intensity (SCI) specification, published as ISO/IEC 21031:2024.
  5. FinOps Foundation, What is FinOps?
  6. Measurements: Cameleer in BENCHMARKS (raw results in benchmarks/results/2026-11-06-linux); simoom in its benchmarks; FinOps arithmetic and the Flexera survey on the FinOps page; all summarized in the ledger.