On Thu, May 9, 2019 at 2:01 PM Boev, Todor
<todor.b...@softwareag.com <mailto:todor.b...@softwareag.com>> wrote:
> Others say you need to distribute based on your business
domains, not on the low level need to share some code
>> But neither choice has an impact on the size of the
(micro-) service
I tend to disagree. Splitting along business domains (e.g.
"product inventory") tends to require that the microservie is
a full-blown, self-container, three-tier web application. It
implies state and storage and more logic to integrate with
other microservices (e.g. call "user management" for access
control).
Right. What I meant is BOTH choices have an impact on the size of
the microservice, and you can end up with a smaller service if
you split by business domains than the boundaries of sharing code
or the opposite.
If you split the service by "logic reuse" you may end up with
something like "interest calculator" - a stateless generic
piece of logic with one rest endpoint to take input and
return output. This is better off as a library.
Debatable. I personally think it's not better off as a library
unless it's "complete" and I won't have to change it whenever I
change my services. If I introduce new functionality and
dimensions to my service and start differentiating offerings to
my customers by e.g. age, i'd have to change the library and
update it in all my services.
If it's just applying a generic mathematical function (based on
literature and with no ties to my business domain), of course it
should be a library. Classic example is calendar or date
libraries, where we should all use an open-source library,
everywhere :)
So "well designed" microservies actually include a lot of
stuff which in turn makes OSGi more attractive: rest sever,
rest client, db access, sso, component runtime to integrate
all of this... What people tend to do is to pick a set of
these things they feel are generic enough, call it "the
platform" or "the microservice chassis" and pay the cost of
having it everywhere. Think of "MicroProfile" - it's a fixed
set of things and try as they might to keep the list small it
inevitably will bloat up with every subsequent release
OSGi gives you a way out. The "platform" is actually a shared
bundle repository and the OSGi build will put together for
you exactly the pieces you need in each microservice. Then
because each bundle is an independent unit with its own
lifecycle they snap together just by being loaded into the
OSGi runtime. If you try to escape the "platform syndrome"
with plain maven for example you may be forced to provide the
glue code yourself since outside OSGi code tends to be shared
as libraries with the expectation that the user of the
library will drive it's lifecycle. If you notice service
dynamics are not used in this scenario yet they are an
important tool to enable the bundles to hook together even
though this happens only once at startup.
I fully accept your analysis of how OSGi gives you a lot of what
http microservices designs give you. Like "each bundle is an
independent unit with its own lifecycle". But it doesn't reach
the same level of decoupling like doing them with separate
processes. If you run microservices in separate processes, you
can rewrite some of them in a different language, you can move
one microservice in a different network, and, most importantly,
you can scale them horizontally (maybe elastically) beyond what
you could do in an OSGi instance
In short you are right that for simple enough microservices
plain maven and plain jars are simpler. However I believe
this gets out of hand very quickly simply because the correct
way to design microserviecs puts the bar of functionality
(and footprint) pretty high.
I agree, but I still stand beside my statement that OSGi would be
limited in terms of decoupling and scalability, compared to what
you could do with separate process, if you get it right. And yes,
huge footprint and overhead (and risk) of defining APIs
differently (like "REST APIs"), code duplication. But in some
situations (If you're Netflix or Uber), you might trade that off
for the extra bit that you don't get with OSGi.
As an example I have built a microservice with REST, JDBC,
SSO through JWT and some hello-world business logic in ~10 mb
(the JVM excluded). Another microservie did not need the JDBC
so it was ~8 MB. What came into the image was driven almost
entirely by the requirements of my business code out of a
common bundle repository.
Regards
-----------------------------------
Todor Boev
OSGi Platform
Software AG
From: Andrei Dulvac [mailto:dul...@apache.org
<mailto:dul...@apache.org>]
Sent: Monday, May 6, 2019 6:21 PM
To: Boev, Todor; OSGi Developer Mail List
Cc: Jürgen Albert; SMAIL LOUNES
Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
This is a great and coherent answer and it made me think a lot.
> Others say you need to distribute based on your business
domains, not on the low level need to share some code.
But neither choice has an impact on the size of the (micro-)
service
> So microservice modularity runs orthogonally to in-process
modularity. Indeed you need efficient in-process modularity
to build good microservces.
What I meant when I said there's an overlap it's the
modularisation part. Yes, with OSGi you can and might want to
modularise your service further, but if you're going through
the infra and ops cost of maintaining and deploying
microservices, you can split down a larger service further
into two microservices (if performance and the arch permits).
And if your services are quite split already, how much
benefits do the extra in-process modularisation bring you?
Don't get me wrong, I love OSGi and, on top of that, I think
it's actually a better way to start a project from a green
field and make use of that modularisation. So start with a
monolith in that strict sense (as you don't have the
scalability part). And when you need all the advantages of
microservices in the strict sense, your service is already
modular (*) and you can just take out the part that needs to
scale and make it a separate service that you can scale
independently.
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] 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
