karaf-user 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:28:49 GMT
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.


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

Open Source Architect

View raw message