History: Orchestrator
Preview of version: 41
WikiSuite Orchestrator
WikiSuite Orchestrator is to deploy, manage software, deploy data and configuration, 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 -> SaaS platform template | ||
| 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? We need to think of the "creep factor".
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
- To do things like this: https://www.siteground.com/blog/new-anti-bot-ai/
- 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
Backups
Automatic, Incremental, off-site and with some sort of test / alerting if something's not right (ex.: disk full)
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
- We are currently on https://github.com/wikisuite/
- Once we Address the software development use case (Phabricator vs Gitlab vs Tuleap vs Allura vs ...), we'll dogfood that and use Github as a mirror. This use case is not a high priority 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 and Competitive 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
- SaaS platform template
- Mist