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
Web: www.datainmotion.de
XING: https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
