History: Orchestrator
Preview of version: 30
WikiSuite Orchestrator
WikiSuite Orchestrator is to deploy, manage, monitor, aggregate data from and handle billing for a large number of WikiSuite instances. Each instance is an autonomous virtual machine, and can be moved to a different physical server.
Status: planning phase
Who is this for?
| Who | Benefit / use case | ||
| Business incubators | Offer a platform to all your members, so they don't waste time / money on basic IT needs, and instead focus on their market differentiator | ||
| Enterprise and governments | Large organizations may want to have autonomous entities, either as a subdomain or a different domain name | ||
| Universities | Offer your professors and researchers secure collaboration spaces | ||
| Hosting companies | Offer usable and integrated software instead of "just hosting" | ||
| Specialized SaaS service provider | Ex.: a firm specialized in a vertical market like ISO compliance could deploy very focused WikiSuite instances for each project. To be combined with Tiki Profiles -> White-label SaaS platform | ||
| Consultants and digital agencies | Quickly set up an instance for a client project | ||
| FLOSS / digital autonomy promotion associations (ex.: Framasoft, FACIL, etc.) | Promote FLOSS in a more integrated fashion than the current Framasoft setup | ||
High-level features
Deploy
- On-demand deployment of virtual machines with WikiSuite fully configured.
Manage
Monitor
Aggregate
WikiSuite Orchestrator will permit to deploy hundreds of WikiSuite instances. But what if we want to benefit from network effects?
Use cases
- Gather logs
- For security purpose (ex.: attack logs)
- These security logs can be agregated and when bad behavior is detected for some of the instances, mitigation measures can be implemented for all instances.
- This is closely related to the FusionCenter project
- For security purpose (ex.: attack logs)
- Marketing
- Usage logs
- Community
Billing
The billing will typically be per instance, and per resources used (CPU, Disk space), regardless of the number of users
Tiki instance to manage
- Project / customer list
- Domain name (use own or a provided sub-domain)
- Access (passwords, public keys)
- Payment
- Monitoring? (probably better to handle from another system)
- Registration
- Launch request for services
Development
- Do we start on https://github.com/wikisuite/ ?
If some private repositories might be needed at some point (or you want the git web service inhouse, or behind proxy, or something), use https://gitlab.com/wikisuite instead (if still available)- Already got https://gitlab.com/u/WikiSuite
- We should address https://suite.tiki.org/Source+Control+Management one day, but I put later because 1- It's not a mainstream use case and 2- The options have quite a bit with overlap with Tiki functionality (task management, wiki, etc.)
Priorities
- Let's start with ClearOS (perhaps unregistered), Tiki and Openfire
- Then, the others
Brainstorming for the future
| What / where | Marketing | Security | Management |
| WikiSuite instances | Web Analytics | IDS data aggregation | ALM |
| Open Web | Media Intelligence | Gateway Antiphishing | n/a |
| Client devices | n/a | VPN | MDM |
https://en.wikipedia.org/wiki/Machine_learning
Related
- https://github.com/hslatman/awesome-threat-intelligence/blob/master/README.md
- How to build a system to demo WikiSuite
- White-label SaaS platform