Re: Proposal to build an example for a cloud native microservice in Aries

[Christian Schneider]

As there is not enough request I cancel this proposal.

Christian

Am Mi., 15. Apr. 2020 um 07:15 Uhr schrieb Christian Schneider <
ch...@die-schneider.net>:

> (I first proposed this in felix. Some people hinted that Aries might be a
> better fit. So I am also starting this discussion here)
>
> In recent years we saw a big trend towards micro services and cloud.
> Lately people discovered though that such services are often made too fine
> grained.
> The newest trend goes to building bigger micro services on the level of
> domain driven design bounded contexts.
>
> Especially for these services OSGi is a very interesting platform as they
> need more internal structure than the more fine grained services.
> Unfortunately it is quite hard to build a cloud native service in OSGi
> from scratch.
>
> So I would like to offer a blueprint for cloud native micro services
> inside the felix community. The goal is to provide all parts of a cloud
> native
> system that are usually needed, like:
>
>  * Declarative services as dependency injection
>  * Aries Jaxrs Whiteboard for REST
>  * Dropwizard metrics exported as Prometheus metrics
>  * Swagger
>  * Halbrowser
>  * Felix healthchecks
>  * Configuration using OSGi configurator + Environment variables plugin
>  * Logging to console
>  * Final application is provided as a runnable jar
>  * Example docker build files
>  * Example kubernetes yaml
>
> What do you think?
>
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: Proposal to build an example for a cloud native microservice in Aries

[Christian Schneider]

I meant interest of course :-)

Am Fr., 17. Apr. 2020 um 09:19 Uhr schrieb Christian Schneider <
ch...@die-schneider.net>:

> As there is not enough request I cancel this proposal.
>
> Christian
>
> Am Mi., 15. Apr. 2020 um 07:15 Uhr schrieb Christian Schneider <
> ch...@die-schneider.net>:
>
>> (I first proposed this in felix. Some people hinted that Aries might be a
>> better fit. So I am also starting this discussion here)
>>
>> In recent years we saw a big trend towards micro services and cloud.
>> Lately people discovered though that such services are often made too
>> fine grained.
>> The newest trend goes to building bigger micro services on the level of
>> domain driven design bounded contexts.
>>
>> Especially for these services OSGi is a very interesting platform as they
>> need more internal structure than the more fine grained services.
>> Unfortunately it is quite hard to build a cloud native service in OSGi
>> from scratch.
>>
>> So I would like to offer a blueprint for cloud native micro services
>> inside the felix community. The goal is to provide all parts of a cloud
>> native
>> system that are usually needed, like:
>>
>>  * Declarative services as dependency injection
>>  * Aries Jaxrs Whiteboard for REST
>>  * Dropwizard metrics exported as Prometheus metrics
>>  * Swagger
>>  * Halbrowser
>>  * Felix healthchecks
>>  * Configuration using OSGi configurator + Environment variables plugin
>>  * Logging to console
>>  * Final application is provided as a runnable jar
>>  * Example docker build files
>>  * Example kubernetes yaml
>>
>> What do you think?
>>
>> Christian
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Computer Scientist
>> http://www.adobe.com
>>
>>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: Proposal to build an example for a cloud native microservice in Aries

[Jean-Baptiste Onofre]

IMHO, Winegrower/Karaf is a good place and already almost covered (again DevX 
and the Karaf ecosystem).

I agree with Romain.

Regards
JB

