How you structure your teams when managing your APIs can have major implications on everything from cost to how customisable your environments are. With Tyk Cloud, you can use role-based access control (RBAC) to manage your team structure, as well as multiple environments and multiple organisations. So, which should you choose?
The case for RBAC
Role-based access control is a mechanism that enables fine-grained access control. You can assign permissions to users that ensure they only have very specific access to the Tyk dashboard pages and the underlying APIs. Users can have ‘read only’ or ‘write access’ to their chosen areas, from analytics to API configuration.
RBAC API ownership allows the segregation of multiple teams within your organisation. Your teams can collaborate safely and securely by accessing only the features that each user profile needs. This is ideal for large, multi-disciplinary teams and a cost-effective way of structuring your teams.
Why choose multiple environments?
For some businesses, RBAC alone isn’t enough; this is where a multiple-environment structure comes in.
With multiple environments, you can provide absolute segregation between your teams. Each environment consists of a control plane and connected gateways. You decide which teams access which environments. Simple, clear, and efficient. You can then implement RBAC within each of your environments.
Multiple environments are ideal for organisations under strict regulatory and compliance requirements. You can also model them based on the software development lifecycle, for example, standing up three separate environments to cover development, testing and production. Or, if budget permits, you could stand up five environments, including staging and user testing. This supports a very structured approach to software development.
Which structure do you need?
One major attraction of multiple environments is that you can deeply customise each environment, and each team can fully control its allocated environment. With RBAC API ownership, on the other hand, when you make a change that impacts one user or team of users, it could also affect others. For example, if you want separate developer portals, you’ll need to opt for a multi-environment structure.
As mentioned briefly above, multiple environments are also ideal for highly regulated operations, as the distinct and separate environments make operational governance easier.
There’s also collaboration to consider. The RBAC approach makes the most sense if you want cross-team collaboration on the same platform while maintaining necessary visibility and access restrictions. With multiple environments, your teams can only collaborate across the different environments by setting up accounts in each environment, which is certainly not ideal.
Of course, the more environments you have, the greater your management overhead will be, which is another key consideration. Your infrastructure footprint will be much larger, and the standalone environments will consume more management time. If operating on a tight budget is your top priority, RBAC API ownership is likely the most straightforward and efficient solution to meet your needs.
A quick word on multiple organisations
If you’re mapping out the best structure for your business, it’s also worth considering the potential of multiple organisations. An organisation is a container for all your environments, control planes and edge gateways. You assign it a home region during setup, where all your data is stored.
This means you could set up one organisation containing multiple environments in one part of the world and another in a different region. As an organisation admin, you can then enjoy an overview of all your organisations, including handy stats and visibility of all your teams, deployments and environments.
Ready to get started?
If you’re feeling inspired in terms of structure and want to get started, why not trial Tyk Cloud? The five-week trial is completely free, with no credit card details required.
