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