> Le 15 avr. 2020 à 20:39, Romain Manni-Bucau  a écrit :
> 
> There is already one without OSGi (utilda:
> https://geronimo.apache.org/microprofile/), guess it is just a matter of
> finishing the OSGi meta for all the desired spec (guess health has not yet
> the right OSGi-CDI registration for ex).
> That said it already runs with winegrower having OSGi and CDI side by side
> :).
> Not sure a good home though for such example.
> After some thought I think Karaf can be saner than aries since it is the
> Apache integration project.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 15 avr. 2020 à 20:37, Christian Schneider 
> a écrit :
> 
>> It sounds very good. Are you planning to provide a similar complete example
>> using the building blocks you mentioned?
>> 
>> Christian
>> 
>> Am Mi., 15. Apr. 2020 um 13:33 Uhr schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> 
>>> Hi Christian, the openX i mentionned are the standards done at CNF so
>>> standard for metrics is openmetrics, for tracing opentracing etc.
>>> On my side I use Microprofile metrics and export it to prometheus with
>> the
>>> spec exporter but I know some java guys use jmx exporter so guess the
>> best
>>> we can do is to use a standard API with a default exporter, this is why i
>>> proposed microprofile.
>>> For the config I think being able to plug its own "source" without being
>>> vendor coupled is important but I agree defaults (system props, env and a
>>> file) is important, here mp-config (equivalent of spring environment)
>> makes
>>> sense IMO. Think Ray dod the work to make it runnable in OSGi.
>>> 
>>> On the packaging side I know JIB works very well with all environment,
>>> including some more complex than OSGi but it can require some custom
>>> wrapping - I know JB started to look some time ago after we discussed
>> about
>>> it, not sure where we are today. Advantage compared to bnd standalone
>> build
>>> is that you dont specialize the build and enable to extend the OSGi
>> runtime
>>> with new layers - enabling to use layer cache - instead of forcing to
>>> restart from almost scratch.
>>> 
>>> In terms of runtime I think winegrower can be interesting since,
>> depending
>>> what bundles you use, you can potentially go native with graalvm very
>>> easily keeping a dev experience quite fluent even outside eclipse (which
>> is
>>> the biggest pitfall of OSGi today IMHO). The docker/k8s move is likely
>> the
>>> devops move so dev part must be more friendly too IMHO.
>>> 
>>> Hope it makes sense.
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
 
>>> 
>>> 
>>> Le mer. 15 avr. 2020 à 13:25, Christian Schneider <
>> ch...@die-schneider.net
 
>>> a écrit :
>>> 
 What do you mean by a runtime? For me the runtime is a suitable set of
 bundles that provide what the application needs. What would be a more
 concrete runtime?
 
 My approach here is to go with standards as far as possible. Ideally
>> also
 rely on Apache bundle impls so we have some leverage if something needs
>>> to
 be extended / fixed.
 
 I am looking forward to see what you have in mind with karaf devx but
>>> have
 not seen anything there.
 
 Christian
 
 
 Am Mi., 15. Apr. 2020 um 07:23 Uhr schrieb Jean-Baptiste Onofre <
 j...@nanthrax.net>:
 
> +0 for me.
> 
> Again, it’s interesting, a blueprint/tutorial is possible but I would
>>> go
> with something more concrete.
> 
> It’s what I started while ago with Karaf-boot and now on Karaf DevX
 branch.
> 
> Go ahead if you want but my concerns are:
> 
> - it will be maybe too abstract and complex for non OSGi users
> (spring-boot guys especially)
> - as I follow agree with your view about "too much fine grained
>>> services"
> (it’s something that I discussed with Netflix), I think a runtime
>> would
 be
