My point is that for serverless architecture, if load balancer can deal with the "0" situation (no containers are running, requests come in, a container is spun up and gets the request), then 1 also works.
2 as the minimum for HA configuration is a good approach for the server-oriented model. On Wed, Nov 2, 2016 at 10:46 AM, Deependra Ariyadewa <[email protected]> wrote: > > > On Wed, Nov 2, 2016 at 10:22 PM, Dmitry Sotnikov <[email protected]> wrote: > >> Not for transactional stuff, right? If this is just a mediation or proxy >> service request and the host fails - the request would not automatically go >> to a second node anyway, right? >> > > Load balancer is the entry point to the Integration / AppCloud. If one > replica fails LB can route the request based on the liveness check. This > use case is valid for endpoint need high uptimes. > >> >> On Wed, Nov 2, 2016 at 9:41 AM, Deependra Ariyadewa <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Nov 2, 2016 at 9:48 PM, Dmitry Sotnikov <[email protected]> wrote: >>> >>>> Wouldn't minimum be set to 0 in true serverless experience? >>>> >>> >>> Yes, in the initial stage replica count should be 0 but in the running >>> state we have to have two copies of each instance to face server failures. >>> >>>> >>>> On Wed, Nov 2, 2016 at 9:16 AM, Deependra Ariyadewa <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Nov 2, 2016 at 1:04 PM, Kasun De Silva <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Past couple of days I was working on a POC for the $subject. >>>>>> >>>>>> Following is the current model that AppCloud use to create >>>>>> application / services. Basically for each application / service AppCloud >>>>>> will create a *Deployment >> ReplicaSet >> Pod* in Kubernetes >>>>>> cluster. At this point each ReplicaSet created has only one replica which >>>>>> is a Pod. This deployment does not scale up or scale down under any >>>>>> circumstances. >>>>>> >>>>>> This effort is to bring up a new feature to autoscale the application >>>>>> / service deployed in AppCloud according to certain metrics. >>>>>> >>>>>> Basically as usual AppCloud will create a *Deployment >> RS >> Pod* >>>>>> in Kubernetes for each application / service created as in above >>>>>> scenario. >>>>>> >>>>>> With the new feature, user can set auto-scaling parameters in the >>>>>> application settings level. We are using Kubernetes v1.3.4, and by >>>>>> default >>>>>> it accepts following parameters for *Horizontal Pod Autoscaler* >>>>>> (HPA). >>>>>> >>>>>> 1. Minimum # of pods >>>>>> 2. Maximum # of pods >>>>>> 3. Target CPU Utilization >>>>>> >>>>>> >>>>>> and the autoscaling logic will be following, >>>>>> >>>>>> TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) >>>>>> / TargetCPUUtilization) >>>>>> >>>>>> But target number of pods will be bounded by the values provided for >>>>>> the MinPods and MaxPods values. >>>>>> >>>>>> MinPods <= TargetNumOfPods <= MaxPods >>>>>> >>>>>> When user set the auto scale parameters AppCloud will basically >>>>>> create a Kubernetes HPA kind for the particular appllication / service >>>>>> version (This is on demand. we do not create an HPA kind for each >>>>>> application / service version that user creates.). So that HPA for that >>>>>> particular version will take responsibility of scaling up, scaling down >>>>>> of >>>>>> pods according to the given threshold. Following will be the model that >>>>>> we >>>>>> are using in Kubernetes with the autoscaling feature in AppCloud. >>>>>> >>>>> >>>>> In the server less paradigm user should get a simple application >>>>> creation user experience, therefore making the auto scaling feature as the >>>>> default behavior is a good option. Also we have to send the minimum pod >>>>> count to 2 to support node failures. >>>>> >>>>>> >>>>>> Your thoughts and comments are welcome on this. >>>>>> >>>>>> Thanks, >>>>>> Kasun >>>>>> >>>>>> -- >>>>>> *Kasun de Silva* >>>>>> Senior Software Engineer | Cloud TG >>>>>> >>>>>> WSO2 Inc <http://wso2.com>*. *|* E*mail : [email protected] | Mobile: +94 >>>>>> 77 794 4260 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Deependra Ariyadewa >>>>> WSO2, Inc. http://wso2.com/ http://wso2.org >>>>> >>>>> email [email protected]; cell +94 71 403 5996 ; >>>>> Blog http://risenfall.wordpress.com/ >>>>> PGP info: KeyID: 'DC627E6F' >>>>> >>>>> *WSO2 - Lean . Enterprise . Middleware* >>>>> >>>> >>>> >>>> >>>> -- >>>> Dmitry Sotnikov >>>> VP of Cloud; WSO2, Inc.; http://wso2.com/ >>>> email: [email protected]; cell: +1.949.303.9653; Skype: DSotnikov >>>> Lean . Enterprise . Middleware >>>> >>>> <http://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> Deependra Ariyadewa >>> WSO2, Inc. http://wso2.com/ http://wso2.org >>> >>> email [email protected]; cell +94 71 403 5996 ; >>> Blog http://risenfall.wordpress.com/ >>> PGP info: KeyID: 'DC627E6F' >>> >>> *WSO2 - Lean . Enterprise . Middleware* >>> >> >> >> >> -- >> Dmitry Sotnikov >> VP of Cloud; WSO2, Inc.; http://wso2.com/ >> email: [email protected]; cell: +1.949.303.9653; Skype: DSotnikov >> Lean . Enterprise . Middleware >> >> <http://wso2.com/signature> >> > > > > -- > Deependra Ariyadewa > WSO2, Inc. http://wso2.com/ http://wso2.org > > email [email protected]; cell +94 71 403 5996 ; > Blog http://risenfall.wordpress.com/ > PGP info: KeyID: 'DC627E6F' > > *WSO2 - Lean . Enterprise . Middleware* > -- Dmitry Sotnikov VP of Cloud; WSO2, Inc.; http://wso2.com/ email: [email protected]; cell: +1.949.303.9653; Skype: DSotnikov Lean . Enterprise . Middleware <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
