I know the question is very general and the answer is too biased to the scale, scope, type, etc. of the the target system. Hence, actually I want to know what is the pros and cons of using various containers such as spring-boot, single-main, karaf, etc. and also when/why I should to use a container for such a system.
In our previous project my colleagues used apacha-karaf but they had a lot of troubles such as building the project, settings to allow components export jmx, poor documentation, etc. with it. Since the current system is a spring-based application maybe using spring-boot makes more sense. Any thoughts?
The main questions you have to ask is what are your requirements regarding:
How many integration (micro?)services you will have to support?
Will you need to support independent configuration of these services?
Will you need to support independent branching/versioning of these services?
Will you need to have "hot deployment" (i.e. deploying/ updating/ re-configuring one does not inherently affects the operation of the others) of these services?
If the answer is yes to all, then you have two main alternatives:
Go the JBoss Fuse way (RedHat branded version of Apache Karaf). This means that each of your integration (micro)services will be an OSGi bundle in Fuse.
Go with a non OSGi container, but in this case in order to satisfy your requirements you need another layer of managing the life-cycle of your services. E.g. you can take a look at Fabric8 (https://fabric8.io/).
This will mean that you will ideally have one (micro)service per Docker container (instead of a micro-service per OSGi bundle) and Fabric8 will provide you will the Web UI (plus many other tools, like Kubernetes commands, maven commands) to manage the deployment of your service to a Docker container. As a result, a service may be using spring boot/ tomcat, another one may be just a jvm standalone process or another one may be an OSGi bundle running inside Karaf container, deployed inside a docker container. So option (1) can also be deployed to option (2).
Depending what path you follow you have to be savvy with different technologies, e.g.:
Fuse: osgi/ Fuse container, camel, maven, ..
Fabric: your on demand container (e.g. spring-boot/ tomcat, java process, Fuse, python process, scala process etc..), Docker, Kubernetes, Fabric8, OpenShift, maven, ..
Hope this help :-)
I use the java dsl of Camel together and deploy it inside apache-karaf wrapped inside a docker container. The key is to use feature descriptors and a maven repository. Then you can create custom distributions of a camel project which are loaded in your karaf distribution. This means you can work towards a really cool microservice approach where services are deployed as individual docker containers.
The biggest difficult was getting the custom distribution of Karaf working. Once that was done the rest was pretty ok. I don't use spring so can't speak about spring-boot.
Inside Karaf/docker you can deploy hawtio and from hawtio do monitoring, see metrics and do all kinds of other stuff. Karaf also has decanter which has a kibana dashboard and alerting feature.
The answer should totally depend on what container technologies you are most familiar with and what you'd like to do with the Camel application.
I think Spring Boot is best when you'd like to create a MSA application with Camel and you are familiar with Spring already. The good news is that Camel now fully supports Spring Boot: http://camel.apache.org/spring-boot.html
On the other hand, if you have a preference to the classical-style standalone approach Karaf would be a rock-solid option since commercial products like JBoss Fuse (https://developers.redhat.com/products/fuse/overview/) use Karaf as the primary container. Plus, if you are an OSGi lover then no doubt you choose Karaf ;-)
Finally, don't forget that you can also run Camel applications on a JEE application container. Basically you can package them as .war and deploy them to any JEE container, but it should be worth noting that WildFly has an extended integration support for Camel: http://wildfly-extras.github.io/wildfly-camel/ With the WildFly-Camel subsystem you can deploy Camel applications as simple .jar as you do on Karaf.
Actually I have the same question, here is my conclusion:
Karaf
pros:
1. OSGI based, hot deploy and support multiple version.
2. Maven support, can continuously deploy from maven repo.
Cons:
1. Legacy jars are not support OSGI, need to recreate the jars
2. Dependency conflicts are really hell.
3. Split functions into bundles, it will take more time to develop and test.
Spring Boot
pros:
1. Spring is like a glue, can integration different libraries easily.
2. Spring boot make it much easier to startup, develop and test efficiently.
3. Spring boot + docker, will make the deployment much easier in cloud environment
cons:
1. If you want to support multiple version at same time, need double your infra.
So my suggestion is to use camel in Spring boot. My architecture design is like Spring Boot + Camel + Docker + Consul + Registrator
Related
I've seen Spring Boot Rest project that generates WAR then deployed in a tomcat container. I wonder if this is best practice because I've also read that in Spring Boot, the new final executable JAR file contains embedded server solution like Tomcat too?
Now i've seen a related post that talks about Spring Boot supports both ways but none talked about the pros and cons of each.
Can someone point out the best practice for deploying a spring boot rest project?
I'm thinking of dockerizing the JAR containing embedded server but i'm wondering if there's any drawbacks vs deploying WAR to Tomcat?
A general best practice ( from 12 Factor App ) regarding the application environment and dependencies is "Explicitly declare and isolate dependencies".
A twelve-factor app never relies on implicit existence of system-wide
packages
With that in mind one should gravitate more towards using embedded container as part of explicit dependency instead of a requirement that needs to be fulfilled separately.There are multiple choices for embedded container in the jar artifact (like tomcat, jetty, undertow, netty) and their respective configuration is also extensive, so using these in production environment is recommended ( I have used them a lot). However there might be certain times when you would want to create a war instead, for e.g., a war file will be deployable in any full-fledged EE Application server ( Weblogic, Wildfly etc) which might be mandated by your environment. With a war, your number of options in terms of app server increases. Personally for me, spring boot jar with embedded tomcat has been quite effective. With embedded container option what you need is a virtual machine with OS and Java installed and you are good to go.
However there is a special limitation related to JSP as mentioned here in Spring Boot documentaion which explain a good reason why you might need to package as a war but still run as jar.
I have an interesting decision to take for my project.
We use spring boot for our micro services.
The development environment is spring boot wíth tomcat in the embedded mode.
However, I am not sure if there are any advantages/ drawbacks if I choose this way in production too.
The counter argument is to deploy a war in a separate tomcat.
I am not able to think on any buying points for both views
What will be the best choice for a large enterprise production system on cloud(jar/war)?
I saw some recommendations here (but I need more stronger reasons to chosse/ not choose any one): Spring boot embedded container or war file in an external container for production
here are my points to use fat jar for production deployment.
fat jars are simple to build and deploy.
Spring Boot aims to be production ready, by default. This means that
it ships with useful defaults out of the box that may be
overriden, if necessary.
Fat JARs are good for running as the microservices as managing
microservices is already a burden then why one more step to
configure and deployment should be considered.
fat jar can also run as a java service easy to manage by a single command, restart server/jvm can be managed automatically.
Spring boot is Embedded with- Tomcat, Jetty and Undertow so changing
app server for any micro services is not a big deal.
I am new to Spring MVC and I have now come accross tutorials that explain how to deploy your web project as a .jar. My IDE is the Spring Tool Suite. I have always used .war + Apache Tomcat.
Can someone elaborate a bit from the practical point of view why to use .jar instead of .war? Any problems to be aware of?
edit: other answers are welcome too
Spring Boot uses fat JAR packaging where is embeds Servlet container with all dependencies into this single JAR.
If you are using Maven, it uses spring-boot-maven-plugin to package the project.
Practical usage of this approach is simple. Ability to easily run Srvlet based Spring application from command line with externalized properties. Such configuration enables powerfully orchestration possibilities which are often used in modern enterprises in so called Microservices or SOA architecture.
There is group of people out there (including myself) which believe that deploying various WAR files of unrelated applications into single Servlet runtime is not very good idea.
So fat JARs are handy for separate Servlet runtime per application deployment.
About having .jar and Tomcat + .war on the same machine, it is possible and I use this. This may be not cool but I had a .war application running in a tomcat server before the rise up of spring boot. Now my new apps are spring boot apps, and we are migrating our architecture to SOA concept, but we can't change the tire with the moving car. The main application, the WAR is running in a tomcat server and the others (.jar) are self contained ( embedded tomcat ), each one running in a different port. It was the most viable solution available for us by the moment.
I am currently trying to deploy my camel app as a FAB bundle in the Fuse ESB container. I understand that I can install Fab(Fabric-bundle) as a feature on OSGI containers like Karaf or felix and deploy the bundle. I want to know if this feature is available on all OSGI containers as well as other application servers like IBM Websphere(Websphere supports OSGI) or will this tie me up to the Fuse ecosystem.
Will deploying as a WAR or an OSGI bundle be a better approach as the goal is to support as many ESB Containers/Application Servers as possible.
No, this is a specialty of Fuse, for this it'll only work on the FUSE containers. Even Vanilla Karaf doesn't understand FAB (unless it's a standard Karaf feature, with just another name to it)
For usage of Karaf Featurs outside of Karaf you'd need to add the feature resolver and services of Karaf to the other OSGi containers first. Never tried that but might be possible.
I would really like to use SpringSource dm Server, but our customer requires us to run our apps on their application server (Websphere). Is there a way to integrate SpringSource dm Server with other application servers? At least dm Server is build on OSGi, and many other application servers (including Websphere) are based on OSGi as well. Is it possible to run a SpringSource dm Server as a websphere component?
SpringSource dm Server is based on the Eclipse Equinox OSGi framework (and should not be confused with the Spring DM technology, included in dm Server, which can run on Equinox, Apache Felix, and Knopflerfish).
However, embedding dm Server in another application server, such as WebSphere Application Server, based on Equinox would be a non-trivial piece of work. It would be necessary to get both products to use the same version of Equinox, which they currently do not, then modify dm Server to support embedding in the server (e.g. to integrate with the host server's application invocation mechanism, thread pools, and class loading scheme).
If you think this support is important, please raise a requirement (which requires a simple registration) against dm Server.
Spring DM is deployed on a Knoplerfish OSGi implementation.
Websphere is deployed on an Equinox OSGi implmentation.
So the question becomes - are the two interchangeable? They both support R4, so I would say, yes, they are.
The next question would be to check dependencies, particularly with respect to things like HttpServices.
I would say this would be ok, but I think the final proof would be try deploying it. Easiest would be to drop the bundles into a Websphere deployment. You'll need your bundles and whatever spring bundles you're using.
I'm also interested in this topic. Another way of looking at this problem is that you want an application depoyable in both Spring dm server and a traditional app server (Websphere, weblogic, JBoss, ...).
The OSGi containers are embeddable inside non-OSGi applications, so it is theoretically possible to deploy an app to both Spring dm server and the same app + OSGi container to a traditional app server.
Now, as usual, the devil's in the details, including such topics of web development and bridging servlets between the outer app server and the OSGi container.
I do not think that this is really the case ...
see the following link for this: http://apsblog.burtongroup.com/2008/11/websphere-7-osgi.html
But it seems on the other side, that the trend is clear ... there will be a time when OSGI based application can be deployed on Java EE application servers