JVM and memory config generator for Apache Ignite deployments

The first time an Ignite cluster hangs in production, the engineer opens a support thread and finds the same answer every time: 'your JVM is misconfigured.' Users explicitly say 'JVM should be configured properly otherwise system will get hang up and performance will be degraded' — but the gap between 'you need to configure it' and 'here is exactly what to set given your workload' is enormous and entirely manual.

This gap persists because Ignite is infrastructure software maintained by a community with no commercial support tier at scale. The people who know how to tune it correctly — heap sizing, GC strategy, off-heap ratios, data region sizing — are a small group of consultants and internal experts who learned by breaking things. That knowledge is not codified anywhere accessible to the engineer who just inherited an Ignite deployment.

The problem is not that documentation does not exist. It is that the correct config is workload-dependent: a write-heavy OLTP cluster needs completely different settings than a read-heavy caching layer. Generic documentation gives ranges; what engineers actually need is settings derived from their specific node count, data volume, access patterns, and hardware. Nobody currently bridges that gap without an expensive consulting engagement.

This is a business and not a feature because every new Ignite deployment starts from scratch, every hardware upgrade forces a re-tune, and every growth milestone (doubling data volume, tripling TPS) invalidates the old config. The need is not one-time — it is triggered by every meaningful change to the cluster or workload. A company running Ignite in production and paying for the hardware would pay several hundred dollars to avoid a weekend of cluster instability.

What to build

Build a web-based configurator that takes Ignite cluster inputs — node count, RAM per node, estimated dataset size, read/write ratio, and GC preference — and outputs a validated ignite-config.xml and JVM options file with inline comments explaining each setting and the workload assumption behind it.

Where to start

Launch as a free config generator with no account required, charge for a 'config review' async service where an expert validates the generated output against a customer's specific schema and query patterns — this seeds trust and surfaces the cases where the generator's assumptions break.

The hard part

Validating that the generated configs actually perform better than what users had before, without access to their clusters — you need a way to collect outcome feedback so recommendations improve, otherwise early customers who get a mediocre result just leave quietly.

How it makes money

Free self-serve config generation to drive discovery; paid async expert review at a flat fee per engagement ($300-500); recurring subscription for teams that want config re-evaluation triggered by deployment changes.