> welcome
> 
> So, I’m no against, but I think the DevX approach is more concrete,
> straight, and addressing non OSGi users.
> 
> Regards
> JB
> 
>> Le 15 avr. 2020 à 07:15, Christian Schneider <
>>> ch...@die-schneider.net>
> a écrit :
>> 
>> (I first 

Re: Proposal to build an example for a cloud native microservice in Aries

[Romain Manni-Bucau]

There is already one without OSGi (utilda:
https://geronimo.apache.org/microprofile/), guess it is just a matter of
finishing the OSGi meta for all the desired spec (guess health has not yet
the right OSGi-CDI registration for ex).
That said it already runs with winegrower having OSGi and CDI side by side
:).
Not sure a good home though for such example.
After some thought I think Karaf can be saner than aries since it is the
Apache integration project.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 avr. 2020 à 20:37, Christian Schneider 
a écrit :

> It sounds very good. Are you planning to provide a similar complete example
> using the building blocks you mentioned?
>
> Christian
>
> Am Mi., 15. Apr. 2020 um 13:33 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hi Christian, the openX i mentionned are the standards done at CNF so
> > standard for metrics is openmetrics, for tracing opentracing etc.
> > On my side I use Microprofile metrics and export it to prometheus with
> the
> > spec exporter but I know some java guys use jmx exporter so guess the
> best
> > we can do is to use a standard API with a default exporter, this is why i
> > proposed microprofile.
> > For the config I think being able to plug its own "source" without being
> > vendor coupled is important but I agree defaults (system props, env and a
> > file) is important, here mp-config (equivalent of spring environment)
> makes
> > sense IMO. Think Ray dod the work to make it runnable in OSGi.
> >
> > On the packaging side I know JIB works very well with all environment,
> > including some more complex than OSGi but it can require some custom
> > wrapping - I know JB started to look some time ago after we discussed
> about
> > it, not sure where we are today. Advantage compared to bnd standalone
> build
> > is that you dont specialize the build and enable to extend the OSGi
> runtime
> > with new layers - enabling to use layer cache - instead of forcing to
> > restart from almost scratch.
> >
> > In terms of runtime I think winegrower can be interesting since,
> depending
> > what bundles you use, you can potentially go native with graalvm very
> > easily keeping a dev experience quite fluent even outside eclipse (which
> is
> > the biggest pitfall of OSGi today IMHO). The docker/k8s move is likely
> the
> > devops move so dev part must be more friendly too IMHO.
> >
> > Hope it makes sense.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 15 avr. 2020 à 13:25, Christian Schneider <
> ch...@die-schneider.net
> > >
> > a écrit :
> >
> > > What do you mean by a runtime? For me the runtime is a suitable set of
> > > bundles that provide what the application needs. What would be a more
> > > concrete runtime?
> > >
> > > My approach here is to go with standards as far as possible. Ideally
> also
> > > rely on Apache bundle impls so we have some leverage if something needs
> > to
> > > be extended / fixed.
> > >
> > > I am looking forward to see what you have in mind with karaf devx but
> > have
> > > not seen anything there.
> > >
> > > Christian
> > >
> > >
> > > Am Mi., 15. Apr. 2020 um 07:23 Uhr schrieb Jean-Baptiste Onofre <
> > > j...@nanthrax.net>:
> > >
> > > > +0 for me.
> > > >
> > > > Again, it’s interesting, a blueprint/tutorial is possible but I would
> > go
> > > > with something more concrete.
> > > >
> > > > It’s what I started while ago with Karaf-boot and now on Karaf DevX
> > > branch.
> > > >
> > > > Go ahead if you want but my concerns are:
> > > >
> > > > - it will be maybe too abstract and complex for non OSGi users
> > > > (spring-boot guys especially)
> > > > - as I follow agree with your view about "too much fine grained
> > services"
> > > > (it’s something that I discussed with Netflix), I think a runtime
> would
> > > be
> > > > welcome
> > > >
> > > > So, I’m no against, but I think the DevX approach is more concrete,
> > > > straight, and addressing non OSGi users.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > > Le 15 avr. 2020 à 07:15, Christian Schneider <
> > ch...@die-schneider.net>
> > > > a écrit :
> > > > >
> > > > > (I first proposed this in felix. Some people hinted that Aries
> might
> > > be a
> > > > > better fit. So I am also starting this discussion here)
> > > > >
> > > > > In recent years we saw a big trend towards micro services 

Re: Proposal to build an example for a cloud native microservice in Aries

[Christian Schneider]

It sounds very good. Are you planning to provide a similar complete example
using the building blocks you mentioned?

Christian

Am Mi., 15. Apr. 2020 um 13:33 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Hi Christian, the openX i mentionned are the standards done at CNF so
> standard for metrics is openmetrics, for tracing opentracing etc.
> On my side I use Microprofile metrics and export it to prometheus with the
> spec exporter but I know some java guys use jmx exporter so guess the best
> we can do is to use a standard API with a default exporter, this is why i
> proposed microprofile.
> For the config I think being able to plug its own "source" without being
> vendor coupled is important but I agree defaults (system props, env and a
> file) is important, here mp-config (equivalent of spring environment) makes
> sense IMO. Think Ray dod the work to make it runnable in OSGi.
>
> On the packaging side I know JIB works very well with all environment,
> including some more complex than OSGi but it can require some custom
> wrapping - I know JB started to look some time ago after we discussed about
> it, not sure where we are today. Advantage compared to bnd standalone build
> is that you dont specialize the build and enable to extend the OSGi runtime
> with new layers - enabling to use layer cache - instead of forcing to
> restart from almost scratch.
>
> In terms of runtime I think winegrower can be interesting since, depending
> what bundles you use, you can potentially go native with graalvm very
> easily keeping a dev experience quite fluent even outside eclipse (which is
> the biggest pitfall of OSGi today IMHO). The docker/k8s move is likely the
> devops move so dev part must be more friendly too IMHO.
>
> Hope it makes sense.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 15 avr. 2020 à 13:25, Christian Schneider  >
> a écrit :
>
> > What do you mean by a runtime? For me the runtime is a suitable set of
> > bundles that provide what the application needs. What would be a more
> > concrete runtime?
> >
> > My approach here is to go with standards as far as possible. Ideally also
> > rely on Apache bundle impls so we have some leverage if something needs
> to
> > be extended / fixed.
> >
> > I am looking forward to see what you have in mind with karaf devx but
> have
> > not seen anything there.
> >
> > Christian
> >
> >
> > Am Mi., 15. Apr. 2020 um 07:23 Uhr schrieb Jean-Baptiste Onofre <
> > j...@nanthrax.net>:
> >
> > > +0 for me.
> > >
> > > Again, it’s interesting, a blueprint/tutorial is possible but I would
> go
> > > with something more concrete.
> > >
> > > It’s what I started while ago with Karaf-boot and now on Karaf DevX
> > branch.
> > >
> > > Go ahead if you want but my concerns are:
> > >
> > > - it will be maybe too abstract and complex for non OSGi users
> > > (spring-boot guys especially)
> > > - as I follow agree with your view about "too much fine grained
> services"
> > > (it’s something that I discussed with Netflix), I think a runtime would
> > be
> > > welcome
> > >
> > > So, I’m no against, but I think the DevX approach is more concrete,
> > > straight, and addressing non OSGi users.
> > >
> > > Regards
> > > JB
> > >
> > > > Le 15 avr. 2020 à 07:15, Christian Schneider <
> ch...@die-schneider.net>
> > > a écrit :
> > > >
> > > > (I first proposed this in felix. Some people hinted that Aries might
> > be a
> > > > better fit. So I am also starting this discussion here)
> > > >
> > > > In recent years we saw a big trend towards micro services and cloud.
> > > > Lately people discovered though that such services are often made too
> > > fine
> > > > grained.
> > > > The newest trend goes to building bigger micro services on the level
> of
> > > > domain driven design bounded contexts.
> > > >
> > > > Especially for these services OSGi is a very interesting platform as
> > they
> > > > need more internal structure than the more fine grained services.
> > > > Unfortunately it is quite hard to build a cloud native service in
> OSGi
> > > from
> > > > scratch.
> > > >
> > > > So I would like to offer a blueprint for cloud native micro services
> > > inside
> > > > the felix community. The goal is to provide all parts of a cloud
> native
> > > > system that are usually needed, like:
> > > >
> > > > * Declarative services as dependency injection
> > > > * Aries Jaxrs Whiteboard for REST
> > > > * Dropwizard metrics exported as Prometheus metrics
> > > > * Swagger
> > > > * Halbrowser
> > > > * Felix healthchecks
> > > > * Configuration using OSGi configurator + Environment variables
> plugin
> > > > * Logging to console
> > > > * Final 

Re: Proposal to build an example for a cloud native microservice in Aries

[Romain Manni-Bucau]

Hi Christian, the openX i mentionned are the standards done at CNF so
standard for metrics is openmetrics, for tracing opentracing etc.
On my side I use Microprofile metrics and export it to prometheus with the
spec exporter but I know some java guys use jmx exporter so guess the best
we can do is to use a standard API with a default exporter, this is why i
proposed microprofile.
For the config I think being able to plug its own "source" without being
vendor coupled is important but I agree defaults (system props, env and a
file) is important, here mp-config (equivalent of spring environment) makes
sense IMO. Think Ray dod the work to make it runnable in OSGi.

On the packaging side I know JIB works very well with all environment,
including some more complex than OSGi but it can require some custom
wrapping - I know JB started to look some time ago after we discussed about
it, not sure where we are today. Advantage compared to bnd standalone build
is that you dont specialize the build and enable to extend the OSGi runtime
with new layers - enabling to use layer cache - instead of forcing to
restart from almost scratch.

In terms of runtime I think winegrower can be interesting since, depending
what bundles you use, you can potentially go native with graalvm very
easily keeping a dev experience quite fluent even outside eclipse (which is
the biggest pitfall of OSGi today IMHO). The docker/k8s move is likely the
devops move so dev part must be more friendly too IMHO.

Hope it makes sense.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 avr. 2020 à 13:25, Christian Schneider 
a écrit :

> What do you mean by a runtime? For me the runtime is a suitable set of
> bundles that provide what the application needs. What would be a more
> concrete runtime?
>
> My approach here is to go with standards as far as possible. Ideally also
> rely on Apache bundle impls so we have some leverage if something needs to
> be extended / fixed.
>
> I am looking forward to see what you have in mind with karaf devx but have
> not seen anything there.
>
> Christian
>
>
> Am Mi., 15. Apr. 2020 um 07:23 Uhr schrieb Jean-Baptiste Onofre <
> j...@nanthrax.net>:
>
> > +0 for me.
> >
> > Again, it’s interesting, a blueprint/tutorial is possible but I would go
> > with something more concrete.
> >
> > It’s what I started while ago with Karaf-boot and now on Karaf DevX
> branch.
> >
> > Go ahead if you want but my concerns are:
> >
> > - it will be maybe too abstract and complex for non OSGi users
> > (spring-boot guys especially)
> > - as I follow agree with your view about "too much fine grained services"
> > (it’s something that I discussed with Netflix), I think a runtime would
> be
> > welcome
> >
> > So, I’m no against, but I think the DevX approach is more concrete,
> > straight, and addressing non OSGi users.
> >
> > Regards
> > JB
> >
> > > Le 15 avr. 2020 à 07:15, Christian Schneider 
> > a écrit :
> > >
> > > (I first proposed this in felix. Some people hinted that Aries might
> be a
> > > better fit. So I am also starting this discussion here)
> > >
> > > In recent years we saw a big trend towards micro services and cloud.
> > > Lately people discovered though that such services are often made too
> > fine
> > > grained.
> > > The newest trend goes to building bigger micro services on the level of
> > > domain driven design bounded contexts.
> > >
> > > Especially for these services OSGi is a very interesting platform as
> they
> > > need more internal structure than the more fine grained services.
> > > Unfortunately it is quite hard to build a cloud native service in OSGi
> > from
> > > scratch.
> > >
> > > So I would like to offer a blueprint for cloud native micro services
> > inside
> > > the felix community. The goal is to provide all parts of a cloud native
> > > system that are usually needed, like:
> > >
> > > * Declarative services as dependency injection
> > > * Aries Jaxrs Whiteboard for REST
> > > * Dropwizard metrics exported as Prometheus metrics
> > > * Swagger
> > > * Halbrowser
> > > * Felix healthchecks
> > > * Configuration using OSGi configurator + Environment variables plugin
> > > * Logging to console
> > > * Final application is provided as a runnable jar
> > > * Example docker build files
> > > * Example kubernetes yaml
> > >
> > > What do you think?
> > >
> > > Christian
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Computer Scientist
> > > http://www.adobe.com
> >
> >
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>

Re: Proposal to build an example for a cloud native microservice in Aries

[Christian Schneider]

What do you mean by a runtime? For me the runtime is a suitable set of
bundles that provide what the application needs. What would be a more
concrete runtime?

My approach here is to go with standards as far as possible. Ideally also
rely on Apache bundle impls so we have some leverage if something needs to
be extended / fixed.

I am looking forward to see what you have in mind with karaf devx but have
not seen anything there.

Christian


Am Mi., 15. Apr. 2020 um 07:23 Uhr schrieb Jean-Baptiste Onofre <
j...@nanthrax.net>:

> +0 for me.
>
> Again, it’s interesting, a blueprint/tutorial is possible but I would go
> with something more concrete.
>
> It’s what I started while ago with Karaf-boot and now on Karaf DevX branch.
>
> Go ahead if you want but my concerns are:
>
> - it will be maybe too abstract and complex for non OSGi users
> (spring-boot guys especially)
> - as I follow agree with your view about "too much fine grained services"
> (it’s something that I discussed with Netflix), I think a runtime would be
> welcome
>
> So, I’m no against, but I think the DevX approach is more concrete,
> straight, and addressing non OSGi users.
>
> Regards
> JB
>
> > Le 15 avr. 2020 à 07:15, Christian Schneider 
> a écrit :
> >
> > (I first proposed this in felix. Some people hinted that Aries might be a
> > better fit. So I am also starting this discussion here)
> >
> > In recent years we saw a big trend towards micro services and cloud.
> > Lately people discovered though that such services are often made too
> fine
> > grained.
> > The newest trend goes to building bigger micro services on the level of
> > domain driven design bounded contexts.
> >
> > Especially for these services OSGi is a very interesting platform as they
> > need more internal structure than the more fine grained services.
> > Unfortunately it is quite hard to build a cloud native service in OSGi
> from
> > scratch.
> >
> > So I would like to offer a blueprint for cloud native micro services
> inside
> > the felix community. The goal is to provide all parts of a cloud native
> > system that are usually needed, like:
> >
> > * Declarative services as dependency injection
> > * Aries Jaxrs Whiteboard for REST
> > * Dropwizard metrics exported as Prometheus metrics
> > * Swagger
> > * Halbrowser
> > * Felix healthchecks
> > * Configuration using OSGi configurator + Environment variables plugin
> > * Logging to console
> > * Final application is provided as a runnable jar
> > * Example docker build files
> > * Example kubernetes yaml
> >
> > What do you think?
> >
> > Christian
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: Proposal to build an example for a cloud native microservice in Aries

[Christian Schneider]

For me cloud native means to fit as well as possible into a typical cloud.
Luckily this currently means k8s as there is not much competition. On top
of course we need the relevant surrounding services like you described.

For metrics the current state of the art seems to be prometheus. A standard
for metrics would be great. We currently use dropwizard metrics in the code
and
export them for prometheus.
I did not yet include opentracing but it makes a lot of sense.
For config I look into felix configurator and the env replacement plugin.
For logging I am not sure what the ideal approach is. The 12 factor
principles say to log to stdout.
For dependency injection stack I currently look into declarative services.
Aries CDI is a very interesting alternative though. Especially if the other
microprofile extensions also fit into OSGi. I guess it makes sense to
provide examples for both.
For packaging I currently use bnd maven plugins for resolving and export.
Some apache based alternative would be great. Looking forward to what you
guys work on.
For building images I currently go with default docker. JIB does not work
with OSGi as far as I know.

Christian


Am Mi., 15. Apr. 2020 um 07:41 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Hmm, here are a few thoughts:
>
> 1. What is "cloud native"? Nothing right? ;). More seriously I guess you
> speak of k8s microservices. If so, pillars are metrics (openmetric),
> tracing (opentracing), config (env, and secret/maps), security (jwt?),
> logging compatible with a docker driver, api exposure (openapi) and
> optionally messaging.
> 2. Assuming we agree on 1, a standard user facing and homogeneous stack can
> be built on top of aries-cdi, jaxrs whiteboard and microprofile (we have
> all that at geronimo).
> 3. Then for the packaging deployment there are two points: the app
> packaging and how to build images. For the first, I agree with jb it shpuld
> be something cloud friendly, winegrower or so. For images I guess JIB is a
> more relevant choice, avoiding docker daemon need on CI and being more
> customizable programmatically if needed.
>
> Hope it makes sense.
>
>
> Le mer. 15 avr. 2020 à 07:23, Jean-Baptiste Onofre  a
> écrit :
>
> > +0 for me.
> >
> > Again, it’s interesting, a blueprint/tutorial is possible but I would go
> > with something more concrete.
> >
> > It’s what I started while ago with Karaf-boot and now on Karaf DevX
> branch.
> >
> > Go ahead if you want but my concerns are:
> >
> > - it will be maybe too abstract and complex for non OSGi users
> > (spring-boot guys especially)
> > - as I follow agree with your view about "too much fine grained services"
> > (it’s something that I discussed with Netflix), I think a runtime would
> be
> > welcome
> >
> > So, I’m no against, but I think the DevX approach is more concrete,
> > straight, and addressing non OSGi users.
> >
> > Regards
> > JB
> >
> > > Le 15 avr. 2020 à 07:15, Christian Schneider 
> > a écrit :
> > >
> > > (I first proposed this in felix. Some people hinted that Aries might
> be a
> > > better fit. So I am also starting this discussion here)
> > >
> > > In recent years we saw a big trend towards micro services and cloud.
> > > Lately people discovered though that such services are often made too
> > fine
> > > grained.
> > > The newest trend goes to building bigger micro services on the level of
> > > domain driven design bounded contexts.
> > >
> > > Especially for these services OSGi is a very interesting platform as
> they
> > > need more internal structure than the more fine grained services.
> > > Unfortunately it is quite hard to build a cloud native service in OSGi
> > from
> > > scratch.
> > >
> > > So I would like to offer a blueprint for cloud native micro services
> > inside
> > > the felix community. The goal is to provide all parts of a cloud native
> > > system that are usually needed, like:
> > >
> > > * Declarative services as dependency injection
> > > * Aries Jaxrs Whiteboard for REST
> > > * Dropwizard metrics exported as Prometheus metrics
> > > * Swagger
> > > * Halbrowser
> > > * Felix healthchecks
> > > * Configuration using OSGi configurator + Environment variables plugin
> > > * Logging to console
> > > * Final application is provided as a runnable jar
> > > * Example docker build files
> > > * Example kubernetes yaml
> > >
> > > What do you think?
> > >
> > > Christian
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Computer Scientist
> > > http://www.adobe.com
> >
> >
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: Proposal to build an example for a cloud native microservice in Aries

