What is the purpose of Edge Microgateway-aware proxies?

mail-2
Participant IV

From reading What you need to know about Edge Microgateway-aware proxies it's not clear to me what the purpose is of MGW-aware proxies.

Can somebody explain what they are needed/used for?

Solved Solved
0 5 469
1 ACCEPTED SOLUTION

The EMG aware proxies are used for 2 purposes:

  1. This is where you specify the basepath, and the target server to be protected by microgateway. When microgateway receives a request, it will apply its configured policies (eg: verify api key and apply quota) and if the request basepath matches the one defined in an EMG aware proxy it will then forward the request to the target endpoint specified in that EMG aware proxy
  2. You can define products for the microgateway using the EMG aware proxy. So, for instance, if you want a backend to be protected by a quota policy, you can define a product using its EMG aware proxy, and include a quota configuration. This it what microgateway will use when checking quotas

View solution in original post

5 REPLIES 5

Not applicable

When you want to setup apigee and the backend service in the same infrastructure, you can install a message processor with target. It will allow you to add some security, analytics, traffic plugins that you can use in the service. It helps in avoiding latency as well.

You can say a small apigee setup for one service. You will get analytics from apigee edge, where as you will have separate message processor dedicated for your service.

The EMG aware proxies are used for 2 purposes:

  1. This is where you specify the basepath, and the target server to be protected by microgateway. When microgateway receives a request, it will apply its configured policies (eg: verify api key and apply quota) and if the request basepath matches the one defined in an EMG aware proxy it will then forward the request to the target endpoint specified in that EMG aware proxy
  2. You can define products for the microgateway using the EMG aware proxy. So, for instance, if you want a backend to be protected by a quota policy, you can define a product using its EMG aware proxy, and include a quota configuration. This it what microgateway will use when checking quotas

I already read this but at the risk of sounding stupid - I do not understand what this is supposed to mean. I cannot really put my finger on a specific point of unclearness as the entire presentation of the MGW and its relation/differentiation to Apigee Hybrid as well as MGW-aware proxies vs regular proxies is very much not comprehendable for me.

Ok. So we need to take this conversation to a higher level.

In a nutshell, Apigee hybrid lets you deploy a fully fledged API runtime close to your backends, on-prem or in your private cloud.

From the point of view of the API developer, protecting a backend service with an API proxy looks almost the same as in Apigee SaaS. You use Apigee UI, specify the proxy basepath (where the proxy will be found), specify the target endpoint (the backend service the API proxy will connect to), drag and drop policies, and when you're ready you click a deploy button to deploy your API proxy to the hybrid runtime.

Apigee microgateway is a lightweight API runtime, with limited features (eg: api key verification, quota checking, analytics).

From the point of view of the API developer, protecting a backend service with an API proxy is a very different experience: First configure the polices to be applied by editing a configuration file in the microgateway (essentially turning on or off the supported features), and then configure basepath and target endpoint by creating an EMG aware proxy in the Apigee UI and deploying it (Note that the role of the EMG aware proxy is just a placeholder for the API running on EMG. . When EMG starts up it talks to Apigee UI and downloads its configuration; analytics about the EMG API are reported under the EMG aware proxy name.)

So, a priori, Apigee hybrid is a superior solution, it provides a full featured API gateway and development experience is great. However the hybrid runtime footprint is vastly bigger than EMG (a Kubernetes based deployment vs a lightweight node.js application).

If you need simple API runtime features, EMG might be a better choice from the point of view of operational overhead/resource requirements.

Finally, and not in the spirit of confusing you more, if you're evaluating Microgateway, I suggest you also look at the Apigee Adapter for Envoy. Feature wise is very similar to Microgateway, but it is based on a more modern architecture -and doesn't require EMG aware proxies 🙂

Thanks, that definitely clarified a couple things. The last paragraph is interesting b/c then AAfE seems to be another competing product - if that is true, then that name is an utterly terrible choice. Also it sounds as if MGW is deprecated in favor of AAfE. Apparently AAfE reached its version #1 less than two weeks ago.