On Sat, Apr 30, 2016 at 7:56 AM, Lakmal Warusawithana <lak...@apache.org> wrote:
> Shall we start with a POC? > > Couple of point to note: > > - Stratos api server should be very light weight > - for state saving we should used external service (eg. external etcd ) > - failure of Stratos should not affect any running application. > - shall we look TOSCA for supporting standard composite app model? > > +1 Lakmal! Will start with a POC. May be we can use a branch for this. Once things are stable will move to the master branch. Thanks > Better if we can have public google doc to capture architecture. Created a > doc [1]. Let start with basic components architecture. > > [1] > https://docs.google.com/document/d/1HnvCzmYqPVpqXSYV-PwGo9d8cmjYKPCPx3TCMKJx8cQ/edit > > On Tue, Apr 19, 2016 at 2:13 AM, Imesh Gunaratne <im...@apache.org> wrote: > >> Hi All, >> >> It's really nice to see the enthusiasm on re-igniting Stratos and >> starting a new journey. The day Lakmal proposed this I challenged the idea >> for several hours and analyzed it's pros & cons. This thread has already >> discussed those in detail. >> >> IMO Stratos Ignite Architecture should be simple enough to do the >> following: >> >> docker run -d -p 8080:8080 stratos >>> >> stratos login https://docker-host:8080/ >> >> stratos add platform kubernetes https://kubernetes-master/ >> >> stratos add platform mesos https://mesos-master/ >> >> stratos add platform swarm https://swarm-host/ >> >> stratos add platform aws-ecs >> >> stratos deploy tomcat --platform=kubernetes >> >> stratos deploy tomcat --platform=mesos >> >> stratos deploy tomcat --platform=swarm >> >> stratos deploy tomcat --platform=ecs >> >> >> >> Architecturally Stratos should be able to run using a light-weight single >> binary distribution and a key/value store like etcd for persistence. An API >> server can be exposed on the same binary and a CLI can be provided for user >> interaction. At a later stage an attractive UI can be introduced. >> >> I was evaluating a similar platform called Rancher very recently and they >> are also doing almost the same [1], but with a different vision and a >> strategy: >> >> - The first main difference is rather than adding existing Container >> Cluster Management Systems (CCMS) to Rancher, Rancher try to setup those >> from scratch and manage them. I don't think a such system should manage >> underlying CCMS. >> - The next is that Rancher implements health checks [2] and >> scheduling [3] of containers. IMO those should be handled by the >> underlying >> CCMS. Almost all the CCMSs provide those features. >> - The other is implementing a single load balancer extension [4]. >> Rancher only supports haproxy, IMO a such solution should have support for >> many different load balancers depending on the platform the containers are >> deployed (ex: AWS-ECS, GCE-K8S). >> >> [1] http://docs.rancher.com/rancher/ >> [2] http://docs.rancher.com/rancher/concepts/#health-checks >> [3] http://docs.rancher.com/rancher/concepts/#container-scheduling >> [4] http://docs.rancher.com/rancher/concepts/#load-balancer >> >> Thanks >> >> On Sat, Apr 16, 2016 at 11:10 PM, Lahiru Sandaruwan <lahi...@wso2.com> >> wrote: >> >>> Good article Akila. Yes, i think we need to define the scope for first >>> phase. >>> >>> Tenant and identity management would be important with first phase, as >>> core Stratos services. >>> >>> In second phase, we can look at few features to be implemented as value >>> additions, like follows. >>> List from Gartner is also interesting [1]. See the following list of >>> features. Out of those, I think something like environment management + >>> environment promotion is something Stratos can offer as an value added >>> service. Also, if we can also handle Autoscaling for the PaaSes which don't >>> have it, it would be good. >>> >>> [image: paas criteria categories] >>> <http://blogs.gartner.com/richard-watson/files/2015/07/paas-criteria-categories1.png> >>> >>> >>> [1] >>> http://blogs.gartner.com/richard-watson/dont-always-evaluate-paas-list-criteria-list/ >>> >>> Thanks. >>> >>> On Sat, Apr 16, 2016 at 5:36 PM, Akila Ravihansa Perera < >>> raviha...@apache.org> wrote: >>> >>>> Hi, >>>> >>>> While doing some online research on Multi-PaaS deployments, I found >>>> this white paper [1], "PaaSHopper: Policy-driven middleware for multi-PaaS >>>> environments", which proposes exactly what we are trying to do here. >>>> >>>> According to the paper, following are the challenges faced by users >>>> when deploying to multi-PaaS environments. >>>> >>>> - Heterogeneity in development and deployment. >>>> There are a lot of vendor-specific solutions in PaaS world for similar >>>> architectural concepts. Because of that portability and interoperability is >>>> restrained. Also there is a risk of vendor lock-in due to complexities in >>>> migrating to a different PaaS. >>>> >>>> - Fine-grained control over execution and storage. >>>> There can be security and legal concerns over the geographical location >>>> of processing and storage of data. Also service providers need control over >>>> how these PaaS environments are being utilized (based on policy model) to >>>> minimize the cost. >>>> >>>> PaaSHopper is a PaaS abstraction layer on top of different PaaS >>>> environments. It enables control over application deployment and execution >>>> through a policy-based model. However, I couldn't find a downloadable >>>> product or open source implementation of it. >>>> >>>> >>>> Advantages of proposed Stratos 5.0 solution to service providers as I >>>> see it; >>>> >>>> - Service providers can use hybrid cloud deployments to reduce the >>>> cost. >>>> Different PaaS providers may support different features but depending >>>> on the use case of service providers PaaS environment selection can be >>>> optimized. >>>> >>>> - Improved availability and scalability by deploying to multiple PaaS >>>> environments through a single platform. >>>> >>>> - Improved interoperability of services deployed on muti-PaaS >>>> environments. Stratos needs a good service discovery model to support this. >>>> >>>> - Portability. Service providers should be able to move to a different >>>> PaaS without any changes to application code. Deployment and execution >>>> aspects are offloaded to Stratos. >>>> >>>> >>>> I think we need to discuss and clearly define the scope of Stratos in >>>> this newly proposed architecture. We might have to come up with a DSL to >>>> describe services and environments. >>>> >>>> [1] >>>> https://lirias.kuleuven.be/bitstream/123456789/470906/3/Walraven-JISA-15.pdf >>>> >>>> Thanks. >>>> >>>> On Sat, Apr 16, 2016 at 7:01 AM, Lakmal Warusawithana <lak...@wso2.com> >>>> wrote: >>>> >>>>> Great explanation Lahiru. Supporting multiple PaaS is not necessary to >>>>> run multi PaaS in one deployment, but if you switch the PaaS, it will not >>>>> change the user experience with Stratos. No need to re learn all >>>>> complicated PaaS terminologies. >>>>> >>>>> On Fri, Apr 15, 2016 at 12:42 PM, Lahiru Sandaruwan < >>>>> lahi...@apache.org> wrote: >>>>> >>>>>> Hi Udara, >>>>>> >>>>>> IMO following are some advantages Stratos 5.0 can have. >>>>>> >>>>>> >>>>>> - If we get the user experience right, users who has used Stratos >>>>>> for one particular PaaS with Stratos, will not really lock his >>>>>> expertise >>>>>> when they want to move to a different PaaS. Therefore it avoids the >>>>>> vendor >>>>>> lockin from context switching of expertise perspective. >>>>>> >>>>>> >>>>>> - Stratos will seamlessly integrate other services such as >>>>>> Kibana, Logstash services for someone's PaaS. These services are also >>>>>> managed by Stratos, making underlying connections between them and >>>>>> PaaS. So >>>>>> he can keep changing his choices and do experiments due to that >>>>>> advantage. >>>>>> >>>>>> >>>>>> - In addition to above, Stratos can also provide more value >>>>>> addition services if there are no other 3rd party applications >>>>>> available in >>>>>> a particular area. >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> On Fri, Apr 15, 2016 at 6:08 AM, Udara Liyanage <ud...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Lakmal, >>>>>>> >>>>>>> To my understanding most Stratos users sticked to one IaaS though >>>>>>> Stratos supported multiple IaaS (cloud bursting). There are very few who >>>>>>> used multiple IaaS such as Ec2 and Openstack at the same time with >>>>>>> Stratos. >>>>>>> >>>>>>> With above knowledge and Stratos acts as a wrapper for PaaS, will >>>>>>> users use multiple PaaSs, in which case Stratos become handy? In other >>>>>>> words, if users are using only one PaaS, say Kuberneties would Stratos >>>>>>> be >>>>>>> useful for them? >>>>>>> >>>>>>> On Thu, Apr 14, 2016 at 5:51 AM, Chamila de Alwis < >>>>>>> cham...@apache.org> wrote: >>>>>>> >>>>>>>> In a way, this is a wrapper to different PaaS frameworks. However, >>>>>>>> the new architecture will also unify concept-wise the different >>>>>>>> approaches >>>>>>>> these different PaaS frameworks have for Container cluster management. >>>>>>>> >>>>>>>> @Lakmal, please correct me if I'm wrong. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Chamila de Alwis >>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>> Blog: code.chamiladealwis.com >>>>>>>> >>>>>>>> On Thu, Apr 14, 2016 at 2:36 AM, Sajith Kariyawasam < >>>>>>>> saj...@wso2.com> wrote: >>>>>>>> >>>>>>>>> With this architecture, will Stratos be a wrapper for different >>>>>>>>> other PaaS frameworks? >>>>>>>>> >>>>>>>>> With Jclouds we get a unified interface for multiple IaaSes, with >>>>>>>>> this approach we thinking of proposing Stratos to provide a unified >>>>>>>>> interface to talk to different PaaS s? >>>>>>>>> >>>>>>>>> On Wed, Apr 13, 2016 at 5:38 PM, Chamil de Alwis < >>>>>>>>> cham...@apache.org> wrote: >>>>>>>>> >>>>>>>>>> As Lakmal mentioned, IMO it is important to focus on a single >>>>>>>>>> user experience on top of multiple PaaS frameworks. Various PaaSes >>>>>>>>>> have >>>>>>>>>> their own implementations and compositions of common PaaS and >>>>>>>>>> Container >>>>>>>>>> cluster related concepts. IMO Stratos Ignite Architecture should >>>>>>>>>> scope, at >>>>>>>>>> least initially, to consolidate these concepts to a single >>>>>>>>>> abstraction. >>>>>>>>>> This should add minimum new knowledge as it could easily become a new >>>>>>>>>> "PaaS" to learn if the abstraction becomes too complex. >>>>>>>>>> >>>>>>>>>> Go lang has proven itself to be able to handle development >>>>>>>>>> processes involved with current Container related space, so I'm +1 >>>>>>>>>> to use >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Chamila de Alwis >>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>> Blog: code.chamiladealwis.com >>>>>>>>>> >>>>>>>>>> On Wed, Apr 13, 2016 at 10:27 PM, Raj Chudasama < >>>>>>>>>> raj.chudas...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> this looks great! >>>>>>>>>>> >>>>>>>>>>> i hope that you all keep this open to dev community for input as >>>>>>>>>>> well as share your progress. please take all your decisions >>>>>>>>>>> through the >>>>>>>>>>> appropriate Apache 2.0 guidelines. >>>>>>>>>>> >>>>>>>>>>> i can see a bright future with these changes. GO did bring many >>>>>>>>>>> improvements to PCF. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Apr 12, 2016 at 7:59 PM, Lakmal Warusawithana < >>>>>>>>>>> lak...@apache.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Devs, >>>>>>>>>>>> >>>>>>>>>>>> Couple of time community were discussed about Stratos refacing >>>>>>>>>>>> to carter new technology and threads. Yesterday I have met >>>>>>>>>>>> (unplanned >>>>>>>>>>>> meeting) few PMC/committers (Lakmal, Imesh, Akila, Chamilad, >>>>>>>>>>>> IsuruH) >>>>>>>>>>>> offline and discussed and came up $subject. Please share your >>>>>>>>>>>> valuable >>>>>>>>>>>> thoughts and feedback. >>>>>>>>>>>> >>>>>>>>>>>> Stratos 4.x and previous versions are mainly focused on run >>>>>>>>>>>> application on top of IaaS. To support multiple IaaSes, we used >>>>>>>>>>>> apache >>>>>>>>>>>> jclouds. But rise of the container technology future app dev and >>>>>>>>>>>> deployment >>>>>>>>>>>> will couple with containers not VM. Because of that we have >>>>>>>>>>>> integrated k8s >>>>>>>>>>>> support in Stratos 4.1.x release. But if we carefully looked at >>>>>>>>>>>> 4.1.x and >>>>>>>>>>>> new k8s releases, we are adding additional layer to k8s without any >>>>>>>>>>>> benefits. Personally I don't like to duplicate engineering effort >>>>>>>>>>>> if it >>>>>>>>>>>> does not giving any value to community. This is the background >>>>>>>>>>>> that we >>>>>>>>>>>> thought of why Stratos need refacing. >>>>>>>>>>>> >>>>>>>>>>>> Stratos 5.0 - proposing name "Ignite Architecture", we though >>>>>>>>>>>> of fully focus on container based application >>>>>>>>>>>> development/deployment. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We do not want to reinvent or compete with current PaaS >>>>>>>>>>>> providers. We propose to change the strategy to support multi PaaS >>>>>>>>>>>> instead >>>>>>>>>>>> of support multiple IaaS(Stratos 4.x). In high level, Stratos will >>>>>>>>>>>> provide >>>>>>>>>>>> unique workflow across deferent PaaS to deploy apps. Users are not >>>>>>>>>>>> going to >>>>>>>>>>>> tie up with PaaS vendors, they will have flexibility to use any >>>>>>>>>>>> PaaS. >>>>>>>>>>>> Stratos will play a role in-between PaaS and SaaS. Initially we >>>>>>>>>>>> can start >>>>>>>>>>>> with k8s (since we all have domain knowledge) then will add Mesos, >>>>>>>>>>>> CF, ECS >>>>>>>>>>>> etc support. >>>>>>>>>>>> >>>>>>>>>>>> User experience should be very simple. One main problem I have >>>>>>>>>>>> seen in all of these PaaS, their technologies are very complicate >>>>>>>>>>>> to >>>>>>>>>>>> understand average user. >>>>>>>>>>>> >>>>>>>>>>>> This is total rewrite of Stratos. We discussed to rewrite with >>>>>>>>>>>> GO, main reason Stratos itself should run in-side a container. >>>>>>>>>>>> >>>>>>>>>>>> Please share your thoughts. >>>>>>>>>>>> >>>>>>>>>>>> p.s: @(Imesh, Akila, Chamilad, IsuruH) please add if I missed >>>>>>>>>>>> anything. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Lakmal Warusawithana >>>>>>>>>>>> Vice President, Apache Stratos >>>>>>>>>>>> Blog : http://lakmalsview.blogspot.com/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sajith Kariyawasam >>>>>>>>> *Committer and PMC member, Apache Stratos, * >>>>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>>>>>>>> *Mobile: 0772269575 <0772269575>* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Udara Liyanage >>>>>>> Software Engineer >>>>>>> WSO2, Inc.: http://wso2.com >>>>>>> lean. enterprise. middleware >>>>>>> >>>>>>> web: http://udaraliyanage.wordpress.com >>>>>>> phone: +94 71 443 6897 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmal Warusawithana >>>>> Director - Cloud Architecture; WSO2 Inc. >>>>> Mobile : +94714289692 >>>>> Blog : http://lakmalsview.blogspot.com/ >>>>> >>>>> >>>> >>> >>> >>> -- >>> -- >>> Lahiru Sandaruwan >>> Committer and PMC member, Apache Stratos, >>> Senior Software Engineer, >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> phone: +94773325954 >>> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/ >>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Senior Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Lakmal Warusawithana > Vice President, Apache Stratos > Blog : http://lakmalsview.blogspot.com/ > -- Imesh Gunaratne Senior Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
