Hi Pubudu, On Tue, Feb 12, 2019 at 12:01 PM Pubudu Gunatilaka <[email protected]> wrote:
> 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. > Yes, we need this anyway. My above response was about if we're going to have our own external service, the push model will be more scalable and simple. Thanks, Bhathiya > > 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 <[email protected]> > 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 < >> [email protected]> 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 <[email protected]> >>> 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) [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 >>>> >>> >>> >>> -- >>> >>> *Tharindu Dharmarathna*Associate 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 >>> >> >> >> -- >> *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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
