Microservices governance for dependency management using Karaf

[CodeCola <pr...@rogers.com>]

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