Martin Fowlers’ definition of Microsorvices
Excerpt from this link:
“Microservices” – yet another new term on the crowded streets of software architecture. Although our natural inclination is to pass such things by with a contemptuous glance, this bit of terminology describes a style of software systems that we are finding more and more appealing. We’ve seen many projects use this style in the last few years, and results so far have been positive, so much so that for many of our colleagues this is becoming the default style for building enterprise applications. Sadly, however, there’s not much information that outlines what the microservice style is and how to do it.
In short, the microservice architectural style 
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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
- Microservices – an evolutionary response
- Separation of concerns
- horizontal scaling
- workload partitioning
- virtualization & elasticity
- automated ops,
- on-demand provisioning
- Microservices are an abstraction
- CAP Theorem
- in presence of network partition, one must choose between consistency and availability
- Eventual consistence
- using functionality such as “Cassandra”
- Stateless service
- not a cache or a database
- have frequently accessed metadata
- no instance affinity
- loss of a node is a non-event
- Stateful service
- database and/or cache
- custom applications which hold a large amount of data
- loss of a node is a notable event
- sharded caching across availability zones
Excerpt from this link:
In order to understand what Apache Camel is, you need to understand what Enterprise Integration Patterns are.
Let’s start with what we presumably already know: The Singleton pattern, the Factory pattern, etc; They are merely ways of organizing your solution to the problem, but they are not solutions themselves. These patterns were analyzed and extracted for the rest of us by the Gang of Four, when they published their book: Design Patterns
. They saved some of us tremendous effort in thinking of how to best structure our code.
Much like the Gang of Four, Gregor Hohpe and Bobby Woolf authored the book Enterprise Integration Patterns
(EIP) in which they propose and document a set of new patterns and blueprints
for how we could best
design large component-based systems, where components can be running on the same process or in a different machine.
They basically propose that we structure our system to be message
oriented — where components communicate with each others using messages as inputs and outputs and absolutely nothing else. They show us a complete set of patterns that we may choose from and implement in our different components that will together form the whole system.
So what is Apache Camel?
Apache Camel offers you the interfaces for the EIPs, the base objects, commonly needed implementations, debugging tools, a configuration system, and many other helpers which will save you a ton of time when you want to implement your solution to follow the EIPs.
Take MVC. MVC is pretty simple in theory and we could implement it without any framework help. But good MVC frameworks provide us with the structure ready-to-use and have gone the extra mile and thought out all the other “side” things you need when you create a large MVC project and that’s why we use them most of the time.
That’s exactly what Apache Camel is for EIPs. It’s a complete production-ready framework for people who want to implement their solution to follow the EIPs.
Microservices with Apache Camel – simple example
Excerpt from link:
“Today I decided to play with Apache Camel
to create some microservices
. I know, microservices are the hot stuff right now, but usually one builds them with hot technology too. Like Clojure
. Anyway, sometimes it’s a good idea to stick with stable and known technology, especially if you are in an enterprise environment with strict rules. Or you want your developers to concentrate on the organisational changes that come with microservices instead of fiddling with new technology.”