Generally I think you can achieve your goals with Apache Karaf and a
selection of additional tools like Chef.
To offer and consume services CXF should be enough. You only need to
involve Camel if you need more transports than SOAP and REST.
When you go into the details you will of course see that providing a
full setup of automation and governance will require a lot of additonal
design and
implementation on top of these frameworks.
Make sure you get a partner with good understanding of OSGi so you do
not fall into the typical traps. One thing to look into is semantic
versioning in OSGi.
The maven-bundle-plugin can check changes on your interfaces and tell
you what kind of version bump is required.
Christian
On 15.11.2016 15:47, CodeCola wrote:
*Background:* an international company with a federation model is
transforming into Microservices due to chronic Monolithic pain. Autonomous
teams with quick deployment is highly desirable. In spite of theory,
services are indeed dependent on each other for higher functionality, but
are autonomous (independently developed and deployed). Since this is a
federation model and decentralized control, we cannot impose strict rules -
just like the UN. We have to create a governance framework that will manage
dependencies else due to the multiple versions in production in different
countries, we foresee uncontrollable chaos.
<br/><br/>
*Broad Objective*
The aim is to create a Microservices governance system or framework for
dependency management. It verifies and enforces at design and run time
dependencies on a particular Microservice through a manifest and performs
some checks and balances to verify the service implementations being
offered.
<br/><br/>
*Detailed Goals*
Services will have dependencies between them. Services may be deployed when
the chain of dependencies is satisfied.
We define the concept of "Bundles". While Micro-service architecture defines
services as independently deployable and upgradeable components, however,
since a service is always the combination of one or more feature, they are
referred to as "bundles". A bundle is a set of interfaces that are
functionally bound to the same data domain (not necessarily data store)
Governance Framework Low Level Design
Being independently deployable and upgradable implies that there must be
strict rules that govern the inter-dependency between "bundles".
<br/><br/>
1. All dependencies are explicitly stated in the Bundle's Manifest file.
This allows the Control Center to validate that a Bundle is only deployed
when all its dependencies exist inside the data domain.
2. A bundle exposes the list of interfaces it implements. Each interface is
small and groups methods and models that are related to a single feature of
a bundle. For example, the order service bundle can group transactional
methods inside an interface and viewing the history of transactions in a
separate interface. It could add a new interface to correspond to a new
feature it’s adding. With that approach, it’s easier to manage the
dependencies another service might have on order since it would only point
to one of the interface. This is important since an interface needs to be
supported for 18 months or until no other bundle have a dependency on it.
3. Adding a method to an interface doesn’t break backward compatibility,
however, one should add new features by adding a new interface instead.
4. Changing a model breaks backward compatibility. You can’t keep the same
interface if you change the model.
For example, say inside the interface IOrderTransaction.v1 you expose Order
as an argument to the CalculateTotal method. Later if you then want to
change that model, you need to expose a new CalculateTotal inside a new
interface version, i.e. IOrderTransaction.v2.
At that point, the bundle can decide to implement both IOrderTransaction.v1
and IOrderTransaction.v2. Because of this a service can decide to implement
one or more version of IOrderTransaction. Also, it’s preferred to change the
namespace of an interface instead of changing the name of the interface when
a simple version upgrade is in order, something like IOrderTransaction.v17
5. A bundle that depends on an external service can’t assume it’s always
available. In the manifest file, it must state whether it has a hard
dependency on that external service or a soft dependency.
a. A hard dependency means the service as a whole stops working when the
external dependency isn’t available.
b. A soft dependency means the service can still work, however some
features
are disabled. For example, the order service bundle can still be active even
when the offer service component isn’t available, however when that’s the
case it will not process orders with offers associated with them.
6. Since a new service can be installed while it’s being used, the EcpHost
ensures that components are connected to the appropriate services and it
handles the fact that those endpoints change dynamically. This implies there
is a client and service discovery process that ensures that requests are
routed to the appropriate service endpoint.
7. Environment services are shared globally. Although it’s possible that a
component wants to use a version of a component for its own purpose, in
practice inside the same data center there are cross cutting needs that must
be fulfilled in the same way by all components. They are environment
configuration, encryption, logging, eventing, caching and messaging.
<br/><br/>
I have been reading interesting things about *Apache Karaf and OSGi Bundle*
OSGi Service / OSGi Bundles - containing services / OSGi Versioning and how
OSGi Container enforces this / Implicit Interfaces / OSGi multiple version
support.
<br/><br/>
Apache Karaf Cellar can also manage the Control Center for managing the
installation and lifecyle of a bundle
- Node: a node which has the Host application installed. The control center
tells the container which modules (or bundles) to install.
- Chef: the initial installation of a processing node is managed by Chef.
Upgrade to the Host are also managed by chef.
- Services marketplace / registry: the marketplace where all bundles that
can work with Ecp are exposed. A market can look at it to determine which
bundle it wants to install based on its needs.
<br/><br/>
Could you kindly validate this line of thinking?
Could we achieve all of the above using this toolkit (OSGi, Karaf, Karaf
Cellar and Apache Camel)?
Is there anything you need clarification or I am missing?
Any thoughts / elaborations / comments?
--
View this message in context:
http://karaf.922171.n3.nabble.com/Microservices-governance-for-dependency-management-using-Karaf-tp4048635.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
