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
