++1
> On May 31, 2016, at 1: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
>>
>
