stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: [Proposal] Stratos 5.0 - Ignite Architecture
Date Sun, 01 May 2016 06:29:26 GMT
On Sat, Apr 30, 2016 at 7:56 AM, Lakmal Warusawithana <lakmal@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 <imesh@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 <lahirus@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 <
>>> ravihansa@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 <lakmal@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 <
>>>>> lahirus@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 <udara@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 <
>>>>>>> chamila@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 <
>>>>>>>> sajith@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 <
>>>>>>>>> chamila@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.chudasama@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
<
>>>>>>>>>>> lakmal@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: lahirus@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

Mime
View raw message