fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adi Raju" <adi.r...@confluxtechnologies.com>
Subject RE: Microservices release question
Date Tue, 31 May 2016 05:21:48 GMT
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:mkrantz@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
mkrantz@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 <ashok@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 <mkrantz@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
> > mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org 
> > <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
> >
> --
> Regards,
> Ashok
>
> Sent from mobile device
>


Mime
View raw message