search

threefoldtech / home

Starting point for the threefoldtech organization
https://threefold.io
Apache License 2.0
9 stars 4 forks source link

Create a commercial service provider based on TF Grid by using weblet deployments #1378

Closed weynandkuijpers closed 9 months ago

weynandkuijpers commented 1 year ago

Create a commercial service provider business

Purpose

To prove that the current state of the TF grid is enough to start a commercial business on. The current TF technology stack is a good set of building blocks to create a service business on. While proving this by doing it we also create content that explains in steps how to use the technical building blocks and put it all together into a full fledged solution.

Outcome

Initial service roadmap:

Type Name Phase Product description
Social services
Mastodon 1
Mattermost 2
Discourse 2
Peertube 2
Wordpress 2
Funkwhale 2
Workplace
Jitsi 1 #1380
Taiga 2
Gitea 2
Developer
Full VM 1
Micro VM 1
Kubernetes 1
Caprover 1
Node Pilot 2
Quantum Safe Storage 2
Media
Plex Media Server Option
Other
Presearch 1
Owncloud (instant dropbox alternative) 1

In the table we're aiming to have only less than 10 initial services to launch with, of which 80% should be already exists today. The focus and effort needed should be around storing the provisioning and customization information backup.

Requirements

Outcome

The outcome for this service provider creation is as follows:

Planning

Architecture

The problem with a FIAT (only) model is how do we create a unique identity and remember / store / create an access method to it. Few options:

Initial though is to create a wallet per individual, have them keep / remember a created mnemonic. Very similar to what we have today for the twitter alternative (mastodon) . That covers the "remember" who you are part, but not the pay in fiat part.

Architecture diagram (DRAFT)

graph LR

subgraph Payment Provider

   paymentProcessing -->|Customer paid checked| servicePortal
end

subgraph Cloud Market
   customer[Customer] -->|Fiat payment| paymentProcessing[Payment Engine]
end 

paymentProcessing --> bank[Bank account]

subgraph TF Grid
   tfGrid[TF Grid Nodes]
   tfGridWallet[TF Grid Wallet]
end

subgraph Service Provider
   bank
   servicePortal -->|payment instruction| serviceWallet[Wallet]
   servicePortal -->|smart contract| provisioningEngine
   serviceWallet -->|Token payment| tfGridWallet
   tfGridWallet -->|Channel token payment| serviceWallet 
   provisioningEngine[Provisioning Engine]
   provisioningEngine -->|deployment instruction| tfGrid
   servicePortal -->|Account information| customer

end
sasha-astiadi commented 1 year ago

challenges / tbd:

to research: benchmark analysis . competitors

samtaggart commented 1 year ago

Mik had a good point about offering an end-user storage system using QSFS, can we add that in? Probably a bigger lift but we can put it on the roadmap.

weynandkuijpers commented 1 year ago

Done, embedded in the roadmap.

Mik-TF commented 1 year ago

Excellent!

In the social services section of the table, peertube is there two times. We could remove one. (I can't edit the post so I write it here.)

Another project we could add:

scottyeager commented 1 year ago

Some ideas and inputs :)

Backups

Users of modern cloud services will generally operate under the assumption that data can never be lost. Furthermore, recovering from even a temporary node outage will require that all data can be reconstructed. Restoring a Gitea or Taiga instance with the users configuration but lacking all the stories and code, for example, is a total failure from the perspective of the user.

"Backups" in the cloud context usually refers to the ability to restore some previous state (whoops I deleted all my WordPress posts), rather than an ability to recover from infrastructure failures (whoops my host needed to perform a routine replacement of the single disk my data was solely stored on). Providing users with an opt in backup feature at additional cost seems likely to me to create bad user experiences if (when) they would need the backup.

The only exception I see would be the "developer" focused category, where backups would be a more complicated matter anyway (much easier to identify and target user data in a known application than an arbitrary VM).

Example pricing analysis: Jitsi #1380

More to come, I'm sure, but that's all for now.

weynandkuijpers commented 1 year ago

Another project we could add:

* provide compute+network to run APIs like the telegram bot and/or AI/ML workloads, like https://www.huggingface.co does

What do you think warrents this a seperate category and does not make it part of "Full VM". Do you consider this to be something that can be replicated for many things (many bots or many API's?).

Mik-TF commented 1 year ago

It might not need a separate category. Good point.

But I was thinking that we could offer a general service where users can try and use different kind of bots and APIs, for specific uses. So, different enterprises would propose different features. The workloads of bots and AI/ML would run on the TF Grid, via Planetary Network when possible, the scripts could be hosted on Github and/or the TF hub.

Users could have the possibility to deploy bots that run on 3nodes. They can write the code on the platform, it gets saved into storage on Github or the TF hub, and the compute of the bots is done by a 3node through the TF Grid.

So for example, a one-click solution to host Telegram bots. You only need to pay X$ per month, the user gives the telegram bot token, and they can run the bot. They can either write the scripts, or simple scripts/bots could be proposed. Also, we note that bots would be using AI/ML in their codes.

The bot's script can be taken from Github or the TF hub, for example, so the 3node runs the script, and if it ever fails, another 3node can simply rerun the script. This is an idea to use mostly the compute capacity, and going over the fact that we can't have "self-healing" compute as we do with QSFS and storage. The compute is centralized on only one 3node at a time. The code is stored and available on Github or TF hub.

On the AI/ML workloads side, it could be done in many ways. For example, we can host standard and mainstream AI for people to use. We can have advanced linguistic translators, text generators, question-answering bots, etc. Each enterprise would focus on one aspect or a group of related features, but all those enterprises could be based on the same basic model, for ease of expansion and development.

This might have some similarities with projects like https://colab.research.google.com/.

Mik-TF commented 1 year ago

How far are we from not solely hosting Wordpress, but offering the standard features of web hosting, like Bluehost does for example?

What we could offer:

Mik-TF commented 1 year ago

As talked with Scott, we could offer some sort of streaming solution, like Plex. If that fits, it could be added on the list. we might need to figure out some details about how we would be doing this.

samtaggart commented 1 year ago

@xmonader @rkhamis Can we get some feedback on this issue and the comments to understand recommended rollout, what's done & what needs to be done, etc. Then we can create and move on an execution plan.

Mik-TF commented 1 year ago

TF Meeting 31-01-23: Commercial Services

Attendees

Main Content Discussed: TF Commercial Services

The meeting was very fruitful and we state here what has been talked in a point-format. This constitutes the basic elements of the project and its parameters.