Part 4 - API gateway details |
It started with laying out the process of how I've approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture. Now it's time to cover various architectural details.
This article takes you deeper in to specific elements (API management and reverse proxy) from the generic architectural overview.
Architectural details
This section covers the visual representations as presented, but it's expected that they'll be evolving visually over time. There are many ways to represent each element in this architecture, but I've chosen icons, text and colours that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this post, or contact me directly with your feedback.
Now let's take a look at the details in this architecture and outline the elements uncovered in my research.
API management
When looking at gateways in to an organization, it's split between managing your API access and hiding the actual landscape behind accessing services in your organization. The first element identified was a management platform for handling API gateway activities.
API management refers to how access is provided to an organization's services. It's the critical path for access internally to services as well as externally.
Researching customer portfolio solutions revealed that it's providing access to service interfaces, applications, and other integration microservices. It's providing scalability, reliability, and interface usage metrics that customer evaluate during operations monitoring.
In the generic architecture it's managing interfaces from:
The basic security is achieved through these proxies, because they are acting on requests from third parties. By retrieving requested resources for their clients, all external parties are prevented from having actual access to internal networks.
Interactions on behalf of their clients provides them access to the following microservices:
Researching customer portfolio solutions revealed that it's providing access to service interfaces, applications, and other integration microservices. It's providing scalability, reliability, and interface usage metrics that customer evaluate during operations monitoring.
In the generic architecture it's managing interfaces from:
- frontend microservices (providing access to internal integration microservices)
- process facade microservices (providing access to automated integration processes)
- other applications (providing access to aggregated microservices or other internal applications)
Reverse proxies
This covers various solutions found in research, but all are delivering the same functionality.Interactions on behalf of their clients provides them access to the following microservices:
- frontend microservices (providing access to internal integration microservices)
- process facade microservices (providing access to automated integration processes)
- other applications (providing access to aggregated microservices or other internal applications)
These details are not all knowing, but should give you the guidance you'd need to get started in your own architectural situations.
What's next
This overview covers the API and proxy elements that make up our architecture for the omnichannel customer experience use case.
- An introduction
- Generic common architectural elements
- External application details
- API management details
- Container platform essentials
- Storage services
- Example process integration
- Example mobile integration
- Example service integration