Microservices are a hot topic at present. But microservices is neither a standard or a specific technology. Like REST it is more a set of ideas. So what constitutes a microservices. The best description I have come across yet has been by Martin Fowler ( http://martinfowler.com/articles/microservices.html ).

We can focus down on a number of specific points that are central to the idea of Microservices:

• the creation of small pieces of functionality that can be discretely deployed,
• are connected typically by web APIs often using REST (but also seen using other abstracting protocols)
• can be replaced with minimal dependency issues
• microservices are typically built by small discrete teams usually in the range of 2-12 people (the so called 2 pizza rule)
• services are usually orchestrated by dumb pipes (so publication/subscription strategies are often used, so the intelligence about how and what to do about each event is within the service not the orchestration).
• design approach changes orientation from n-tier (presentation, orchestration/business logic, persistence) which could be described as horizontal separation to vertical separation where partitioning is functional/service centric (which internally may embody the horizontal partitioning but this is secondary and down to how the service delivery team wish to work).
• Search service us running as their own CPU process – typically using container technologies such as Docker, Rocket, Spoon and Drawbridge
• Any orchestration is dumb, the decisions of what to do and when to participate are taken by the service

The small container footprint (making the enforcement of the decoupling with minimal governance) means density of processes can remain high as the overhead compared to full VMs is a lot smaller but also means instantiating clean environments for fresh deployments and testing is very fast. This does not fit so well within many ESB environments such as Oracle’s SOA Suite as the pre-requisites create a substantial footprint that would need to reside within the container for the ESB (RedHat’s JBoss Fuse is one of the few exceptions if you consider the required footprint for Apache Camel for example).

However, some of the microcontainer principles can  be pursued within the larger ESB environments utilising capabilities such as :

• Service Component Architecture (SCA) provides a means to create isolated versions of solutions that can run concurrently. By exploiting proper versioning and version dependency controls you can start pushing out different solution pieces with great ease.
• Exposing composites via we services REST or WSDL based and adopt a more SOI approach to artefacts so don’t tap into DVMs directly use web services to perform the lookups
• Microservice implementations have a number of NFRs characteristics that are not (atleast in my exerpience) often utilised when rich ESB frameworks such as
  • service compensation http://soapatterns.org/design_patterns/compensating_service_transaction
  • standard implementation of Tolerant Reader patterns –   http://servicedesignpatterns.com/WebServiceEvolution/TolerantReader (in conjunction with versioning patterns such as canonical versioning – http://soapatterns.org/design_patterns/canonical_versioning)

These approaches allow you adopt the dumb pipe approach (you don’t want services directly invoking each other except in case of utility services otherwise a lot of inter service dependency will build up). Using a publish & scribe framework or simple service sequencing we should be able to exploit OSB, Weblogic MQ in an Oracle Context and Weblogic as an OSGI container (for discovering technical services). In line with the Microservices ethos it would more than legitimate to build Microservices with other tools and then use an ESB like SOA Suite to provide the technology for weaving the services together.

In a Redhat product set there are more options as the solution footprints are smaller. But you would consider Karaf (OSGi container), Active MQ,and simple uses of Camel to weave microservices together.

With cloud middleware, adopting the goals of microservices will become easier as instantiating fresh environments and deployment approaches will become more akin to those of containers – for example Oracle Integration Cloud Service (ICS) deployment is simply an import of a whole set of configuration and integration process information.

It should be noted that Microservices does fit better with a number of organisational and management approaches, such as:

• dev ops – the build team carry the role of operational support
• product centric rather than project centric life cycles i.e. the team exists as long as the product, rather than existing until all the current funded features are complete
• works for build rather than buy delivery (buy is likely to introduce artefacts too large for a Microservice model).

Each microservice is likely to contain its own copy of data – potentially leading to greater data duplication – therefore data reconciliation checks and management thinking maybe be needed.