What are the components?

All components are container-deployable via Docker / Kubernetes. We don't do installable software or libraries. Just containers.

The major components are:

  • API / Dashbaord
  • Neo4j Database
  • Collectors - AWS, GCP, VMware, etc.

How do the collectors get their data?

They use public APIs. For systems with APIs that support events (Kubernetes, AWS Cloudwatch Events / CloudTrail) we subscribe to the stream of events.

For everything else we use a variety of polling logic to interrogate the source system and extract data. From there, we perform some lite normalization of the data and persist it into Neo4j.

Do I have to change how I do things?


Our philosophy is that we want to find people where they are and help them along their journey. We have no interest in telling you how to run your systems.

If you have the kinds of problems that we are solving, it necessarily means that you are successful. Pat yourself on the back for that.

Maybe you are fully containerized. Maybe you are just starting. Maybe you are 100% cloud. Maybe you are 80% data-center.

It doesn't matter to us. We want to to find your systems where they are, consume asset and configuration data, and present it back to you in a way that is meaningful and useful to you.

Is it a Platform-as-a-Service?

No. We don't want to tell you how to run your infrastructure.


Why did you build soluble?

We built a similar system in previous lives. We stumbled into using a graph database to manage infrastructure and found it be very effective (and fun).

After some time, we came to believe that there was more opportunity in developing this platform than to continue to toil away in the salt mines at our day jobs.

We use <tool-here>. Why would I need soluble?

Very few tools in the industry attempt to capture the breadth and make it available to everyone.

Management systems are highly balkanized into little silos of data. Software engineers don't log in to network management systems or VMware. Security teams don't log in to APM or observability.

We want to be the first pane of glass that can tie together all these distributed systems.

AWS already keeps track of all my infrastructure. Why isn't that enough?

With a simple deployment topology in one account and one region, it's probably not. But as soon as you start getting more than a handful of accounts and regions, even simple things become tedious.

What account is my service in again?

What is this IP?

What AMI versions are all my instances running?

If you add Kubernetes into the picture, there is a new dimension of complexity.

Which pods are exposed via public ELB?

Which services are running with container images with a known defect or vulnerability?

Do I need to write code to use soluble?

No. We are software engineers. We like to write software.

Who are the target users for Soluble?

  • DevOps
  • SRE
  • Security
  • Technology Management


What database does soluble use?

Neo4j, the leading graph database. It is a true delight.

It has a rich and expressive query language that is easy to learn.

Why use a graph database?

Infrastructure things are all connected to each other.

Source code resides in repositories. That code is built and tested by CI jobs. The CI jobs produce images and artifacts. Artifacts are deployed to servers. Servers run in VPCs, which reside in accounts and regions. Deployed services have owners. Infrastructure and services are monitored by APM and Observability tools. Sometimes software has vulnerabilities. Those vulnerabilities are associated with services and lines of business. To fix those vulnerabilities, they need to be in engineers' sprint plans.

You get the picture. All these things are related. Their representations should be related as well!

What other databases have you considerd?

We have used a variety of graph databases. Gremlin-based systems like Neptune and CosmosDB are interesting, but we found the query language to be a significant barrier to productivity.

DGraph looks very interesting. However, the query language is, like gremlin, a significant barrier to general use. Some people have been asking for Cypher support for DGraph. We may re-consider DGraph.


Is it open-source?

Yes. The core components are all Apache-licensed.

Is it all open-source?

Not everything. We are following the same open-core model as Elastic, Databricks, Confluent, Neo4j and others.

We want the core components that engineers use every day to be free and open.

We want to monetize on enterprise features that have commercial value to to technology management.