10 Good Reasons for using Apache Camel to create Microservices

Microservices is an architectural style for distributed applications that is taking over the developer community in high pace. There are tens of blog posts on the net every day, conferences and even books on the topic already.
To contribute to all the buzz around it I've written a post where I gave 10 good reasons why Apache Camel and Fabric8 are great tools for creating microservices applications. If you are interested in microservices topic, the article is published on

Circuit Breaker Pattern in Apache Camel

Camel is very often used in distributed environments for accessing remote resources. Remote services may fail for various reasons and periods. For services that are temporarily unavailable and recoverable after short period of time, a retry strategy may help. But some services can fail or hang for longer period of time making the calling application unresponsive and slow. A good strategy to prevent from cascading failures and exhaustion of critical resources is the Circuit Breaker pattern described by Michael Nygard in the Release It! book.
Circuit Breaker is a stateful pattern that wraps the failure-prone resource and monitors for errors. Initially the Circuit Breaker is in closed state and passes all calls to the wrapped resource. When the failures reaches a certain threshold, the circuit moves to open state where it returns error to the caller without actually calling the wrapped resource. This prevents from overloading the already failing resource. While at this state, we need a mechanism to detect whether the failures are over and start calling the protected resource. This is where the third state called half-open comes into play. This state is reached after a certain time following the last failure. At this state, the calls are passed through to the protected resource, but the result of the call is important. If the call is successful, it is assumed that the protected resource has recovered and the circuit is moved into closed state, and if the call fails, the timeout is reset, and the circuit is moved back to open state where all calls are rejected. Here is the state diagram of Circuit Breaker from Martin Fowler's post:

How Circuit Breaker is implemented in Camel?

Circuit Breaker is available in the latest snapshot version of Camel as a Load balancer policy. Camel Load Balancer already has policies for Round Robin, Random, Failover, etc. and now also CircuiBreaker policy.
Here is an example load balancer that uses Circuit Breaker policy with threshold of 2 errors and halfOpenAfter timeout of 1 second. Notice also that this policy applies only to errors caused by MyCustomException
And here is the same example using Spring XML DSL:

A Docker Maven Plugin for Integration Testing

What is Docker?
Docker is the buzzword that is taking the DevOps world. If you don't know yet what is Docker, be warned, you will find yourself using it one way or another very soon. The rest of this post assumes some basic understanding of Docker, but if you are not familiar with it now, I'm sure you will come back later and read this.
Docker is ideal for integration testing, complex demos of distributed systems or even running production systems. It is an open source software container. You can imagine it as a very lightweight and ultra fast virtual machine.
An example
Inspired by the "Integration testing with Maven and Docker" article and using Docker Java API I've created a simple Docker Maven Plugin that can manage Docker containers. Given a Docker image, the plugin will create a container from it and start it as part of maven build process and stop and remove the container when the build process is finished. If the image is not available locally it will pull it down from the public Docker registry before creating a container from it.

The following integration test in Apache Camel is ignored because it requires a running Redis instance:

To make it pass, we can use docker-maven-plugin with a Redis image and 6379 port accessible for the test:

The plugin will start a Docker container at compile phase that has a running Redis instance and shut it down at post-integration-test phase.
This is a very simple example, but the plugin can support more advanced scenarios with multiple images configured differently and started/stopped at different phases. Enjoy.

Software engineering vs Software consulting

I've seen articles with this topic in the past but have to admit to have never read one. If you have, probably you already know which one is the better profession so stop reading this now. If you are still interested, this is my take on the topic.

Software engineering
Software engineering is great profession. I was engineer in companies in different sizes, from startups with 5 people to organizations with 5K stuff. In general the work load is usually predictable, products to work and roadmaps known well in advance. Technology may change, but usually the company and the team already have experience with specific languages and tools and uses those during the everyday job. There are quiet times where there is nothing to do and say in the standups and there are overwhelming times where you get back and wrist pain from typing code for hours. But overall engineering involves predictable work where you have to ship lot's of code regularly. And if you are lucky enough to work in a normal company, you might be doing agile development with all the rituals and practices, the company may send you to trainings and conferences and even have some days in a month to hack something based on your interest. What else to want form life, isn't it.

Software consulting
Consulting is tough. Depending on the nature of consulting, you might be at different customer every other week or month. Different customers from different industries, each of them with different habits and rituals. There are days and even weeks where you might not write one line of code, and there are days where you have to write code without any tests that goes directly to a production system. No dedicated time to learn new stuff or do hack whatever you want Fridays. Customers pay for getting things done in the way they think is best. Overall lets opportunity to have an impact on the organization or change its culture towards something better. The good side of all this can be summarized with "What doesn't kill you, makes you stronger". There is no training or conference that can teach you new things in such a short time than a real Customer.

Software craftsmanship
I enjoy both professions and try to get most out of them during the different stages of my short career so far. My drive is, regardless of your job title, be a software craftsman first. Being software craftsman is a state of mind, it is your attitude towards the everyday activities at work. Whatever you do, do it well and then be proud of it. Don't blindly follow any old habit or ritual that will make you write "WTF" code. Write well-crafted software that adds real value, and next time make it even better. To find out more about software craftsmanship, join a user group(like LSCC), read a book, and pass the craft on.

Master/Slave Failover for Camel Routes

One way to implement a master/slave failover pattern is to have a cluster of instances of an application where one instance (the master) is currently active and the other instances (the slaves) are on standby, ready to take over whenever the master fails. Some projects provide this kind of master/slave support out of the box:
Creating a failover deployment for Apache Karaf is straight forward: we start two or more Karaf instances and let them point to the same lock (file system or database). Then the first instance that starts gets the lock and becomes the master while the other instances will be waiting to get the lock before starting the bundles. In addition Karaf offers hot standby functionality where some bundles are started even in the salve intances and other bundles wait for to get the lock.

Apache ActiveMQ offers couple of ways for creating master/slave configurations but the simplest is to start two or more instances of ActiveMQ pointing to the same datasource(file or database) where the first broker gets the lock and becomes the master and the second and other brokers become slaves, waiting for the lock. Simple.

What about Camel? How can we have multiple routes (in one or separate containers) where one is the master (in running state) and the other routes are waiting to take over as soon as the master route stops ensuring high availability at route level? There are couple of components providing such a capability and all of the them rely on having some kind of centralized external system used as a lock.

1. Camel Quartz component has clustering support.
- If you are using quartz consumers, in clustered mode, you can have only one of the routes triggered at a time.
- Or if a quartz based CronScheduledRoutePolicy is used, in clustered mode, only one of the routes will be started/stopped.
Both of these options rely on having quartz to be configured with a datasource that is shared among all the routes in the cluster. This usage is not exactly master/slave but will have the same effect at the end.

2. Camel Zookeeper component offers a RoutePolicy that can start/stop routes in master/slave fashion. The first route that gets the lock will be started where the remaining routes will be waiting to get the lock. One advantage of this component is that it can be configured to have more than one master running.

3. Camel JGroups component also has master/slave capability using JGroupsFilters.

4. JBoss Fuse Master component is probably the easiest way to have master/slave setup in a Fuse environment. Internally it relies on Zookeeper's znode capability similarly to zookeeper component above.

5. This is not implemented yet but in theory it is possible to implement a RoutePolicy using ActiveMQ's exclusive consumers feature that provides a distributed lock. Do let me know if you implement this ;)