[Microgateway] Communicate with external system during microgateway startup and while running

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Microgateway] Communicate with external system during microgateway startup and while running

Sanjeewa Malalgoda
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) [hidden email] | (b) Blogger, Medium

Integration Agility for Digitally Driven Business

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Microgateway] Communicate with external system during microgateway startup and while running

tharindu1st
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 <[hidden email]> 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) [hidden email] | (b) Blogger, Medium

Integration Agility for Digitally Driven Business


--
Tharindu Dharmarathna
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94779109091


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Tharindu Dharmarathna
Associate Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94779109091
Reply | Threaded
Open this post in threaded view
|

Re: [Microgateway] Communicate with external system during microgateway startup and while running

Bhathiya Jayasekara
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

Thanks,
Bhathiya

On Tue, Feb 12, 2019 at 10:22 AM Tharindu Dharmarathna <[hidden email]> 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 <[hidden email]> 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) [hidden email] | (b) Blogger, Medium

Integration Agility for Digitally Driven Business


--
Tharindu Dharmarathna
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94779109091

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhathiya Jayasekara
Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Microgateway] Communicate with external system during microgateway startup and while running

Pubudu Gunatilaka-2
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 <[hidden email]> 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

Thanks,
Bhathiya

On Tue, Feb 12, 2019 at 10:22 AM Tharindu Dharmarathna <[hidden email]> 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 <[hidden email]> 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) [hidden email] | (b) Blogger, Medium

Integration Agility for Digitally Driven Business


--
Tharindu Dharmarathna
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94779109091

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhathiya Jayasekara
Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185
_______________________________________________
Architecture mailing list
[hidden email]
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 : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Microgateway] Communicate with external system during microgateway startup and while running

Bhathiya Jayasekara
Hi Pubudu,

On Tue, Feb 12, 2019 at 12:01 PM Pubudu Gunatilaka <[hidden email]> 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 <[hidden email]> 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

Thanks,
Bhathiya

On Tue, Feb 12, 2019 at 10:22 AM Tharindu Dharmarathna <[hidden email]> 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 <[hidden email]> 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) [hidden email] | (b) Blogger, Medium

Integration Agility for Digitally Driven Business


--
Tharindu Dharmarathna
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94779109091

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhathiya Jayasekara
Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185
_______________________________________________
Architecture mailing list
[hidden email]
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 : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhathiya Jayasekara
Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Microgateway] Communicate with external system during microgateway startup and while running

Shani Ranasinghe
This pull method is to monitor aliveness?  Push will be needed to check the readiness of the service (Something similar to Kubernetes readiness probe)?

On Tue, Feb 12, 2019 at 12:25 PM Bhathiya Jayasekara <[hidden email]> wrote:
Hi Pubudu,

On Tue, Feb 12, 2019 at 12:01 PM Pubudu Gunatilaka <[hidden email]> 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 <[hidden email]> 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

Thanks,
Bhathiya

On Tue, Feb 12, 2019 at 10:22 AM Tharindu Dharmarathna <[hidden email]> 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 <[hidden email]> 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) [hidden email] | (b) Blogger, Medium

Integration Agility for Digitally Driven Business


--
Tharindu Dharmarathna
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94779109091

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhathiya Jayasekara
Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185
_______________________________________________
Architecture mailing list
[hidden email]
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 : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhathiya Jayasekara
Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Thanks and Regards,
Shani Ranasinghe | Associate Lead - Technical Writer | WSO2 Inc
(M) +94 772 273 555 | (E) [hidden email]





_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture