Adi, I like your approach. So within the core set of microservices, we'd take solution 2 right?
Greets, Myrle *Myrle Krantz* Solutions Architect RɅĐɅЯ, The Mifos Initiative mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> On Tue, May 31, 2016 at 7:21 AM, Adi Raju <adi.r...@confluxtechnologies.com> wrote: > I would expect there would be X number of microservices which are > core/heart of the application which no deployment can do away with. I would > suggest these to be released as a single package/release. > > All other microservices should be optional based on the deployment/end > user requirements. They can be released individually by mentioning the > minimum core dependency version. > > This suggestion would mean multiple projects under apache fineract, but I > feel this is where we are heading by keeping separate repo for each > microservice. > > Regards, > Adi > > -----Original Message----- > From: Myrle Krantz [mailto:mkra...@mifos.org] > Sent: 30 May 2016 23:43 > To: dev@fineract.incubator.apache.org > Subject: Re: Microservices release question > > We should create a docker image and host it on docker hub for small > organisations. These users would install docker, and run a single command > to start the system. They wouldn't even have to download our compiled > source directly; docker does that for you. We would need to figure out how > to make installing a valid certificate for their domain in their docker > image easy. > > The answer to that question for larger organisations who want to take > advantage of the scalability that microservices offer, particularly ones > which wish to adjust the code before deploying it in their environments, > will depend on how we answer the question I started this thread with. > > Greets, > Myrle > > > *Myrle Krantz* > Solutions Architect > RɅĐɅЯ, The Mifos Initiative > mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org < > http://facebook.com/mifos> <http://www.twitter.com/mifos> > > > On Mon, May 30, 2016 at 6:46 PM, Ashok <as...@confluxtechnologies.com> > wrote: > > > Hi Myrle, > > > > Release process looks very interesting and same time highly confusing, > > I am wondering how small organisations or independent implementors > > will understand this process to carry out their implementations > > without much hurdles. > > > > Regards, > > Ashok > > > > On Mon, 30 May 2016 at 7:57 PM, Myrle Krantz <mkra...@mifos.org> wrote: > > > > > Hi Fineract, > > > > > > I'm starting a new thread for a question which Roman asked in the > > multiple > > > repos thread. He asked how we'd like to release if we are dividing > > > our code into microservices. Assuming we want to do clockwork > > > releases, > > there > > > are three major alternatives: > > > > > > 1.) Release each microservice version separately, on its own > > > schedule, > > > 2.) Release a set of microservices as one release which are > > > compatible > > with > > > each other, taking the newest service version from the leafs of the > > > dependency tree, or > > > 3.) Release a set of microservice versions as one release which are > > > compatible with each other, taking the newest service from the root > > > of > > the > > > dependency tree. > > > > > > > > > 2 and 3 probably require a bit more background to understand: > > > Microservices will be dependent on each other. For example all > > > services will depend on the tenant provisioning service, and on the > > > service for managing users and permissions. > > > > > > So let's say you have services A, B, and C in multiple versions > > > which depend on each other like this: > > > > > > Av1 -> {} (no dependencies) > > > Av2 -> {} > > > Av3 -> {} > > > Av4 -> {} > > > > > > Bv1 -> Av1 > > > Bv2 -> oneOf(Av1, Av2) > > > Bv3 -> oneOf(Av2, Av3) > > > Bv4 -> oneOf(Av3, Av4) > > > > > > Service C: depends on B > > > Cv1 -> Bv1 > > > Cv2 -> oneOf(Bv1, Bv2) > > > > > > In solution one, we'd release a new version of A as soon as it was > > > complete, even if none of the other services were updated and still > > > required older versions of A. > > > > > > In solution two, we'd release a source code tar ball containing Cv2, > > > Bv2, and Av2. Even though Av3 and Av4 exists we wouldn't include it > > > in a release until all services were updated to be compatible with it. > > > > > > In solution three we'd release a source code tar ball containing > > > Av4, and Bv4. We wouldn't include any version of C because there > > > would be none which is transitively compatible with the latest > > > version of A. If C is a service which not everyone deploys, this may > be acceptable. > > > > > > What do you guys think? Keep in mind that in Apache the release is > > > a source code release. It's signed and it should include all the > > > source code... > > > > > > Greets, > > > Myrle > > > > > > > > > > > > *Myrle Krantz* > > > Solutions Architect > > > RɅĐɅЯ, The Mifos Initiative > > > mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org > > > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > > > > -- > > Regards, > > Ashok > > > > Sent from mobile device > > > >