[Jean-Baptiste Onofre]

Bascially, ongoing Karaf DevX effort is the result of the discussions I have 
weekly with Netflix.

Regards
JB

> Le 15 avr. 2020 à 08:24, Grzegorz Grzybek  a écrit :
> 
> +? from me as well.
> 
> I've sent my answer to felix-dev ML about this.
> 
> BTW JBO - do you have some report/minutes/comments after you talked with
> Netflix? It'd be super interesting to hear about their decisions related to
> OSGi!
> 
> regards
> Grzegorz Grzybek
> 
> śr., 15 kwi 2020 o 07:23 Jean-Baptiste Onofre  napisał(a):
> 
>> +0 for me.
>> 
>> Again, it’s interesting, a blueprint/tutorial is possible but I would go
>> with something more concrete.
>> 
>> It’s what I started while ago with Karaf-boot and now on Karaf DevX branch.
>> 
>> Go ahead if you want but my concerns are:
>> 
>> - it will be maybe too abstract and complex for non OSGi users
>> (spring-boot guys especially)
>> - as I follow agree with your view about "too much fine grained services"
>> (it’s something that I discussed with Netflix), I think a runtime would be
>> welcome
>> 
>> So, I’m no against, but I think the DevX approach is more concrete,
>> straight, and addressing non OSGi users.
>> 
>> Regards
>> JB
>> 
>>> Le 15 avr. 2020 à 07:15, Christian Schneider 
>> a écrit :
>>> 
>>> (I first proposed this in felix. Some people hinted that Aries might be a
>>> better fit. So I am also starting this discussion here)
>>> 
>>> In recent years we saw a big trend towards micro services and cloud.
>>> Lately people discovered though that such services are often made too
>> fine
>>> grained.
>>> The newest trend goes to building bigger micro services on the level of
>>> domain driven design bounded contexts.
>>> 
>>> Especially for these services OSGi is a very interesting platform as they
>>> need more internal structure than the more fine grained services.
>>> Unfortunately it is quite hard to build a cloud native service in OSGi
>> from
>>> scratch.
>>> 
>>> So I would like to offer a blueprint for cloud native micro services
>> inside
>>> the felix community. The goal is to provide all parts of a cloud native
>>> system that are usually needed, like:
>>> 
>>> * Declarative services as dependency injection
>>> * Aries Jaxrs Whiteboard for REST
>>> * Dropwizard metrics exported as Prometheus metrics
>>> * Swagger
>>> * Halbrowser
>>> * Felix healthchecks
>>> * Configuration using OSGi configurator + Environment variables plugin
>>> * Logging to console
>>> * Final application is provided as a runnable jar
>>> * Example docker build files
>>> * Example kubernetes yaml
>>> 
>>> What do you think?
>>> 
>>> Christian
>>> 
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Computer Scientist
>>> http://www.adobe.com
>> 
>> 

