Cost of plugins pipelines - Serverless plugin in production ?

[arnauddeman]

Hi,
In our project, for some specific externs services, we will have a service catalog which will provide information on the upstream service to use for a given user.
I created a POC that uses these plugins:

• Openid-connect: checks the access token,
• Serverless pre-function: queries the service catalog and sets variables for upstream and access point,
• Traffic split: select the upstream,
• Proxy Rewrite: Sets endpoint.

It works fine, but I wonder about the cost of such pipelines and especially the serverless one (regardless of the function itself).

Thanks in advance !

[nfrankel]

I'd personally avoid traffic-split because it's not designed with that in mind.

However, are you aware that you can define multiple routes, define an additional check in addition to the usual domain/URI/method, and APISIX will try them them in order and forward to the first match found.

Here's an example using an HTTP header:

routes:
  - uri: /thingies*
    name: Europe
    upstream_id: 1
    vars: [["http_x-country", "==", "fr"]]
    priority: 3
  - uri: /thingies*
    name: USA
    upstream_id: 2
    vars: [["http_x-country", "==", "us"]]
    priority: 2
  - uri: /thingies*
    name: default
    upstream_id: 1
    priority: 1

APISIX will try to match the route Europe, which has a priority 3; it matches if there's an HTTP Header X-Country: fr. It will then try the USA route, which matches if there's an HTTP Header X-Country: en. If none matches, it defaults to the default route that has no additional check.

You can use any NGINX variable, not only HTTP headers (cookies, etc.).

[arnauddeman]

Thanks very much for your answer,
The difficulty here is that the headers are set by the route itself via the serverless pre-function plugin. The plugin interact with a catalog service which gives the upstream and uri to use for a specific user.
For instance, user1 will be associated to https://backend.univ1.fr/anURI and user2 to https://backend.univ2.fr/anotherDifferentURI.

Could you explain why the traffic split plugin is not adapted here ? In its description, it is said that "it can be used to dynamically direct portions of traffic to various Upstream services".
Sorry if it is obvious, I am quite new to Apisix :)

[nfrankel]

Could you explain why the traffic split plugin is not adapted here ? In its description, it is said that "it can be used to dynamically direct portions of traffic to various Upstream services".
Sorry if it is obvious, I am quite new to Apisix :)

IMHO, the traffic-split plugin is for random forwarding. If you already know the population, it's much better to use my way.

The plugin interact with a catalog service which gives the upstream and uri to use for a specific user.

Do I understand correctly that the forwarding logic is outside of APISIX, i.e., in the catalog service?

In this case, indeed, you'll incur additional performance hits, not because of the pipeline in itself but because of the extra query. It would be much better to let APISIX manage the forwarding data. If you can't, I suggest that you manage a local cache, so you query the catalog only on the first request. Even better, you could pre-warm the cache.

Unfortunately, at this point, it goes well beyond APISIX and is about system architecture: options are infinite, it all depends on your requirements and your budget.