Hi, I think it is a basic need to have a health API for the microgateway. This is the pull model. If you take any container mgt system or any other system, to configure the health of the microgateway we need to provide an endpoint.
As explained above in the problem description, if the microgateway needs to connect to the external service, then we may need the push model as well. We can provide an extension point for the users to come up with their own implementation based on the external service. IMHO we may need to think about having both options in the microgateway. Thank you! On Tue, Feb 12, 2019 at 11:20 AM Bhathiya Jayasekara <bhath...@wso2.com> wrote: > Hi, > > This will be a good addition. I'm more into a push model because of the > scalable nature of that. > > I found this[1] interesting even though it's questionable what happens if > the agent stops responding. Maybe they have implemented a deadman's > switch[2]. > > [1] https://github.com/hashicorp/consul/issues/2693#issuecomment-280095924 > [2] https://en.wikipedia.org/wiki/Dead_man%27s_switch > > Thanks, > Bhathiya > > On Tue, Feb 12, 2019 at 10:22 AM Tharindu Dharmarathna <tharin...@wso2.com> > wrote: > >> Hi Sanjeewa, >> >> The use of pull model it's the best model to operate since container >> system also supports to give availability from health check api. >> >> Configure outside system inside gateway is tricky as we locked down the >> outside system can't be change with the time . ( Different load >> balancers,etc.). >> >> On Thursday, February 7, 2019, Sanjeewa Malalgoda <sanje...@wso2.com> >> wrote: >> >>> Hi All, >>> When we deploy API micro-gateway without complete container management >>> system we do not have way to track all running instance details from >>> central place. Sometimes all the deployments will not have enough resources >>> to deploy container management system. In that case if we have some >>> mechanism to run simple ballerina code within gateway itself that would be >>> helpful. If we have something like that then when server starts up it can >>> call some external service and confirm gateway existence. Also over the >>> time it can do periodic call to external system and update it with >>> aliveness. >>> We can implement this feature in different ways. Push model and pull >>> model both should work in this case. >>> >>> Pull Model - The external system can call some API and based on the >>> response trigger an action. In this case external system need to know IP >>> address and port of each micro-gateway running in system. If we have >>> controlled environment with fixed known number of gateways this will be >>> good option. >>> Push model - The external system opens some API to call to do an action. >>> So in this case micro-gateway will call external and update about its >>> aliveness. Advantage with this approach is central system do not need to >>> know anything about gateways and running locations. We can start gateways >>> anywhere and they will inform status to central system. >>> >>> In this case external system can be some monitoring tool, control point, >>> service registry, management server or anything like that. We can see >>> use-cases related to each of these. Having generic support with extension >>> capability would be much useful here. >>> Shall we let users to engage some kind of ballerina file when generate >>> microgateway artifact? So when gateway runs it will call some init function >>> and it can do some background work while gateway running. This capability >>> will help us to do some additional stuff when we implement solutions. As >>> example we can think of generating UUID during server startup and send it >>> to some external system for tracking purpose. >>> >>> Thanks, >>> sanjeewa. >>> >>> -- >>> *Sanjeewa Malalgoda* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger >>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>> <https://medium.com/@sanjeewa190> >>> >>> GET INTEGRATION AGILE <https://wso2.com/signature> >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> >> *Tharindu Dharmarathna*Associate Technical Lead >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: *+94779109091* >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Bhathiya Jayasekara* > *Technical Lead,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > *Phone: +94715478185* > *LinkedIn: http://www.linkedin.com/in/bhathiyaj > <http://www.linkedin.com/in/bhathiyaj>* > *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* > *Blog: http://movingaheadblog.blogspot.com > <http://movingaheadblog.blogspot.com/>* > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Associate Technical Lead WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