Re: Proposal to build an example for a cloud native microservice in Aries

[Grzegorz Grzybek]

+? from me as well.

I've sent my answer to felix-dev ML about this.

BTW JBO - do you have some report/minutes/comments after you talked with
Netflix? It'd be super interesting to hear about their decisions related to
OSGi!

regards
Grzegorz Grzybek

śr., 15 kwi 2020 o 07:23 Jean-Baptiste Onofre  napisał(a):

> +0 for me.
>
> Again, it’s interesting, a blueprint/tutorial is possible but I would go
> with something more concrete.
>
> It’s what I started while ago with Karaf-boot and now on Karaf DevX branch.
>
> Go ahead if you want but my concerns are:
>
> - it will be maybe too abstract and complex for non OSGi users
> (spring-boot guys especially)
> - as I follow agree with your view about "too much fine grained services"
> (it’s something that I discussed with Netflix), I think a runtime would be
> welcome
>
> So, I’m no against, but I think the DevX approach is more concrete,
> straight, and addressing non OSGi users.
>
> Regards
> JB
>
> > Le 15 avr. 2020 à 07:15, Christian Schneider 
> a écrit :
> >
> > (I first proposed this in felix. Some people hinted that Aries might be a
> > better fit. So I am also starting this discussion here)
> >
> > In recent years we saw a big trend towards micro services and cloud.
> > Lately people discovered though that such services are often made too
> fine
> > grained.
> > The newest trend goes to building bigger micro services on the level of
> > domain driven design bounded contexts.
> >
> > Especially for these services OSGi is a very interesting platform as they
> > need more internal structure than the more fine grained services.
> > Unfortunately it is quite hard to build a cloud native service in OSGi
> from
> > scratch.
> >
> > So I would like to offer a blueprint for cloud native micro services
> inside
> > the felix community. The goal is to provide all parts of a cloud native
> > system that are usually needed, like:
> >
> > * Declarative services as dependency injection
> > * Aries Jaxrs Whiteboard for REST
> > * Dropwizard metrics exported as Prometheus metrics
> > * Swagger
> > * Halbrowser
> > * Felix healthchecks
> > * Configuration using OSGi configurator + Environment variables plugin
> > * Logging to console
> > * Final application is provided as a runnable jar
> > * Example docker build files
> > * Example kubernetes yaml
> >
> > What do you think?
> >
> > Christian
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
>
>

