Personas
Review the user personas that Gloo Mesh helps address.
The Gloo Mesh API v2 is designed for the following user personas.
Persona responsibilities
As you plan your Gloo Mesh environment, consider how the following user personas relate to your own organization. For example, your workload administrator might be the same person as your development team lead.
Meet Pam, the platform administrator. She sets up the environment, so she does a lot of heavy lifting in the beginning. After setup, she doesn’t worry much about day-to-day operations. But she is there when you need more clusters registered to the mesh or have a new team to onboard.
As the figure shows, her common tasks include:
- Creating or having admin access to clusters
- Installing Gloo Mesh in the management cluster and registering workload clusters
- Creating Gloo Mesh workspaces for each team in the right clusters and Kubernetes namespaces
- Creating a
globalworkspace settings to enforce certain default behavior across workspaces, like service isolation - Installing Istio in each cluster
- Helping onboard teams
Other typical job titles might be systems administrator, service mesh owner, or lead site reliability engineer.
Arjay, the app owner admin, picks up where Pam left off. He configures the workspace settings so that teams share their resources across workspaces. After the workspace settings are just right, he helps his development team deploy their apps. He’s a great person to ask if your developers aren’t sure where a resource belongs so that it’s available to other workspaces.
His common tasks are shown in the figure.
- Create the workspace setting
- In the workspace settings, import resources from other workspaces into this workspace
- In the workspace settings, export resources from this workspace to other workspaces
- Coordinate with other workspace admins and developers to make sure
importFrom,exportTo, and resource selectors are set up correctly - Help operators and developers label their resources so that they are automatically available for import and export
- Add virtual destinations if the app needs to be reached by apps that run in different clusters
- Add a virtual gateway if the workspace needs its own gateway
- Add external endpoints and services if the app runs outside the cluster
Other typical job titles might be lead developer, senior software engineer, or workspace administrator.
Oliver the operator sets up all those little details that make your service stay up and running. To do so, he configures networking and policy resources. He is an expert at knowing how to shape traffic to increase availability across clusters.
As the following figure shows, his common tasks include:
- Set up the virtual gateway for multicluster traffic
- Create policies for resilience, security, observability, and traffic control
- Work with developers to set up route tables to point to the right backing virtual destination, external service, or Kubernetes service
Other typical job titles might be network and security operations engineer, service operator, or site reliability engineer.
Alice is your app developer. She wants to deploy or update her app and make sure it’s serving on the right host paths as easily as possible. To do so, she can use a couple Gloo Mesh resources, but doesn’t need to worry about all of the policies. Instead, she can reuse what her operator and app owner set up for her.
Her common tasks are shown in the figure.
- Deploy or update a Kubernetes app, which includes the workload and service
- Update route tables to make sure that they point to the right backing virtual destination, external service, or Kubernetes service
- Create policies to test out the app before production, such as retries, timeouts, or custom Wasm deployments
Other typical job titles might be software engineer or microservice developer.
Review the following diagram to see all four of the personas together. This view can be helpful as a quick reference of what sorts of Gloo Mesh APIs different roles commonly need. To enlarge, click on the image.
Did you notice none of these personas need to be Istio experts? That is because Gloo Mesh automatically creates Istio resources for you. The following diagram shows some sample Istio resources that might be created.
Going forward, don’t edit Istio resources directly. Instead, update your Gloo Mesh resources. Then, Gloo Mesh automatically updates the Istio resources in the workspace across clusters.
Team organization
In your organization, the same person might have responsibilities from several of the Gloo Mesh personas. Similarly, you might have several teams that have many of these roles, such as in the following diagram.
In Gloo Mesh, you can create a workspace for each team. Then, you can configure the workspace settings to decide how to share resources across your teams. For more information, see Workspaces.
Example RBAC roles by persona
To learn more about how to control user access, see Kubernetes RBAC.
| Persona | Roles | Rationale |
|---|---|---|
| Pam, Platform Admin | The cluster-admin cluster role for all clusters in your setup. | To install Gloo Mesh Enterprise and Istio in each cluster. Also, to add users to the clusters. |
| Arjay, App Owner | The cluster-admin cluster role for the cluster or admin or edit role for the namespace that has the workspace settings resource. | To update the workspace settings to control importing and exporting. Also, to help manage any Gloo resources that the team wants to export or import. |
| Oliver, Operator | The admin or edit role for each namespace he is responsible for operating. | To create Gloo resources such as policies for the namespace. Consider giving the view role to the namespace with the workspace settings, so that the operator can review what resources are imported from other workspaces, if any. |
| Alice, App Developer | The edit role for each namespace where she needs to deploy her app. | To create Kubernetes resources such as a Deployment and Service, or Gloo resources such as a Route Table. Consider giving the view role to the namespace with the workspace settings, so that the developer can review what resources are imported from other workspaces, if any. |