Micro Services have received a lot of discussion of late. While its easy to argue the exact meaning of the term; its hard to deny there’s a clear movement in the Java ecosystem towards micro services: using smaller, lighter weight and isolated micro service processes instead of putting all your code into monolithic application servers with approaches like DropWizard, Spring Boot and Vert.x. There are lots of benefits of the micro services approach; particularly considering DevOps and the cloud.
Fabric8 is poly app server
On the fabric8 project we’re very application server agnostic; there are lots of pros and cons with using different application servers. The ideal choice often comes down to your requirements and your team’s knowledge and history. Folks tend to prefer to stick with the application servers they know and love (or that their operations folks are happy managing) rather than switching; as all application servers require time to learn.
OSGi is very flexible, modular and standards based; but the modularity has a cost in terms of learning and development time. (OSGi is kinda marmite technology; you tend to either love it or hate it ;). Servlet engines like Tomcat are really simple; but with very limited modularity. Then for those that love JEE there’s WildFly and TomEE.
In the fabric8 project we initially started supporting OSGi for managing things like JBoss Fuse, Apache Karaf, and Apache ServiceMix. If you use version 1.0.x of fabric8 (which is included in JBoss Fuse 6.1) then OSGi is the only application server model supported.
However in 1.1.x we’re working hard on support for Apache Tomcat, Apache TomEE and WildFly as first class citizens in fabric8; so you can pick whichever application server model you and your team prefer; including using a mixture of container types for different services.
Fabric8 1.1.0.Beta5 now supports Java Containers
I’m personally really excited about the new Java Container capability which is now available in version 1.1.0.Beta5 or later of fabric8 which lets you easily provision and manage java based Micro Services.
A Java Container is an alternative to using an application server; its literally using the java process using a classpath and main you specify. So there’s no mandated application server or libraries.
With pretty much all application servers you’re gonna hit class loader issues at some point; with the Java Container in fabric8; its a simple flat class loader that you fully control. Simples! If things work in maven and your tests; they work in the Java Container (*); since its the same classpath – a flat list of jars.
* (provided you don’t include duplicate classes in different jars, where the order of the jars in the classpath can cause issues but thats easy to check for in your build).
The easiest, simplest thing that could possibly work as an application developer is just using a simple flat class loader. i.e. using the java process on the command line like this:
java -cp "lib/*" $MAINCLASS
This then means that each micro service is a separate isolated container (operating system process) with its own class path so its easy to monitor and perform incremental upgrades of dependencies without affecting other containers; this makes version upgrades a breeze.
However the problem with micro services is managing the deployment of all these java processes; starting them, stopping them, managing them, having nice tooling to view whats happening and performing rolling upgrades of changes. Thats where fabric8 comes to help! The easiest way to see is via a demo…
Here’s a screencast I just recorded to show how easy it is to work with any Java project which has a maven build and a Java main function (a static main(String args) function to bootstrap the Java code. I use an off the shelf Apache Camel and Spring example; but really any Java project with an executable jar or main class would do.
For more background on how to use this and how all this works check the documentation on the Java Container and Micro Services in Fabric8