Re: Proposal to build an example for a cloud native microservice in Aries

[Romain Manni-Bucau]

Hmm, here are a few thoughts:

1. What is "cloud native"? Nothing right? ;). More seriously I guess you
speak of k8s microservices. If so, pillars are metrics (openmetric),
tracing (opentracing), config (env, and secret/maps), security (jwt?),
logging compatible with a docker driver, api exposure (openapi) and
optionally messaging.
2. Assuming we agree on 1, a standard user facing and homogeneous stack can
be built on top of aries-cdi, jaxrs whiteboard and microprofile (we have
all that at geronimo).
3. Then for the packaging deployment there are two points: the app
packaging and how to build images. For the first, I agree with jb it shpuld
be something cloud friendly, winegrower or so. For images I guess JIB is a
more relevant choice, avoiding docker daemon need on CI and being more
customizable programmatically if needed.

Hope it makes sense.


Le mer. 15 avr. 2020 à 07:23, Jean-Baptiste Onofre  a
écrit :

> +0 for me.
>
> Again, it’s interesting, a blueprint/tutorial is possible but I would go
> with something more concrete.
>
> It’s what I started while ago with Karaf-boot and now on Karaf DevX branch.
>
> Go ahead if you want but my concerns are:
>
> - it will be maybe too abstract and complex for non OSGi users
> (spring-boot guys especially)
> - as I follow agree with your view about "too much fine grained services"
> (it’s something that I discussed with Netflix), I think a runtime would be
> welcome
>
> So, I’m no against, but I think the DevX approach is more concrete,
> straight, and addressing non OSGi users.
>
> Regards
> JB
>
> > Le 15 avr. 2020 à 07:15, Christian Schneider 
> a écrit :
> >
> > (I first proposed this in felix. Some people hinted that Aries might be a
> > better fit. So I am also starting this discussion here)
> >
> > In recent years we saw a big trend towards micro services and cloud.
> > Lately people discovered though that such services are often made too
> fine
> > grained.
> > The newest trend goes to building bigger micro services on the level of
> > domain driven design bounded contexts.
> >
> > Especially for these services OSGi is a very interesting platform as they
> > need more internal structure than the more fine grained services.
> > Unfortunately it is quite hard to build a cloud native service in OSGi
> from
> > scratch.
> >
> > So I would like to offer a blueprint for cloud native micro services
> inside
> > the felix community. The goal is to provide all parts of a cloud native
> > system that are usually needed, like:
> >
> > * Declarative services as dependency injection
> > * Aries Jaxrs Whiteboard for REST
> > * Dropwizard metrics exported as Prometheus metrics
> > * Swagger
> > * Halbrowser
> > * Felix healthchecks
> > * Configuration using OSGi configurator + Environment variables plugin
> > * Logging to console
> > * Final application is provided as a runnable jar
> > * Example docker build files
> > * Example kubernetes yaml
> >
> > What do you think?
> >
> > Christian
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
>
>

