Scaling a Cribl.Cloud deployment - To workspace or not to workspace?
When growing a Cribl deployment you may encounter a situation where some new people need to use Cribl. This can arise from new business units engaging, new subsidiaries or an international expansion. At this point, the current team needs to decide how to support this. Would a new workspace be best or would a dedicated Stream Worker Group/Cribl Edge Fleet be sufficient?
In this article, I’ll explain the trade offs involved in each choice and when one might be best for you.
Cribl.Cloud Workspaces
A Cribl.Cloud Organization consists of one or more Workspaces. Each Cribl.Cloud Workspace has its own isolated components and logical groups. The Leader nodes are different, the ingestion points are different, the compute resources are different, the Cribl products are different and the access permissions are different.
In fact, Workspaces are so different, there’s only a few common Organization settings to consider. The commonality in the management plane covers APIs, SSO, FinOps and Member management.
📚 If you’d like to learn more about permissions in Cribl Cloud, please read this guide which goes into greater depth about this: https://knowledge.cribl.io/other-guides-84/permissions-overview-in-cribl-cloud-1778
Cloud Organizations can have up to three Workspaces included as part of an Enterprise plan. Note that additional Workspaces beyond this will incur an additional credit cost.
Separating access by Group/Fleet
Within Cribl Stream, access can be managed at the Worker Group level. This is mirrored in Cribl Edge at the Fleet level. Both Groups and Fleets are logical groupings of devices that each share a common configuration and purpose.
⚠️ Permission management for Edge Fleets must be applied at the top level rather than a subfleet.
It’s possible to grant access solely to a single worker group. Under this approach a Cribl Workspace admin would give worker group level admin access to a new Team.
Let’s say we’ve got Team “SubsidaryA” and we give them access to the worker group “ProductionEU”. Members of the SubsidiaryA team can interact with this worker group and perform their normal roles. They can grow and shrink the group, add new pipelines, monitor performance and generally happily oversee the elements of the Cribl deployment they care about.
This component level access can be extended into Cribl Search and Cribl Lake by applying the same logic. A Team can be given scoped access to only the components they need to manage or control.
Why are Workspace divisions valuable?
Workspace divisions are best when the following conditions are met:
1. There is a need for a new regional control plane.
When you create a Workspace, you can choose the region it's created in. This means a new Workspace presents a useful option if compliance or contractual requirements wish for more control plane traffic to remain in a specific area.
2. The team using the new Workspace will be using most or all of the Cribl Products.
As each Workspace contains all the Cribl Product suite, these high level divisions are best when separation is required for each. For example the team wishes to use their own Cribl Lake instances, run their own Search loads and manage their own collection layers.
3. The team is sufficiently skilled at using Cribl and will take on continued responsibilities.
A Workspace is like a garden - It does require some care! If a team isn’t willing or able to support one, other operating models may be better.
Why are Worker Group or Fleet divisions better?
The other division option is at the component layer (Group/Fleets/Datasets). This is a good option for the following conditions relating to the incoming new team:
1. The team’s requirements are straightforward.
If a requirement is a simple collection and routing use case, then having extra components is superfluous. If a requirement only needs a single Cribl product, a workspace division would be excessive with extra costs and overheads.
2. The team trusts the existing Cribl administrators.
As the new team will only have a small bit of visibility into the wider Cribl deployment, they need to trust the incumbent administrators will provide support, guidance and stewardship. This works well when an existing team has a proven Cribl deployment and is seeking to support a newer function.
3. The team lacks Cribl skills and/or cannot take on full responsibilities.
If the new team to Cribl is unfamiliar with the whole capabilities of Cribl.Cloud, why add the extra complexity? A single group is a manageable introduction which can be supported easily with a tiny or part time team.
Conclusion
I hope this helps you with your discussions about scaling Cribl.Cloud. As with all things Cribl, choice remains our key watchword! There’s no reason why you must pick one option and circumstances will be unique to your needs and objectives.
If you ever need more tailored advice, please get in touch with your Cribl account team and they’ll be happy to help.