karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CodeCola <prasen...@rogers.com>
Subject Microservices governance for dependency management using Karaf
Date Tue, 15 Nov 2016 14:52:20 GMT
*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.

*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. 

*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".

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.

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.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.

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-tp4048638.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Mime
View raw message