stackabletech / stackabletech/demos
New sales demo / restructure existing demos
Nobody has claimed this yet.
- Dominant language
- Jupyter Notebook
- Stars
- 3
- Forks
- 13
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 2
Description
Current Situation and Problem Statement
Coming from a sales point of view, the current list of demos we have is not ideal for my specific use case, which I know is very non-normal :)
For me the normal case is, that I have to pick a demo and spin it up before a meeting and then show it to some people who are interested in - I don't know what they are intersted in before the meeting :) At most I know a few products they want - and unless we score a lucky hit there is usually not a demo covering all of them.
On top of that, there are additional topics that may or may not come up during the discussions:
- GitOps
- Security
- Logging
- Monitoring
- Integration with tool xyz (see below for more details on this)
At the moment we have specific demos for some of these topics, but that usually means having a second demo deployed if I want to show any of these topics. Ideally these cross-cutting functionalities could be enabled on all our demos - at the cost of additional complexity and overhead.
Then there is a long list of tools that are often brought up in discussions, which in theory integrate nicely with our stack, and it would be great being able to "just" show this ad-hoc:
- OpenMetadata
- dbt + Astronomer Cosmos
- Lakekeeper
- Polaris
- GarageFS / ...
- DataHub
- dagster
- ...
Sure, not all of those are super-relevant, but for example having just OpenMetadata, dbt and Lakekeeper in a demo would probably cover 80% of what I am currently being asked about.
For me, and again, super subjective and just my personal situation, this leads to fairly often having to just say "this is possible" or "i can show you later" in these demo meetings, when in principle we'd have everything in place, because I "guessed" wrong, when standing up a demo.
For me personally, the ideal situation would just be one demo that does it all:
- logging
- metrics
- security enabled
- audit logs ingested
- some random use case or two
- Trino set up with multiple backends
- Postgres
- OpenSearch
- Kafka
- S3
- Hdfs
- Lakekeeper
- Hive
- Airflow running a dbt dag with Cosmos
- OpenMetadata ingesting tables and lineage
- Keycloak
- Policies
- whatever else
That way I could spin up the same demo every time and know I have what I need. But I know that I am not the norm there, so this is not an ask for that demo, I'd just discuss possible ways of improving the situation for me. And if there is nothing to do, that is fine too, it has worked so far.
Ideas
- Merge a few demos into this one big demo, might actually cut down on the net effort needed to maintain demos, not sure
- Maintain the demo as a sales owned but not officially supported demo, no testing for releases, we are in charge of maintaining it and extending it as needed -> totally fine, I am happy owning it, but that'll take time and is not my job, I cannot decide that on my own
- many more options
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by inventorying the existing demos and comparing their deployment and maintenance boundaries with the requested integrations and cross-cutting features. Done requires an agreed demo structure, ownership model, and concrete scope before implementation can begin.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kafka, postgresql
- Domain
- data-engineering, devops, observability, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100