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

Reply via email to