karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Microservices governance for dependency management using Karaf
Date Wed, 16 Nov 2016 12:30:31 GMT
Please do not cross post to different lists. The karaf user list is the 
best place for this question.
karaf dev is meant for discussions around developing on the karaf sources.

Christian

On 15.11.2016 15:52, 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.
>
> *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.


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message