If we think current solution we proposed for container based deployment
without this hot pool concept still we may need some intelligence at load
balancer level. Isn't it?

Let say i send request to gateway.sanjeewa.info.wso2.com.
Then load balancer should this request comes to gateway. Then tenant is
Then only it can handle request properly and send correct node.

Without that capability how should we handle fully automated deployment?
Did i missed something here?


On Tue, Oct 11, 2016 at 2:24 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> On Mon, Oct 10, 2016 at 8:01 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>> When we do container based deployment standard approach we discussed so
>> far was,
>>    - At the first request check the tenant and service from URL and do
>>    lookup for running instances.
>>    - If matching instance available route traffic to that.
>>    - Else spawn new instance using template(or image).  When we spawn
>>    this new instance we need to let it know what is the current tenant and
>>    data sources, configurations it should use.
>>    - Then route requests to new node.
>>    - After some idle time this instance may terminate.
>> ​If we were to do this with a container cluster manager, I think we would
> need to implement a custom scheduler (an entity similar to HPA in K8S) to
> handle the orchestration process properly. Otherwise it would be difficult
> to use the built-in orchestration features such as auto-healing and
> autoscaling with this feature.
> By saying that this might be a feature which should be implemented at the
> container cluster manager.
> *Suggestion*
>> If we maintain hot pool(started and ready to serve requests) of servers
>> for each server type(API Gateway, Identity Server etc) then we can cutoff
>> server startup time + IaaS level spawn time from above process. Then when
>> requests comes to wso2.com tenants API Gateway we can pick instance from
>> gateway instance pool and set wso2.com tenant context and data source
>> using service call(assuming setting context and configurations is much
>> faster).
> ​I think with this approach tenant isolation will become a problem. It
> would be ideal to use tenancy features at the container cluster manager
> level. For an example namespaces in K8S.
> Thanks
>> *Implementation*
>> For this we need to implement some plug-in to instance spawn process.
>> Then instead of spawning new instance it will pick one instance from the
>> pool and configure it to behave as specific tenant.
>> For this each instance running in pool can open up port, so load balancer
>> or scaling component can call it and tell what is the tenant and
>> configurations.
>> Once it configured server close that configuration port and start traffic
>> serving.
>> After some idle time this instance may terminate.
>> This approach will help us if we met following condition.
>> (Instance loading time + Server startup time + Server Lookup) *>*
>> (Server Lookup + Loading configuration and tenant of running server from
>> external call)
>> Any thoughts on this?
>> Thanks,
>> sanjeewa.
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware


*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

Architecture mailing list

Reply via email to