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