You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by David Holiday <da...@holitek.io> on 2021/01/12 16:54:47 UTC
Introducing K-car: a microservice framework for Camel
Hello fellow Camel riders!
I made a thing for Camel that makes it dead simple for teams to quickly
build and deploy prod-ready microservices. The MVP can be found on github
<https://github.com/davidholiday/kcar>. I'm posting here to ask for your
thoughts on what works, what doesn't, and whether or not you find it
useful.
I wrote this because I needed a way to quickly produce Camel services. I
needed something that encouraged re-use of service artifacts, didn't rely
on Spring, and could scale in a way that gave me the ability to farm out
work to other engineers without a lot of 'too many cooks in the same
kitchen' bs.
I'm sure I'm not the first engineer to have these challenges so definitely
curious as to your thoughts not only on the merits of this particular
solution, but also your thoughts and experiences in addressing them.
cheers (and ty!)
David
Re: Introducing K-car: a microservice framework for Camel
Posted by "Shultz, Dmitry" <Dm...@kaltire.com>.
David,
It will be great if you can specify what problems exactly K-car is solving. I scanned through the readme and still not sure, sorry.
Having some simple project (so everybody can compare it with CDI/TomEE based one for example) in the repo implemented using it would be good too.
Cheers,
Dmitry
________________________________
From: David Holiday <da...@holitek.io>
Sent: 12 January 2021 10:02
To: Romain Manni-Bucau <rm...@gmail.com>
Cc: users@camel.apache.org <us...@camel.apache.org>
Subject: Re: Introducing K-car: a microservice framework for Camel
Hi Ramain
Thanks for giving the thing a look!
In response to your question: while personally I prefer not to use Spring
or CDI there's nothing in K-car that pushes you one way or the other. The
service chassis in the MVP (the ready-bake thing you instance and add
Routes to via properties file) is camel/servlet-only but there are others
planned that will use Spring and other frameworks.
The big idea behind K-car is the deeper integration between Maven and Camel
to the effect of auto-magickally turning Camel elements, routes, chassis,
and services into maven build artifacts that all adhere to a small set of
standards so they automatically play nicely with one another.
In other words, Camel is already very modular but it, alone, doesn't scale
well across an engineering org. Without something like K-car, I, the
Principle Eng, can't decompose whatever wonky business logic the product
team wants into work I can distribute across my dev teams without dealing
with an integration mess at the end of the evolution. A feature and a curse
of Camel is that there are a gazillion different ways to do the same thing.
As such I'm kindof forced to have the same person handle all the routes for
a given service because that's the only way I know for sure that it'll all
play nicely with itself. Moreover, without something like K-car setting a
paradigm for things like namespacing, it's hard to re-use camel artifacts
w/o a lot of cutting, pasting, and snitty re-wiring.
Lastly, K-car does the same thing for deployed services that Maven does for
project structure. For any given K-car service, I don't have to know
anything about a given service to know my way around. This helps enormously
with on-boarding new folks as well as ensuring the teams aren't screwed
when someone leaves. Because everything is standardized down to the element
level, everyone can work on anything in the ecosystem. Yes standards can in
theory be enforced via institutional knowledge but in 20 years of doing
this I've never once seen a shop disciplined enough to maintain standards
w/o the help of frameworks, linters, and automation.
As for python - long term my goal is to replace that with a camel-main
project that runs a full CLI. Python was a way to get MVP out with some of
the maven automation. It's definitely going to be removed in a future
release. Nothing against python - it's just that this is a java project and
I don't want to force java devs to maintain a python dependency as well.
David Holiday
On Tue, Jan 12, 2021 at 10:11 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi David,
>
> Did read the readme and browsed (too quickly this is why i asked) the code
> but i'm not sure currently what I get compared to camel+cdi/openwebbeans
> stack which looks as simple/customizable/flexible and opens the door to k8s
> native integrations (from healthchecks, metrics, tracing to native mode
> with graalvm).
> Any highlights on that? Is the value the python script to help to
> bootstrap? (if so it would be great to not require pythong for java dev but
> maybe java?).
>
> Romain Manni-Bucau
> @rmannibucau <https://urldefense.com/v3/__https://twitter.com/rmannibucau__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1nacjnfGLmV$ > | Blog
> <https://urldefense.com/v3/__https://rmannibucau.metawerx.net/__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1naciL4Ea9y$ > | Old Blog
> <https://urldefense.com/v3/__http://rmannibucau.wordpress.com__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1nackh--Axy$ > | Github
> <https://urldefense.com/v3/__https://github.com/rmannibucau__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1nacugzSxw0$ > | LinkedIn
> <https://urldefense.com/v3/__https://www.linkedin.com/in/rmannibucau__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1nack8x9TbJ$ > | Book
> <https://urldefense.com/v3/__https://www.packtpub.com/application-development/java-ee-8-high-performance__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1nacmg8ISp-$ >
>
>
> Le mar. 12 janv. 2021 à 17:55, David Holiday <da...@holitek.io> a
> écrit :
>
>> Hello fellow Camel riders!
>>
>> I made a thing for Camel that makes it dead simple for teams to quickly
>> build and deploy prod-ready microservices. The MVP can be found on github
>> <https://urldefense.com/v3/__https://github.com/davidholiday/kcar__;!!LdWlNaMnLCM!OUmmU8VA_vpR6RBOuGLXlR5tI5wzEt81sjpd_SZ43IUFVbAcJCrIHnSLz1nackbuvNof$ >. I'm posting here to ask for your
>> thoughts on what works, what doesn't, and whether or not you find it
>> useful.
>>
>> I wrote this because I needed a way to quickly produce Camel services. I
>> needed something that encouraged re-use of service artifacts, didn't rely
>> on Spring, and could scale in a way that gave me the ability to farm out
>> work to other engineers without a lot of 'too many cooks in the same
>> kitchen' bs.
>>
>> I'm sure I'm not the first engineer to have these challenges so definitely
>> curious as to your thoughts not only on the merits of this particular
>> solution, but also your thoughts and experiences in addressing them.
>>
>> cheers (and ty!)
>>
>> David
>>
>
Re: Introducing K-car: a microservice framework for Camel
Posted by David Holiday <da...@holitek.io>.
Hi Ramain
Thanks for giving the thing a look!
In response to your question: while personally I prefer not to use Spring
or CDI there's nothing in K-car that pushes you one way or the other. The
service chassis in the MVP (the ready-bake thing you instance and add
Routes to via properties file) is camel/servlet-only but there are others
planned that will use Spring and other frameworks.
The big idea behind K-car is the deeper integration between Maven and Camel
to the effect of auto-magickally turning Camel elements, routes, chassis,
and services into maven build artifacts that all adhere to a small set of
standards so they automatically play nicely with one another.
In other words, Camel is already very modular but it, alone, doesn't scale
well across an engineering org. Without something like K-car, I, the
Principle Eng, can't decompose whatever wonky business logic the product
team wants into work I can distribute across my dev teams without dealing
with an integration mess at the end of the evolution. A feature and a curse
of Camel is that there are a gazillion different ways to do the same thing.
As such I'm kindof forced to have the same person handle all the routes for
a given service because that's the only way I know for sure that it'll all
play nicely with itself. Moreover, without something like K-car setting a
paradigm for things like namespacing, it's hard to re-use camel artifacts
w/o a lot of cutting, pasting, and snitty re-wiring.
Lastly, K-car does the same thing for deployed services that Maven does for
project structure. For any given K-car service, I don't have to know
anything about a given service to know my way around. This helps enormously
with on-boarding new folks as well as ensuring the teams aren't screwed
when someone leaves. Because everything is standardized down to the element
level, everyone can work on anything in the ecosystem. Yes standards can in
theory be enforced via institutional knowledge but in 20 years of doing
this I've never once seen a shop disciplined enough to maintain standards
w/o the help of frameworks, linters, and automation.
As for python - long term my goal is to replace that with a camel-main
project that runs a full CLI. Python was a way to get MVP out with some of
the maven automation. It's definitely going to be removed in a future
release. Nothing against python - it's just that this is a java project and
I don't want to force java devs to maintain a python dependency as well.
David Holiday
On Tue, Jan 12, 2021 at 10:11 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi David,
>
> Did read the readme and browsed (too quickly this is why i asked) the code
> but i'm not sure currently what I get compared to camel+cdi/openwebbeans
> stack which looks as simple/customizable/flexible and opens the door to k8s
> native integrations (from healthchecks, metrics, tracing to native mode
> with graalvm).
> Any highlights on that? Is the value the python script to help to
> bootstrap? (if so it would be great to not require pythong for java dev but
> maybe java?).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 12 janv. 2021 à 17:55, David Holiday <da...@holitek.io> a
> écrit :
>
>> Hello fellow Camel riders!
>>
>> I made a thing for Camel that makes it dead simple for teams to quickly
>> build and deploy prod-ready microservices. The MVP can be found on github
>> <https://github.com/davidholiday/kcar>. I'm posting here to ask for your
>> thoughts on what works, what doesn't, and whether or not you find it
>> useful.
>>
>> I wrote this because I needed a way to quickly produce Camel services. I
>> needed something that encouraged re-use of service artifacts, didn't rely
>> on Spring, and could scale in a way that gave me the ability to farm out
>> work to other engineers without a lot of 'too many cooks in the same
>> kitchen' bs.
>>
>> I'm sure I'm not the first engineer to have these challenges so definitely
>> curious as to your thoughts not only on the merits of this particular
>> solution, but also your thoughts and experiences in addressing them.
>>
>> cheers (and ty!)
>>
>> David
>>
>
Re: Introducing K-car: a microservice framework for Camel
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi David,
Did read the readme and browsed (too quickly this is why i asked) the code
but i'm not sure currently what I get compared to camel+cdi/openwebbeans
stack which looks as simple/customizable/flexible and opens the door to k8s
native integrations (from healthchecks, metrics, tracing to native mode
with graalvm).
Any highlights on that? Is the value the python script to help to
bootstrap? (if so it would be great to not require pythong for java dev but
maybe java?).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 12 janv. 2021 à 17:55, David Holiday <da...@holitek.io> a
écrit :
> Hello fellow Camel riders!
>
> I made a thing for Camel that makes it dead simple for teams to quickly
> build and deploy prod-ready microservices. The MVP can be found on github
> <https://github.com/davidholiday/kcar>. I'm posting here to ask for your
> thoughts on what works, what doesn't, and whether or not you find it
> useful.
>
> I wrote this because I needed a way to quickly produce Camel services. I
> needed something that encouraged re-use of service artifacts, didn't rely
> on Spring, and could scale in a way that gave me the ability to farm out
> work to other engineers without a lot of 'too many cooks in the same
> kitchen' bs.
>
> I'm sure I'm not the first engineer to have these challenges so definitely
> curious as to your thoughts not only on the merits of this particular
> solution, but also your thoughts and experiences in addressing them.
>
> cheers (and ty!)
>
> David
>