A wise man once told me: "You will never get the architecture and
domain boundaries right from the start with microservices"
(*) As long as you future-proof a bit and don't make an architecture
that assumes blindly that osgi services are sharing the process with
other services.
- Andrei
On Fri, May 3, 2019 at 5:32 PM Boev, Todor via osgi-dev
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
I work on tools build OSGi-based microservices for the likes of
K8S. By extension this includes thinking/experimenting to discover
whether/how OSGi is applicable in these environments.
One thing I noticed is that when you have a distributed
application all of its pieces must coordinate their internal
lifecycles across the network. This is more in the realm of
communication between the microservices, rather than in the realm
of deploying containers. For example K8S can maintain replicas of
your containers, but this is for scalability rather than to create
the illusion network calls can’t fail. The application running on
top is expected to adapt on the fly. You really need good
programming models.
OSGi provides one elegant programming model. You already have
services that coordinate their independent dynamic lifecycles. If
you model an external entity as a service (e.g. a remote client
object) you can hook your application internal state directly to
it. Then use discovery to distribute knowledge when things are
coming/going/relocating and have the distributed system keep
itself in balance while K8S takes care of responding to load – it
is a good fit.
The other thing I have noticed is the inclination to think of
microservices as a universal modularity solution. People brag
about having hundreds of services with some consisting of one
function. To share this one piece of code you seem to pay the cost
of handling distribution, memory/cpu/network to maintain extra
processes. This ultimately translates to paying raw money. While
Martin Fawler promotes modularity through microservices he
explicitly does not say where to stop if I remember correctly.
Others say you need to distribute based on your business domains,
not on the low level need to share some code. So microservice
modularity runs orthogonally to in-process modularity. Indeed you
need efficient in-process modularity to build good microservces.
Here again OSGi can be a compelling solution since it tends to
build really small footprint images, because it has deep
understanding what each jar needs. This does not come for free –
you need to describe your code well in the module metadata.
The third thing I noticed is that it only really works well when
you use simple/light OSGi components. Use http whiteboard, not web
bundles. Use declarative services, not blueprint. And so on. Even
if you use “traditional” distribution without the dynamic
lifecycle it is still quite fun and OSGi has a lot to offer (e.g.
JAX-RS whiteboard).
So in general if you choose a microservice architecture and choose
to build immutable small containers you are not at odds with OSGi.
It actually can help. If you already have an OSGi application you
can consider it a head start. You will have to refactor a lot to
split your business logic into independent services, but you won’t
refactor less if you were not OSGi based.
Mohamed however mentioned he’d like to use ready-made solutions to
implement application features and has issues with OSGi in that
respect. What are they?
OSGi can provide means to structure distributed applications, but
it sure can’t provide an independent analog of every heavy-lifting
framework out there.
-----------------------------------
Todor Boev
OSGi Platform
Software AG
*From:*osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>
[mailto:osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>] *On Behalf Of *Jurgen
Albert via osgi-dev
*Sent:* Friday, May 3, 2019 3:41 PM
*To:* SMAIL LOUNES; OSGi Developer Mail List
*Subject:* Re: [osgi-dev] Migrating from OSGI to Microservices
Well, like I said: Kubernetes only knows and cares about
Containers (Pods) and nothing about any application life cycle.
You can define e.g. dependencies like an application container
requires a container with a DB. So when someone triggers the start
of your application container it will make sure that the DB
container is started and as far as I remember will set the
coordinates to the DB as system properties for you. However, It
will not know the state of readyness of your application or the
DB. As an example, we have search server tailor maid for one of
our customers. On first start it rebuilds the index from the raw
data in their DB. This can take a couple of minutes. For
Kubernetes the container is up and running, but the server will
not be available to answer queries until the index is ready.
Thus, if you want to use the Kubernetes API to start a Pod for a
specific services it you can do that, but everything else is not
in its scope. It is just a convenient tool to manage an
Infrastructure. The rest belongs to your application domain.
Regards,
Jürgen.
Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES:
Thank you for this remarkable answer,
I'm working on a research project about developping a highly
distributed and dynamic communication platform, so we're
looknig for using kubernetes to manage µservices life cycle,
osgi is a condidate too. we can use an osgi container to
deploy some µservices.. do you have an idea about using
kubernetes for life cycle mangement and how integrate it's API
Thank you so much, Best regards
Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> a écrit :
Hi Mohamed,
I had the fortune and in parts misfortune of being part of
a few such migration projects. Besides our own internal
one, everyone decided against OSGi. The descension was
always because of personal resentment and/or because
everybody had his personal favourite toy they wanted to
play with. The reasons ranged from " We don't want to use
Eclipse" (enroute with maven wasn't available at the
time) over "We want spring because we don't understand
OSGi and it seems to complicated" to " Java is outdated,
we want to build it with NodeJS". They all jumped on the
Martin Fowler approach without really considering what it
means in the end. Each ended in disaster or went through a
hard phase of near disaster with jobs and reputations on
the line. Most ended up with something OSGiish with a lot
of the pain going along with modularity but missing most
of its benefits.
The issue is complex but we Identified one main reason:
Modularity is an abstract concept for many developers.
Spring for example does not really teach and force a
developer to think in a modular fashion. All I saw was a
bunch of smaller Monoliths packed in Docker containers.
The dynamic nature of a Microservice environment OSGi
addresses with its Bundle and Service life cycle , was
pushed in the realm of Kubernetes. But Kubernetes (or
comparable Systems) is made for managing your Containers
and not for any application and service life cycle. Thus
one needs at least a few Developers/Architects that have
modularity internalised and address issues early on.
Another issue with the Martin Fowler approach you have
already addressed. A fully distributed system comes with a
lot of different problems (e.g. caches). Also the point of
network latency and the time serialization and
deserialization is an underestimated issue.
Like Neil stated: If you are already have an OSGi
application you already have a microservice architecture,
but maybe no distributed one. The way to go is build a
good microservice monolith (or modulith, like it is called
nowadays) and then move only the services to there own
containers, that really need scaling. Graham Charters talk
from the 2016 EclipseCon Europe addresses this quite
nicely:
https://de.slideshare.net/mfrancis/microservices-osgi-better-together-graham-charters
By your mention of blueprint, I deduct that you might use
an older version of OSGi. Our internal project was
somewhat similar and we managed to go distributed without
major problems. We migrated to the latest OSGi Version and
used bnd instead of PDE. Later we moved some service to
there own container. It worked like charm. We could even
show the process to a customer, with zero downtime, by
pulling up the new containers and removing bundles with
the local service implementations while the system was
running.
Regarding your point of finding/keep OSGi developers: This
is something we are confronted with rather often. The best
way get developers sold on OSGi is using the latest
version of it together with bnd (pure or with the maven
integration). The development speed you can reach and
maintain even in complex applications makes most other
Java developers jealous and interested to learn more.
Regards,
Jürgen.
Am 03/05/2019 um 10:57 schrieb Mohamed AFIF via osgi-dev:
Hi Andrei,
My question had as aim to collect some experiences of
suchs migrations if this exist, we're in brainstorming
phase and I'm not making any judgement value about
OSGI or microservices architecture, but what we push
to believe that we should probely move toward another
technology, is: the business requirement, indeed we
want to expose our service to clients as API, and the
several technical complications we 've ve been faced
to everytime we want to implement a feature easily
provided and could be implemented by other open
framework in the market, there is also the Human
ressource question is involved beacause it's not easy
find/keep OSGI developers.
personaly I think that OSGI is a perfect tehcnology
for servers or embedded system, but I've some doubt
when it's regarding applications with open
architectures, it's my own view and I could be wrong
Regards
Mohamed.
@Neil
Obviously a simple
Le jeu. 2 mai 2019 à 16:52, Andrei Dulvac
<dul...@apache.org <mailto:dul...@apache.org>> a écrit :
Hi Mohamed, Neil.
Neil, while I agree with you, I think Mohamed
means it in the more "modern", widely-accepted sense:
https://martinfowler.com/articles/microservices.html
"""
In short, the microservice architectural style [1]
<https://martinfowler.com/articles/microservices.html#footnote-etymology>
is an approach to developing a single application
as a suite of small services, each running in its
own process and communicating with lightweight
mechanisms, often an HTTP resource API.
"""
Mohamed, I'm curious what you end up with. Without
getting too much into it, I dismissed the idea as
something "not worth it".
- Andrei
On Thu, May 2, 2019 at 12:37 PM Neil Bartlett via
osgi-dev <osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>> wrote:
Well the good news is that OSGi is already a
microservice architecture, so you have already
finished. Congratulations!
If that answer doesn't quite satisfy you,
maybe you'd like to describe in more detail
what you are attempting to achieve and why?
Regards,
Neil
On Thu, 2 May 2019 at 11:06, Mohamed AFIF via
osgi-dev <osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>> wrote:
Hello everybody,
We 're starting to study the possibility
to transform our architcteure in order to
migrate from OSGI to microservice
architecture, and I would like to know if
there is alreay some people who had
thought about this subject or already
start this migration.
Because at first sight it would not be an
easy task, many problems/issues we will be
facing to them (blueprint injections,
managing ditrubued caches instead of one
cache in one JVM...)
Many thanks
--
Cdt
Mohamed AFIF
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Cdt
Mohamed AFIF
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Jürgen Albert
Geschäftsführer
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: 0157-72521634
E-Mail:j.alb...@datainmotion.de <mailto:j.alb...@datainmotion.de>
Web:www.datainmotion.de <http://www.datainmotion.de>
XING:https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
--
Jürgen Albert
Geschäftsführer
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: 0157-72521634
E-Mail:j.alb...@datainmotion.de <mailto:j.alb...@datainmotion.de>
Web:www.datainmotion.de <http://www.datainmotion.de>
XING:https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
