For the programmer who wants to try it
How to tell your boss you need to play in this sandbox.
You are not asking your company to adopt FrogNet. You are asking for permission to find out whether a large amount of the distributed-system machinery your team writes and maintains needs to exist at all. That is a much smaller request, and a much more interesting one.
The Simulator — attacking the mechanics under arbitrary topologies.
Everything below is yours to copy. It is written to be pasted into an email with your own subsystem's name dropped in.
Two engineers. One subsystem you already understand. A fixed period.
No production migration. No architectural commitment. No procurement. No replacing anything you run today. Reproduce one subsystem's behaviour against FrogNet, put both implementations through the same workload and the same injected failures, and compare what the application code has to contain.
Pick the subsystem carefully, because the experiment is only as good as the thing it is run on. You want one whose distributed behaviour you understand well enough to argue about — something with real coordination in it, where you already know where the bodies are buried. A component nobody understands will produce a result nobody believes.
Two people is right. One senior systems programmer who has maintained distributed code in production, and one strong application programmer who knows the subsystem. Not a committee, not an architecture initiative, and not a working group.
Write the stop conditions down before you start, and mean them. If the experiment does not materially simplify the system, it stops and you report that. An evaluation that cannot come back negative is not an evaluation.
This is much easier to take upstairs than “I found a cool networking project.”
Count what the application no longer has to contain.
Lines of code is the weakest of these and the easiest to game. What matters is how many things exist that only exist because the components are in different places.
| Count | Why it is the thing to count |
|---|---|
| Endpoints | Every one is a public surface, a schema, a version and a test. |
| Message types and schemas | Each is a contract two components must agree on and keep agreeing on. |
| Retry, timeout and reconnect paths | The code most likely to be wrong, and least likely to be exercised before production. |
| Deduplication and idempotency machinery | Exists only because a message can arrive twice. |
| Queues, brokers and consumers | Infrastructure to run, monitor, upgrade and pay for. |
| Coordination state | State that exists to track a conversation rather than to describe the world. |
| Integration tests and distributed mocks | Count what you delete, not just what you write. |
| Deployment dependencies | What has to be up for this component to start. |
| Failure modes still in application code | The honest one. Some will remain. Name them. |
| Time to add an equivalent feature | The debt question: does the next feature cost less? |
| Time to diagnose an injected failure | The operational question, and the one your on-call rotation cares about. |
Run both implementations against the same topology, the same workload, the same injected failures and the same correctness oracle. Without a shared oracle you are comparing two programs that do slightly different things, and the comparison means nothing.
If you cannot answer these yet, you are not ready to ask.
This section is here so the page is not sales copy. A good manager will ask most of these, and you should have the answers before you walk in.
About the experiment
- What exactly are you going to test?
- Which existing subsystem, and why that one?
- How long, and what does it displace?
- What are the stop conditions?
- How will you measure improvement?
- How will you verify the two implementations are actually equivalent?
About the risk
- What limitations have you already found?
- What new operational dependencies would adoption create?
- What is the continuity risk if the project stalls?
- What happens to us if FrogNet disappears?
- What would have to be true before you would recommend production use?
On that second column, the honest answer today is that FrogNet is one person's work with a young specification, and the reference implementation is licensed rather than open. There is an intended Foundation and an intended open specification, and intent is not the same risk profile as a mature independently implementable standard with several implementations. That is a real reason not to put production on it yet, and it is exactly why the ask is an experiment and not a migration.
The cost of disproving this is small. The cost of never checking is not.
A conventional distributed application is domain behaviour plus machinery that exists only because the parts are in different places. Nobody sits down to write the second category on purpose. It accumulates: an endpoint here, a retry policy there, a queue because the retry was not enough, coordination state because the queue reordered something, a circuit breaker because the coordination state got stuck.
The proposition worth testing is that a substantial part of that second category can live in the platform instead. If it can, the saving is not mainly lines of code. It is fewer failure paths, fewer interfaces, fewer protocols to maintain, fewer integration seams, less observability built solely to reconstruct a conversation that went wrong — and, more importantly, a lower rate at which the next feature adds more of the same.
That last part is the argument to make upstairs. Not this deletes our technical debt — which depends on your application and has to be measured — but this may reduce the rate at which we accumulate it.
And eliminating debt is not automatically worth it. Conversion costs real time: learning the memory model, rewriting components, validating semantics, adapting operations, training, and taking a dependency on a young platform. So the question is not “does it delete code” but whether the lifetime reduction in engineering and operational cost justifies the conversion. That is what the experiment is for, and it is why a bounded one is worth more than an opinion from either of us.
Run the experiment.
Not “try FrogNet.” Run the experiment, on your own software, with your own failure cases, and keep the result whichever way it goes.
The simulator and the test discipline → is where to begin, because it is the apparatus: the same topology, the same injected failures, and an oracle that has to go from red to green. The demonstrations → show the machinery under real conditions, and the programming surface → is the claim itself, stated plainly enough to disagree with.
If the experiment says no, say so publicly. That is worth as much to this project as a success, and it is the only thing that makes the rest of the site trustworthy.