Re: Proposal to build an example for a cloud native microservice in Aries

[Christian Schneider]

Forgot the link.

The current state can be viewed in
https://github.com/cschneider/osgi-best-practices

It already implements most of the aspects above but still got some rough
edges. The example also contains some bundles like the
swagger and halbrowser repackagings that should rather be versioned
separately so users of the example can simply reference them.

Christian


Am Mi., 15. Apr. 2020 um 07:15 Uhr schrieb Christian Schneider <
ch...@die-schneider.net>:

> (I first proposed this in felix. Some people hinted that Aries might be a
> better fit. So I am also starting this discussion here)
>
> In recent years we saw a big trend towards micro services and cloud.
> Lately people discovered though that such services are often made too fine
> grained.
> The newest trend goes to building bigger micro services on the level of
> domain driven design bounded contexts.
>
> Especially for these services OSGi is a very interesting platform as they
> need more internal structure than the more fine grained services.
> Unfortunately it is quite hard to build a cloud native service in OSGi
> from scratch.
>
> So I would like to offer a blueprint for cloud native micro services
> inside the felix community. The goal is to provide all parts of a cloud
> native
> system that are usually needed, like:
>
>  * Declarative services as dependency injection
>  * Aries Jaxrs Whiteboard for REST
>  * Dropwizard metrics exported as Prometheus metrics
>  * Swagger
>  * Halbrowser
>  * Felix healthchecks
>  * Configuration using OSGi configurator + Environment variables plugin
>  * Logging to console
>  * Final application is provided as a runnable jar
>  * Example docker build files
>  * Example kubernetes yaml
>
> What do you think?
>
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com