# Waterloo Marketplace Product Discovery **Author:** Miller Hooks *miller@dtmf.com* # Document Purpose This document outlines different possible Cloud Marketplace Products that [Waterloo Data](https://waterloodata.com/) and [DTMF, inc.](https://www.dtmf.com) can release. I will outline the technologies we might consider, potential configurations and topologies, similar products and their costs and usage (if usage info is availible), and general info about the marketplaces we can deploy to and strategic discussion around how to "write once deploy everywhere". ## First Volley There are a lot of ways to pull this thread. I think the best way to do it involves shiping something for the absolute lowest amount of effort possible as quickly as possible so we can test out and build the pipelines to work with the marketing folks, understand how the marketplaces work, figure out how support works, and make sure we've got payout down. The initial effort doesn't have to, an probably shouldn't be the best of our best but should be something that has some potential market viability. This repo. https://github.com/trxcllnt/rapids-compose This repo is based off my normal patterns for managing a project deployment but is a bit of a fork that my friend Paul did while I was at Nvidia. He stripped out all the stuff that builds it into a kubernetes deployment. Which is great! It's actively maintained and updated, and is used by most of the RAPIDS AI internal development team. We can hard fork this to be a Waterloo Data repository and I can add back in the helm chart stuff for the deployment. It includes build out for all of the RAPIDS AI tools and functioning JypyterLab. I think this makes it a perfect first candidate for the following reasons: * It doesn't expose us to a long iterative development cycle. * It is a repo that we can fork. * Which means we can pull updates from the upstream and stay current with RAPIDS. * I've got the additions already in my back pocket to make it a Kubernetes deployment. * It's not a problem if we ship the repo fully open to the public . * So we can test out open source Github Issues and community engagement. * It touches on most of the requirements for the fancier things we want to do. * A known good deployment makes it easier to focus on CI/CD tooling, which will be critical to success in growing this endeavor. I don't see anything quite like it in any marketplace. https://aws.amazon.com/marketplace/search/results?searchTerms=RAPIDS However, even if there is, who cares. We can have it shipping to Amazon before this week is out, which would mean we can engage the marketing team with context. Then use that context to plan our futher moves, possibly with a stream of revenue from marketplace sales. ## Branding (Waterloo Data v. DTMF, inc.) ### What is DTMF, inc. DTMF is not a data consultancy. DTMF is a thinktank. DTMF does and will continue to offer products. They are going to be weird and probably be things that would confuse Enterprise customers. DTMF's operations that have enabled this product exploration are only possible because of what DTMF is. DTMF's primary focus involves edge computing of point cloud data. It inherantly builds the tools that Enterprise needs today and tomorrow. It will continue to do R&D, utilize the tools it has built, improve on them, and build more tools. Some of those tools will be very useful for enterprise consulting. DTMF does not want to compete in any way in the space that Waterloo Data operates in. The tools DTMF has developed interally have been well tested due to the requirements of the thinktank research. Through that process, DTMF has developed a standard pattern for building products and actively documenting their operation. DTMF products grind off the difficulty of these new technologies and make them accessable to a wider range of developers. This decreases the risk of engaging with things like Kubernetes and GPU compute for a consultancy. As of this writing, that gives us a fairly large market advantage. DTMF has a focus on building out it's tools to match as universal of a pattern as can be determined. Because of the methodology DTMF has developed, the tools will remain servicable without constant invention. The tools are not a trap to create dependance on DTMF for support. The philosiphy of DTMF is that anyone should be able to run the whole stack with one command and continue to modify, expand, and apply the tools perpetually with or without DTMFs involvement. DTMF is not in the business of polishing turds for tokens. DTMF will not be building out a consulting or enterprise training workforce. DTMF is inherantly a high risk endeavor. DTMF's near term goal (withing the next year) is to be innovating in AI generative silicon photonics. Not grinding out perpetual support contracts on messy, bloated, code that generate support dollars through "boiled frog" acceptable complexity. DTMF is incentivised to make sure it's code is operationally transparent and clean because it needs these tools to reach it's next operational goals. The methods needed to solve the problems DTMF is trying to solve require that it's work products operate at a high level of interoperability and broad serviciability with as small of a footprint as possible. ### What is Waterloo Data Waterloo Data is an established enterprise services consultancy. Waterloo Data has a competent team of contractor developers. Waterloo Data has a brand that is in line with what enterprise operations expect to see and work with. Waterloo Data has availible marketing resources. Waterloo Data has customers that can use the tools that DTMF produces and would enjoy paying for them to gain advantage in their respective markets. People that use our Cloud Marketplace Products will likely end up over their head in their operation or need aditional resources and contact Waterloo Data to help them solve their problems. DTMF will never be the right organization to contact to help them. Waterloo Data is not an operation designed to take the R&D risks that DTMF is designed to do. ### What Does the Relationship Look Like? DTMF builds tools. DTMF wants to take these tools and work with Waterloo Data to build a brand around a set of Cloud Marketplace Products. The relationship between DTMF and Waterloo probably doesn't need to be obfuscated completely. If in the course of business it's determined otherwise, that's not a huge deal. I think probably it should be like how DoorDash is entirely powered by the infrastructure built by Foursquare. No one uses that silly social app anymore, but the tools and data built by it make it so we can all get soggy nachos without leaving our house. You can see some places in the DoorDash product the occasional attribution "Powered by Foursquare" or whatever. But it really doesn't matter. Having some distance between these operations creates a mutually beneficial feedback loop without the risk of Waterloo Data having to answer for hologram puppet shows or other bazzar content. By working with Waterloo Data, DTMF gets the benefit of having a coupled sandbox to sell work products generated from it's R&D and grow those items into stable enterprise tools which provides capital but also that infrastructure feeds back into DTMF effort making the R&D efforts more stable and effective. DTMF is built to document and train people to use distributed GPU compute tools. Building learning products along with the marketplace deploy means that we have a nice sandbox to train Waterloo employees, contractors, and customers to use the tools and thus have a feedback loop to improve the training tools. Which then means that Waterloo Employees or Contractors make decent on-site intensive instructors for these tools. In my view, this relationship seems to have a nice congruity. We can start from nearly nothing without much risk. If it's a failure, no one loses much. I don't see a lot of room for the type of thing I consider failure. The effort and income appear to scale together. The product and tools can be built collaboratively, but also have a clean path to either spinning off the work into a seperate entity, or establishing some other operational structure that fits as needed. If Waterloo Data decided to close up shop or pivot, this would not disrupt DTMF's core business and similarly if DTMF ceased operation, Waterloo Data would have the tools to continue operating with a solid base and grow as they see fit with it. It seems to be uncomplicated to establish appropriate service level agreements or other contingencies to protect both operations. The endeavor can remain low risk while growing. --- # DTMF Technologies This is a general overview of the assets that DTMF brings to the table. I have siloed them into four bins. These are not dogmatic and this is just a draft. The goal here is to line these things out and their intersticial components so we can easily chunk them into salable Cloud Marketplace Products that can (hopefully) work like Russian Nesting Dolls that exponentiate MRR. Once in to one product, the customer finds that it would be useful to branch out to more instances of that Cloud Marketplace Product as well as any of our adjecnt product offerings. ## Kubernetes GPU GIS Stack *This is the head of the snake.* * GeoDjango Project * NextJS Frontend * Mapbox/ArcGIS/DeckGL * PostGIS * Enterprise Org Auth Integration ## GPU Data Science Tooling *This is it's teeth.* * Dask * RAPIDS AI * Notebooks * JupyterLab * BinderHub * Kubeflow * GeoArrow/GeoParquet ## 3D GIS Rendering Portal *These is the eyes.* * Unity3D * Unreal * Blender * NextJS * Mapbox * ArcGIS ## Service and VPN Mesh *This is it's body.* * Multicloud Kubernetes * NetMaker * OpenZiti * Istio Ambient # Things to Avoid In our initial outing we may want to avoid manging these parts of a computing product because of complexity, variability of customer needs, variablity of host requirements, or because they are already well served. Rules are meant to be broken too, but I think it's good to list boundaries for where we aren't really looking right now unless a surprising market oppertunity is found. * NFS Provisioning * SSL * Active Directory * Log management * other than basic prometheus sidecar and health check endpoints # Things to Consider Here are some things that might dovetail into this and be an easy win or enhance our products that aren't fleshed out an tested yet. * AI/Machine Learning Model Marketplace * Data Science Notebook Marketplace * On-site compute resource management * Multi-cloud compute resource overflow (burst or subscription). * On-site training and digital learning products * This can be extremely lucrative. * Many large companies have yearly budgets for contiued learning and they will purchase online learning tool or on-site intensives. * If we are considering the knowledge products while building he marketplace deployments and document as we build with an eye for assembling those learning materials, the production of learning syllibus comes for nearly free. --- # Marketplaces There are more marketplaces other than the big ones. It's possible we can hit them all at once by using a vendor to aid in that. It may also be more effective to target each marketplace surgically to test the waters or decrease the support liability exposure. All deployment will have a base infrastructure cost. Some will chose to add additional software costs, others will launch with free software, some will let the user upgrade to a pro version with a key or license (thus avoiding Amazon taking a cut of the software cost). As a marketplace vendor, we will get a kickback for infrastructure deployed with your image even if you aren't charging additionally for the tooling. * https://aws.amazon.com/marketplace/campaigns/software-procurement * https://aws.amazon.com/marketplace/partners/management-tour * ## AWS The largest marketplace availible. * https://docs.aws.amazon.com/marketplace/latest/userguide/user-guide-for-sellers.html ## Azure Azure has a strong enterprise footprint and a much closer relationship with Nvidia. * https://azuremarketplace.microsoft.com/en-us/sell ## Google Cloud The smallest of the big boys. * https://cloud.google.com/marketplace/sell ## Lambda Labs Lambda Labs is a data science centric host. They are as much as 80% cheaper that the big dogs above. * https://lambdalabs.com/ ## Digital Ocean No GPU but much cheaper. A longer game might be to offer multicloud deployments that take into account rates for servies and uses the cheapest availible. I don't know what products are out there that do that, but I'm pretty sure there's still room in that market. Espeically going into next year. Digital Ocean is one of the most widely used VPS hosts that isn't the big 3. * https://marketplace.digitalocean.com/vendors ## Other VPS Hosts * https://www.vultr.com/marketplace/become-a-verified-vendor/ * https://www.linode.com/marketplace/app-partners/ # Marketplace Seller Tools I have not used or vetted these tools, but since this is a sales effort and there are so many marketplaces I figured something like this would exist. So far this is all I've found. Looks slick though. ## Tackle.io Tackle Accelerates Revenue Through Cloud Marketplaces > Our zero-engineering platform and industry expertise provide a go-to-market solution to help B2B software companies establish, operate, and scale sales through the cloud. ## Others * https://www.cloudblue.com/solutions/vendor-product-information-management/ * https://spryker.com/marketplace-platform-us --- # Similar Marketplace Products Below I will outline a few different Cloud Marketplace Products. Mostly focusing on AWS. The goal here is to get a sampling of things that have a similar shape to better understand what people are already providing. By understanding this we can more easily scope for underserved market fit that maximizes revenue and has the least competition. ## Kubernetes ### EKS Amazon offers an EKS-optomized AMI with GPU support. We could even consider forking this for Kubernetes deployment. However, EKS may have a different update and development cycle, custom ingresses/load balancers particular to EKS, or other quirks. Since our focus is on multicloud and flexibilty, we should put our efforts into the most universal parts but strive to construct and interoperate and/or swap out for platform specific tools like this AMI or Google's Anthos (possibly) where beneficial for customer needs or ease of integration on our parts. This Marketplace AMI is however, a very good benchmark of Kubernetes infrastructure deployment costs on EKS via the Marketplace. * https://aws.amazon.com/marketplace/pp/prodview-nwwwodawoxndm * > This deployment in the recommended configuration, for the AWS infrastructure is **$3.06/hr**. ## Data Science ### Data Visualization * NVIDIA IndeX * https://aws.amazon.com/marketplace/pp/prodview-jungamkavzpw2 * > NVIDIA IndeX is a 3D volumetric, interactive visualization SDK that allows scientists and researchers to visualize massive data sets, make real-time modifications, and navigate to the most pertinent parts of the data, all in real-time, making it possible to gather better insights faster. * > **5.00/unit/hr** ### AI/ML Tools * HuggingFace Disilbart CNN 12-6 * https://aws.amazon.com/marketplace/pp/prodview-kjdlmojb4jm4m * > This is a tool, one of many, deployed as a Marketplace Product by the AI model depo https://huggingface.com that can be spun up at will to do text summation. * > The software is provided for free. The recommended deployment infrastructure for this tool costs $1.125+$0.736 per host per hour. * > **$1.861/host/hr total.** ### Kubeflow * Arrikto KubeFlow-as-a-service * https://www.arrikto.com/kubeflow-as-a-service * > Neet to look more at pricing. Very slick product. * Kaptain AI/ML Add-on GPU - Premium Support * https://aws.amazon.com/marketplace/pp/prodview-hdq67t2dtey6y#pdp-pricing * > This looks like a Marketplace Product that deploys Kubeflow to AWS for you. * > **$4000** for 12 months. ## Edge Computing ### Snowball and Snowcone This is a new AWS data product that involves encrypted and semi-customized next day delivered storage and compute units. They cost between $300-$2500 for a single unit but can be delivered in clusters and that comes with a 10 day usage. When you're done, they send a courier to pick it up or you pay a day rate to keep using it. When they are dispatched they are loaded with an AMI selected by the user. So, an Marketplace AMI can be sent out as a Snowball or Snowcone with whatever equipment is required to run the infra. I think this is a very fertile market that has only barely begun to see use. https://aws.amazon.com/snowball/ --- # Support Considerations ## Continuous Integration and Delivery Our products will be built from the start with [semantic versioning](https://semver.org/) in it's releases. This is very important for deploying, updating, and securing containerized deployments. We will likely use either [Argo](https://argoproj.github.io/) or [GoCD](https://www.gocd.org/) for building out our build pipelines. While picking the tools for our CI/CD we will be weighing the cost to host and operate the CI/CD platforms against what is availible as a service. If we can find free or inexpensive cluster native CI/CD tools run by a vendor, that is preferable unless the vendor is designed to create lock in. The CI/CD tooling should be built in a way that it can be moved to or integrated with self or vendor hosted alternatives as our budget and attention demands. We must be rigid and intolerant of tools that suck in this arena. CI/CD is so critical to exponential success in this endeavor that any tools for this part need to be evaluated with a very critical eye. ### Questions * How are we building and releasing the products? * What is the lowest cost and effort CI/CD suite to test and release these tools? ### Security When we build a new image, the deployment in all of it's parts needs to be run through known vulnerability and eploit (CVE) checks. * https://www.cvedetails.com/ * https://www.armosec.io/lp-container-security/ * https://www.prplbx.com/resources/blog/docker-part2/#docker-vulnerability-scan-overview * https://www.cisecurity.org/benchmark/docker ## Technical and Account Support It's likely we can pick a single helpdesk and chat product that will track user tickets and handle communication. Services like this also generally have an option to build out support scripts that can be farmed to support workers. Properly managed, this should produce a knowledge base through usage and funnel users to that knowledge base instead of direct support. ### Public Slack Channel https://slack.com/solutions/customer-service ### Email #### Questions * Email group? * Who is responsible at Waterloo? * How does Waterloo escale to DTMF? ### Submit a Ticket Github? ### Community Forums I doubt we should do this, but we should consider it. Ideally it would be a checkbox to deploy one with a general helpdesk product. ### Knowledge Base, Wiki, Docs and AutoDoc * Docs should be as AutoDoc as possible. * Knowledge Bases should be generated from support requests. * A wiki can be hooked to a github repo. --- # Marketing ## Marketing Team Collaboration When we release this product or suite of products, it is my understanding that we will be working with a contracted marketing team. In my opinion, building out the workflows to engage with and maximize the effectiveness of the marketing team is part of the Software Requirements Specification. ### Questions * How many people are on the current team? * Who is the primary Point of Contact? * How do we shorten or automate a feedback loop for ad pushes? * How are we tracking the closed loop of the marketing and pinning it to campeings? * What is our strategy for iteration, testing, or pivoting the Marketplace Products to match consumer interest? ### Metrics and Conversion Reporting #### Questions * What is the prefered method of connecting data from marketplaces to salesforce or whatever? * What does that look like? * What are the endpoints? ### Marketplace Poduct Interoperation Product offerings should be designed in a way to make it easy for as wide of a customer base as possible to engage with the product at whatever level is appropriate for them. Following that, the products should augment each other and encourage futher adoption of our Cloud Marketplace Products. #### Questions * How do we tier the products and interop them to maximize usage? * What's the gateway drug? * What's the end game? * Who are we targeting and why would they use these parts? ### Marketing Copy and User Base Communication #### Questions * What does the customer who clicks the button to buy this marketplace product look like? * What is his/her budget? * Who do they report to? * What do they expect to get out of the product? * How much support are they likely to need? * How do we intend to provide that support? * How do we intend to engage the communities that would most benefit from these tools? * Can we offer trials or credits to first time customers? * How would tirals or credits work on each platform? ### Community Edition This is a useful litmus test for the value of the Marketplace product and is good marketing. Have a public github and some docs that show people how they can just spend some time with a repo or a release and deploy it themselves. There's a lot of stuff that comes with a Cloud Marketplace Product that does network, auth, storage, and other setup. Most people will fiddle for a bit themselves but if the marketplace image is handy just go spend some cash and spin it up. People that do go and set it up themselves will then usually ask questions as GitHub Issues and sometimes even submit helpful PRs. Engaging in the FOSS community is a good way to make sure we are engaged with the market. ### Marketing Tools Currently Used >@Mattbrown Please detail what tools are currently being used. ### Marketing Team Structure #### Questions * How big is the team? * Who is the team lead? * How do they prefer to communicate? * How do we plan and track our communications so requirements are not lost? ### Waterloo Marketing Assets #### Blog * https://waterloodata.com/blog/ #### Twitter #### Youtube #### Ad Buys #### Mailing List Tools / Direct Marketing --- # Useful Links * **XPU AI/ML GPU Virtualization FREE** * https://aws.amazon.com/marketplace/pp/prodview-psp7e6soyi7ne?sr=0-4&ref_=beagle&applicationId=AWSMPContessa * > Somebody is offering a free GPU Virtualization (multi tennancy) product. * >I've never seen or used this product, but it's relevant to our interest.