In the previous post, we dissected the concept of API gateways by outlining what sort of challenges API gateways can solve and some shortcomings. Overall, the API gateways do add something to the table – however, it needs to be used in more efficient ways to support fast-paced DevOps teams. So, let’s continue by investigating different approaches organizations can take to simply make the enterprise API gateway more accessible.
Need for a flexible access control model
Before we should even consider allowing outside teams access to the API gateway, the API gateway must support being configured to function like a multi-tenant SaaS solution. We essentially need to carve out a piece of the central API gateway for use by a dedicated team, where the team is given isolated access for creating and managing proxies, transformations, and other building pieces as deemed necessary, all owned and operated by the team.
For this option to work, the API gateway must have flexible support for the notion of teams in their underlying access control model. We are seeing more API gateway options that support the notion of teams but it is still quite common that API gateways rely on an access control model based on the assumption that a single team will manage all the development, and another team all the administration.
API gateway developer skills != Traditional software developer skills
Moving on, assuming it would be possible to isolate access based on the notion of distinct teams, then the next concern would be competence requirements for building and managing proxies in the API gateway. Even though modern API gateways support many commonly available programming languages for use in proxies to process requests, developers new to distributed systems may fail to recognize fundamental differences compared to traditional software development that influences design decisions. Before being able to contribute, the developer probably also has to learn about new features and concepts – all together, may simply result in an overwhelming experience, making the competence entry step to the platform somewhat high.
However, any skill can be learned with proper training, hence the takeaway is rather to acknowledge the difference in API gateway skills compared to traditional application development skills and plan for training before granting individuals access to the platform. This is a very important concern, especially if the team would be responsible for operating API artifacts in a production environment.
Quality assured API gateway building blocks
Consistency is another challenge that needs to be addressed. Essentially, platform foundational challenges such as logging, error-handling, and security flows should be addressed in standardized ways to increase the manageability of the platform as a whole – but also to provide a consistent developer experience (from the perspective of an API consumer), e.g. the structure of error messages thrown by one API should not differ compared to the structure of error messages thrown by another API.
What sets a seasoned developer apart from a rookie one, is that the seasoned developer can build implementations that work on a rainy day – i.e. when things go wrong. However, not all organizations have access to experienced API gateway developers, yet as a consequence of a distributed application development model, each DevOps team must know all it takes to fully manage their application – and if an API gateway is within the scope of their application, it means that the team must gain skills in developing and managing API gateway runtime artifacts.
However, due to its specialized nature, a supply of API Gateway skills may be scarce and then the organization is faced with the challenge of organizational learning – a challenge of leveling up the API gateway skills. But training takes time and focus away from other duties, hence there is a need to reach a level which is regarded as sufficient for contributing – but no more.
To provide guardrails for new API gateway developers, a dedicated team of API gateway specialists should be responsible for providing and managing shared building blocks for the API gateway. New API gateway developers can incorporate these building blocks into their API gateway designs, then fundamental parts of the design get automatically quality assured – enabling individuals without extensive experience to build high-quality API gateway proxies.
As a complement to quality-assured shared building blocks, a design improvement function could be provided as well – where API gateway experts review and help improve design proposals early on in the development phases where major re-designs to the solution proposal can be archived without causing ripples on the water.
Summary
Outside teams could be granted development and operations access to their own isolated bubble within the central API gateway assuming the access control model of the API gateway supports restricting access based on the notion of teams.
Specialized skill is often required to contribute to a sophisticated platform such as an API gateway. Any skill can be taught but expect it to deviate in significant ways from the skillset held by traditional software developer roles. Plan for training in advance and appoint a highly specialized team of API gateway platform experts tasked with designing quality-assured building blocks aimed at leveling up solution designs produced by less experienced API gateway developers.
Also, consider employing a solution design improvement service for helping new API gateway developers get their solution design right before it gets expensive to change fundamental aspects of the design.
