There is a lot to consider when it comes to how best to structure your teams when managing your APIs. The right structure can save you time and money, with teams working efficiently to achieve what they need while you productise and monetise your APIs. The wrong structure can do the opposite.
There are several ways that you can work with teams when using Tyk. These include role-based access control (RBAC) API ownership and multiple organisations or environments, which we’ll explain below. Your choice will depend on your priorities, as each approach has advantages.
Let’s explore a few scenarios with Tyk Self-Managed to put this into context.
Structuring your teams with Tyk Self-Managed
There are two options with Tyk Self-Managed (on premise):
- A multi-data centre offering – an enterprise solution enabled by Tyk Multi Data Centre Bridge (Self managed MDCB)
- A single data centre offering – called “Tyk Self Managed”.
The multiple data centre approach
The multi-data centre offering is the logical choice if you want to structure your team. It enables you to create separate environments that different teams can own, using various worker data centres to meet various needs. Each worker data centre can contain one or more Tyk API Gateways and a Redis cluster.
This structure delivers complete segregation in terms of infrastructure and user access to the configuration but with management from a single control plane.
This approach means you don’t need multiple databases. You can create different environments – for example, team A, team B and team C– all managed through a single Tyk Dashboard. This is great if you want a few different environments for every team. Here’s why:
- You can run different versions of Tyk Gateways in the worker data centres, separate Redis resources and avoid sharing GWs resources with other teams
- Different teams own different data centres and avoid noisy neighbour problems, as there is no shared infrastructure in the data plane level
- A single control plane allows you to share the HA (a highly available and costly database) and the configuration dashboard.
The API ownership approach in Tyk Self-Managed
An alternative way to restrict access to API configurations and policies between users and teams is API ownership. This is where you define an API with a user or team owner using RBAC so that only that user or team can access that API.
Using this API ownership approach, other users won’t be able to see the API or use it in any policy. You can use Tyk Self-Managed to achieve this approach to segregation. It’s a cost-effective way to structure your teams efficiently, so if budget is your top priority, this is a great option.
Using API ownership capability means teams still share resources in the Redis cluster and the gateways. In this case, you have the noisy neighbour problem in which a particular team’s API can take a lot of resources (GWs or Redis) even till exhaustion or crash. Another problem is that every API update triggers a gateway reload; if you share gateways, every API that is not of your concern will make the gateway reboot.
To solve this, you can split the gateways in this deployment between teams so every team will have their gateway/s. This setup has a small footprint in terms of TCO and licence.
Multi-tenants approach with Tyk Self-Managed
Setting up RBAC using API ownership is cumbersome when you have many teams. Also, some dashboard screens are shared across teams by design. To deal with this, you can create multiple organisations in the Tyk Dashboard, an org per team. This means that teams won’t be able to see or access other teams’ configurations.
Here, you can also split the gateways between the orgs you created in Tyk Dashboard (org per real-life team) to avoid the noisy neighbour problem while saving on infra (since you use shared configuration using the same dashboard).
The multi-tenant approach with MDCB
Say you have two teams that need development environments in the US and EMEA. There needs to be more than the multi-tenant approach using Tyk Self-Managed since it’s in a single data centre.
With the MDCB solution, you can set up a local gateway cluster per team within their geographic location. We call it a “worker data centre, ” essentially the data plane. In this setup, every worker cluster belongs to a single Tyk org. The same org can have multiple worker data centres, such as the team’s dev1 and dev2 environments. You should only use one org in a single-worker data centre.
Using this approach, both organisations will be defined in the control plane, and both will have all the data in that control plane. This means they will share the same infrastructure in terms of configuration and management but with traffic processed by different worker data centres, with other infrastructures and specs and different teams using each organisation (and potentially each environment).
Data governance
The multiple environments and the organisation approaches described above use Tyk’s multi-data centre offering. This comes with an added benefit in data governance, as each worker data centre processes traffic without data or traffic leaving that data centre. As such, if a worker data centre is in a country with restrictions around data movement, this is a great way to ensure everything stays within that country. You can even keep your analytics within that data centre by using Tyk’s Hybrid Pump, which will send traffic wherever you need it from that specific data centre.
Time to try it out?
If you’re feeling fired up and ready to implement the ideal structure for efficient, cost-effective API management for your business, why not try Tyk Self-Managed? It’s free for 14 days with no credit card required, so you can get to grips with creating the perfect structure for your teams.
