Hi Tharindu, Thank you for providing detailed clarifications.
In that case, will the adaptor components bundle into the Gateways or the Control Plane instances? Will this design consider the aspects of supporting the gateways of older versions such as supporting the Synapse Gateway from the version 3.2.0? Regards, Firzhan email: [email protected] mobile: (+61) 40 177 5941*| blog: *https://medium.com/@firzhan *twitter: https://twitter.com/firzhan007 <https://twitter.com/firzhan007> | linked-in: **https://www.linkedin.com/in/firzhan <https://www.linkedin.com/in/firzhan>* On Tue, Nov 24, 2020 at 10:47 PM Tharindu Dharmarathna <[email protected]> wrote: > Hi Firzan, > > Please find my comments below. > > > On Mon, Nov 23, 2020 at 2:39 PM Firzhan Naqash <[email protected]> wrote: > >> >> Hi Sanjeewa, >> >> When it comes to hybrid deployment i guess publisher and TM both will >>> reside on cloud. In that case we will need to use an adapter for onprem >>> deployment to connect with cloud. >>> Considering that we can draw the same with the adapter. Adapters can be >>> gateway type specific but always need to communicate with traffic managers >>> using the same protocol. >>> Adapter to gateway communication can be selected based on the gateway >>> type(xds for envoy etc). Default adapter which allows synapse gateway to >>> communicate with traffic manager can be built into traffic manager for >>> default cases. When hybrid mode used can be separated and brought into >>> onprem. So those who use all in one pack or having simple deployments won't >>> notice any complexity. Thoughts? >> >> >> Does this mean that the customers could have the flexibility to use the >> non-wso2 gateways along with our throttling functionality as well? >> > No, Currently we will not be going to support any non-wso2 gateways. > > Are we planning to provide the flexibility of choosing the adaptors from a >> dropdown or a configuration? >> > No. > >> In addition, I assume according to the proposed changes, we are moving >> away from immutable micro-gateway concept. >> > > Yes, We are moving away on immutable micro-gateway concept, after new > micro-gateway comes up it can connect into adaptor to retrieve artifacts to > deploy. > > >> >> Regards, >> Firzhan >> >> >> email: [email protected] >> mobile: (+61) 40 177 5941*| blog: *https://medium.com/@firzhan >> *twitter: https://twitter.com/firzhan007 >> <https://twitter.com/firzhan007> | linked-in: >> **https://www.linkedin.com/in/firzhan >> <https://www.linkedin.com/in/firzhan>* >> >> >> On Thu, Nov 19, 2020 at 9:14 PM Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> When it comes to hybrid deployment i guess publisher and TM both will >>> reside on cloud. In that case we will need to use an adapter for onprem >>> deployment to connect with cloud. >>> Considering that we can draw the same with the adapter. Adapters can be >>> gateway type specific but always need to communicate with traffic managers >>> using the same protocol. >>> Adapter to gateway communication can be selected based on the gateway >>> type(xds for envoy etc). Default adapter which allows synapse gateway to >>> communicate with traffic manager can be built into traffic manager for >>> default cases. When hybrid mode used can be separated and brought into >>> onprem. So those who use all in one pack or having simple deployments won't >>> notice any complexity. Thoughts? >>> >>> Thanks, >>> sanjeewa. >>> >>> >>> >>> >>> On Thu, Nov 19, 2020 at 3:25 PM Tharindu Dharmarathna < >>> [email protected]> wrote: >>> >>>> Hi All, >>>> >>>> Currently, WSO2 API Manager has the following two methods of deploying >>>> artifacts into the Gateway deployments. >>>> >>>> 1. Push API artifacts into Gateway nodes. >>>> 2. Pull Gateway Artifacts from Traffic Manager nodes based on the >>>> event. >>>> >>>> from the next APIM release, we will be going to remove the [1] option >>>> and we going to make [2] the way of deploying APIS. >>>> >>>> *Problems come in [2] architecture implemented.* >>>> 1. Introducing a new Gateway Type (Envoy Micro Gateway, etc) couldn't >>>> use existing event-based architecture since it handles only the synapse >>>> artifacts at the publisher end. >>>> >>>> *Solution* >>>> The following model going to be implemented based on the above points >>>> as discussed. >>>> >>>> [image: deployment.png] >>>> Your feedback on the above implementation is highly appreciated. >>>> >>>> Thanks >>>> >>>> *Tharindu Dharmarathna*Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: *+94779109091* >>>> >>> >>> >>> -- >>> *Sanjeewa Malalgoda* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 712933253 | (e) [email protected] | (b) Blogger >>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>> <https://medium.com/@sanjeewa190> >>> >>> GET INTEGRATION AGILE <https://wso2.com/signature> >>> Integration Agility for Digitally Driven Business >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> > > Thanks > > *Tharindu Dharmarathna*Technical Lead > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: *+94779109091* >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
